Another day, another late blog post. I probably owe other Gaslampers some kind of savory pastry or something. Maybe a delicious soy-based iced confection? I don’t know.
Most of my day was spent putting together the finishing touches on the accompanying source code for my Game Developer Magazine article. (Yes, I’m pimping the article again. If you like it, tell the good folks at Game Developer to keep the hits rolling.) I spent five hours fixing a race condition, which is ironic because the article is about how to *avoid* race conditions. I still managed to create one in the code for the message-passing architecture mentioned in the article, and it’s taken me a good long time to figure out what the heck was causing it. Hopefully my learning experience will save somebody else – maybe one of you! – some trouble down the road.
As an independent developer, you want to be looking at things like my article’s source code for things that you can easily… ah, lift … for your own projects. I’ll admit it: without utility libraries like the Simple DirectMedia Layer (SDL) and libexpat, there wouldn’t *be* a Dungeons of Dredmor. I would still be spending my time trying to write XML parsers. Thanks to other people’s efforts, I was able to stop writing code for things that other people have already written code for, better than I can, and was able to get on with the work of making a video game. If you’re not building a video game by slapping other people’s code together at high velocity, you’re not an independent game developer; you’re some guy writing his own XML parser. Our next project uses… ah, several libraries: SDL, OpenAL and OpenGL, libexpat, Freetype, Boost, PhysFS, the Bullet physics library, and also has Ruby embedded in it as a scripting language. (For now, anyhow. This is going to change, and the reason WHY this is going to change is going to become a new blog post next week.) We also have a fair amount of code in there that has been cribbed from John Ratcliff’s Code Suppository; the Code Suppository is the place to go when you desperately need some small routine to do a thing, and really don’t have the time, the energy, or the technical know-how to sit down and write it without spending three weeks on it. (Dredmor uses the template-based A* pathfinding implementation that is provided there.)
You may notice some common libraries shared between these two projects. This is because once I find a solution for a software engineering problem that works, I tend to stick with it… at least, until it stops working. For instance, you may notice that Dredmor and The Next Project both use libexpat. This is because I have a nice set of Expat-based XML managing routines that I cribbed in 2002 from Thomas Tong back when I was working at Furious Entertainment, an ill-fated startup in Vancouver doing a Playstation 2 game for the mighty Ubisoft. Thomas now makes software for 3D scanners, and I bet he’s still using a variation on that same XML loading code. We all have some crib sheets for routines that we keep coming back to. Some stuff you use on one project, and then the next time you start a project and need to fill that hole – you go back to the last project you did and you figure out what worked last time. Maybe you lift it verbatim; maybe you reflect upon what didn’t work out so well last time and come up with a new way of making it work.
I have a few tools that I tend to use all over the place. One of my favourite tools is boost::any<>, the handy little storage container that could. Whenever I need to pass messages, or store data in a generic container, and I have no idea what sort of messages I’ll be sending or what I’ll be doing, it’s time to reach for boost::any<>. It’s a handy solution for a common problem. I may actually over-use it in places, and I need to start thinking about the consequences of using a hammer when I see something that looks, at a distance, like it might be a nail. (Interestingly, Dredmor does not use boost::any<>; I guess I just never saw the need. Then again, most of Dredmor’s software engineering is pretty dodgy.)
The toolkit we use for handling factory method creation in Dredmor is based on a couple of chunks of code that I wrote many, many years ago, back in 2002. It was then lifted from the first version of the Next Project for Dredmor. It has a number of flaws, mainly that the factory methods are hard-coded to support one, and only one, hierarchy. This wasn’t good enough for the Next Project, which uses factories to solve a number of problems in the networking system, the UI code and the level editor. Consequently, the current factory method template that I am using for all future work is based on an article in the Conversations column by Herb Sutter that I read in the C/C++ User’s Journal many, many years ago. (The Conversations column started off as an effort to combine handy coding tips with Sutter’s attempt at science fiction, and they got rid of the science-fiction aspects of it after a year.) Over time, I have modified it to suit my own style, and I think it picked up a few pieces of something else along the way. It’s something I should re-examine before I use it again in anything, and it’s something that I should re-examine in those luxurious few weeks before real game development starts where you get to sit down and look at your toolchain.
Some code from the failed game that we didn’t finish ended up making its way into Dredmor. Our first project at Gaslamp needed a set of routines to convert RGB colors to an HSV color mode, and then back again. These found new life in Dredmor when it came time to tint our “monstrous commander” sprites.
Don’t think that because we use other people’s libraries, our games contain very little original code. Dredmor’s source tree contains approximately 45,000 (forty five *thousand*) lines of source code. The next project contains closer to fifty thousand lines of source code, and it doesn’t even do anything yet. My point is this: as an independent game developer, you don’t have time to go write everything from scratch. Your goal is simple: ship a game. You don’t have time for not-invented-here syndrome. Figure out what technology pieces you have to provide yourself, and figure out what technology pieces you should look elsewhere for. Hopefully, you will find time to contribute something interesting and useful back to the community so that other people have an easier time.
I’ve let you look at a few of my secrets. What’s in your toolbox?
