Rewriting Aril
April 4, 2013, written by Maxim Aril, Game Development, Technical

Currently we are in the process of rewriting the code for Aril. This sounds counter intuitive seeing as we’ve already worked on it for more than half a year. But I will try to explain why this is not a waste of time and why in fact it is a very smart move to make.

There are several reasons for us to rewrite Aril. The first one is that between the time we started programming Aril and right now, we’ve learned a shit ton about programming and project management in general. As it turns out the initial structure of our code and the way we’d organised it had turned into quite a mess. At the university I took a course on design patterns (a way to structurise code) and I realised we’d written some really terrible code. We could either put a lot of time and effort into refactoring the current code, or we could start with a clean slate and build it up all neat and pretty without having to deal with old garbage.

The second reason would be because we got really sick and tired of C++ (as can be read in my blog post about Programming Language Elitism). Right now we’re writing in C# using the Monogame Engine. Monogame is an opensource cross-platform implementation of Microsoft’s own XNA game library. It allows us to write the game in a nice language (C# is sooo much more forgiving that C++ ^^) and, if everything’s well, we’ll be able to instantly port the game to Mac, Linux and maybe even iOS and Android! Sounds pretty amazing rite? The old C++ code could not be instantly ported to C# of course so we’ve been busy rewriting all the language specific code. But a lot of the pure logical game code could be copied almost to the letter. For instance the code that made the Sentinels wiggle was purely logical code, this allowed us to copy it right into the Sentinel object and voila, the Sentinels we’re all wiggly jiggly again.

The third and final reason ties in very neatly with reason 1 and 2. The truth is, I am very very afraid of end project code. What often happens is that you’ve just finished/abandoned a project in which the code in the end was a complete mess, so you promise yourself the next project is going to be the pinnacle of clean and neat and awesome code. This usually holds up for about 2 to 3 weeks and than you realise there’s time pressure and people want to see features and the things you have to make are really simple and little and nothing (nothing!) can go wrong if you just hack this little feature right into your code. These temptations build up and then half a year later you’re stuck with another stinky pile of garbage code that haunts your dreams and makes you wake up in the middle of the night screaming and sweating and… I think you get the picture.

Therefore I’ve come up with an idea that might save us from these terrors. I’m not sure if it’ll work and we’ll thoroughly test it out with the next project. The idea is that we test out all the game’s features and ideas in prototypes. We’ll quickly and efficiently test out all the gameplay and ideas and see what makes the game work and what doesn’t. This will also allow us to test out code ideas and give us a general feel of how the code should be setup for the final project. Then, when we’re sure we’ve got everything down, we enter a new phase where the artists and musicians and stuff make the bulk of the content, while we, the programmers, rewrite the game from scratch. As long as we know of every feature we want to have in the game before we start writing the code we’ll be capable of writing everything around these ideas as apposed to patching half of ‘em in somewhere down the road.

I dream of a game with neat, readable, pretty and (dare I say it?) bug free code. Let’s see how close we can get!