olegloshkin-blog - Tumblr blog

olegloshkin-blog · 6 years ago

Text

Forces et Faiblesses.

Forces:

Bonne capacité d’apprentissage:

Sans être hors du commun, j’ai une capacité d’apprentissage qui me permet de tacler beaucoup de sujets différents, techniques et mathématiques y compris, ce qui est indispensable pour un programmeur.

Cette flexibilité me permet de m’adapter aux difficultés car si un sujet n’est pas clair pour moi, j’ai la capacité de prendre du temps pour le comprendre.

Indépendant:

Bien que je ne puisse pas me passer d’une guidance minime, je suis capable en grande partie de chercher et apprendre par moi-même, autre qualité indispensable pour un programmeur étant donnée la nature changeante de l’informatique.

Laborieux:

Pour peu qu’un sujet m’intéresse, je suis capable de consacrer un temps considérable à une tâche. Plus qu’une capacité de m’épuiser à la tache pendant un ou deux jours, je suis capable de persévérer sur une moyenne durée en manageant mes efforts pour fournir un travail constant.

Organisé:

Préférant planifier, j’ai la capacité à mettre en place des outils me permettant d’améliorer ma productivité, que ce soit avec un agenda, une structure d’équipe ou une documentation.

Flexible:

N’ayant pas d’intérêts chronophages mis à part les jeux vidéo que je tâche de contrôler, je suis capable d’ajuster mon emploi du temps en fonction des nécessités.

Aimant la logique:

La logique étant un outil puissant dans tout domaine, j’ai pris l’habitude d’essayer de l’appliquer dans les limites du possible, la préférant à la sentimentalité.

Cette approche permet donc de garder plus de contrôle sur ma vie et minimiser les aléas.

Il va sans dire qu’apprécier la logique est indispensable dans le métier de programmeur.

Faiblesses:

Perfectionniste:

Bien que ce trait puisse être une force dans certains domaines, pour un programmeur c’en est un très mauvais.

Tout peut être amélioré en programmation et de ce fait, une tâche qui prendrait une journée à accomplir pour un non perfectionniste, peut prendre au perfectionniste plusieurs mois.

Ceci est bien sûr inacceptable dans un contexte de planning avec des deadlines.

Réservé:

N’ayant pas de passion pour les interactions sociales, il est souvent difficile pour moi de m’intégrer dans un groupe et y rester.

Dans une industrie où le travail en équipe est primordial, ce trait de personnalité doit être géré.

Impatient:

En combinant mon aisance d’apprentissage avec ma reclusivité, j’ai pu observer à plusieurs reprises ma tendance à devenir impatient avec les autres.

Encore une fois, dans une industrie où le travail d’équipe est primordial, une telle réaction doit être gérée.

Allergique à l’académisme:

Ayant acquis de mauvaises expériences avec les institutions académiques, je commence toute interaction avec l’académie avec réticence.

Ceci est problématique car l’académie, derrière sa bureaucratie, reste une ressource de connaissance très importante.

Optimiste:

La surestimation de mes capacités et ceux d’autrui, innées ou circonstantielles, a été à de nombreuses reprises la cause d’importants échecs.

Il est important de manager ses ambitions, de se questionner et de demander conseil aux autres pour estimer les capacités.

Indécis:

Bien qu’aimant l’organisation, je l’utilise comme un outil flexible. Ceci permet une meilleure adaptation aux circonstances mais résulte également en un changement fréquent de direction. Ceci a pour effet de déstabiliser sur le court terme et sur le long terme de démoraliser.

Domaines-clés à développer:

Capacité d’estimation:

Être un membre sûr d’une équipe implique une bonne capacité d’estimation, que ce soit l’estimation d’heures de travail nécessaires à l’accomplissement d’une tâche ou l’estimation de ses propres capacités et capacités de ses coéquipiers.

En l’état, toute tâche que j’entreprends a une chance sur trois d’échouer, ce qui est inadmissible.

Persistence:

Bien que je sois laborieux, mon indécision et mon impatience avec les autres et avec l’académie sont des facteurs forts qui sabotent ma motivation.

Bien que je n’aie pas de solution concrète à ce problème, je suis conscient qu’il est nécessaire de le régler.

0 notes

olegloshkin-blog · 6 years ago

Text

First experience developing a game.

Hey there!

I’m Oleg Loshkin, a Game Dev student currently studying Games Programming at the SAE Institute in Geneva. I’ve got a brief background in illustration and after finishing up my current training I intend on studying Entrepreneurship with the goal to become an Entrepreneur in the Swiss video games industry.

For this post I’m going to talk about a recent experience relating to game development which is my first experience in leading a game development team for a 3 months project during the first three weeks, until the stage of having a game prototype which is the stage our team is at during the making of this post.

To give you some context, the SAE Institute is a multimedia private school that offers training in Game Art and Game Programming. I am currently studying in the latter section.

By the end of the first year we are tasked with the creation of a full fledged game that is to be put on Steam and actually sold.

The process begins with people from different sections of the school being put in small teams of three people and two weeks later, the team pitches their idea for the game.

Based on that pitch, half the teams are eliminated and those without a project are to find a place in one of the remaining teams.

One week after that, all teams must showcase a prototype of their game and this is where the scope of this post ends.

Now, this is exactly the kind of experience I needed to acquire considering my aspirations, and so far, the project has taught me a LOT.

I am a pretty introverted person. I have only started to come out of my shell a few years ago, and having to lead a team, organizing people, making or sometimes enforcing decisions, ensuring that things get done on time is quite a deviation from my usual way or doing things.

So let’s start from the beginning: the game’s pitch.

Since I wanted to make the most of this experience, I’ve ended up being the one to take the leading role in our small initial team, and we ended up going with my suggestion for the game’s base idea: a platformer where you play a dinosaur heroine that chews chewing gum. That was the base idea.

From there on we started developing that basic idea and… we went waaaaay too far with it.

By the end of the first week we had “plans”, if you can call it that, to make a platformer meets an RPG that meets a brawler with waaaaaay too many features and gameplay mechanics that we would never have the time to implement in just three months. We were just excited to make a cool new game and just didn’t have the experience to realize that the ambition was set way too high.

Thankfully, we had access to some professional, heart blending yet true feedback in the shape of our Game Programming teacher who during our first meeting with him promptly destroyed all these exceedingly high expectations.

When you’re that invested in a project, even if you get ready for it, it always hurts to hear people point out the obvious flaws in your project, and the worst part is that when the feedback is true, you really don’t have the easy resort of just saying “That person’s doesn’t know what they’re talking about, I’m right, I’m gonna do things my way!”.

You’ve got no other choice other than suck it up and do what is necessary to address the issues even if it means abandoning aspects of the project you were really looking forwards to.

So by the end of the first two weeks, instead of a huge orgy of features of a game, we were left with a simple, yet doable project: a platformer where you play around with a chewing gum as a toy. No overly complicated story, no excessive amount of irrelevant characters and a simple and concise gameplay.

Then comes the pitching session. It might be an odd idea for players but for game developers, the pitch of a game is one of the most crucial elements of a game: this is the sole element that determines whether a game will exist or will disappear.

No Man’s Sky has demonstrated this idea perfectly: what has driven the project’s development wasn’t the mechanics or the gameplay footage nor was it the company working on the game.

The game gained it’s hype through it’s pitching, so much so that when the actual game came out, people were disappointed to discover the shortfalls of the project, having built up an amazing idea of the game in their mind only to discover that in reality, game development is much harder than just making promises.

Needless to say, keeping all that in mind put on me quite a pressure: whether the project lived or died relied on my performance in front of the jury. By the end of the pitching session, only half the projects would be kept alive, and considering the projects of other teams, there were quite a competition.

I had done writing the presentation the day before and just barely had my speech down. Leading up to our team’s turn I was on edge and the speech kept flying out of my mind.

Once it was our team’s turn, I walked out in front of the class with the mental state similar to getting ready to get hit by a truck. Yet once the presentation started, under the effect of the adrenaline (and Xanax I had taken earlier), everything just came back up whenever I needed it.

I went though the presentation smoothly, and while I didn’t perform the presentation with the eloquence of a Hollywood actor, I didn’t mess up the presentation by standing in front of the class like a deer on a highway in front of a car as I feared I would.

A few stressful hours later, the results were announced: we were not eliminated!

My reaction to these news was in hindsight quite funny:

“Oh sweet we’re not eliminated, wooahoo!”

”...”

”Wait. Oh no. We’re not eliminated, that means I’ll have to be the lead on this project for over two more months!”

As satisfying as the temporary victory was, the stress leading up to this moment had taken quite a toll on me.

But for now, I had no time to process any of it as everyone moved on to a session of brief interviews where the members of the eliminated teams had the occasion to talk with those that were left, suggest their candidature and get the team’s mails to later get into contact with them.

A brief note before I move on with the recruiting segment of the project’s timeline:

There were quite some talented artists that worked on the presentations of the other teams. There was a team for instance with gorgeous artistic direction showcased during the presentation, a team that has been eliminated to everyone’s surprise.

The team had by far the best visual presentation of their project, but they were nonetheless eliminated: The presentation wasn’t timed well.

While it was very clear, it was just way too long, and by the end of the five minutes they had to show off their project, there was still a lot of the presentation to be done with key elements like marketing. The team just didn’t have the time to say everything they wanted.

As a result, the jury just wasn’t able to attribute any consideration to various aspects of the project and therefore eliminated the team to everyone’s surprise.

This is a very good example of the importance of the pitch: if the team had the time to complete their presentation, they’d certainly be amongst the confirmed projects.

But back to recruiting. One thing that quickly became obvious to me over the recruitment period that lasted a few days is that you shouldn’t be asking for very specific roles when recruiting. We were looking for an Environment Artist, a Game Designer, a Games Programmer and a Technical Game Designer.

However, as people started joining the team, different configurations of roles would make more sense than others, so much so that an artist that initially proposed their candidature for the post Environment Artist ended up being a Character Artist.

Depending on the people you “hire”, the dynamics of the team changes and the roles of the different people in your team need to be switched around, so it is much better to just ask for “an artist” or “a programmer” rather than for a very specific role.

As we started to work together as a team of 8 people, things got much more difficult.

We have pretty much been accepting every candidature sent our way and in the end we’ve ended up with people of very different skills, very different schedules, very different work styles and different habits of communication.

As a result, in order to allow everyone to work as a team properly, as a manager I had to put a lot of effort into tracking everyone’s availabilities and progress, and I had to spend a lot of time just keeping everyone up to date with the project’s current state. In itself that isn’t particularly problematic.

In the end however, if working in a team with four people working at 25% yields a 100% total performance, producing the same effort in a team with two people working at 50% instead would yield more than 100% total performance.

A smaller team means that communication is much easier, there’s much less need to get everyone’s agreement to take a decision and you’re less likely to have to wait for a coworker you need to talk with to show up for work . All these factors mean that the same effort would produce more total progress since more of the effort is spent on the actual work and less on communication.

For these reasons, it is better to hire a few invested people rather than a lot of average people.

This situation, with way too many cooks cooking the broth has been worsened by an organization problem. Prior to having multiple Game Programmers in the team, I was the only one coding. Once the new teammates have arrived, I had been already concentrating on management rather than on code but the system I had laid down for the Game Programmers was way too complex and not documented enough for them to use it properly.

As a result, over the next week of the project the feature implementation followed the same bad pattern: I’d ask for a feature to be implemented. The feature would be done completely detached from the system that I had laid down. I would discard the work done by the programmers and redo the code myself integrated in the system.

This has led to a lot of frustration from both sides. The programmers were discouraged by constantly getting their efforts thrown into the bin and I was frustrated from feeling like I had to do the work my coworkers were supposed to be doing all the while exhausting myself and not leaving me any time to live a life.

This completely killed communication during a few days leading to the release of the prototype as I had no more time available to do my manager’s duties.

In the end however, we’ve successfully showcased our prototype, and whilst we have gotten a fair bit of negative feedback, we’ve also received some good ones.

From there on we’re currently rethinking the way our team is organized to remedy the problematic situation and so far things are going much better.

In conclusion, the start of this project has already taught me a whole lot and my general disposition as a project lead has changed. I have become more exigent, am going straight to the point and am much empathetic towards my teammates.

#gamedev

1 note · View note