Category Archives: Quake

What Writing Does in Game Dev

Time for an update.

Hard facts

On the technical side, I’m now working on a new PC that should be Unreal-capable. We’ll see when I get that running, I might feel inspired to start porting the first level to Unreal.

Truth is, as may be obvious in hindsight, that the switch away from the Quake engine was more of an obstacle than it should have been. I lost the ability to quickly prototype. But in the end, it’s better for the project. It may look like the old Daikatana mistake, but there’s a difference. This is not 1997 and Quake doesn’t cut it anymore, not in the face of Unreal, Unity and Cryengine. So I still feel the switch was necessary and justified.

It’s simply a fact of life that the FTE engine was too buggy, that I couldn’t do the things I needed to do, and that every time I broke one of those invisible Quake-technology walls I ended up in a minefield of untested things prone to failure. So while the engine switch did end up hurting the project, there really was no alternative. There is Darkplaces, but that would have meant another risky wager that a largely untested engine based on 1996 tech would be better suited than the first one. It just didn’t seem like a smart thing to do.

We’re slowly coming up, by our own boot-straps if you will, to a state where we can likely do a hopefully soft landing on a different platform. One of the environments was already dropped into Unity just to see what happens. Turns out it’s very doable. Unreal won’t be that different.

So engine wise, cutting the cable sort of spun me into a different orbit. Which took some time. Not least because I was busy thinking about more fundamental things.

Squishy stuff

Of course that’s not what most of the development time was sunk into over the last two years or so. People tend to not understand why all this writing is necessary. I won’t go into it much further, just know that the script basically IS the game, just minus the technical implementation side. It is simply the case that the style of game development I’m currently doing is so far removed from Quake modding that there’s not even any common ground I could use to explain it to that crowd.

We’re talking apples and oranges. Quake modding is largely mechanical. Change a line of code, and you’ll make the grenade launcher spit voreballs instead. Yay. The communication problem simply lies in the fact that modding Quake’s pineapple launcher and making a game like Scout’s Journey are two different universes. It’s like the language isn’t even the same.

The entire paradigm has changed. In late 2013, Scout’s Journey was basically a Quake mod that started to mightily rattle the cage. Development was largely writing code and painting textures, blocking in level geometry or modelling weapons. Roughly the stuff we did in Remake Quake, plus new problems such as doing terrain, being a lot more detailed and breaking the BSP visibility stuff to get it running fast enough. Very down to earth stuff in gamedev terms.

Real game development in 2016 is a completely different thing.

Scout’s Journey development isn’t based around just going in and writing code or smacking brushes together. It is turned inside out, or rather, right side out. The mechanical aspect of code and polygons is only an extension of the ephemeral core that is plot and design. This brings with it the realization that scriptwriting is in fact the new engine room. Not 3D modelling suites and not level editors and not IDEs.

The holy trinity of Scout’s Journey style game development are actually writing, art and programming, with the latter two being extensions of the former. Which is how it should be. It is a common complaint by game writers that companies are trying to tack on some writing on the tail end of an already half finished game. That is doomed to fail, and is what I’m NOT doing.

Simply put, a lot more development happens BEFORE the art and code stages. This is akin to saying, “hold on a moment, put down whatever tool you’re using and start actually thinking.” And this is the opposite of the modding mentality, which is “I’ll just go in and do this…”

Game development SHOULD start with writing. Unless it’s Pong or Tetris.



As an example, this lightning monster cage thing (from Remake Quake, around 2011?) was a result of the “I’ll just do something cool” approach. No doubt that approach is a valuable tool. But Scout’s Journey then takes something like this and turns it into that:


An apparatus, like two half-moons made of humming electrodes, seems to draw energy from the creature itself in periodical crackling flashes. Hoses and cables stuck in the creature are drawing its blue ichor, in a slow drip, into a large glass vial.

Scout slowly wanders around it, circling the cage. She wonders, ”What is this thing doing?” Big Bear says, ”Whatever it is, keep your hands off of it. You’ll just run into trouble again.” The goddess speaks up: ”May I look through your eyes?” ”You may.” Scout gazes at the entire contraption. The goddess says, ”This right here says to me: Naruuk, the Star-Eater was here.” Scout keeps circling the machinery. The camera moves in large sweeps.

”He hates me because I’m of the Earth, and he thinks the Earth his slave and spits on it. It is the same with the Luminar. You know now that there are many worlds. And just like that, Nature finds a way to protect them, and tend to them. That is what the Luminar do. They are weavers of the great web. Holy servants of Nature.”

Scout fearfully reaches out to touch the creature. It doesn’t respond.

”They’re killing them”, Scout says. The goddess replies, ”Yes, they’re killing them. For fear, for greed, for negligence, they’re killing them.”


So the idea of the shambler cage is still in there, just minus Quake’s shamblers, obviously. That’s because instead of monsters, Scout’s Journey has just another faction of intelligent beings that happen to be victimized by the real antagonist (and pissed off about it). Who, needless to say, was more than a little inspired by H.P. Lovecraft’s “elder gods” and so forth. I mean, with a name like “the Star-Eater.” And this, especially once Scout (and the little voices in her head)  encounter it, creates something more interesting than a random eye catching landmark on a Quake level. Basically, something like the shambler cage just makes the player say “neat” and move on to kill more monsters. The cage in Scout’s Journey has become much more than that. It became an anchor point for story, characters, philosophy, conflicts and what have you.

A whole lot of the stuff I did in Remake Quake was the nucleus for ideas that turned into something meaningful in Scout’s Journey, but only because of the writing.

The next step, after writing it out like the example above, is to turn it into new concept art (the cage won’t look quite the same, the size relations are different, the meaning is more complex) and only then modelling it, putting it into a level, and coding stuff like particle effects.

A lot of similar features and landmarks from my Remake Quake levels did survive into Scout’s Journey, just laden with different meaning.

Hopefully this gives people an idea what the writing phase is good for and what can be done with it. It’s like metamorphosis.

That’ll be it for now. In the interest of better understanding what is going on behind the sometimes slow-moving blog. The writing is unfortunately not as photogenic as simply posting assets.

Oh, and because the world is what it is: I call dibs on my own script. All rights reserved.


Thoughts on Xonotic situation

I’ve read at the Xon forums and elsewhere that they’re strongly considering a move to a different engine. In my opinion as a longtime user of hotrodded Quake engines, that is a reasonable idea.

I’ve also read that they are looking at some Quake 3 based engine. There was also mention of idtech4. Again in my opinion as a […] that is a very bad idea.

Old warhorses

Xonotic currently uses Darkplaces, which as Quake-derived engines go is probably one of the most stable, feature rich, and bug free options. However, the gap between Darkplaces and Unity or Unreal is huge at this point. Also, Darkplaces doesn’t seem to be in active development currently. So to future-proof a game, moving to a new engine seems like a good plan.

However, in switching from one Quake-based engine to another, aren’t you replacing your old warhose with an equally old one that has a slightly different colour? Quake 3 is almost as old as Quake, folks.

And while idtech4 might seem like a halfway visually-competitive idtech engine, keep in mind that it is over ten years old as well and equally unsupported and unproven. Yeah, I know, the Dark Mod, but that’s not really enough to prove the viability of a game engine for a totally different game. Looking at Doom 3 multiplayer, nothing screams “awesome arena FPS engine” at me. Knowing Doom 3’s lighting model doesn’t improve this impression. An arena FPS is fast first and foremost, and needs excellent netcode to accomodate many players at a low ping second, right? I don’t see that in the Doom 3 engine.

You’re switching one old engine that is stable, relatively feature rich and proven to work for arena FPS for another that’s also old and perhaps less proven.

IMHO, bad idea ™.

I understand that there are several problems atached to the decision.

  • License (open source or not?)
  • Having to potentially rewrite the gamecode
  • Asset portability
  • Finances
  • Manpower
  • Future proof-ness
  • Mobility of the player base
  • Strafe jumping and physics
  • others.

From my point of view, there are several possibilities in such a situation:


Conservative option: Keep Darkplaces and work around the limitations. Go for an even more comicky/clean art style (see Warsow.) Cut everything that isn’t up to scratch from the game (maps, game modes etc), then focus work on improving and unifying the remaining core, especially gameplay, and polish it to a mirror shine. Pros: Not as much work, proven arena FPS engine. Existing install base, comfortable niche. If you want to step it up, abandon BSP for your levels and move them to modular meshes or something. For lighting, potentially switch to high-resolution vertex lighting (dense mesh – polycount is less of an issue today.) Move the visuals off technology and onto art style, it will benefit performance.

Mediocre option: Switch to an engine that is just as old and less proven but doesn’t require any rewriting of code or porting of assets. This seems kinda redundant, it’s changing one old horse for another and will only postpone the problems.

Radical option: Switch to Unreal. It’s a proven arena FPS engine, looks awesome, is future proof and well supported. Accept having to start from scratch. Unreal already provides an arena FPS codebase and sample assets. Create a new player model and new weapons plus at least one new map and call it a prototype. Label it Xonotic 2. Use existing player base to test the hell out of it. Then build on that. Imitate Quake physics as far as possible. It won’t be open source, but it pretty much guarantees a future for the game. This would certainly require brass balls, but potentially provide the biggest payoff. Might also provide the dev team with some money (early access etc.) Perhaps some mappers would be OK with licensing their existing maps for this. BSP maps can be ported pretty easily, the Quake 4 editor spits out pretty good meshes upon export. Regarding the player base, continue supporting old Xonotic for a couple years but make it clear where the future is. Engage the player base in the new game via testing and feedback.

Crazy option: Create your own engine from scratch. This might work pretty well if you have the capability.

I can only say that I would choose the radical option, and have done so with Scout’s Journey. I accepted having to rewrite my gamecode and port and modify my assets (after two years of development.) I certainly didn’t have any license problem, because the assets and code were all mine, which made it easier. Yes, it set me back, and it made things slightly more difficult. But eventually you’ll have to make the jump unless you want to be still using a Quake engine ten years from now. You’ll be losing players all the time. The gap is only going to get bigger and the jump is only going to get harder.

Needless to say, this goes for any Quake-based game. The time window for making the jump to more modern technology is shrinking because game development gets more difficult all the time.

Jump now, or pay the price.

My 2 cents.