What is Game Design
Game Design is a discipline involved in game development. Game Design is primarily concerned with player psychology: how will players feel when they experience this? What will they be thinking about? What will they expect, what will they want to do?
This is probably not very useful. Let’s start somewhere else.
Why am I writing this at all?
Because every single definition of Game Design I’ve found on the Internet is bad, actively harmful, misleading, talking about edge cases or the experience of people with full creative and budgetary control creating a game from scratch, which is not what game design is for 99.9% of game designers.
The least harmful definition of what game design is the Wikipedia article, and holy shit that can’t be right?
Caveats
I’ve only done game design on live games in my career. I’ve never designed for a boxed product. This colors my understanding of design. I’ve also only worked on competitive PvP games with characters. A lot of my design work has been specifically character design. This, too, will color the rest of this article. Keep this in mind. I’m certain to have lots of blind spots.
Okay, let’s start with what game design isn’t.
Game Design vs Game Development
This is the type of confusion I see most often: people using game design as a catch-all for game development. I want to be as inclusive as possible here: anyone who works on a game is a game developer, from community management to sound design. And I also want to be inclusive with the activity of game designing: a sound engineer who bakes in anticipation into a wind-up sound is engaging in game design.
So: an animator is a game developer, but not a game designer, even if part of what they do when they animate can be described as game design.
But this is pretty academic. For people who are thinking about getting into game design, it’s not very helpful. So what does a Game Designer actually do?
Let’s start from the MVP (which is also a thing a game designer will do)
First of all, a game designer does not require a computer at all to engage in game design. You can be a game designer with some index cards and a pen. Go ahead and design a card game! You’re now a game designer. Obviously if you’re reading this you’re probably not hoping to break into card game design; chances are you’re wondering about what a game designer does on a video game.
Systems, Mechanics, Game Feel, Tuning — the What
A game designer works within systems. Rarely will a game designer also create these systems from scratch, but much more commonly you will be hired as a game designer to work on a game that already exists in one form or another, and you’ll be designing within its systems. Even new games often inherit their systems from genre conventions, and that’s perfectly fine. If you’re making a new God of War-like fighting game, you’re probably going to have some form of a health bar, some kind of stamina system, a system for enemies to be staggered, a combo system to chain attacks and so on. As a game designer, it is your job to understand these systems and what they’re achieving so that you can design whatever you’re making to fit them: whether you’re designing a new weapon, a new skill, a new type of enemy, or even a new map.
Most of what a game designer creates can be described as mechanics. (Let’s not get into the academic definitions of mechanics/dynamics/aesthetics here; not very useful for people trying to understand if they want to be a game designer.)
Say you’re making a new champion for League of Legends.
As a champion designer, you will create mechanics for that champion. Generally they’ll be variations of things that exist: you could create a new skillshot or a new dash. One of the systems you’re designing within is the character you’re creating: what other options it gives the player, what type of playstyle it’s likely to evoke in the player, what its weaknesses are and so on.
For instance, as the game designer on Lucian you might decide that you’re building a movement based ADC (another system: roles that categorize characters). You want the psychology of playing the character to be one of agility, quick reactions, dancing at the edge of your attack range; you want the skill expression to be one around finding angles (either through or around enemy front line characters). You decide that because there is so much mobility in your vision of the character, you need to explicitly exclude mechanics that affect enemy movement (so called Crowd Control or CC).
So now you have your kit. But now you need to make decisions about things like which ability should take how long to cast, which animation should be cancellable and which one shouldn’t be, how quickly should a give skillshot move, what should be the size and shape of its explosion, how long should a state of heightened power (such as having your double shot passive ready or the state of shooting a torrent of bullets in your ultimate) last, what should or shouldn’t be able to interrupt your character.
You’re also getting into game feel here. For instance, how do you make him feel fast but controlled? You decide there should be one very impactful ability that has a longish cast time that roots him in place, while everything else is extremely fast. This one ability is the moment where players need to think carefully around timing, positioning, angles; it needs to be very impactful so players have to play around it, and it’s the only moment where we make you stand still. Cool!
To hit the gameplay fantasy of “dual pistols” you give the character a passive where after he uses an ability, he shoots twice. In order to nail a game feel of precision, you decide to let this double shot passive smartly seek out low health enemies in a predictable fashion so players can play around it; you decide that your skillshot should blow up in a plus pattern and not the usual circle so that the angles you care about for two of your other abilities also apply to this one. You make sure that the second shot of your passive can be fired off while you’re dashing to further hit that agile feeling. You build a system of using your passive to reduce your dash cooldown to nail the feeling of being smart and purposeful; instead of mashing all your abilities at once, you have to build smart back and forth loops of ability / attack / ability / attack.
Finally, you start looking at everything that affects balance while keeping in mind how your tuning changes affect everything we’ve discussed so far: game feel, individual mechanics, and how your champion fits into the larger systems that exist. You look at damage numbers, delays that give the enemy a chance to dodge, ranges, cooldowns, resource costs, etc.
Note what I haven’t mentioned anywhere in the section above: I’ve not said a single word about scripting or coding, about specific visuals, narrative, sound, visual effects and so on. The discipline of game design is primarily concerned with the things I mentioned above. (Caveat: see section Reality is Messy)
Ideating, paper kitting, scripting, other tools — the How
Now let’s talk actual tasks a game designer has in order to create the above.
Ideating, or finding and selecting what you want to build, is often, but not always the first stage. You generally do not create a game from scratch. So before you even start ideating, you need to make sure you understand what else exists for the game you’re designing for, why these things exist, how they interact, and so on.
Ideating is the process of coming up with a useful idea for something you could be building, but also the process of knowing when to reject an idea or how to change it so it better fits the rest of the game. This is usually a very collaborative effort where lots of game designers brainstorm together, or at the very least give feedback on your ideas.
Paperkitting is the process of putting some stakes in the ground and deciding early details for the thing you’re building. You’ll usually describe the design in whatever level of detail is appropriate. These days this mostly happens in a google doc that lots of people will comment on. Sometimes there’s more text in the comment threads than in the actual document. Paperkitting should not try to solve all problems but instead focus on the most important details that can be decided at this point.
Once you’ve paperkitted out your design to a sufficient degree that you feel you know what you need to know, you start building it. Notice how there’s all this work that has already happened at this stage but you haven’t even touched the actual game files yet. All this is game design.
Prototyping or kitbashing is the process by which you make your idea “real enough”; here’s where the MVP (minimum viable product) concept comes in. What is the least amount of work you can do to have a good enough approximation of your design that you can playtest it and get good feedback? This is a highly subjective question and designers will absolutely disagree how much of a thing you need to build to get to an MVP. You generally build your prototype by kitbashing it: that is to say, by taking existing assets (animations, sounds, models, textures, VFX, etc) from other parts of the game and repurposing them (often by crudely editing them) to represent the design you’re working on.
This isn’t about building a thing that’s robust or super cool or impressive; it’s about answering questions. Such as, is this fun? Do players understand what I want them to do? Is this fair? Do enemies have play around this? Your goal is to build something that looks and feels unfinished and placeholder. Good production value can sell a bad design. You want your prototype to look janky as fuck, like it’s barely hanging together with duct tape and chewing gum.
Your work now is to make people playtest your design, give you feedback, then to sit down and think hard about that feedback (did they get confused about something you’d expect a new player to get confused about or is there a fundamental problem? Did they react to poorly tuned content or is the pattern at fault? Is their dislike because of something wrong with your design or is it a player taste thing?) and iterate: that is to say, based on the feedback and your analysis of it, make changes and test again. You do this over and over until your design is ready for production.
At this point your work turns from discovery to making it real. This is where a lot of scripting and working with other tools happens. This is also where you work closely with other game devs that create animations, visual effects, sounds, and so on. This is also where you work most with engineering: anything that shouldn’t exist in script for performance or robustness reasons gets moved to code; things you could only do poorly in script gets built in code for real.
Reality is Messy
What I’ve described above is exaggerated in its clean separation of disciplines. Of course designers do not work exclusively with abstract geometric shapes in a grey void. When you pick the pieces that you kitbash your prototype out of, you absolutely think about the visual appeal of what you’re building; you think about the gameplay fantasy and the narrative for the character, you think about what they should sound like, how they should move, and you pick pieces that approximate this. When you work with your designers and writers and sound engineers, you don’t come to them with nothing: you come to them with a vision that you explain and then protect by checking everything that gets made against that vision. When something doesn’t feel right, it is your job as the game designer to go and talk to whoever made the asset and work with them to better approximate the overall feeling and vision you’re building.
It is also extremely useful for a designer to be adept at scripting. The faster you can build prototypes, the sooner you can move on to validating them in playtests. Having good visual aesthetic sensibilities will help you build mechanics that mesh with the overall visual goal of your design. Understanding concepts from animation such as anticipation and follow-through allows you to design mechanics that will feel right — the right amount of hefty vs speedy, impactful and weighty, anchored in the world of the game.
And the same is true on the flipside. A good animator understands the design of whatever they’re animating. They understand which moments are important, how they can help work toward the overall goal by over- and underemphasizing certain parts of the movement, they understand tuning around animation cancels and animation locks and help sell those moments.
Being Inclusive But Being Clear
The reason this article is so hard to write for me is that I want to be maximum inclusive: everyone who works on a game is a game dev, and everyone who works on a game will do some amount of game design: from a social media manager who uses the right language to describe an upcoming character to mold player psychology from before the first time a player experiences the design all the way to the QA specialist who has opinions on which bugs are actually bad for the intended design and which can safely be ignored or deprioritized.
But when people ask me how they can become game designers, I have to assume they’re talking about the actual job of a game designer.
Why I wrote this
I wished there was a better description that I can link people who come to me with questions to; something that explains what a game designer is and what they do.
Look, let me show you why I’m so upset. Here’s one of the top results I could find:
“Video Game Designers design core features of video games.”
That’s super helpful! Next you’ll tell me graphical designers design graphical things?
“Specify innovative game and role-play mechanics…”
What the fuck are “role-play mechanics”? Specify? Like you speak a mechanic into the world?
“…story lines, and character biographies.”
Nope. That’s a narrative designer’s job.
“Create and maintain design documentation.”
Show me a piece of design documentation for a shipped game and I’ll show you a hilariously out of date document that no one but the original author has ever looked at.
I could go on, but I’ll spare you.
So to reiterate: a game designer is not:
- The “ideas person”. There’s no such thing.
- A visual artist. They can be and it’s great when they are, but that’s not what game design is.
- A writer. Narrative design is separate from game design.
- Primarily a coder. It’s helpful to know how to script, but you can be a game designer without writing a single line of code. (This is unrealistic in the real world, but I’m saying it to make a differentiation here)
- A UX/UI designer (again, very useful to be good at, but a separate discipline)
Do you need to know how to code to be a game designer?
You know how I said a bunch of times up there that you can be a designer without writing a single line of code? That’s only true in an academic sense. Any modern studio you work at today, as the game designer you’re expected to have some ability to script. Maybe you don’t need to be able to write performant pathfinding algorithms in your sleep, but you should be able to think algorithmically: that is to say, given something you want to achieve in a game, you should be able to come up with the instructions for a computer to make the thing real.
It’s more important to be a fast scripter than to be a good scripter. Eventually, yes, you’ll be responsible for the quality of the script you wrote that will actually ship to players (always more than you expect); but there’ll be an entire department of designers to help you get there, and typically engineers are very invested in the quality of script that is released as well and will happily review your work and help you make it better. While you’re building something though, it’s vastly more useful that you can achieve something quickly; because 9 times out of 10, you’ll throw away the thing you scripted and try something else. That’s iterative game design.
How do I become a designer?
Honestly, there still isn’t a great path to becoming a game designer. The courses offered in many US universities are getting better, but they’re certainly not guarantees that you’ll get a job. Also a lot of these courses are much more interested in teaching you game development rather than game design (I hope you remember the distinction!). This is a good skillset to have of course, but it means you’ll spend less time actually learning game design.
The best you can do in my opinion is to make games. As I said above, you can make a game right now. You don’t even need a computer! Design a card game, or design a board game, or design a table top role playing game. That prospect too daunting? Cool, design WITHIN an existing game. Maybe you’re a big fan of Magic: The Gathering? Awesome! Design a few cards (ideally cards that work well together) then play your design with a friend. Take feedback after, think about the feedback, and iterate on your design. Maybe something was OP and needs to be tuned down? Maybe some situation you imagined would arise regularly never arose and so your card never did anything? Cool! Figure that out and iterate!
Or you could make mods for a game you enjoy! Or you could jump into a game with a robust creative mode that allows you to make games within the game — I hear good things about both Fortnite Creative and Roblox. Or make your own small game with a toolset such as Twine; you can do way more than just text adventures in Twine. Go build a JRPG in Twine! You’ll learn lots about scripting, narrative design, but also game design things like building a combat systems, designing scarcity into your resource loops, and so on.
And when you’re done with that, put what you’ve built on your CV. Extra points if you can make it available online.
