HOW TO BE A GAME DESIGNER

Game design is the job that confuses everyone outside the industry and half the people inside it. Ask ten random gamers what a game designer does and you'll get ten different answers. Some of them will say artist. Some of them will say programmer. Some of them will say the person who comes up with the idea, which is maybe the least useful answer in the whole industry.

A game designer is the person who decides what the game is, how it works, and why a player would care. Not what it looks like. Not what language it's written in. What it is. The rules, the mechanics, the loops, the feel, the way all of those pieces talk to each other to make something that feels like a game instead of a pile of code with pretty textures on it.

If that sounds vague, that's because the job is vague by nature. And if you want to be one, the vagueness is the first thing you have to get comfortable with.

What game designers actually do all day

I've worked with designers who spent months on spreadsheets. I've worked with designers who never opened one. I've worked with designers who wrote narrative bibles the size of novels, and designers who only ever wrote in bullet points on a whiteboard that got erased every Friday. The work looks wildly different depending on the studio, the project, and the specialty.

But there are some core activities that every designer touches, regardless of which flavor of the job they end up doing.

Systems design is thinking about how the pieces of a game connect. If the player picks up a shiny rock, what does the shiny rock do? Does it unlock a door? Does it increase a stat? Does it combine with other rocks? What happens to the economy of the game if shiny rocks are too common? Too rare? Systems designers think in graphs and feedback loops and second-order effects. The best ones can look at a change to one system and predict how it ripples through six others.

Mechanics design is closer to the moment-to-moment feel. How does jumping work? Does the character have a double jump, a wall jump, a coyote-time window? How long is the window? What does the animation look like at each frame? Mechanics designers obsess over the small stuff because the small stuff is what players feel even when they can't articulate it. Nobody writes a Steam review saying "the coyote time was perfect." They just say the controls feel good, and the coyote time is half the reason why.

Player psychology is the squishy part of the job. Why does a player stop playing? What makes them come back tomorrow? What feels rewarding, what feels like a chore, what feels like cheating? Designers steal from behavioral economics, from casino research, from child development, from anywhere that studies humans making choices under incentives. A designer who doesn't understand psychology is a designer who ships games that look good on paper and bounce players in the first hour.

Balance is the math part. Is the boss too hard? Is the economy inflating? Is the level two skip actually faster than the intended path? Balance is where spreadsheet designers live. It's tedious and it's what separates a game that feels fair from a game that feels broken. Most players never notice good balance. They only notice when it's bad.

Narrative structure is the part that crosses over with writing, but isn't the same thing. A narrative designer isn't necessarily the person writing dialogue. They're the person deciding how story information reaches the player. When does the twist happen? What gets revealed through environmental storytelling versus cutscene? Does the quest system support branching or is it linear? The writer and the narrative designer sometimes share a desk, sometimes share a brain, and sometimes are two people who have to negotiate which one of them gets to cut what.

The thing almost every new designer gets wrong

Game design is a thinking job, not a tools job.

This is the sentence I repeat to every aspiring designer who emails me asking what software to learn. Unity or Unreal. Articy or Miro. Blender or Figma. None of it matters if you can't think about systems. None of it matters if you don't understand why players make the choices they make. None of it matters if you can't look at a mechanic and ask the right questions about it.

I'm not saying tools don't matter. You need to be able to prototype, which usually means picking up an engine. You need to be able to communicate designs, which usually means some kind of document tool. But you can design a great game on index cards. You can design a great game in your head on the bus. You can design a great game before you've written a single line of code.

What you can't do is design a great game without doing the thinking. Reading about what makes games work. Playing games analytically instead of just consuming them. Breaking down why a level is satisfying or frustrating. Noticing when a system creates an emergent behavior the designer probably didn't predict. That's the actual job. The tools are how you communicate the thinking to other people.

The reading list

There are three books I give to every person who tells me they want to be a designer. If you haven't read all three, you're starting behind.

"A Theory of Fun for Game Design" by Raph Koster is the short one. You can read it in an afternoon. Koster's argument is that fun is the brain pattern-matching, and games are machines for producing that pattern-matching experience. Once you see games that way, you can't unsee it. The book is also full of doodles, which makes it the least intimidating starting point.

"The Art of Game Design: A Book of Lenses" by Jesse Schell is the thick one. It's organized around a hundred "lenses" you can apply to any game design problem. The lenses force you to look at your design from angles you'd never think of on your own. This is the book I come back to when I'm stuck on a mechanic and can't figure out why it isn't clicking.

"Uncertainty in Games" by Greg Costikyan is the overlooked one. Costikyan breaks down the different kinds of uncertainty a game can produce and shows how they create different kinds of player experiences. It's a short book that completely rewired how I think about randomness, hidden information, and player skill.

Beyond those three, Chris Crawford's older writing is still useful if you can find it. Game Developer magazine archives from the 2000s have incredible postmortems. GDC Vault has thousands of hours of free talks from working designers explaining how they made real games. If you haven't watched Mark Brown's Game Maker's Toolkit series on YouTube, start there. It's free and it's some of the best design analysis being made right now.

Read like your career depends on it, because it does. The designers I know who plateau are the ones who stop reading. The designers who keep getting better are the ones who treat their field like a library and not a trade.

How to build a portfolio without a degree

A formal game design degree is nice to have and nowhere near required. I know working designers with CS degrees, with art degrees, with English degrees, with philosophy degrees, with no degree at all. What every one of them has is a portfolio that proves they can design games.

A portfolio is not a list of ideas. A portfolio is a collection of finished things. This is the part that trips people up. Ideas are free. Every gamer has ideas. What hiring managers want to see is evidence that you can take an idea from "wouldn't it be cool if" to "here is a playable thing you can hand to a stranger." The idea is the smallest part of the work.

Start with tabletop prototypes. This is the advice that new designers ignore and then wish they hadn't. A paper prototype of a game system can be built in an afternoon. You can playtest it with three friends the same night. You can iterate on it the next day. A digital prototype of the same system takes weeks to build and you still don't know if the system is any good. Tabletop is how you learn to design fast.

Game jams are the next step. Ludum Dare, Global Game Jam, GMTK Jam, itch.io's constant rotating lineup. A jam forces you to ship something in 48 or 72 hours. It teaches you how to scope. It teaches you how to cut. It teaches you that your first idea is usually the wrong idea and the one that shows up in hour 20 is usually better. Do ten jams. Ship ten games. You will know more about game design at the end of that than most people with a degree.

Modding is the underrated path. If there's a game you love and it has modding tools, use them. Make a map. Make a total conversion. Make a balance mod that fixes what you think the designers got wrong. Half Life, Skyrim, Minecraft, Slay the Spire, Stardew Valley. Some of the most successful working designers started by modding a game they were obsessed with, because modding forces you to think about why the base game made the choices it made.

When I wrote how to be a video game creator, I got into the same point about portfolios being physical evidence. The underlying truth is that the industry doesn't trust people who haven't shipped. No amount of credentials substitutes for "here is a thing I made that works."

How to practice when you're not making a game

A lot of design practice happens outside of actually building games.

Play analytically. When you notice a good game feeling good, pause and ask why. What's the input delay? What's the animation telegraphing? How is the level teaching you its vocabulary? When you notice a bad game feeling bad, do the same thing. Frustration is data. If a quest is annoying, work out exactly what part of it is annoying. The pacing? The reward? The checkpoint distance? The unclear objective? Specificity is how you train the muscle.

Write about games. Not reviews. Breakdowns. Why does the grappling hook in Just Cause feel better than the one in other games? Why does Hollow Knight's map system create the exploration feeling it does? Why does the combat in Sekiro click on the third try but not the first? Write a thousand words on a single mechanic. Post it somewhere. You'll learn more from writing one breakdown than from watching ten videos about games.

Design on paper. Keep a notebook of mechanics and systems you're thinking about. Sketch them out. Work through the edge cases. What happens if the player does this weird thing? What if two systems interact in an unexpected way? This is the cheapest iteration in the world. You can design a hundred games in the time it takes to build one.

Pitch games out loud. Tell someone the idea in three sentences. If you can't do it in three sentences, the idea isn't focused enough yet. The pitch is its own design exercise. It forces you to decide what the game is actually about.

The paths into the job

There's no single way in, but the patterns are recognizable.

Some people start as QA at a studio and transition internally. QA gives you a deep understanding of how real games break, which is the unglamorous foundation of design competence. It's also one of the few entry points that doesn't require an existing portfolio, which makes it a real option for people who need a foot in the door before they can build one.

Some people start as programmers or artists and drift into design. Every studio has people whose job title says one thing but whose actual contribution is design work. A programmer who keeps sending design feedback that turns out to be right, or an artist who keeps reshaping levels in smart ways, often gets invited to stop pretending.

Some people start as indies. They make small games, they get attention, and eventually a studio offers them a design role because their indie work is already better than what most designers with ten years of AAA credits can produce.

Some people come in through narrative, which is its own adjacent discipline but often a path into broader design work. If you can write, and you understand game systems, narrative design is a door that opens faster than most.

None of these paths are better than the others. Pick the one that matches what you already have going for you.

The honest part

Design jobs are competitive. There are more people who want to be designers than there are design jobs. The people who get the jobs are usually the ones with the best portfolios, the best networks, and the most visible output. None of those are handed out at birth. They're all buildable. But they take years, and pretending otherwise is how people get disappointed.

The good news is that designing games is fun. Not always. The parts where you realize your system doesn't work and you have to throw away six weeks of work are not fun. But the parts where a mechanic clicks, where a playtester laughs at exactly the moment you wanted them to, where a stranger emails you to say your game made them feel something. That's a real thing that happens, and it's most of what keeps designers designing.

If you want to know more about the technical side of what it takes to get into the industry, the programming-focused path is worth reading about separately. Design and programming overlap enough that most working designers have at least a passing competence in both.

Start small. Finish things. Read the books. Play games like a scientist. Make a hundred tiny systems on paper before you make one big game in an engine. The designers I respect most all did some version of that, and none of them had a straight line to get there.

The job exists. The path is real. The work is the thinking, and the thinking is something you can start doing today, before you've written a line of code or opened an engine.

That's the whole thing.