EXECUTIVE SUMMARY
GAME DESIGN COURSES DO NOT TEACH GAME DESIGN
DESIGNERS WORK AT THREE LEVELS OF ABSTRACTION
HOW DO YOU BUILD WHAT YOU WANT
WHAT IT IS YOU WANT
AND WHY DO YOU WANT THIS THING
HOW IS THE EASIEST TO TEACH
WHAT CAN BE COVERED BY PLAYING A LOT
WHY IS THE CORE OF THIS BLOG
THE MORE SENIOR YOU BECOME THE MORE YOU CARE ABOUT WHY
WE SHOULD DO A BETTER JOB TALKING ABOUT OUR WHYS
Game Design Courses Only Teach You How
As you know, Bob, I don’t think very highly of most game design courses. I assume they are all created and taught by well-meaning and informed academics. They often interface smartly with the computer science and arts programs at the institution where they are taught. And often students do get real life experience in seeing a game project through from start to finish. That’s awesome. Some really good games have started their lives as student projects; Portal comes to mind, where Valve basically hired the student team and told them to make their student project again but this time with production value and experts ready to help.
The only tiny little problem is that these courses do not teach game design.
That’s of course an inflammatory statement. What I mean by this is that they teach a lot about HOW to make games, and a little bit of academic theory (that is to say, how to analyze games), but if there’s any instruction in why one would choose one game mechanic over another, how to solicit good playtest feedback, how to iterate, and so on, then they’re keeping that a secret. It’s definitely not reflected in their syllabi.
Going to university to study game design will teach you how to make a game, but it won’t teach you what to put into your game and why to choose one element over another.
I think that’s on us, the game design community. We don’t do a very good job communicating what it is exactly that we do. That’s sort of the raison d’etre for this blog: maybe I can communicate a bit better what it is that I love doing.
Anyway, what do I mean when I say these courses do not teach game design?
Let me first be super clear here when I say I don’t want to gatekeep this profession, this calling. If you make a game, you’re a game designer. Congratulations! Welcome! We’re sorry! (for everything)
But when you just MAKE a bunch of games and focus on the how, on the logistics of getting the computer to do your bidding, or even on the physical process of making card or board games and making the rules clear and parsable, then you’re still just taking shots in the dark.
Malcolm Gladwell may have told you that it takes 10000 hours to master a skill (which is wrong, but that’s neither here nor there), but he neglected to mention that it takes more than just time. Veritassium has a great video that actually backs its claims up with science on this: https://youtu.be/5eW6Eagr9XA?si=6NxbT1bVWhy11zGi
The TLDW is that on top of putting in a lot of time, you need a few more things to become really good at a skill. You need iterated training with timely feedback (did you do well or not, told to you as quickly as possible), you need a valid environment (you can’t become a coin flip master, or a wall street investment master, which is the same thing), and you need to constantly challenge yourself. And that’s just for the base skill of making games humans love.
When you get your timely feedback in a valid environment (someone unbiased in a feedback tells you “this sucks” as they close the game, for instance), the next step is figuring out why it sucked and how to improve. I don’t see any evidence that students are taught this, neither from the syllabi I’ve looked at nor from the many juniors I’ve seen hired straight out of school. When it comes to design problem solving, someone who’s graduated from a game design program does not seem to have an advantage over someone plucked from a random unrelated industry. I’ve seen finance people, music producers, and urban planners exhibit more structured and useful design thought than recent graduates from design courses at USC or Carnegie Mellon.
That’s weird. Those courses aren’t cheap. No one sets out to teach students a bunch of stuff they can’t use.
When I think about what’s going on here, I usually come back to the three layers of abstraction. Let’s go through them and maybe use a fun example to illustrate how a junior designer would employ these tools.
LAYERS OF ABSTRACTION
First, a quick summary.
HOW: Assume you have a particular behavior you want to implement in your game. How do you do this? Do you write script or, god forbid, code? Do you just enter a bunch of different numbers or select a bunch of different drop-downs in your suite of tools? How do you implement the VFX that communicate gameplay? How do you enter delays? How do you block other inputs while an attack is playing out? And so on.
WHAT: Okay, but what is it you actually want to put into your game? What actions should be available to the player character? Sure, they should be able to jump, but should they double jump? Should the double jump have the same amount of impulse as the initial jump? More? Less? Should the player be able to wall-jump? Should wall jumping reset the double-jump timer? What happens when the player jumps onto an enemy? What happens when they jump onto a boss? What other tools should they have?
WHY: Okay, but why? Why do we choose double jump over single jump or triple jump? Why do we unlock it from the beginning vs unlocking it later? Why do we lock out the player’s other inputs while an attack is happening? Why should these enemies die in three hits vs 10 hits?
The how is the implementation. It’s doing what an engineer does, but poorly.
The what is your set of gameplay patterns and nouns and verbs.
The why is your set of theories and frameworks and goals behind it all.
FROM JUNIOR TO PRINCIPAL
A common career path in design starts at the level of associate/junior game designer. Normally, a junior designer is supposed to be able to execute a small, self-contained feature that is described to them by a more senior designer with a small amount of oversight.
That sounds like I’m saying a junior designer only deals with the how, and that would make the choice of these game design courses make a lot more sense: if all you need at the start of your career is the how, why would they teach anything else? But it’s not that simple. While you’ll be thinking mostly about the how in your first few months on the job, you’re constantly making WHAT type decisions at a micro level, and if you’re super curious and talented maybe you’re already asking your lead WHY type questions.
But actually it’s worse than this. The above wrong assumption could be summarized as “a junior designer only needs to know HOW, so that’s all a course needs to teach”. That’s getting it backwards. It’s actually closer to this:
“A junior designer will usually only know the HOW, so that’s all we can task them with.”
— someone I made up
This is also true usually for self-taught designers and folks who join our industry from the modding scene. This is the reason game design can draw from so many other fields for its candidates: there isn’t a particularly useful way to learn the trade before you start working. It’s all learn on the job stuff. (And nothing wrong with that, in theory. We should in fact de-emphasize university learning and accept that many jobs that now require a BA or more could much more efficiently and cheaply be learned on the job. There’s no reason anyone who goes to work as a web dev should have to study computer science and learn about building compilers and mathematically proving the runtime of a given algorithm.) (This is a subject for another post. I can tell because I want to keep writing and we’ve already detoured too much.)
So let’s follow our hypothetical junior designer. She’s just been hired to be an associate champion designer at Riot Games working on League of Legends. Awesome! She knows the game inside out and is eager to jump in. After some initial shadowing, she is assigned her very first character. (This is a little unrealistic; you’d be a mid level designer before you’re designing a character on your own, but much of what I’m about to say would apply to the more realistic but boring choice of “small scale character reworks” that an associate would actually work on as well.)
She sees the concept art and is very excited: we’re making a big scary Kaiju-style monster. Awesome! And she’s had a month or so to learn the tools and they seem very straightforward, plus there’s 150+ existing champions where she can dig through script and learn / copy from. Cool!
She gets to work and builds a big scary scream attack that damages and slows, a stomp attack that deals persistent AOE damage around the character, a big fat skillshot where her character rips a chunk of rock out of the ground and tosses it at the enemy, and finally for the ultimate a big Godzilla-style laser that shoots out of the monster’s mouth. She figures out how to build these things very quickly; they’re very similar to existing skills.
And then the first playtest rolls around and disaster strikes: her character isn’t even close to balanced and immediately causes such an imbalance in the teams the test has to be restarted without her character. Okay, happens to all of us. She goes back and nerfs her character. Next test, no one can even get out of lane on her character without dying a dozen times and it’s basically useless. Okay, so maybe somewhere in between? Many more playtests come and go until she finds tuning points for all abilities that seem acceptable, and then comes the most crushing feedback: now that her character is balanced and fair, it’s just kind of… boring? It doesn’t seem to do anything new or interesting.
A ruder more veteran playtester goes through it ability by ability: your Q is just Camille W without the inner/outer gameplay, your W is just Alistar E without the stack gameplay, your E is just Big Gnar Q without the pickup gameplay, and your R is just Vel’koz R without the slow turn gameplay.
Devastating (and of course a good lead would not have let it get to this point) but in our hypothetical designer’s defense, where and when would she have learned WHAT to build?
FROM HOW TO WHAT
As you are promoted throughout your career, your area of responsibility grows, the expectation that you will show initiative and pick your own battles grows, the oversight you’re supposed to require to do your job decreases, and as far as game design is concerned, you’re supposed to master the how pretty early, get good at the what around mid level, and then beyond that dive very deep into the why.
A mid level designer (usually job-titled Game Designer) is supposed to be able to solve a small-scale problem where they’re only given the problem statement, but not the solution. This means they’re now fully expected to own the WHAT. In practice, these things are usually worked out collaboratively, especially in bigger teams.
So let’s revisit our hypothetical character designer a year into her career. She’s now mid-level and given her first character for real. She spent her first year perhaps doing small reworks, fixing bugs in existing characters, or tag-teaming a mid-size rework with a more experienced designer. Now she’s ready to build her own character, and she’s learned WHAT to build.
From her experience playing both League and other MOBAs like Dota or Heroes of the Storm she knows a lot of ability patterns and kit patterns. She knows about core loops, ability combos that players will want to use together, she knows about setup and follow-through, about hit-confirm abilities with a risky full commit option and so on.
This time she builds her character around a core passive first: Impending Doom. The longer Kaiju remains in battle, the more threatening but also the more exposed it becomes. Her monster hulks out and gains damage, attack speed, ability power, ability size, and eventually at full stacks true damage. She knows the importance of telegraphing critical gameplay, so she works with her 3d artist and VFX artist from the beginning, brainstorming cool and clear ways to show the different stages of power. At the same time, her monster loses armor and magic resist as it hulks out and becomes reckless, allowing the enemy to take it down.
Cool. From here she sets up a two stage chomp / tail sweep Q where the chomp heals her kaiju based on the target’s missing health and the tail sweep deals current percent health damage. These are familiar patterns she’s seen in a lot of places and they seem to make sense. The W becomes the toss ability, but to make it more interesting, the kaiju only tosses rock when there’s nothing else in range. When there’s a minion or a monster in range, the kaiju tosses that instead, and emboldened by early lane tests, our designer decides to embrace her inner chaoslady and allows her character to also toss nearby champions, both allied and enemy. “That’s crazy,” remarks a more senior colleague. “Yeah,” she thinks, “so crazy it just might work.”
Realizing that most juggernaut-shaped characters should have a defensive ability in their kit and that said defensive ability usually goes on the E, she comes up with a shield that scales with recently inflicted damage and also boasts a very solid base value and bonus health scaling, but to make up for all that defensive power, she applies a self-slow to kaiju.
Finally, she really liked her laser-breath ultimate, and to differentiate it from Vel’koz R she makes it unit-targeted (so it automatically snaps to the nearest enemy champion) and also has it slowly push the enemy away during the cast duration. She plays around with that in editor a bunch of times and the feeling of power when she melts an enemy healthbar and slowly pushes them away feels great. The VFX artist sees a video she posted of the ability in Slack and becomes super inspired, quickly building preliminary VFX and dropping it in, and the ability looks like a clear winner to everyone.
Then come the playtests and while it’s not disaster this time around, it’s also not great.
While everything reads great on paper, reality asserts itself. It turns out that most of the time, players do not have agency over how long they are in a fight. Sometimes enemies just flee (and it turns out there’s nothing in this kit that stops them from doing so), sometimes teamfights with very bursty teams are decided in seconds, one way or the other, and so the passive feels really bad: there’s a lot of theoretical power the player wants to access, but outside of the laning phase they have no way to make it happen. The designer briefly considers letting an in-combat state with AI also trigger the passive, but one playtest with a sophisticated playtester abusing the hell out of this by constantly keeping the passive up in lane convinces her otherwise.
Her Q doesn’t work like she thought either. In her head, she expected the tail leash part to drop high health characters to low health, at which point the chomp would heal kaiju. Awesome little loop! In reality it turns out though that with realistic damage values, one ability alone cannot affect the enemy healthbar enough for this to ever become relevant. Instead, based on the enemy’s current health, it feels like either half of kaiju’s Q is always useless.
The worst offender though is the W. A few playtests after she enabled it working on enemy champions, a very strange thing happens: people stop using the ability altogether. It turns out that if you dangle an incredibly high value use case in front of your players, they will hold the ability until they get access to said use case. And now it also turns out that repositioning an enemy is inherently so powerful already that there isn’t a lot of power budget left on the ability for damage, so not only are people not using the other use cases (no target nearby / minion nearby) because they’re holding it for usage on the enemy champion, the game also further reinforces that they should never use the “bad” version because it does so little damage.
And even though kaiju players hate the W for how hard it is to use, feedback from the people playing AGAINST kaiju is similarly negative: they only remember the rare times when the W DID work and threw them deeper under tower when they already had tower aggro, basically killing them with a single basic ability.
It goes on and on: no one actually likes using the E because it just allows enemies to either run away or ignore kaiju in the front line and access the backline. Scaling a shield turns out to do very little if the enemy’s correct play is just to ignore the shielded character. The ultimate finally keeps pushing people out of range, cutting its own damage potential short, and even when our designer changes it to not push enemies farther than 80% of the ability’s range, it still helps enemies get away from kaiju, and most of kaiju’s power is in its melee attacks. Players never use the ult except to finish and enemy off.
What happened? Well, our designer applied a good amount of WHAT knowledge. She recognized patterns of abilities from other games and other characters, she found cool things that worked together very well on paper, and she made a kit made of much better individual abilities, but there was no rhyme or reason to WHY she picked what she picked (except, if you paid attention, the E: she realized that juggernaut-type characters have to have a defensive button. That’s a WHY type judgment.)
FROM WHAT TO WHY
Not all is lost, though. This experience is very common. In fact, it’s what I went through on my first three or so characters. I was lucky enough to have more experienced designers talk me through what wouldn’t work before I even playtested and help me find better versions.
This is the WHY level of game design.
So in this case, our hypothetical designer spent a week or two going back to the drawing board—back to paperkits, soliciting feedback on them, and so on.
She starts by applying the unique inputs / unique outputs framework for League characters: ideally, characters have an input (a button press or a way of moving) that FEELS unique, and ideally the presence of a given character in a match changes that match for EVERYONE. For instance, Draven spins his throwing axes and they bounce off the targets he hits. If he catches them before they fall on the ground, he maintains the damage bonus. So Draven players have to move differently from any other character’s players. Or take Sejuani: she has a passive on her E that requires 4 stacks on an enemy before she can freeze them. She can apply these stacks with her attacks and with her Q, but anyone on her team can also help her stack, as long as they’re melee. This changes the meaning of team comps and makes fights feel very different based on how many melee characters on Sejuani’s team are involved.
For her unique input, she designs a passive that’s inspired by raid bosses in MMOs. Instead of just having a normal health bar, kaiju has four segments: 0-25, 25-50, and 50-75, and 75-100% health. Whenever kaiju falls below one of those break points, it briefly becomes covered in a rock-hard shell, gaining invulnerability but also becoming unable to attack or cast for a brief amount of time. Then its rock-shell breaks apart into two large halves. Kaiju can walk onto a shard to pick it up and transform its next auto-attack into a ranged rock throw skill shot that stuns the enemy it hits.
And as it turns out, this is her unique output as well! Kaiju is an especially strong pick against burst champions because it can never be killed entirely from 100% health. The enemy has to land at least 4 hits. It also means that the enemy has three opportunities to de-aggro and walk away, unless Kaiju uses its rock throw perfectly.
Our designer tests this pattern with three placeholder abilities; she literally uses Cho’Gath’s kit because at this point the abilities don’t matter. She confirms in lane tests that it’s fun to play against (but adds some additional balancing levers, bringing back the lowered resistances/increased damage from our HOW level attempt at lower levels of health and adding a “must return to base to regrow shell” rule to enforce lane attrition, another useful framework) and cautiously throws the character into a full playtest, with Vel’Koz’s R bolted on as a temporary ult. There are teamfights when kaiju seems like an unfair unkillable front line, there are teamfights where the enemy team uses the self-silence and disarm to just walk past kaiju, and then suddenly enemies start picking poke comps to get the shell off kaiju before a teamfight, and they discover that DOT builds fare extremely well against a character that absorbs bursts, and suddenly we have a unique output: knowing the enemy will run kaiju changes how you play the game.
This isn’t guaranteed to work. Nothing ever is. But at least we’re approaching the problem from a place of hypothesis that can be falsified and frameworks that can point the way. We’re not going to have holes in the kit because we know what this class needs and why. We’re not going to have abilities with degenerate use cases such as “never use this unless condition X is fulfilled and then you just win for free”, because we know why this kind of thing happens and how to stop it from happening. And most importantly, when something doesn’t work, we immediately have at least a good idea where to go to make it work.
And to be fair, I can’t think of a way to teach this kind of thinking in a way that it’ll be applicable to all kinds of games. I could probably teach a course in WHY thinking for one or two genres, max. But I still think we should try.
Anyway, why don’t we teach WHAT and WHY?
WHY HOW IS EASIEST TO TEACH AND LEAST USEFUL
A lot of time in design courses is spent on making students learn various tool ecosystems. That’s not a bad idea; not only is there a fair amount of centralization in the world of game dev these days and knowing your way around both Unreal and Unity is a very good idea indeed in 2024, but also it turns out that learning a toolset makes you generally better at learning further toolsets in the future. So by all means, put these kids through Unity, Unreal, Godot, Twine, Gamemaker, what have you.
It’s also really easy to make a curriculum for these tools. You can break down the kinds of things a designer would need to do in Unreal and have neat checklists for them. It’s easy to tell if a student has learned how to place entities into a 3D scene or if they can string together some nodes in Blueprint to achieve a given behavior.
Things that are easy to score are attractive to a teaching environment. It’s unclear how to score one particular set of cards a student made for a deckbuilding game, but you CAN score them easily enough on a bug-free game, a game that looks and feels good, responsive controls etc.
However, I can teach a new designer HOW to make stuff extremely quickly as well. When I got the game design job at Riot in 2012, they gave me perforce access to the codebase even though I was still in Dublin office, where no game development was happening. On my own, by dissecting existing characters, I learned the game tools for League in about a month, to the point that the first day I arrived in the Los Angeles office, I was able to usefully put new things into the game. The on-boarding plan called for a one month “learn the tools and play some games, but mindfully” phase that I got to skip altogether, and I’m not exceptional by any means.
People who’d never worked a day in any kind of tech job, nevermind games, learned our toolset in a week or two. Of course you continue learning and getting better over the years, but basic competency to the point where you can contribute productively? You can get there in about a month.
It’s of course very helpful if you’re familiar with the engine the game is using, but the reality of game dev in 2024 is that a lot of the big games have either their own bespoke engine, use an obscure in-studio engine like Frostbite or Lumberyard, or have grown such an extensive custom tool ecosystem on top of a standard engine like Unity or Unreal that you may as well be learning a new system.
That’s why I’m not a fan of spending so much time on learning the how. It’s easily and quickly learned on the job and even when the game does use an engine you’re familiar with, you’ll still have to learn a lot of the game’s unique pipelines.
What we’re doing to prospective game designers is like teaching prospective artists how to hold a brush, how to mix paint, how to stretch out canvas, but never breathed a word of color theory or instructed them in figure drawing. We’d just give them the bare tools and have them “paint lots of pictures”, hoping they’ll eventually figure it out.
THE VILLAIN IS CAPITALISM
In a world setup to foster creative expression and usefully prepare students for game design work, most game design courses would be taught by people with ample game design experience. This is almost never the case, and capitalism is to blame.
The typical game designer here in California could go and teach instead of working as a designer, but having looked into it myself, a typical designer can expect to earn about a quarter to maybe a third of what they’re making in the industry. For most people that’s just not a feasible income reduction.
We also don’t do a great job of teaching each other the nitty-gritty of how we design. At the individual designer level, there’s usually a healthy appetite for knowledge sharing. People WANT to talk about what they’ve learned and how they’re making decisions. Companies aren’t exactly incentivized to encourage this, but from my experience most also don’t stop designers from exchanging knowledge. It is the rare studio indeed that actively tells its designers “go out and talk about your jobs!”
But Daniel, you will say, assuming you know my name still after reading half a Torah’s worth of article at this point, there’s GDC talks and DICE talks and what not! And yes, those are very good and can sometimes teach you about a really cool thing, but due to how rarely we give these talks and because of how much of a career-enhancing move it can be to have a talk that is very popular, designers tend to cherry-pick the most exciting and cool topics. I’m not sure a lot of people would come to “how I learned the account for CC and reliability in my character’s power budgets”, but that’s the kind of stuff you need to know about.
SO WHAT’S THE SOLUTION
Is the solution then to read this blog and learn all the secrets? No, because frankly I’m not that good a writer or a teacher, and I fundamentally don’t believe you CAN learn these things by just reading about them. You have to actually use them on a game that people regularly playtest in a group of designers who each also thinks very deeply about the work.
Which makes this project very silly, doesn’t it? Who is my target audience? Designers who already know this stuff?
Well, my hope is that designers who know SOME of this stuff might find some of this useful. Perhaps there’s a lens you hadn’t thought to use. But also students just learning how to be game designers might at least find an idea or two in here that they can try out and thereby perhaps learn, or if they’re lucky enough to be in a studio with experienced designers willing to teach them, some of the thoughts I express here might represent a conversation starter or two. “Tell me, oh experienced Principal Designer with the Thousand Yard Stare, why is optimal not aligned with fun in our game?” That kind of thing.
DID YOU JUST MAKE ME READ FIVE THOUSAND WORDS JUST TO VERBALLY SHRUG?
I sure did. But WHY? And HOW? And… what?