Romans knew that - part I

If you read this article chances are that you work in the fine industry of creating virtual game-worlds and you are also probably aware of its norms. What is normal is that game projects get slipped, employees get “crunched” and gamers get frustrated about receiving low-quality products.

From the production point of view most problems in the process of developing a game come down to the way workers are being addressed. This series of articles was created to express some opinions about few, most popular approaches applied in this matter.

Let’s start with setting a scene here.  You have your game studio and you’re making a simple game, say… a game about jumping. In this game you eventually need to have a main (jumping) character. What do you do?

In the first approach you do the first thing that comes to your mind – you go to the artist and ask for a character. After that you stop by your animator and ask him to make some animations right after the character is finished. By doing that you are applying a very commanding, micro-managing style where each person is addressed individually with a single (small in scope) task. What is wrong about that?

1. Each of the employees is doing what’s told ASAP, meaning they have no time for anything else including talking to one another! If you go down this road you’ll get hit by many consequences of your team not communicating properly.
2. This approach is laborious for the manager. It requires him to be updated every time when each task is being finished and he needs to reshuffle the plan each time a task is done quicker or slower than expected. Consequently, if a manager isn’t running around all the time people can stop working at all while waiting for further instructions.
3. Most of the people don’t like getting so many instruction every hour. It totally limits their creativity about resolving issues they encounter and shuts out their thinking about what is needed for the game. They stop thinking in categories of making something right, they are rather forced to think in a way of “finishing what is ordered”. That creates loads of demotivation and frustration along with producing an awful amount of unexpected “polishing” tasks afterwards.

If this commanding style is so bad why is it being used? Surprisingly it is quite common to see it in action. It is simply because many managers like to have a direct control over each and every aspect of the game but that does not turn out right if the project involves too many people. 

On the upside I found that this method can be very efficient when used temporarily during the finishing stages of the project.

1. There is no more time for opinions and feature proposals so it is best to reschedule any longer, “let’s-add-this” discussion to right after the initial release.
2. If it is the “polishing” phase, you want it to be kept as concise as possible. It is horrible but sometimes it is better patch it up and ship the product on time than to make it “the right way” but delay the release.  
3. The more hectic and stressful the working environment becomes while closing in on a Gold build the better off you are with a commanding approach. It takes away a lot of pressure from your team if they feel that despite every day’s fuss there is somebody who controls everything and leads everybody towards common goal.

Romans knew that the best way to win the war was to suspend democracy and appoint one man to lead for the duration of a conflict. This is more or less the same thing. Although this approach seems very limited and defective in the long run it is actually the best solution in the right time for any game project.

Note: Remember to appoint somebody who intends to step down after the dust settles! :)