I get nervous a lot. I have a lot of anxiety. Saying things that sound like I’m making a globally true statement is both fun and nerve-wrecking. So what I always want to do is add a shit-ton of disclaimers. However, that would slow individual posts down, so I figured I’d write one standard excessive disclaimer post and link to it whenever the anxiety gremlins gnaw at my heart. This is that post.
First, if you’re making a game that people love, you’re doing it right. Don’t listen to me.
Next, there is no such thing as a video game. There’s at least three genders of videogames (I just got here), being:
- Predominantly narrative experiences
- Predominantly systems-driven experiences
- Predominantly dexterity-based experiences
Writing this not very exhausting list I came up with potentially a fourth category, but it only consists of geoguessr, so not sure how useful that is. (Predominantly knowledge-check driven games? Trivia games live here too, I think).
I mostly play and exclusively make predominantly systems-driven games. I could probably make one of the other types as well, but I’d suck at it.
So when I say “game design”, I need you to hear “game design for predominantly systems-driven games that probably are PvP and free to play”, because that’s what I know stuff about.
Knowledge and skills transfer unless they don’t. A lot of the things I have to say about, say, clarity, viscerality (yikes, that’s a 2012 word for you), and motivation probably apply both to single and multiplayer games, but stuff like mastery, complexity, fairness, counterplay etc probably only apply to PvP multiplayer games (at least in the way I’m talking about them! They all APPLY in their own way for single player games, for instance, and maybe even for narrative games, because every game is a little bit of everything, but I wouldn’t follow my advice if you’re not making the kind of game I know stuff about.) (I wouldn’t follow my advice at all, actually. See next point.)
You don’t know anything unless it’s in the game. All of this is “dancing about architecture”. It exists for entertainment purposes. I am not a lawyer, astronaut, pastry chef, or insurance adjuster. I’m just a little funky lad who makes predominantly systems-driven PvP multiplayer games that are probably free to play.
Iterative game design is a tautology. There is no other kind of game design (in predominantly systems-driven PvP multiplayer games that are probably free to play.) You can write a 200 page game design document and have people follow it to the letter, but that’s the equivalent of putting a million monkeys in front of a million Visual Studio instances and hoping one of them writes cogent C#. You don’t know anything unless it’s in the game (q.v.)
Every rule will be broken, by me, in everything I work on. The rules are there so I can think of the “default” mode of design. Nothing ever gets made fully in default mode.
Good bespoke hand-made game design matters a lot… in predominantly systems-driven PvP multiplayer games that are probably free to play and once the player has played for a 100+ hours. If that’s not what you’re after, store-bought game design is just fine. Seriously. Sometimes design is coming up with the most complex and engaging challenges while also crafting the most intricate and mastery-full tools to overcome said challenges, and sometimes it’s doing the obvious bare minimum so the player can have their 10 hours of fun (remember when we made games like that?) and then getting the fuck out of the way.
Design is coal. Art, music, sound design, UI etc is tinder, small twigs, medium-sized logs. Narrative is the big ol’ logs you throw on when the fire’s going nice and steady. You can’t make a fire with just big logs. You can absolutely not make a fire with just coal (only of course you can as long as you pour enough accelerant on the coal, but that doesn’t fit my metaphor so I’m ignoring it). But also if you want to have heat for days, twigs won’t be enough.
(To add a disclaimer to that last disclaimer, you need all of these at all points, but the point when their maximum effectiveness in entertaining, hooking, and satisfying a player kicks in is different for all of them. Great art and graphics? Immediately appealing. Super deep game design loops that keep you coming back for more? Probably won’t even notice them for the first 10 hours or so.)
No one discipline is more important than another. Games do not run on silicon, they run on synapses (q.v.). You don’t know what strange alchemy of perception and interpretation transforms your audio-visual stimuli into subjective experience and enjoyment. Maybe it’s not the most important thing to have shiny god-rays and ray-cast shadows and reflections, but maybe it is? Maybe the right art direction on a character turns that character from an odd niche choice to a popular favorite. Maybe just the right sound on your gun has a player continue playing your game until it clicks for them when otherwise they mightn’t have? You don’t know.
Games run on synapses, not silicon. The code you produce runs on silicon, but the code is not the game. The game happens in the player’s mushy and soft hardware, that is their brain. Only a fraction of the signals you put out will be received, non-existing signals will be hallucinated, obvious loud “press X to continue” prompts will be overlooked, your exciting and counterplay-ful skill design will fail because someone didn’t hear a sound cue or didn’t understand what they were supposed to do, or invented a story of how your skill works and played according to that story and never noticed it was wrong. And that is good and proper and how it should be. Spend more time debugging the game that’s executing on synapses than debugging the game that’s executing on silicon.
We’re all game developers. QA is game dev. Community is game dev. Customer support is game dev. The person who cleans the studio after hours is game dev. We’re all in this together and the only gatekeeping we have to do is of gatekeepers.
That’s why I don’t want you to call everyone a game designer (although everyone does game design when they work on a game, there’s a specialty, and it’s my specialty, so I’m protective), and I don’t want you to call engineers and only engineers “game devs” (although that seems to be a Brazilian thing. So if you’re Brazilian, first of all, tudo bom? Secondly, engineers are engineers, everyone’s a dev. Thirdly, roda, roda e vira, solta a roda e vem, me passaram a mão na bunda e ainda não comi ninguém.)
Being technical is super important and also doesn’t matter. If you’re making a computer game, someone has to know how to make the computer do what you want the computer to do (if they ever find a person who does, let me know). But also, if you’re a game designer, you don’t have to be that person. It’s super useful if you are, both because you can make your own thing and because even in a studio structure with engineers and tech artists you can still be a self-starter and slap together a prototype with no one’s help, but if like me you have a very limited number of very tired brain cells and they tell you you have to pick one, pick game design.
Be good at what you’re really good at and spend your time on that. Except if you don’t want to, then go and do everything. But if you want to maximize your impact and you have the structure around you where you can let other people do the things you’re not good at, do that. Go really deep on what you’re excited about and good at.
But also being T-shaped (ugh) isn’t a bad thing. Especially when it comes from a genuine place of curiosity. I’ll never be a sound designer, but I’ve got Audacity and I’m not afraid to use it. I can google for ways to do things I can’t do and teach myself the bare minimum if that is the best use of my time or if I really want to.
Wait, this isn’t a disclaimer article anymore. That brings me to my next disclaimer:
I’m not good at writing blogs. I don’t know who I write for. Some days it’s my peers (hi peers), some days it’s the hypothetical game design student who’s wondering if there’s more to game design than knowing where the right knobs to twiddle are in Unity (there is; you can twiddle knobs in Unreal as well, but that’s it). Sometimes the intended audience changes halfway through an article. I am very sorry but also maybe that’s charming?
I have ADHD. I should have started this disclaimer with that. I have very loud ADHD. And sometimes it’s fun embracing that.
So: this blog will talk about game design a lot, but really I should be talking about “game design that’s worked for me on predominantly systems-driven multiplayer PvP games that are probably free to play and that you want players to invest many hundreds of hours into.” Sorry, I should have said that upfront.
To my many design colleagues who do other kinds of design: please tell me where something I say really doesn’t apply to your type of design. I’d love to learn!
To the three game design students who will eventually stumble across this blog, scratching their heads: consider just getting an MBA in making money? You won’t get laid off as often and you’ll probably be able to buy a house some day.
To my dogs: I’m sorry I couldn’t pet you these last 15 minutes, this was a very important post to write that I had to get out of my system.