Writing: A game designer’s secret tool
If there’s something elemental about being a game designer, it’s the writing.
With my growing passion for RPGs lately, I felt it appropriate to grab myself a copy of the 5th Edition of D&D Player’s Handbook. After marvelling at the impeccable writing like Patrick Bateman with the business card, my brain threw me back to when I watched a video of Richard Bartle speaking of game innovation¹.
In the talk, he speculated some ideas on how you could easily spot a game designer. Two points in particular stood out for me:
- They’ve got stacks of game design documents lying around.
- They read game manuals.
Remembering his points felt timely because in a way, the handbook itself was a glorified game design document (GDD) detailing the modularity of the game’s design.
Additionally, it was only today (or at least, a few days before publishing this post) that I was reading Dead Space’s game manual. Here’s a snippet of it:
You can see how readable everything is. From how the upgrade benches work to what goes on in the inventory system; even a child could understand it. Yet another example of a perfectly well-put GDD.
Learning games through their manuals and jotting down your own documentations makes you no less a game designer than a child with Play-Doh. Even so, it highlights your dormant sense for problem-solving and audience empathy.
I wager this is where the controversial question of ‘Are GDDs really useful?’ comes from. But the difference between amateur and professional GDDs is the latter considers the audience they’re being written for.
I believe that’s where writing shines so much.
GDDs, game bibles, pitch decks, whatever you want to call them, all have clear and succinct writing that help validate the vision and the concept at a large scale. How you write makes all the difference between who agrees with your idea versus who’s still left scratching their heads. It’s low-key persuasion.
Some may not know it. Some may already do, but don’t realise it. But I think adopting this ‘secret’ tool (maybe not ‘secret’, but it certainly wows people) can work wonders for your design plans.
The problem is…
It doesn’t get covered enough!
There are many game design books that stress the need for soft skills for one to become an efficient designer. ‘Communication’, ‘listening’, ‘feedback’, ‘experience’ and ‘documenting’ are common words that get thrown around.
Yet, writing in and of itself is seldom mentioned as a core aspect. Or it’s mostly sidelined as a ‘good to have’ add-on when you talk to some designers. When we put it that way, it gives the notion that it carries minimal value. What happens then? People wouldn’t care enough about it!
It’s also treated as the ‘obvious’ element when we mention ‘documentation’. I felt this quote from one of Bartle’s personal blog posts strongly applies here:
It’s often a surprise, though, just how much something that is obvious to a person who’s been designing games for decades is not obvious to someone who doesn’t design games at all.
In my eyes, the industry is still young and so are its people. As much as focussing on other design aspects is crucial, some people skip out on the writing part. They don’t realise it helps them make sense of their design.
With that said, writing — in the context of design — is NOT obvious at all.
In fact, the unspoken consensus is there’s a need for designers with a strong knack for good writing. What stopped the employers from tossing my application at their rejection pyre was my unique background with design and writing. It took me by surprise, in all honesty.
So why is writing important?
Well, in my experience, good writing exposed me to a layer of articulacy that I couldn’t normally get from other methods of designing or brainstorming.
Whether it’s to ask the right questions, layer all the answers, choices, and possibilities, or figure out how to quantify abstract or absurd concepts.
It’s also a better alternative to the more-than-usual moments of ‘we had a lot of back and forth about it’. This seems rather Russian Roulette in nature in that you’re hoping something clicks between you (the designer) and your teams.
Or sitting beside a developer, telling them word-for-word what to do instead of providing a complete design in one go. Some designers do this, as unbelievable as it sounds.
Unless it’s a miniscule change that doesn’t affect the rest of the design (which is rare), every bit of design or redesign is planned.
Liz England’s Door Problem² is the perfect example of what writing can do for you; I imagine it probably came with hours and hours of brainstorming, discussing, and phrasing and rephrasing questions the right way.
Better yet, you would have naturally ran into user persona write-ups³ if you are currently practicing UI/UX.
Bottom line, designing isn’t improv. Not at most times. Writing — better yet, good writing — can help you put your design together in line with your vision with high precision, which is something you intend to achieve.
All of this helps determine your design’s conviction.
What do I mean by ‘design’s conviction’?
The entire marketing industry is testament to how powerful writing can be. Without the right words, you cannot compel anyone to try your product. Heck, Instagram is a haven for one-phrase posts with high user engagement.
It’s the same for when you’re trying to pitch your design. Writing can cater to your thought process and help evolve it. If used correctly, it may even dig up difficult questions about your design, for which you need time to think of good answers.
Questions that, if you manage to answer clearly through writing, can convince the reader of your design’s validity.
In other words, right words gets you valid design. The manner in which you talk of your design’s logic directly affects how it sells.
Of course, you can only do this if you can convince the right people. Most of the time, it’s NOT your players. It’s actually your team.
Your programmers, your artists, your producers, your darn friends and families! If they can’t buy into the concept you’re putting together, you can’t hope to sell it off to the public at large.
This translates well in situations where you (a designer) must work with other teams, especially programmers.
What designers do wrong with writing
An acquaintance told me of their experience working with programmers to create the design components and mechanics for a VR game. I wager they’d rather run 3 triathlons than have to go through that pain again.
The coders couldn’t understand how the design worked. And if they did by God’s will, then they’d later realise the technical complexities later and refused to get it working.
I’m sure most designers and programmers can relate to this. That’s simply the nature of game production.
That being said, game designers simply don’t think in terms of readability or clarity in most cases. This mindset doesn’t do much in favour of the teams involved.
This is echoed by the woes of other development teams who take a strong stance that entire documents and bibles that drone on about the A to Z of the game are a dime a dozen.
Not to mention their notoriously vague nature make programmers in particular gag and yeet it to the side.
As a designer, I sympathise with the other teams. What’s worse is most designers don’t acknowledge this mistake.
I can see how — from the designer’s perspective — it’s tough to think about whom we’re writing for when we’ve got our main target audience, i.e. the players, bolted into our minds all the time. Still, we must make the effort to change whom we address as the audience once a while.
In fact, Brenda Romero’s guide on creating GDDs⁴ nails this aspect:
Before you start writing, consider [who] is your audience. Many new designers write documents as if they’re being written for gamers instead of a programmer who’s tired, annoyed and up at 3 a.m. coding your combat system. The latter is your audience.
But the programmer example is one of many. We still have the other teams to worry about and many factors to consider. As a tiny example, finding ways to adapt their lingos to your writing is one great way to propose your designs without putting off your teams.
This is how designers can take charge, be responsible, and keep documentation accessible. In other words, be a team player. Writing helps a lot with that because it helps adjust your mindset towards your target audience.
In fact, writing IS the initial stage to designing
And this will remain the case until the designer understands (not by feeling, but by knowledge) that the design works. We can’t beat around the bush with that. Unfortunately, some non-designers don’t take this for an answer.
Writing sets the stage for what your game is about. It’s how you find the perfect one-liner to stick by.
Ann Handley, the author of Everybody Writes, talks about how you must reshape your ideas into something digestible to remind yourself why what you’re writing about matters to the reader.
In essence, whittling your vision down to a single, sellable line can dictate your thought process for the entire project. You can think of it as an elevator pitch to yourself. In other words, not a marketing tool, but a compass.
The more you simplify the nature, intent, and purpose of your idea, the stronger the constraints you apply to keep yourself from overscoping. In other words, straying from the path you started on.
Without good, consistent writing, this will be made difficult for you.
All of this serves towards the point that you will flesh your game idea out in a nick of time than without, no matter how small that idea may be.
It’s why, in my opinion, arguments such as ‘you don’t need a GDD for your first game’ is rather weak. Most folks barge in with their usual ‘I WANNA MAKE A GAME’ chestnut, so pushing the narrative that design — the writing part especially — is part of the development process is pertinent.
This way, we transform aspiring game designers’ thought processes and turn them into better game designers.
Arguably… designers are, inherently, writers
Before we began clacking away on our K&Ms making digital games, tabletop games were, and still are, the rage.
Board games, card games, dice games, you name it: You always needed a cleanly-written instruction manual or document lest you leave the player in the dark about what your game is about and how to play it.
Back then, the onus was on game designers to write all of that down. There was no dedicated person for that. The result was almost always a succinctly written booklet that covers all the spectrums of design — level, puzzle, UI and narrative.
Use cases for documenting can be different when it comes to digital games, of course. That said, it shouldn’t be looked at as ‘less impactful’.
For as much as there are people who want it done away with, there are an equal, if not more, number of people who are in the middle of a game’s production wonder if there’s a central point of reference. (Irony abounds.)
Non-designers fail to understand the importance of it, at times shaming us with the ‘do you actually do anything?’ argument. Though having to say ‘staring at spreadsheets and documents and designs’ doesn’t help paint us as ‘useful’ in their eyes, it is indeed the ELI5 of it. We can’t twist that truth.
Designers are writers, plain and simple. Designers must embrace this, non-designers must accept this.
So if you’re a designer, you should learn writing
‘I should?’, you ask.
Absolutely.
Both require you to study your prospects closely, both need a strong incentive to fuel its believability, and both need you to consider the audience you’re trying to grow.
Essentially, you’re solving a similar problem: How do I retain and engage my audiences?
Writing is to designers as a chisel is to sculptors; you could thunk away at an idea long enough to get something that works, or understand how to use writing the best way possible to create something brilliant.
Write your documents, whittle your ideas, manage resources and learn how to address both the external and internal target audiences. This is part of growing as a designer, wherein you’ll eventually turn those documents into actionable prototypes.
And with that, I’ll leave you with a few good footnotes to look into.
[1] ‘Innovation in Game Design’, game design talk at Tallinn University Institute – Richard Bartle
[2] ‘The Door Problem’, April 2014 – Liz England
[3] ‘What is a User Persona and How Is It Relevant to UX?’, August 2018 – Himanshu Khanna
[4] ‘Creating a Game Design Document’, November 2008 – Brenda Romero
Misc. References
- ‘One-Page Design’ GDC Talk – Stone Librande
- ‘The Design of Dirty Bomb’, in-depth GDD – Splash Damage
