StepWood Games Development

Our game has been progressing at a very pleasant clip for some time.  Many tweaks to the engine and additions to the capabilities it has as we struggle through the intense process of building a game from scratch have made their way into the code base.  During this process we’ve been testing things mostly on our PCs since that’s where we are developing.  We still generally compile the code for the XBox 360 just to be sure it builds, but beyond that deplying to the console is something that up until now has been done relatively infrequently.

This weekend was one such deployment.  The results were, well, less than outstanding.  We ran into things that worked so slowly we began to wonder if we were coding to a system that could get out of its own way.  Other things, that ran at a decent speed, did so thanks in part to not working as expected at all.  Overall we were comparing a “decent” laptop to an XBox 360, and the laptop didn’t just win, it destroyed the competition.

I for one picture games like Halo 3 and have mental pictures of a system with unlimited horsepower.  Afterall, how could such a game exist or function on the machine without said machine being very speedy indeed.  As it turns out there are several reasons.  To begin with, Microsoft doesn’t want just anybody coding to the metal of the XBox 360.  Indie developers, as we are now called, get XNA and C# in what is called a “managed code environment.”  They give us access to basically everything anyone would need to write a game, but do a good deal of keeping us out of the finer points of managing our own memory usage.

To those out there that are not coders, this may not mean a whole lot.  In English, they took away the need to care about memory management, but at the extremely high cost of imposing upon us something called a garbage collector to do it for us.  Ignoring the details of how a garbage collector works, the high level explanation is that when we are no longer using something it throws it away for us to free memory for later use.  As it turns out, the garbage collector they gave us is geared around tight management of memory and using as little as possible.  The cost of that decision is that the way it works is very heavy and involves throwing the game into a cocked hat while it’s doing it’s thing.

After literally days of work, we have stolen some of the power of that garbage collector back from the system at the high cost of effectively coding our own memory management.  Instead of letting the garbage collector steal our unused objects away from us, we effectively keep references to them forever.  This pattern prevents the garbage collector from caring about them since to it they are still in use.  It’s a careful balance and it adds a good deal of complexity to our code to use our system instead of theirs, but the improvements created by keeping the garbage collector from running all the time out weigh that nicely.  By the time we are done, with any luck, we will be able to run our 2D adventure game on the same hardware as Halo 3 uses without our game plowing through all the resources of that system.  Who knew we’d be pushing the envelope of horsepower on the XBox 360 with our game?  We sure didn’t.