March 2006 Archives

Hotloading was for a while, well a hot, topic in the game development industry. As games progressed from being very simple programs to more of world simulators today the issue of tweaking and how assets are handled became more of an issue. When your data fits on a standard floppy disk it's not that bad, but when you have your system administrator breathing down your neck because your using up a Gigabyte of disk each night things become complicated.

So what's wrong with the "traditional" way of having a group of developers write code, checkin and get latest in isolation? It's been working for several projects, right? So why should we fix something that isn't broken? Well, I could argue that it is broken. I obviously don't know what kind of problems you have at your company, but I know that in the past I've been faced with broken builds and didn't even know that it was a problem until much much later.

Bringing data into your program is always a source of problems. Problems like filesystems, paths and unreliable system calls sound familiar? These problems are not the ones you want to battle with in addition to your unit tests. There is light at the end of the tunnel though. Static data in the executable. We've all done it, quick hardcoded tables inline with the code. Taking it to the next step is simply integrating this into the buildstep and creating these tables from ordinary data, bypassing the filesystem at runtime completely.

This little article will explain how to setup an environment for developing python programs. It will explain the different components and the workflow for developing slightly larger programs in python since the small tutorial ones are pretty much covered and they always (in my opinion) leaves out the really hard stuff.