How Game Writing Is The Same As, But Totally Different From, All Other Disciplines

Today I am going to blow your mind with a discipline-by-discipline comparison showing how writing fits into game development. By asking a couple of simple questions, then following up with a few nifty diagrams, this article will change your world for ever.

Is It Reusable?


Each piece of code in a game has a defined objective. Code may change, but it is designed to be modular, as are gameplay mechanics, interfaces, et cetera. Thus if you change a game mechanic in one area of code, you change that mechanic throughout the player’s entire experience of the game, for free. For instance, say you’re working on a platformer like Braid, and you need to change the height of the player’s jump — change the value of one constant, or tweak the physics engine, and the whole game is adjusted. Need to change how the game logs errors? Alter the one error-logging function that is called throughout the game engine. Done. Reusable? Yes.


Game art is similar insofar as there is one piece of art for, say, a weapon, building or vehicle. If it needs to be adjusted (for art direction, useability or story reasons), that single source file is altered and re-exported, at which point the new asset goes into the game and is accessible, again, wherever in the game it is needed. Obviously there are sometimes very specific pieces of art that only appear once (e.g. the Eiffel Tower). But because game artwork consists of discrete objects, those assets can be applied reusably throughout the game — e.g. wall textures or weaponry — without any additional overhead. Reusable? Yes.


Music is similar. Although, as in a film score, some specific music may be written for one or two ‘cinematic’ moments, in general, music is reused. For instance, one track might play in a loop as you traverse one level. Increasingly, simple AI-based systems are used to dynamically adjust game music depending on what’s happening in gameplay. But this is still the exception, rather than the rule; nor has this technique been mastered. The underlying logic still more or less consists of: ‘Shooting started? OK, change to the combat music.’ Not exactly the most complex musical theory, is it? Nevertheless, music: reusable.


Game design — and I’m thinking here about a combination of level design, design of encounters with NPCs, bosses or enemies, and design of the player’s experience in a particular area or game-wide — is again pretty modular. You either have a global design (for instance, the combat design, which is applied globally but designed as one consistent, difficulty-based gradient); or a local design (for instance, a particular level layout with its enemies / puzzles). In the case of a particular level, the designer may make the required changes by combining and manipulating assets. This level-by-level work is obviously not reusable. But in the case of combat design, mechanics design, puzzle design (at least of basic puzzle mechanics), these designs are all reusable, and implementation of these will generally involve a coder modifying precisely the sort of modular code discussed above. Reusable? Yes.


Some game writing is (sort of) reusable. So-called ‘barks’, exclamations that are cued procedurally (which is to say, the game engine decides when it’s appropriate to play a sound, rather than a narrative designer specifically planning that moment), can happen repeatedly throughout the game. But even this reuse is usually managed, by limiting a set of barks to a particular area, or restricting the number of times you hear one piece of audio, or one type of audio cue, within a certain time period. This is because the human ear quickly identifies repeating audio, and each repeated bark then becomes a painful burr lodged in the ear of the player, jabbing them a little bit each time they hear it.

But no. Most writing, for this very reason of repetition fatigue, is not reusable. Stories, when they are experienced, are by definition a linear series of events. Unless you’re playing a very specific type of game about time travel, you’re unlikely to keep replaying the same story twice. Unless, of course, you keep dying on that one level. And, as we all know, both the time-travel scenario, and the keep-dying scenario, could be extremely annoying if you did keep listening to the same story content over and over. So even then — straight repetition is a no-no. Reusable? No.

So, let’s tally things up.

CODE — Reusable.
ART — Reusable.
MUSIC — Reusable.
DESIGN — Mostly reusable. The stuff that’s not reusable (i.e. a particular level design) is the stuff that most closely resembles story design, i.e. it’s linked to the player experience, and the:
WRITING — Mainly not reusable.

Is It Iterative?

By ‘iterative’, I mean that the products of your work in a particular discipline can be looked at, prodded, tested, analysed, and then improved upon. After you improve it, you poke it again, test it more, and then improve it again. Et cetera.


Sure, code’s iterative. You either iterate over your code because: a) the code initially didn’t do everything the design specified; b) the design was changed after the code was first implemented (coders will usually say b happened; designers will usually insist that it was a); c) the code is inefficient and needs to be optimised or rethought; d) some game engine fundamental or other inter-dependent code changed, and that broke something in this code, or at least requires an update.

As you can probably tell, it turns out that most iterative code (re)development is actually a result of the inter-dependence of different disciplines. The design changed? Then, nine times out of ten, the code changes too. Of course, limiting expensive engine code changes is why scripting languages were invented for use by scripters (that strange crossover breed between designers and coders). But don’t be fooled. Scripting is usually just coding-lite. And sometime not even that lite. And when it’s not coding-lite, it’s really design. Iterative, either way!


Sure, art’s iterative. Your first draft used too many polys? You’re over-budget for your level? Cut it down for the next version. The publisher thinks that your completely nude model of Princess Leia is somewhat inappropriate? No problem! — Iterate! You have your discrete piece of artwork, and you can usually change it without fucking everything else up.


Yes. Your tune sounds tinny on mobile speakers. There’s too much timpani. The mid-frequency guitar noise is really interfering with the game’s speech audio. Iterate. Fix that tune! Likewise for other audio — add new sounds, tweak exciting effects, reduce audio bitrate to free up disk budget. Iterative.

Turd to gold. Iteration. It's the dream.


Design is the most iterative discipline of all. This is why designers are widely viewed as the most whiny, hard-to-please, inconsistent, demanding prima donnas of game development. This is, of course, both a) true, and b) completely necessary. All creative endeavors are shots in the dark. Design is the art of iterating over the player’s experience, until you have turned your slightly brain-damaged Duke Nukem Forever into a beloved Portal 2. You can design based on a tried-and-true game template (‘Space-marine FPS’ springs to mind), but unless you figure out to improve your work, electrify it with the spark of originality, and find its unique voice, it will die, unloved, unwanted, and unprofitable. And then so will you.

As the good people at Valve will tell you; as the good people at Google will tell you; as the good people at Stephen King (namely Stephen King) will tell you:

First, you create your ‘masterpiece’. Naturally, you got everything about it right on the first go. At least, that’s what your mother keeps telling you. Eventually, you realise that it sucks. Then you tear its guts out, take out everything you thought was ‘awesome’ while you were crunching at 2am, way past both the Ballmer Peak and your bedtime, and gradually you go through your design until everything is as good as you can make it, given your schedule, budget, people and tools. Unfortunately, realising that ‘this mechanic is not fun like we thought it would be’ and repeatedly redesigning it means that yes, coders have to keep re-writing the implementation. And if you’re unlucky, or disorganised, you might run out of money before you iterate the game into your dream state. You just have to get as close as you can. This is why everything in Google is Beta. It’s why Valve games take forever to make, but also why they’re so successful. It’s why Stephen King has to do rewrites on his latest manuscript, even though he’s written a gazillion books already and you think he’d know how to do it by now. In conclusion: game design. Iterative? YES.


Is writing iterative? Well, there’s the saying, ‘Writing is rewriting.’ Does that help?

Yes, writing is definitely iterative, in the sense that it can always be improved. Usually this means ‘Convey more by saying less’. It means ‘Marry the writing to the game mechanics’. For games, the film axiom Show, don’t tell becomes Play, don’t show. If you can convey your story through the game itself, you have won. This means working with game designers, sound designers, coders, actors. Ideally, it means being a narrative designer yourself, iterating over the game’s inherent story mechanisms. Iterating.

But there’s another reason why game writing is iterative: it’s because it depends on all the other disciplines. If you wrote an epic battle with a dinosaur as the conclusion to Act I, but you’re told there’s no longer the budget to create the model, or the time to animate it, and, er, could you please write a battle with a big floating robot instead?… What are you to do? Well, iterate. But this is where game writing differs radically from the other disciplines.

The Part Where Game Writing Differs Radically From The Other Disciplines

I shall now present a couple of diagrams. These are flow charts. Game developers love flow charts. Designers love flow charts. Even project managers have been known to love flow charts. Especially if they feature toolchains, ‘resources’, or company hierarchy. Brace yourself: here there be flow charts.

Game Development Flowchart without Story

That first chart is pretty clear. Development generally flows from design and creative direction downward, until you hit game testing, at which point implementation-specific bugs are sent to different departments (e.g. code). At the same time, the game is tested for ‘fun’ — play-testing — and the results of this are sent to the designers (who are, of course, testing the game for fun themselves as well). They then iterate on the design, and everything starts again.

Throw story into the mix and things get a bit more complicated. As you can see, it’s kind of bundled up with design, which means it can affect everything else. It’s also specifically likely to affect audio and art independent of the design:

Game Development Flowchart with Story

Finally, the most scary flowchart. This demonstrates that by changing a specific part of the design (e.g. the design team decide ‘Oh, this level is too hard, we’ll move it to near the end of the game’), you will require changing a part of the story, which in turn may require changing the whole story, which means potentially changing the entire design, which changes everything else:

Interdependence of Game Disciplines with Story

The Part Where I Talk Straight With You And Tell You How It Is

Writing is unique among disciplines in its lack of modularity. If you change anything at one point in the story, the ramifications of that change may require changing every other part of the story, and not in a simple way like renaming a character. No, one change at the end of the story, or the beginning, OR in the middle, may require rethinking and reinventing EVERY other part of the story.

If the project lead tells you that now have to fight a big robot and not a monstrous dinosaur, your Big Bad Corporation may need to be a robotics corporation and not a biotech one. Your bad guy might be a NASA scientist gone rogue and not a cloning researcher who lost his way. Your hero may stop being a witty paleontologist who hails from Stickleworth, England, and works at the Natural History Museum, and become a brave-but-dumb mechanic from Idaho who drinks beer and likes burgers from the local place. Your hero might be in the wrong place at the wrong time for a completely different reason.

No robot. Yes, dino

Game development is the process of dreaming incredible visions of a fantastic world, a world taken straight from the imagination and made real; and then gradually compromising, struggling, fixing, rethinking, fighting, laughing, weeping, giggling uncontrollably, drinking too much, mainlining caffeine, and frantically iterating your way to a game, a working, running thing, that probably doesn’t much look like what you dreamed, but hopefully works, is fun, is exciting… and leaves you with plenty of leftover dreams for next time.

You do need to expect to compromise when responding to other disciplines, to budgets and requirements. So expect to change everything, including the entire story, because of other factors. Or because the story itself wasn’t working. Mostly likely both, in combination. But bear in mind that changing any one key story element also potentially changes the whole story… and that changing the story, in turn, potentially changes the design, the code, the art, the sound, the whole rest of the game. If you refuse to admit this (or, worse, the project management won’t acknowledge this), and you starting leaving more and more little inconsistencies in your game — things that ‘used to make sense’ but no longer do — it will become really weak. It is not acceptable to say ‘the script was fine until everything got changed’. Adapt. Communicate. Fight when absolutely necessary. Agree wherever at all possible.

But it’s not all bad news. Often, new requirements on the story will take you in really exciting directions — original directions, directions that force you to see everything from a new perpective. Necessity is the mother of invention.

But for God’s sake, don’t give away the store just because someone says ‘Could it be a robot, and not a dinosaur?’ If the project is called Jurassic Park, sometimes you need to tell the producer who thinks he’s making Terminator that he’s sending you writing notes for the wrong game. And you really need that frickin’ dinosaur.

Writing Is Different. Writing is the same.

Writing is holistic. One whole story cannot be chopped into separate pieces and then edited in bits without regard for the whole. Writing is different.

Writing is iterative. Writing is inter-dependent with all the other disciplines, just as all other disciplines are inter-dependent with each other. Writing is the same.