My game development demons

March 8, 2010

It’s been now a long time, since I decided to write a certain game and talked a lot about it with friends. However I must confess, now after a few years, I still haven’t managed to finish a game. I wrote a lot of code and both bugs and documentation is so far not the problem. Instead there are a couple of demons that  slow down the process that I would like to introduce to you (you probably know them already):

Efficiency Demon: This one is always in the back of my head. It tries to convince me not to use virtual functions as they are somewhat slower than normal function calls. However this approach makes things a lot more complicated and I spent time to circumvent the usage of “the single most important feature of C++” by using probably less efficient detours. Additionally following strictly the rule: first make it run, then optimize would encourage me to take a deeper look in profilers, which would be definitely a knowledge I wish to possess. There are a couple of nice quotes to this one on the Wikipedia page on program optimization – I guess I am not the only one having this demon.

Engine Demon: Instead of tackling simply completing the game logic/event managing/input handling part, I try to generalize what I just coded and put it into a part that I call “engine”. This “engine” is some kind of container of reusable code that I will most certainly need in the future. The catch is just: I do not yet know what exactly I will be needing in the future. Actually neither whether I need the generalized case nor the specialized I wrote in the first place. There is a very well written article (write-games-not-engines) from Josh Petrie which talks about this one. This demon is sometimes called Premature Generalization.

Beauty Demon: The Beauty Demon is related to the Engine Demon. It makes you want to clean up your mess (a.k.a. code). You just hacked in some features and now you want to polish it a little. So you polish. Then you realize you should add documentation. So you add it (and look at the beautiful caller graphs that Doxygen creates automatically for you). Then you realize that you could create of this feature set a library against which you can link dynamically – oh yeah, this is great, because then you can do this for all the other games you will write and reuse it. Oh, and the build system it got a little messy. How about … Yeah, you get it. You do a lot of things which are actually very useful. However they do not complete your game.

Just-that-feature-and-then-I’m-done Demon: I coded hard. The prototype works. And I am very happy. So I relax and think: Awesome, I’ll be done soon with the whole game and I can finish the rest tomorrow. There is a huge difference between a prototype and putting it into your game. I had a few nice parts, such as an event system and entity management system and so on which worked very well on them selves. But when I actually tried to make a simple game with it, I had to rewrite a lot of it and it was a lot harder than I expected. So unless the code is not in your game don’t think anything is done! (Please note that this is not an argument against writing prototypes – they are very important because you realize what the actual problem is and what kind of difficulties you run into!)

A long time ago, I read this very inspiring article ‘How do I make games?’ A Path to Game Development.When I look back, I must admit, I skipped quite a few steps suggested there. So last week I started to abuse my “engine” to create an Asteroids clone. So far controlling the ship, destroying asteroids and getting killed works, but there are still some areas untouched (menu, game-over screen, etc.). It took me a lot longer than I expected and I currently have a lot of quirks on making things work.

So far it is not efficient, not an engine, not beautiful and there is still a lot of work to be done. But I’ll stay on that rocky road and bring it home.

Thought game development is fun? It is – but getting it done is actually quite hard!


About the View in a Model-View-Controller

February 25, 2010

I recently bought the third edition of the book “Game Coding Complete” from Mike McShaffry (a.k.a. MrMike) et al. which has been very delightful to read so far. I have been reading a few chapters which gave me a new way of looking at game architecture and other things that I was convinced that I already understood them quite well.

One of them is the famously known Design Pattern: the Model-View-Controller. To me, the Model always was the data that is being modified, the Controller takes care of the input (mouse, keyboard, maybe network, …) sent to the application and the View simply displays the data. If you want to improve graphics – you work on the View. You want to update keybindings in your input system – you’ll modify the Controller. Also the Controller keeps track of the player id that tells us which entity is being controlled by the player. Need a new type of vehicle / weapon? – Go to your Model (and of course, add code to the Controller and View to reflect them).

So far so good.

However in this book Mike gives an overview of a game architecture consisting of three basic parts: the Application Layer, the Game Logic and multiple Game Views. The Application layer hides the platform specific from the game and the Game Logic resembles what is going on in the game. The Game Views represent the game from different perspectives e.g. for a human player or a AI agent.

Game Architecture after Mike McShaffry

At first my head tried to map them onto a Model-View-Controller which failed as they resemble completely different things. Especially the description of the Game View gave me a different way of looking at the View in a Model-View-Controller. The Game View does not only display what is going on in the game, instead it also takes care of the input handling. More specific: the Game Views receive all the input events (key presses, etc.) and communicate with the Game Logic over events.

At first this seems a bit awkward concerning to what I wrote further up concerning the View, but giving the view the ability to receive input and send events has some nice properties. For example it might be “easier” to add a split-screen mechanic as each player has its own Game View (remember: we have multiple Game Views!) and also its own keybindings. Also one could imagine having a GameEditView which has completely different abilities than e.g. a HumanGameView. This gives the View more power as it also contains not only the way how you look at things but also how you interact.

Maybe I got it all mixed up, however I think it one shouldn’t be too strict on saying input is clearly handled in the Controller or that the job of a View is drawing only.