Tales from the front line

[Byron]

In every project there is always one file that strikes fear into the hearts of all programmers everywhere. These files are usually full of code that could render a battle-hardy coder to complete gibbering tears within seconds and that is just for looking at it – if they have to make changes to the file then they usually make their farewell calls to their loved ones, have a swift drink of something to bolster their courage and run into the battlefield screaming as they go. Somewhere in the world is an honour monument to those who fell.

Today it’s my turn. When I joined the Multiwinia team I was told mythic tales of this particular file and like a fool I sat back in my mis-guided confidence and boldly said ‘it can’t be that bad’. Around me I could see the looks on my fellow coders faces that said they felt sorry for my wife, as I was not long for this world. They shook their heads in sorrow and patted me on my back while in the corner a coder was shaking and sobbing every now and then – I was to learn later that he was actually in the file and desperately trying to call in the support copters to get him out ASAP. There’s not much help the others can give him – he just has to brave it out and hope he lives to tell the stories over the campfire while he sips his well earned beer and not forgetting to take the sedatives the doctor game him to calm his nerves.

Even mentioning the name of this file is a curse so brace yourselves:

Game_menu.cpp

Still there? Check those dark corners you never know if its there waiting to pounce out on you!

Game_menu.cpp isn’t a large file, it’s the Cthulhu of all code files. It currently weighs in at 9765 lines of C++ code and lots of classes. Unlike a lot of Cthulhu files the code in this one is not bad code, there’s just a lot of it and a few of those classes don’t take prisoners. Why is this file so large you might ask? The answer is simple – evolution. Early on in a game project decisions are made as to the route you may go down in order to achieve a working solution to a known problem, in this case it’s the game menu system, or the bunch of buttons you have to wade through in order to play the game. It’s not always easy to see all of the consequences that seemingly simple decisions makes down the line. In previous companies some of the designers used to make small off-hand requests for a feature that results in 2000+ lines of code and when it was finished they decided they hated anyway. Game_menu.cpp has a really good concept at its heart and had to evolve that concept in order to cope with the demands of Multiwinia. Unless you have lots of time on your hands and also a lot of money most games companies do the smart thing and re-use code. This means that as a coder it’s your job to go through some really ancient (2 weeks old) code and re-factor it so that it does the new job at hand. In Multiwinia it meant bolting on the new menu layout and all the UI code to handle the multiplayer aspect. The end result is a beautiful swan on the outside and a pair of ugly feet paddling like crazy under the surface. That’s our job though – make the ugly bits so that they can power the pretty bits for you the player.

UI in games is usually one of the most hated areas of code and given to the juniors to do because nobody else wants to do it. I always feel that this is a stupid reaction to what has to be one of the most important features of your game, for instance, can you think of any game you played that made it so difficult for you to actually get to the game because of an un-intuitive UI flow that you actually considered or indeed did give up on the game? I know I have. A prime example of this is the online multiplayer section of Halo 3, which is too painful for words when you first encounter it (well, I thought so anyway). The real reason it’s hated though is that anybody can have an opinion on the UI and during the development process if one person hates it then it usually leads to a re-design which in most cases means a re-code too (sorry, these days we call that a re-factor).

The reason I have to brave into the murky realms of Game_menu.cpp is that I am now working on putting a spectator mode into Multiwinia. What this means is that like Defcon if you join a full game then chances are if you really want to and the host lets you – you can watch the game. This is also useful for tournaments so that we can set up the host computer to be a spectator only and judge who the winner really was. This is where coding gets to be fun as to do this I pretty much need to know how the whole UI, gameplay and networking systems interact with each other and more importantly how not to screw it up. It’s a great responsibility doing this type of modification as it goes straight to the core of the whole Multiwinia experience and if I check in dodgy code right now it means anybody who does an update will either have to roll-back to a known working version or take a break until I fix it. I’ll let you know how I get on.

[djspiewak]

Have you heard of it?

Seriously though, you don't have to put all that code in a single file. Especially if it's a .cpp and not a header, it's almost trivial to split that up and make it easier to manage. Might I suggest a subdirectory and a slightly modified makefile?

[barabanus]

Seriously though, you don't have to put all that code in a single file. Especially if it's a .cpp and not a header, it's almost trivial to split that up and make it easier to manage. Might I suggest a subdirectory and a slightly modified makefile?

That doesn't solve the problem - namely it's small classes with magic interactions between them.
Imagine store-room with a lot of stuff. You can put this stuff in one large box or many small boxes with labels. The latter might make easy access to stuff, no more than.

I used to be junior programmer to handle UI =)

[shinygerbil]

Let me just say "Yay!" but for several reasons I will not say what I'm referring to here.

Jelco

I think you just gave it away. D'oh!


And Byron, I wonder if you've ever looked at the code for Uplink? Anyone around here who has the Dev CD will know what I mean

[Rkiver]

That's how I learnt to code, from Uplink's DevCD.

Wonder what the code to Darwinia and Multiwinia looks like compared to it?

[Pox]

Interesting post, offers a bit of insight into Introversion, which I always love.

I also have some portions of various applications I (or others at the company) have written that are very, very annoying to mess with, especially when whoever had written the code originally (not me, never!) had made it next to impossible to make a small change without making manual, non-automatable (is that a word?) changes to tens of subroutines... and everything we do is fairly simple stuff really, I can't imagine database-driven statistics/accounting or gluing-ancient-software-to-other-ancient-software could possibly be as messy as a game could get.

Also, spectator mode coming. Wahee!

[zach]

Hmm - To be honest, I started out having my entire projects in single files. Turned out to be the wrong way to do it pretty quickly, now they weigh in at approximately two files (source and header) per class, and (at least) two files for wrapping.

At least you're not handling bad code, just a lot of decent stuff.

[Byron]

**** NEWS FLASH ****

In what can only be described as a unique event in gaming history a cross-over event took place between Introversion's Defcon and their up-coming game Multiwinia. A stray Nuclear missile managed to break free of the confines of the Defcon map and strike into the heart of the Game_menu.cpp source code. Reports are coming in still but early accounts tell of many casualties and at least 60 splinter fragments of what used to be Game_menu.cpp. It would appear that in the panic of the early warning siren a lot of the classes inside Game_menu.cpp ran for the hills and set up their own files in order to escape the on-coming storm. What remains of Game_menu.cpp has yet to be ascertained.

Stay tuned for more news as we get it in.

[Pox]

Refactor alert! Refactor alert!

Also, 60? That's a lot of classes. Have fun dealing with the diaspora.

[prophile]

I have a file called utils.cpp which has a giant ghostbusters logo in ASCII art in comments at the top.

[brog]

The real reason it’s hated though is that anybody can have an opinion on the UI and during the development process if one person hates it then it usually leads to a re-design which in most cases means a re-code too (sorry, these days we call that a re-factor).

I don't think this is the real reason it's hated. I cringe whenever I have to delve into my UI code, and it's reasonably well-written (compared to my previous attempts at least), and this is completely a one-man project. There's just something about UI that simply isn't nice.

This game doesn't really have a file-of-doom; gui.cpp is the closest thing but as I said, it's really not that bad. I've learnt my lessons. A previous game of mine though had the legendary "monsters.cpp" which is some 3500 lines long, most of which is a single 2956-line function "move_monsters" which loops through a crude homebrew data structure, and then has an enormous switch statement which contains all the behaviour for every enemy in the game, including bosses (bosses being the worst because they're a single "boss" enemy type, which then switches over the level number to see which particular boss it is and then over its current state). It's full of magic numbers and complicated state machines and is pretty horrific to look at. Basically at the time I had no idea how to use inheritance and the code just sort of grew with no design in mind.
This file got passed around my friends a bit and it took a while to live it down.

[Byron]

There's just something about UI that simply isn't nice..

That raises an interesting point. If you are a coder is there one aspect of coding that you hate? Or is it all code and therefore goodness??

[brog]

That raises an interesting point. If you are a coder is there one aspect of coding that you hate? Or is it all code and therefore goodness??

I don't particularly like code that's dealing closely with the OS or hardware. Low-level graphics code, audio, networking. Some people really get into this stuff, I don't so much. It's not the bane of my existence, sometimes it can even be fun, but I much prefer things like implementing gameplay or complicated mathematical algorithms.
But I don't think anybody really loves UI code.

[prophile]

My particular hate is input. Graphics and audio and AI I love doing, because they're brainpower-intensive and you can get great results, networking is a lot of work but very interesting, good resource management and the low-level stuff really tests your ability as a programmer (and I love a challenge), and UI I don't worry much about because I have that done in a scripting engine and configuration files which make it relatively easy to change. But input? Ugly, boring, hard to get right, difficult to debug, confusing to refactor, horrible to separate out from the graphics context, etc, etc. Hate hate hate.

[Phelanpt]

I think the reason most programmers don't like UI code, or input code, like prophile mentioned, is because it is mostly full of repetition, and the tiniest thing might create a hard to find bug.
There usually isn't much room for creative programming, only creative design.