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.

Translation

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:

#script

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.”

/script

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.

Script 3.0

G’day, friends and copper-stickers.

Long time no post. I’m here to change that.

There was a bit of family drama that required my attention recently, and that accounted for a few exhausted weeks. But I’m getting back in the groove.

The major attention right now is STILL on scriptwriting. I’m in the third revision. The plot condensed even more. Still fewer cinematics, more interactive scenes (a little like the Half-Life 2 ones, but not so static),  tightened-up introduction and end. The player is inserted into the game after a relatively short, action filled cutscene, followed by a bunch of interactive scripted things, Scout is still more emotional, you’re being watched wherever you step, nowhere is safe, and the world is a big grab bag of stuff to be explored.

Player initiative is the guiding principle. You get lots of choice.

There is a middle sequence that’s especially difficult to get across because the protagonist does an absolutely crazy thing there. I’m still working on making the player understand Scout’s motivation and getting the player on board with the crazy decision. It’s a lot of fine-tuning to set this major event up and prepare the player for what’s coming without shoving it down their throat.

Gameplay is in the script now instead of separate. High integration.

I’ve gotten a ton of feedback on the script and implemented 90% of it. I hope to get still more feedback. This thing is being road tested like crazy. I’m getting brick-in-the-face type feedback and learning from it.

One of my exchanges unfortunately failed, I didn’t hear back from the other author. That kind of thing is a setback but we’ll just have to plow on. I’m in contact with another beta reader to offset this.

On another note, the old RMQ project website is online again. Supa is going to do something with putting the stuff on Quaketastic. And I added the old Quake Radiant mapping tutorial to the menu up there on this page together with the CSQC stuff.

Herd Base Timelapse

Want to see an animated time-lapse of SJ’s Herd Base level growing from tender beginnings to an engine-eating monster?

There are over 80 images from various phases of the project, the earliest still containing Quake textures and monsters, the latest showing my experiments with shadowmaps and dynamic lighting in the FTE engine as well as increasing use of custom assets.

Click here for the goodness.

Browser support:

• Firefox displays this slideshow excellently.
• Safari should work as well.
• Chrome users: Please install the APNG addon and restart the browser.
• Opera 15 and later also supports APNG via addon.

Sorry for the possible inconvenience, but I chose animated PNG format over Youtube for image quality reasons. The plugin takes only a couple clicks to install and you probably want it anyway.

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:

Options

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.

An Open Word

There’s trouble ahead.

Isn’t there always? Any creative effort has to struggle with obstacles. But there is no doubt that the one Scout’s Journey has to deal with now is an especially depressing one.

The game might have to switch engine. Mid production. Awesome.

In a recent talk with FTE’s author it was implied that I shouldn’t count on SJ-related bugfixes nor tech support. I have been encouraged to fork the engine and fix them myself.

I have come to the conclusion that this idea is illusionary. I don’t understand the innards of a Quake engine, and especially not those of FTE. I could probably learn it, but that would take so much time and effort that it’s unrealistic. I cannot realistically fix the bugs in FTE nor do tech support once the game releases. FTE is basically a black box to me. Without support, a black box’s only use is as a paperweight.

And there are bugs in FTE. Some have gone unfixed for well over a year. Physics and realtime shadows are far from production ready; these things are currently novelty features, I would say. There are also PVS-related bugs that require knowledge I definitely don’t have.

I don’t know where to find a programmer who can fix a Quake-based engine. It’s specialist work. Not that I could afford it anyway.

The sad thing is that I like FTE. But it’s clearly not suited to do a modern first-person RPG in; its additional features such as realtime lighting were probably always intended to use with Quake and Quake-like games and developed with a Quake-modding mindset. For what I want to do, that mindset won’t cut it.

This same problem also affects the Darkplaces engine. Its features do not extend past the Quake-modding scenario and it’s not actively developed by its original author anymore. So that’s not a solution either.

Another sad thing is that John Carmack’s GPL engine dream is probably dead. Almost no one used the GPL Quake engines to make new, original games with. There are more games that used the commercial idtech license than open source idtech ones. A major issue is that the advanced GPL Quake engines are under-documented and relatively arcane. Perpetual bugs and lack of tech support are another. Considering Unity and UDK are *free* to make a game with, well-tested and supported by well motivated teams, there is little reason to not simply use one of those. UE4 is 20 bucks a month plus five percent of the sales. And for a rock solid game engine with tech support and documentation, five percent is nothing.

Where to go from here?

First of all, Scout’s Journey isn’t going to die. It’s too far along to quit, and frankly it’s also too good to quit. This is just another obstacle and it’s not insurmountable. I will have to port a certain amount of code – all the RPG things are basically done – which is a minor nuisance but much better than being left in the cold with obscure engine bugs. The assets are all portable – luckily I already switched away from BSP half a year ago. Sixth sense, probably. Polygons are polygons, art assets are art assets, sound files are sound files and writing is writing, no engine required.

Second, the options are, in the end, Unity or UE4. I pondered finishing a prototype on FTE, which is feasible, but admittedly the entire situation depresses me so much that I can’t stand it. The less time spent looking at a trainwreck, the better. It’s just super depressing and that has to stop.

Third, this probably marks my exit from the active Quake modding scene. The engine was the last link. Scout’s Journey was still using the Quake engine because it organically developed from the unlucky foster child that was the Remake Quake project. I will continue to play and pass on knowledge and I’ll remain with the quakeone.com staff for as long as they want me, though.

Now for the positive things.

Getting rid of Quake might also be liberating. To be honest, every time you talk about game development with someone from the Quake community, they AUTOMATICALLY assume you are making a shooter game. I can’t count the number of times I’ve been asked “when can I shoot stuff in your game?” and the number of times I’ve had to explain that it just isn’t that kind of game. I’m sorry. It just isn’t. Shooting stuff is not at the top of the agenda here. “Will the physics be like Quake?” Well duh, um, actually, who cares. Probably not.

Full disclosure:

I find most shooter games incredibly inane, shallow and meaningless. I can usually only enjoy a shooter if it has been enriched with a certain amount of brains (Bioshock) or story (Stalker.) And I relish it when a first-person game dares to drop the gun. Mirror’s Edge is a prime example of what a first person game can be if you take people’s guns away for the most part. It was an eye-opener in so many ways (how many games have people actually hugging?). I would like to go one step further and just drop the player into the world without a lot of obvious threats and without a weapon. The first level of Scout’s Journey has exactly three enemies, the first of which can just be avoided. Later levels have patrols, but engaging them (and how you engage them) is completely optional. Scout is not a beefcake space marine. The only time when you will meet opposition is when you [SPOILER].

It is just tiresome to talk about shooter games all day when you really want to do something different, but no one understands what you want to do. Unity/Unreal have a much broader spectrum of games. Not shooting things in the face all the time might be better received there.

I keep hoping there is an audience for less violent, exploration based, problem solving, spiritual, soul-searching, more human and truly mature (and I don’t mean that in the “lol boobs” kind of way, I mean mature in the full sense of the word) first person games.  Leaving the FPS modding community behind might actually help me to get there.

Interesting times. For now I will concentrate on assets and other engine-independent things. There’s enough work to do that has nothing to do with programming. People (especially FPS people) always underestimate how much work is in writing and concept art, for instance. I’ll be busy enough.

 

 

One more bug from 1996

As recently posted on the Inside3D forums, apparently the Quake engine lets you overwrite the game data with savegames should you be enough of a moron to call your save “pak0.pak”, a bug that seems to hail all the way from the original release eighteen years ago.

Wow.

What’s even more amazing is that this hasn’t been fixed yet. I wonder what else is in there.

This just reinforces my belief that it’s best to hide the game’s console from the player. Unfortunately with an open source game, completely hiding it is impossible.

Hexen 2 aftermath

My Hexen 2 map — as gnounc put it — “exploded”. This morning, after collecting my teeth from the concrete wall of Hexen 2’s BSP format limit, I gave it a look in FBSP. I think it’s not too shabby. The FBSP conversion messed with the lighting, but that can be fixed.

Actually, I think this is Scout’s Journey material. It might just have been fate’s trick to get me to make another SJ level, after all. Spike pointed out that Hexen 2’s additional clipping hulls eat into the same clipnodes limit that is familiar from Quake, meaning the clipnodes limit in Hexen 2 is effectively much lower than in Quake. Sadly, that makes a lot of sense, and sadly, that is a hardcoded limit. This is too much for poor Hexen 2.

So, while I would have liked to release this as a Hexen 2 map, technically it’s just too complex for that game. But in every disaster, there’s a gleam of hope, or something like that…

Say hello to another Scout’s Journey level — number six in the lineup.

Hexen 2 map

I decided to collect the Hexen 2 screenshots in a new post; I’ve had a bit of innocent fun making this level, and in the course of doing so I hacked all the compile tools. Hexen 2 mapping is a bloodbath. It’s not pretty. The tools are stone age, I have to hack the map format itself by search and replace in a text editor, and I’m breaking all sorts of compiler limits. I’m also seeing cool new error messages.

I hacked AguirRe’s light tool for the coloured lighting.

The lava crack of doom; the rocks here broke the compiler and the Vis tool. I had to jack up MAX_HULL_POINTS and MAX_MAP_PLANES. I used AguirRe’s TxQBSP as a guideline for some good values.

And it’s not over yet. Let’s see if I can finish this.

And it’s over. The short mapping session today (April 19), including this lovely little ruin, broke the BSP format limit… specifically clipnodes. Same problem as in RMQ, which led to the creation of the BSP2 format.

Unfortunately hacking the BSP2 toolchain to support Hexen 2 isn’t an option right now. All the tools hacking I had to do before I even got to this point has worn me out.

I’m considering to take it to q3bsp. The upside would be even prettier lighting and the ability to use static meshes, the downside would be having to convert all the lowres hexen 2 textures to Q3 images and no more scrolling sky.

Not sure what I’ll do about this. For now, I’m quite frustrated.

Under Construction: E1 Exteriors

Apparently I got frustrated enough to start mapping again. I wanna see how much detail I can cram into this map. It’s obviously Remake Quake’s Episode 1, cookie for whoever guesses the map, two cookies for who guesses the correct area. Teammates, ex-teammates and engine coders can’t participate.

I’m taking longer to build this area, not to mention the next one, than I needed to build the entire rest of the level… Yesterday I got some pointers about what works and what doesn’t though. That little courtyard isn’t finished yet, which is good because you’re already getting enough spoily stuff. A little bit is OK though because you don’t get the big picture without actually playing the map. Here’s another somewhat under-construction shot:

There’s some boxing of the area with sky brushes here, to avoid compiler segfaults for as long as possible… I know the red banners suck, I’ll make models for them. I also hope to get the entire map decked out in high resolution textures, with a little help from my friends. I have more and prettier shots, but you’ll have to wait until June 22nd to get your hands on this. As a reminder, I posted some interior shots a while ago here.

I played ijed’s part of the demo yesterday, and it is pretty good. rj reported a large amount of brushes placed in his recently, and while I haven’t seen it, I have seen the other episode 2 stuff. It has been described as “I get that Unreal feeling…”

We will have three gorgeous maps for you.