I’ve been programming ever since I was 12, when I cracked open a copy of C for Dummies and tried to figure out what all the weird curly braces meant. I loved the style of that book: the first thing it told you to write was a program that spat out “Goodbye, cruel world!” in an attempt to cast off the shackles of convention, and then it told you to ignore half of what you’d written and that it’d explain it later. Perfect for a 12-year old with the attention span of a hyperactive butterfly.

When I tell people this, they always react with derision, shock, snarkiness or, if they’re about to ask me a computer-related question, elation. What they never ask, with a couple of notable exceptions, is “why?” You see, the reason I picked up C programming is because I read, most likely in a copy of PC Gamer, that Quake III Arena was written in C. At the time, I was a huge fan of Quake III (the demo – I didn’t have the patience to save up for the real thing, nor would the wonderful people at Gamestop have looked down at my pre-pubescent features and willingly handed over a copy of the 15-rated Nirvana-inducer), and I wanted to know how to make games just like it.

What’s that? I should get to the point before you finish making up your mind to stab me in my sleep? Fine, here we go. Today, I came across an article from 2005 detailing the square root algorithm used by Quake III, most likely originally coded by the geniuses that worked at 3dfx (and not the fools who ran it). Now, I understand that out of the four of you that read this, three of you will not care how a computer finds the square root of a number, but that’s not really what I want to talk about. Suffice it to say that computers usually have an operation built into the hardware for finding the square root of a number, and that id’s software implementation was faster than the instruction that was built into the chip. Someone out there found that if you were willing to accept a higher margin of error, you could get away with combining very few simple instructions into a passable function which was much faster than the standard way of doing things. This, to me, encompasses what Quake was all about: pushing the boundaries to make a fantastic game. The tools the guys at id were given weren’t good enough, so they made their own, they made them better, and they made damn sure they kicked ass from day one.

That “day one” concept is important. Time and time again, we’re seeing developers release patches in the first few days after release. You often hear people comment on negative reviews with “Don’t worry, I hear the developers are going to patch that soon.” The attitude of “ship first, fix later” is one born largely of laziness and a lack of enthusiasm for the very project the developers are working on. It smacks of an Electronic Arts-like culture, where a game’s release date is based more on public holidays and trade shows than its quality and progress. To make a game great, you don’t just need a solid pitch – everybody working on it has to have the same enthusiasm they had when they first uttered the magic words to the lead designer: “Wow, that sounds awesome!” Have you ever wondered why the indie gaming scene is killing it right now? If you’re an indie developer, you’re the boss. If the enthusiasm stops, you don’t release the game. I have no doubt that the number of indie games out there is far greater than the number of professional games: it’s just that the bad ones, the unfinished ones and the flawed ones don’t often see the light of day. I’m sure I have eight or ten sitting on a hard drive somewhere which I wouldn’t even show my mates.

Of course, there’s a downside to putting your all into a game, and polishing the hell out of it until it’s perfect. It’s the same with any medium, any project, any piece of art. It’s never perfect. There’s always something more to be done. I think this is what happened with Duke Nukem Forever: the team was never truly happy with their project, and management was too sentimental to stop them, so they kept plugging away, completely writing and rewriting everything from the ground up until the whole company ground to a halt. It’s a damn shame, because you never really know when to stop – it’s just an arbitrary line in the sand. “We’re not done yet” plagues some developers more than others – Valve are renowned for it, but I don’t see it being a huge problem in the long term: if your game is exciting enough, journalists will write previews, people will find out about it and they will force you to get it out the damn door. Just please take a lesson from the current innovators of the industry – the indie devs out there – and make sure it’s the game you said you were going to make; the game you’re proud of; the game you want nothing more than to sit down and play.

Tags: code, duke-nukem-forever, quake-3
Categories: Comment

You can leave a response, or trackback from your own site.