Project management: What can go wrong when developing a game?

Communication with industry acquaintances often leads to certain thoughts about what game development should and should not be. Based on such conversations, we have written a short article about possible managerial mistakes when creating games.

But first, I suggest “keeping” one simple thought in mind: writing material about common mistakes is not the most noble occupation. You never know who can have any mistakes. You write about important things, they will laugh, they say, guys, the material is about nothing, everyone knows everything. At the same time, you look into the app store below the hundredth position – and your eyes immediately climb to the forehead.

In other words, let’s remember that banality is a tired truth. And to go further, it would be good to remember about it.

What are the common points that relate, first of all, not to the projects themselves, but to everything that is happening around them? Because of what, instead of hits, we often encounter a prokhodnyak?

1. When developing, there should be no conflicts in the team, but there should be stress

For a project, having stress is better than not having it. But here it is important to understand that it should not be caused by a conflict in the team or fear of punishment. Of course, at certain stages it can have a useful effect, but only in the short term. By itself, it destroys the team, and, as a result, the project.

Conflict in the team is a big problem

The importance of good relations in the team with the advent of free-to-play (games-services) has become an important condition for the well-being of the project itself.

Stress is a positive motivator only when it is associated with concern about the quality of the project, about its fate, about the need to deliver it on time. In a sense, this can be compared to worrying about your own child. Whether he ate, whether he went to bed when he returned from school.

If the team is not worried, then there are three possible options:

• the deadlines are calculated correctly, the team competently distributed the loads and calmly performs the tasks set (utopian version);
• the tasks have already been completed and the project is ready (a mystical option, since we are all working on service games today, the tasks for which end only if the project is closed);
• everyone does not care and most do not even do business, but either watch videos or do not crawl out of correspondence with friends.

There is another option: when everyone seems to care, but the work begins only when the milestone looms somewhere nearby. The key word here is “like”. That is, in fact, no one wants to engage in the project, it is not interesting to the team or its part. And the output is a game far from expectations.

2. You don’t need to hire just anyone, you can’t do a project with just anyone

It is difficult to find professionals, especially if you start from scratch. However, hiring “at least someone” is a bad idea, because these “someone” will either quit or be insufficiently qualified. It is especially important not to hire random people if the team is small. So you need to be patient and try to contact as many people as possible so that the starting team is the best possible.

Make sure the rear is covered

Why are we writing about this? Because we regularly face the opposite situation. Here, for example, is a dialogue in which one of the authors of these lines was a participant.

Developer: Hello! We are a young team of indie developers, we need a unity programmer, we are making a 2d paltformer shooter!

Author: Hello! It is wonderful.

Developer: Does that mean you agree to join us?

Author: No, I’m not a programmer and I don’t understand at all why you’re writing to me)

Developer: Damn, hahaha, no luck. You were in the Unity group.

Author: Where is the connection between a person’s subscription to the Unity group and the ability to program?

Developer: Usually there is one.

And this happens regularly. We are not talking about the fact that some teams hire employees, more based on the name of the offices in which they managed to work, rather than on their real skills and experience.

A team assembled on the principle of “who agrees to such a salary” is unlikely to be able to do something sensible (if it can do anything at all, and will not break up in a couple of weeks or months). However, this is also true if the team is assembled from those who are free, who have nothing to do at the moment. But this is rather typical for large companies that can assemble a team not from the requirements of the project, but in order to occupy good employees with something, for whom there are no tasks at the moment.

3. At the planning stage, first of all, it is important to formulate what kind of game and for whom it is being developed, and not how

Another seemingly banal piece of advice. The funny thing is that everyone agrees with him, but, as a rule, they still act in their own way. As a result, the project starts without a detailed design document, and comes out not in a couple of months, but, at best, in a year.

Plus, there is another point: as soon as the full functionality is determined, it will immediately become clear which toolkit will be better to use.

For example, we decided to make a 3D first-person action game, one of the features of which is the ability to interact with a large number of devices with their own UI. And it immediately becomes clear that the choice here is limited to Unity and Unreal, since both have recently implemented support for such functionality. Etc.

UI created in Unreal 4 Engine

It is clear that planning is the most stressful (and unpleasant) moment at the initial stages of development. However, it needs to be given as much attention as possible, because the final option is what you and your team will be working on in the coming months or years.

Do not forget, it is critically important to understand who the project is being done for. It is clear that this, of course, does not apply to real indie, since such projects are developed “for themselves”, but in all other cases – you, figuratively speaking, should always have your audience in front of your eyes.

4. When coming up with game functionality, features, put a question in front of everyone – why?

To be honest, the question “why” is very useful for life in general, because it works perfectly as an Occam razor (in other words, it cuts off everything superfluous). It also works in game development.

For example, a game designer suggests introducing caravans (or, in extreme cases, “cows”) into the game. The idea itself is nothing. You can immediately imagine a string of camels, which are rhythmically waving their humps, walking through the desert hoof to hoof.

But the timely question “why do we need caravans in the game” (plus, clarifications to it, like what caravans will give the player, what they will give the game, whether they will raise its retention, improve monetization, and so on), dispels this atmospheric picture.

Therefore, it is often better to go from tasks to features at all, rather than vice versa.

5. Love your project and the genre in which you work

Another thing that everyone understands, which, unfortunately, very rarely has at least some shaky connection with reality. A person who dislikes or is indifferent to the genre in which he works (and not just spending hours in it trying to figure out what such games earn) will never make a hit.

A developer can be a real professional, a genius, but if, for example, the magic of match-3 does not work on him, how can he embody it in his game? He (or she), playing, will not understand whether there is pleasure from the process or not.

It’s not necessary to love like that

So how can he say that his game is better than other projects that he doesn’t really appreciate?

6. Believe in your project

It is consonant with the previous thesis, but there is a difference. Without ambition, without confidence (factually conditioned, of course) that your work, your project is worth a lot – you don’t even have to take it. This, by the way, is one of the important tasks of the project manager – to instill in every person working on the game the belief that the game can become a hit. But, again, without love for the genre and the market as a whole, this is only possible in a short-term format.

In other words, you can run around the office with the company flag and shout: “we will tear everyone up,” or you can calmly share with the team your thoughts on why your project is better than the others and what needs to be done to make it really become such.

7. Be critical

In love and faith, it is important not to go to extremes. It often happens that developers simply do not see a shortage in their projects (this is especially true for very small teams whose staff consists of a maximum of three employees). Therefore, again, it is very important to be well-oriented in your genre. A fan of three-dimensional shooters who has passed the last Wolfenstein or Far Cry a couple of times can hardly be proud of having developed an action game in gray corridors.

We have everything.