DevBlog > article
No nice picture and no dreamlike music here. If you are looking for the story, the atmosphere or the universe of the game: pass by. Here, we talk about code, architecture (the game’s one, not the world’s one) and functionality.
OK, are the curious gone? Now that we are between ourselves, we can start.
First, I’m going to address the role of the programmer, his constraints, his difficulties, his suffering… most of them due to graphic, level and sound designers, among others.
The programmer has to centralise the other project participants’ requests. For the game and the editor’s features, he has to find the best and simplest possible solution. Since he doesn’t have enough time to address all the requests, it’s important to assess their significance. The first difficulty is to make a clear distinction between real needs and simple envy.
The team (yes, I lump the whole team together) doesn’t really realise the technical limitations and is able to ask for a feature that need 6 months of work with the same confidence than for a 3-hours one. They’re not afraid to ask for something that would need a NASA’s computer from 2020 to be developed but they hesitate to produce assets that can be run on the first Game Boy. But we doesn’t have to go to the opposite extreme by refusing everything that doesn’t seems important at the risk of breaking their creativity and the game identity.
The most efficient sorting technique -according to me- is the “Triple NO”. It’s quite easy: each time somebody asks you for something a bit complicated, you just answer “NO”, so you have time to think about a potential technical solution. Anyway, if the request is important, the person will try again. Repeat the operation thrice to be sure it’s really important. Then, you have two options:
- or you have a solution and you can add it to the production schedule,
- or you don’t have any solution. If so, you have the agonizing and hard job to explain your mate that isn’t possible, even if you’ve understood how important it’s for him.
We got to know that a programmer is continuously called out and therefore has to be everywhere. People call you for the slightest problem, several times a day. It happened to me to explain 5 times the same thing to the same person during the same day (He was tired, Ok).
Figure 1: Programmer’s daily moving
Note that this isn’t representative of our team. I spend much more time with the level-designers.
This essentially summarises (almost exactly) the programmer’s routine.