Games are fun – if they weren't we wouldn't bother with them – and for the most part games development is fun too. However, the kind of blog friendly design exploration that people think about when you say "game design" is only a small part of the whole. I sometimes call myself a game designer because I design games every day, but most of the time during those days is spent programming.

Towards the start of a project the programming that needs doing isn't even particularly sexy. That is, most of what you're writing doesn't relate much to the interesting gameplay, doesn't involve any especially clever algorithms and isn't the sort of thing you can get done in a day. Modern approaches to development involving short "sprints" between working prototypes sound appealing, especially to novice programmers, because of the word "short". But in reality there is sometimes a big task that needs doing that you can't meaningfully split up.

So, what I've been (mostly) doing for the last few weeks is writing the core engine code for Knights & Ruffians. I use the word "engine" here because I like it, but really I'm just talking about rather dull basic modules on top of which I will build everything else.

However, there is one aspect of this I felt was worth a quick mention: why is it that I decided to write the entire motion and collision system using only integers (!).

Let me tell you a story. When the original Fantastic Contraption was released I immediately loved it and played it a lot. The first level I didn't solve straight away was Awash. Once I had eventually managed it I decided to link to my solution from my blog. My solution was messy and took a long time to complete, so I asked for suggestions for improvement. One of the responses that I got was interesting. As well as an incremental improvement, the poster pointed out that in fact my solution didn't work! Further investigation revealed that for some players it was fairly fast, for some it was slow and for others it failed outright. I posted our findings to the Fantastic Contraption forum.

What had happened was this: In common with almost every Flash application ever written, Fantastic Contraption was using Flash's built in Number class for its floating point arithmetic. This is a good thing, but one feature of doing so is that the underlying hardware is doing your floating point work for you. As it turns out, not all floating point hardware behaves 100% identically.

So the bottom line is this: if I want my game engine to run 100% identically on everything then I cannot use Numbers at all (except for purely cosmetic things).

Why does this matter? Well, suppose I use some attack which does variable damage to opponents depending on their distance from the centre of the blast. That could give rise to a situation where on my machine a particular enemy dies, but on yours it lives! This can be fixed by adopting a Diablo-II style approach where you allow your client data to drift apart but you then continously attempt to resync-it. However, this is messy and difficult to get right and even Diablo-II sometimes fails (following a period of lag you can suddenly die without warning).

The remaining question is whether the probability isn't way too small to care about. Again, the answer is no. The reason being, collision systems amplify errors very rapidly indeed.

Working with integers in Flash isn't fun since there is no 64-bit integer built-in type. Consequently you have to be very careful of overflows. But for now everything seems to be debugged and working, so more interesting tasks await!