We’re getting into bunker mode here, and bunker mode means that we shut up and program. Programming soundtracks are infinitely variable, but everybody tends to have one. For Dredmor, 50% of the programming was done while drinking coffee and listening to Rhapsody albums. Rhapsody is a largely insane European power metal band who mainly sing about unicorns, swords of magic, and dwarven economic practices. Christopher Lee was on their last album. It’s a reasonably intense experience, and a certain amount of silliness from the albums has transfused itself into Dredmor like some kind of musical background radiation.

Everybody has crunch mode stories. One of my favourite ones in my experience was several years ago – back in 2001 – when I was trying to ship a first person shooter using The Goddamned Lithtech Engine. Lithtech Talon, back then, was not known for its robustness, and most of my job description involved taping bits of it back together in order to get things shipping on time. One last problem we had before shipping our demo was that certain objects were suffering from z-fighting with the wall. Depth buffer precision issues are notoriously hard to fix, so I decided that the easiest thing to do – given that this was a last minute fix – was to tag the offending models (which were lights, or something) and give them a little depth bias in order to stop them from fighting with the walls. With that done, and a few more bugs taken care of, I crashed on the company couch in case I was needed later.

Three hours later, I was woken up: QA had gotten the build of the demo, gone through it, and wanted to know why there were vases floating through walls. It turns out that the depth buffer bias had been cranked… a little too high at the last minute, and on some of the wrong things. It still took me fifteen minutes for my brain to figure out how that was even possible.

I hope to have something a little more insightful for you next week. Until then…

It’s that time of year again, when students everywhere (well, everywhere on a semester schedule at least) undergo the long and grueling process of ingesting dangerous amounts of caffeine and overloading their short term memory capacity.

As one of these barely human coffee zombies, I am nearly free of the clutches of final examinations, but since Nicholas is also somewhat tied to the chains of academia, we’ve been forced to put development on hiatus until Monday.

Fear not, though! A bunker session the likes of which Gaslamp has never seen is slated for just the next day! I understand coffee and instant noodles are being stockpiled in the workplace of choice, and we are destined to either never emerge from our self-imposed programming exile, or we will shamble out of our dimly lit and stagnant bunker to bring to light something odd, fun, and addictive in video game form.

I really should be talking more about the programming decisions in Dredmor, but for the most part the programming decisions in Dredmor are uninteresting. There are a few little bits of cleverness lurking under the hood – there’s some good stuff in the map generation system, and some good stuff in the load/save system – but for the most part, Dredmor’s programming isn’t particularily sophisticated or challenging. Instead, I’d like to talk about some technology decisions that didn’t work out.

In the engine that we’re putting together for the next game that we’re making, and for the game that we tried to make before deciding to finish Dredmor, we found ourselves needing a scripting language. Scripting languages are important for games: they form a divide between certain elements of game logic and the engine itself. They also make it harder (if correctly implemented) for a game designer – who may not be thinking as a programmer – to crash the engine or to introduce Exciting Behaviours into C++ code. We wanted a scripting language, and I shopped around looking for one.

For our first attempt at solving this problem, we decided to use Ruby. Ruby is a scripting language that now powers… well, a fair amount of the web… due to its elegant design and a little library called Rails that you might have heard of. Ruby has a lot to like about it. It’s a smart, well-designed language that comes with a good set of useful primitives. It supports serialization and reflection of objects out of the box, it has a number of useful string manipulation functions, and it has utility libraries for everything under the sun. It looked like a winner, and it came with some binding code to help you integrate it into your C code. The problem, then, was how to integrate it into C++? How do we get two object-oriented programming models to play nicely?

Integration, surprisingly enough, turned out to be a very pleasant experience. I started with some good hints from Gaffer and his Ruby wrapping classes, and ended up mangling the hell out of his library to add some features specific to our needs (like cross-platformness and transparent object serialization.) The part that I found particularily delightful about the experience is that Ruby can internally serialize classes – including new, exciting sorts of objects – as plaintext strings. This made it very easy to get Ruby playing nicely over a network.

So, why doesn’t Ruby work? Short answer: the garbage collector sucks.

Long answer: Ruby’s GC does not support asynchronous garbage collecting, or incremental garbage collecting. Instead, when the garbage collector runs – it *runs*. And by runs, I mean chugs. I hope that some day this will get fixed, and would fix it myself except that I don’t know enough about Ruby’s internal source code or how to write a garbage collector to attack the job. If anybody out there knows something about these two topics and wants to make Ruby’s GC useful for games, let’s talk.

What are we going to do next? I’m not sure. My occasional hackmaster buddy, Ryan C. “Icculus” Gordon (that’s a mouthful), suggested Lua. Everybody does Lua these days, and that’s both a good thing and a bad thing. I suppose it does what you want it to do, but … I don’t know, something about it doesnt make me happy. AngelScript has also been floated, but I don’t know what the point is of embedding a language in a C++ application that programs exactly like C++. Next week, we’ll explore more interesting and arcane alternatives. Like that Erlang thing.