Author Archives: Nicholas

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…

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.

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.

{ read this article }

I had an original post here, which I made, and it was late, and then everybody decided that it was too incendiary. Therefore, it has been relegated to the bin of Posts That We Will Save For When We Require Webtraffic. I should mention, incidentally, that we have a blogging schedule:

Sunday – Nicholas
Monday – David
Tuesday – Derek
Friday – Daniel

I think that’s correct, anyhow. I’m just running late because of Easter, but I have returned from the grave in order to provide you with inspiration for how to better live your life. It seemed…. appropriate, somehow.

Instead, let me congratulate the Dwarf Fortress crew on their recent release on April Fools’ Day. Dwarf Fortress continues to be a source of supreme inspiration, mainly because it takes normal expectations about how to make a good video game and turns them upside down on their arse. I will readily admit that we stole a few ideas from Dwarf Fortress: in particular, I will readily confess that Dwarf Fortress was what originally inspired us to put random names on everything. It started with a simple conversation between myself and somebody else, where one of us said “Hey, let’s put random decorations on artifacts.” Next thing you know, we had maces decorated with tawdry post-it-notes and clapped-out llama fur. At this point, Dredmor spiralled off into the realms of chaos as we asked ourselves, “What else can we do with this text database?” Artifact names were the next logical conclusion, as were monster names. At some point afterwards, I wanted to make it so that certain rooms would be given names, and then decided that one of the most entertaining things in Dredmor was exploring the dungeon and discovering that you had entered the Diseased Maze of Pickles.

There have been a few other sources of indie inspiration in how we run things at Gaslamp Games. We completely stole our PR model from the Wolfire guys, who first showed the indie community how important blogging actually is when you need to produce PR. In-house content is cheap, and if you can continually send eyeballs to your website, then so much the better. When we developed our new web site, I kept sending people over to the Wolfire blog so that they could get an idea of what I ultimately think has been the most successful model for indie self-promotion to date; ultimately, this is why we ended up using WordPress for our blogging system. Well done, Derek, for getting that set up. I think that the next game will further reflect other lessons that we’ve learned from other independent developers, both in terms of how to – and how not to – make a game that sells well, and lets us stay in business.