Archive for the ‘devblog’ Category

How not to write a computer game

Tuesday, December 30th, 2008

Devout apefans will find this hard to believe, but Danger Balls is not perfect. No, no, it’s true. In fact, I think I may have the dubious accolade of having made every mistake possible in the creation of a game. For the benefit of other aspiring developers and hobbyists, I will now list these transgressions, in no particular order.

How not to write a computer game

  1. Write everything from scratch. Granted, it can be fun, insightful and downright educational, but writing your graphics engine from scratch is the slowest way to make a game. Nearly everything you want has probably already been written; don’t be afraid to stand on the shoulders of giants.
  2. Build the engine first, add content later. This sounds obvious now that I say it to myself, but a game has to have a point, however abstract or whimsical, and it has to have it before you write a line of code. I spent years developing Danger Balls as “some kind of tank game” before ever adding any balls.
  3. Close your source. Not having written any open-source software, I can’t yet sing its praises, but I can tell you that the knowledge that no one will see your code allows you to do dirty, shameful things to it. Open it up for the world to see and, even if no one’s interested, you’ll be forced to take a certain pride in it.
  4. Take seven years. Enough said.
  5. Don’t update your website. The warning sign here was when the owner of another website with a similar name remarked that he wasn’t able to tell what it was we were doing. One major overhaul of the site later, I hope it’s a little clearer. If not: we make computer games.
  6. When you do update your website, hand-write the HTML. Even after the overhaul, it took me a few months to realise that what I was doing on the site was blogging. Once I had installed Wordpress, this became a lot less of a chore. Use the right tool for each job.
  7. Hand-write XML. I recently decided that I was too old to be hand-writing XML. It you have to write XML, treat yourself to an editor.
  8. “Those are just proof-of-concept models; they won’t be in the game”. I actually believed this when I said it, but it’s all too easy to leave test data in the game. Beware the dreaded “good enough”. Either bin your test content, or develop your engine against release-quality content.
  9. Keep it to yourself. Until I announced a release date for Danger Balls, the only indication of any progress was a “coming soon” notice on the public site. Behind the scenes, some decent work was being done, but all on the private wiki and issue tracker, with nothing being blogged for the benefit of the public.
  10. Don’t have a deadline. The only reason Danger Balls is available now is thanks to a drunken promise I made last year to finish it within three months.


Thursday, September 4th, 2008

In the good old days, all XML for models in the Primate was hand-written. I took an evolutionary step recently by downloading an actual XML editor, rather than doing it all in Notepad.

Now, I’ve finally managed to build part of a model in Blender (that’s an actual model editor, people!) and export it to Primate XML.


I just had to run it through a couple of teensy weensy SED statements:

# Points
s/\([-0-9.]\+\) \([-0-9.]\+\) \([-0-9.]\+\),/<point x=”\1″ y=”\2″ z=”\3″\/>/

# Indexes
s/\([-0-9]\+\), \([-0-9]\+\), \([-0-9]\+\).*/<index>\1<\/index><index>\2<\/index><index>\3<\/index>/

Simple, eh? You’d do that in your sleep! It took me less than 2 hours to convert an object!

It doesn’t work properly, of course. Still, great days.

OpenGL transparency

Wednesday, September 3rd, 2008

You can’t have danger balls without explosions, and you can’t have explosions without transparency. I decided I’d have two types: transparency in textures - for billboarding pictures of dirt being thrown up in the air - and overall transparency of objects - for clouds of semi-transparent smoke.

A simple matter of enabling GL_BLEND, setting a blend function adding an alpha channel to texture images and setting alpha values on object colours…

But what’s this? OpenGL documentation saying there’s more to it…

“When using depth buffering in an application, you need to be careful about the order in which you render primitives. Fully opaque primitives need to be rendered first, followed by partially opaque primitives in back-to-front order. If you don’t render primitives in this order, the primitives, which would otherwise be visible through a partially opaque primitive, might lose the depth test entirely.”

You guys crack me up! How could something so basic necessitate such a contrived algorithm? This must just refer to mid-80s SGI hardware or something…

WAAAAAAAGH!! It’s true! If you don’t draw primitives in the right order it nobbles the whole thing! Come back, Java3D, all is forgiven! I promise I’ll use you in Primate 2.0!

Okay, okay, calm down. I can still use if for explosions, because they get added to the end of the draw list and only last a couple of seconds, so there shouldn’t be any transparencies overlapping. And what kind of a tank game would it be if there was more than one explosion at a time? Ha! I’d like to see that!!