Part I: What Is Game Design?

Chapters 1--4

Here is the single most important thing I can tell you before you read another word of this book: game design is not what you think it is.

It is not coming up with cool ideas. It is not imagining epic boss fights in the shower. It is not writing lore documents or sketching characters on napkins. Those things are fun. They are part of the process. But they are not game design.

Game design is the discipline of creating experiences through systems of rules. It is deciding that pressing a button makes a character jump --- and then figuring out how high, how fast, how floaty, how much control the player has in the air, what happens when they land, what sound plays, what particles spawn, how the camera reacts, and whether any of that actually feels good. It is making a thousand small decisions that, together, determine whether a human being picks up your game and doesn't want to put it down.

That is the invisible art. The player never sees it. When it works, the game just feels right. When it fails, the player quits and can't explain why.

This part of the book is about establishing what that discipline actually is, what you're actually doing when you design a game, and who you're designing it for. By the time you finish these four chapters, you will go from "I like games" to "I understand what games are made of." That shift in perspective changes everything.

What You Will Learn

Chapter 1: What Is a Game? starts with the question everyone thinks is simple and nobody agrees on. Is Minecraft a game? Is a walking simulator? Is Animal Crossing? We will look at the definitions --- Salen and Zimmerman's, Schell's, Costikyan's, Juul's --- not because memorizing definitions matters, but because the arguments between them reveal what games actually do. You will learn to see games as systems of rules that create meaning through player action. You will understand why a ball, a field, and two goals become something transcendent when you add the right constraints. And you will write your first design artifact: a one-paragraph player fantasy statement for the game you will build across this entire book.

Chapter 2: What Is a Game Designer? dismantles the myth of the "ideas person." If there is one misconception I want to destroy early, it is the belief that the designer is the visionary genius who has the Big Idea and then tells everyone else to build it. The designer is a communicator, a playtester, a systems thinker, a collaborator, and --- above all --- an advocate for the player's experience. This chapter covers the actual roles and responsibilities, from solo indie dev wearing every hat to AAA lead designer managing a team of hundreds. You will create a one-page design concept document for your project. Not a full design doc --- those come later. Just enough to capture the core of what your game is.

Chapter 3: Setting Up Your Design Laboratory gets your hands dirty. We install Godot Engine, create your first project, build a scene with a moving character, and establish the workflow you will use for the rest of the book. I chose Godot deliberately: it is free, open-source, lightweight, and its GDScript language reads almost like pseudocode. You do not need to be a programmer to use it. You need to be someone who wants to see their designs come to life --- and Godot is the fastest path from idea to playable prototype I know. By the end of this chapter, you will have a character moving on screen. That moment --- the first time you press a key and something you built responds --- never gets old. I have been doing this for years and it still gives me a jolt.

Chapter 4: The Player turns the lens around. Everything you design exists for another human being to experience. Who are they? What do they want? Why do they play? This chapter introduces player typologies (Bartle's, Yee's, Quantic Foundry's motivational model), persona creation, and the fundamental insight that you are not your player. Your instincts about what's fun are useful but unreliable. The only way to know what works is to watch someone else play your game. You will write three player personas for your project's target audience --- and those personas will haunt your design decisions for the next thirty-six chapters.

Why This Part Matters

I have seen hundreds of aspiring designers skip straight to the exciting stuff --- combat systems, narrative branching, procedural generation --- and build games that feel hollow. They feel hollow because the designer never asked the foundational questions. What experience am I trying to create? Who am I creating it for? What is the core thing that makes this a game and not a movie or a slideshow?

Celeste did not start with wall-dashing and screen-shaking. It started with Matt Thorson and Noel Berry asking: what if a platformer was really, really hard but also really, really fair, and the difficulty was actually the point --- the emotional core of the game? That question --- a design question, not a mechanics question --- is what makes Celeste work. Everything else grew from it.

Dark Souls did not start with builds and invasions. It started with Hidetaka Miyazaki asking: what if a game respected the player enough to let them fail, repeatedly, and trusted that the learning process itself would be the reward? That is a philosophy of design. It is a stance about what players are capable of. And it produced one of the most influential games ever made.

Breath of the Wild did not start with the chemistry engine or the paraglider. It started with the question: what if a Zelda game gave you all the tools at the beginning and then trusted you to figure out the rest? That question broke almost every convention of modern open-world design --- and it worked because the team understood, at a foundational level, what games are and what players do with systems.

You need to understand these foundations before you build anything. Not because theory is more important than practice --- it isn't --- but because theory without practice is useless, and practice without theory is aimless.

Your Project Begins Here

By the end of Part I, you will have:

  • Godot Engine installed and running
  • A first scene with a character that moves
  • A one-page design concept document
  • Three player personas for your target audience
  • A one-paragraph player fantasy statement

That is not much. It is a character sliding across a screen and a few pages of writing. It will not impress anyone.

But here is what you will also have: clarity. You will know what you are building, who you are building it for, and what experience you are trying to create. You will have a design vocabulary that lets you articulate why something works or doesn't. And you will have the tool --- Godot --- that turns your ideas into things you can play, test, break, and fix.

Every shipped game started with less than this. Most shipped games started with a character moving on a screen and a designer who had a clear idea of what feeling they wanted to create. That is where you are.

A Note on How to Read This Part

Each chapter contains exercises, a case study, a quiz, and a section of the progressive project. Do the project work. I cannot stress this enough. Reading about game design without making a game is like reading about swimming without getting in the water. You will understand the words, but you will not understand the thing.

The progressive project is designed so that each chapter's contribution is small --- thirty minutes to an hour of focused work. But they accumulate. By Chapter 40, you will have a complete, playable, published game. The foundation for that game is poured right here, in these four chapters.

I don't care if your game is "innovative." I care if a player picks it up and doesn't want to put it down. That starts with understanding what games are, what you do as a designer, and who is on the other end of the controller.

Let's begin.

Chapters in This Part