Make your first video game
This curriculum takes you from understanding what makes games tick to actually shipping your first indie game. It moves through four tightly sequenced stages: first building a designer's eye and vocabulary, then mastering the craft of levels and narrative, then learning the practical code and tools to build a real game, and finally tackling the business and finishing mindset needed to get it out the door.
Foundations: Thinking Like a Game Designer
New to itUnderstand the core vocabulary of game design — mechanics, dynamics, player psychology, and what separates a fun game from a frustrating one.
▸ Study plan for this stage
Pace: 10–12 weeks total. Weeks 1–7: "The Art of Game Design" by Jesse Schell (~30–35 pages/day, 5 days/week — use the "lens" prompts at the end of each chapter as active reading checkpoints). Weeks 8–12: "Rules of Play" by Katie Salen (~25–30 pages/day, 5 days/week — denser academic text, so slow down and
- The Elemental Tetrad (Schell): Mechanics, Story, Aesthetics, and Technology as the four interlocking pillars of every game
- The Designer's Lenses (Schell): Using focused 'lenses' (e.g., the Lens of Fun, the Lens of the Player) as repeatable mental tools for critiquing and improving a design
- Player psychology and motivation (Schell): Understanding what players want — challenge, fantasy, curiosity, fellowship — and designing to satisfy those needs
- The Magic Circle (Salen): The conceptual boundary that separates the game world from ordinary life and why maintaining it is essential to meaningful play
- Meaningful Play (Salen): The idea that good game design creates actions whose outcomes are both discernible (the player can perceive them) and integrated (they matter to the larger game)
- Game as a system (Salen): Defining games through objects, attributes, internal relationships, and environment — seeing any game as an interconnected system of rules
- Rules vs. Play (Salen): The distinction between the formal rule structure of a game and the emergent, lived experience players create within those rules
- Fun vs. Frustration: Recognizing the design patterns — unclear feedback, unfair difficulty curves, broken agency — that tip a game from engaging to frustrating
- According to Schell's Elemental Tetrad, how do mechanics, story, aesthetics, and technology influence each other — and can you illustrate this with a game you know well?
- Choose any three of Schell's Lenses and apply them to the same game. What different problems or opportunities does each lens reveal?
- What does Salen mean by 'meaningful play,' and what are the two conditions (discernible + integrated) that must be met for an action to qualify?
- How does the concept of the Magic Circle explain why the same action (e.g., shooting someone) feels acceptable in a game but not in real life?
- Using Salen's systems framework (objects, attributes, relationships, environment), break down a simple game like Tic-Tac-Toe or Chess. What does this exercise reveal about the game's design?
- What specific design failures — drawing on both Schell and Salen — cause a player to shift from a state of flow and fun into frustration or disengagement?
- Lens Journaling (Schell): After finishing each chapter of 'The Art of Game Design,' pick one lens from that chapter and spend 10 minutes applying it in writing to a game you play regularly. Build a running journal of 15+ lens entries by the end of the book.
- Elemental Tetrad Teardown: Choose three very different games (e.g., a video game, a board game, a mobile game). Draw a four-quadrant diagram for each and fill in how Mechanics, Story, Aesthetics, and Technology manifest — then write one paragraph on how changing one pillar would affect the others.
- Magic Circle Stress Test (Salen): Identify two real-world examples where the Magic Circle was broken (e.g., pay-to-win mechanics, real-money gambling in games, harassment in online lobbies). Write a short analysis of what design or social failure caused the break and how it could be repaired.
- Systems Map (Salen): Pick a simple game and map it as a formal system — list every object, its key attributes, the relationships between objects, and the environment. Then identify one rule change and predict how it would cascade through the system.
- Fun-to-Frustration Audit: Play a game intentionally looking for moments of frustration. Log each instance, then diagnose it using vocabulary from both books (e.g., 'broken feedback loop,' 'violated player expectation,' 'non-integrated outcome'). Propose one design fix per issue.
- Micro-Design Prototype: Using only index cards or paper, design a tiny 2-player game (5–10 rules max). Playtest it with a friend, then write a one-page post-mortem using Schell's lenses and Salen's meaningful-play criteria to evaluate what worked and what didn't.
Next up: Mastering the vocabulary of mechanics, systems, and player psychology here gives you the precise language needed to study how games are actually built — moving from 'what makes a game good' to 'how do I construct one,' which is the focus of the next stage on game design and development practice.
The single best starting point for any aspiring designer: it builds a complete mental framework for why games work, using 100+ 'lenses' to analyze every aspect of a game. Read this first to establish the vocabulary everything else builds on.
A rigorous academic treatment of game mechanics, systems, and meaning. Introduces formal design thinking that prepares you for the more craft-focused stages ahead.
Craft: Level Design and Narrative
Some backgroundLearn how to design compelling spaces players want to explore and stories they want to inhabit — the two craft pillars of most indie games.
▸ Study plan for this stage
Pace: 8–10 weeks total: Weeks 1–5 for Totten's "An Architectural Approach to Level Design" (~25–30 pages/day, reading chapters alongside sketching exercises); Weeks 6–10 for Dille's "The Ultimate Guide to Video Game Writing and Design" (~20–25 pages/day, with slower passes over the design-document and dia
- Architectural grammar in games — how principles like prospect/refuge, compression/release, and landmarks borrowed from real-world architecture guide player movement and emotion in Totten's framework
- 2D and 3D spatial sequencing — Totten's analysis of how level geometry creates pacing, tension, and reward loops through deliberate spatial progression
- Affordances and player communication — using visual language (lighting, texture, silhouette, negative space) to teach players what a space 'wants' them to do without explicit UI
- Metrics and scale — Totten's emphasis on designing spaces around the player avatar's physical dimensions to ensure spaces feel believable and navigable
- The game narrative ecosystem — Dille's distinction between story (what happened), plot (how it's told), and gameplay narrative (what the player causes), and why all three must coexist
- Character design for interactivity — Dille's framework for building player characters, NPCs, and antagonists whose motivations survive contact with player agency
- The Game Design Document (GDD) as a living craft tool — Dille's templates and philosophy for writing design docs that serve both narrative vision and production reality
- Environmental storytelling as the bridge between disciplines — using level geometry and art direction (Totten) to carry narrative weight without cutscenes (Dille)
- According to Totten, how do the architectural concepts of 'prospect' and 'refuge' translate into concrete level-design decisions, and can you give an example from a game you know?
- Totten argues that scale and metrics are foundational before any aesthetic work begins — what does he mean, and what goes wrong when designers ignore this step?
- How does Totten use the concept of 'genius loci' (spirit of place) to argue that levels should feel like they existed before the player arrived?
- In Dille's framework, what is the difference between a story bible and a Game Design Document, and why does he insist both are necessary on the same project?
- How does Dille approach the problem of player agency 'breaking' a linear narrative, and what structural techniques does he recommend to give players freedom while preserving story integrity?
- Synthesizing both books: how can a level's spatial design (Totten) do narrative work that Dille would otherwise assign to dialogue or cutscenes — and what are the limits of that approach?
- Spatial analysis sketch: Choose one level from any game you admire. Re-draw its top-down layout by hand, then annotate it using Totten's vocabulary — mark prospect/refuge zones, compression/release moments, landmarks, and chokepoints. Write a one-paragraph reflection on what the geometry is 'saying' to the player.
- Metrics-first blockout: Before adding any art, blockout a small playable space (even in a free tool like Valve's Hammer, Unity ProBuilder, or even graph paper) using only the player avatar's jump height, run speed, and eye-level as your constraints, following Totten's metrics-first methodology. Playtest it with one other person and note where they hesitated or got lost.
- Genius loci world-building exercise: Pick a fictional setting and write a 300-word 'archaeological history' of one room or outdoor space — what happened there before the player arrived? Then translate that history into three purely visual/spatial details (a broken object, a stain, a blocked doorway) that communicate the story without any text, per Totten's environmental storytelling principles.
- Story bible draft (Dille): Using Dille's GDD templates as a scaffold, write a one-page story bible for an original game concept: define the world, the protagonist's core want vs. need, the antagonist's motivation, and the central dramatic question. Keep it to one page — Dille's discipline of concision is itself the exercise.
- Branching dialogue map: Write a single in-game conversation between the player character and one NPC using Dille's character-motivation framework. The conversation must branch at least twice and converge back to a single outcome. Map it visually as a flowchart, then evaluate: does each branch feel like a genuine choice, or just an illusion of one?
- Integration challenge — 'Silent level, loud story': Design (on paper or in a blockout) a 3–5 minute level sequence for your original game concept that tells a key story beat from your Dille story bible entirely through spatial and environmental means — no dialogue, no UI text. Annotate the design with one column citing Totten's spatial principles and a second column citing which narrative beat fro
Next up: Mastering how space and story work together at the craft level gives you the creative foundation to tackle the next stage's focus on production and systems — understanding not just what you want to build, but how game mechanics, loops, and pipelines turn these designed spaces and narratives into a shippable, playable whole.
Translates principles from architecture and urban design into practical level-design techniques. Read first in this stage because space is the most immediate thing a player experiences.
A practical, industry-tested guide to writing characters, dialogue, and branching narrative specifically for games — builds naturally on spatial design by adding the story layer.
Building: From Idea to Playable Game
Some backgroundGain the practical programming and engine knowledge to prototype and build a complete small game, even with limited coding experience.
▸ Study plan for this stage
Pace: 12–16 weeks total. Week 1–5: "Game Programming Patterns" (~25–30 pages/day, focusing on one pattern per session). Week 6–11: "Learning C# by Developing Games with Unity" (~20–25 pages/day, coding along with every Unity example). Week 12–16: "Game Design Workshop" (~20 pages/day, applying each framew
- Core software design patterns for games: Game Loop, Update Method, Component, State, Observer, and Object Pool (Nystrom)
- How patterns solve real, recurring problems in game codebases — not just theory but when and why to apply each one (Nystrom)
- C# fundamentals in a game context: variables, control flow, classes, inheritance, and interfaces as used inside Unity scripts (Ferrone)
- Unity engine architecture: GameObjects, Components, the Inspector, Scenes, Prefabs, and the MonoBehaviour lifecycle (Awake, Start, Update) (Ferrone)
- Prototyping as a design discipline: building the smallest playable version of a mechanic to test a core idea quickly (Fullerton)
- Playtesting methodology: structured observation, feedback collection, and iterative refinement based on what players actually do (Fullerton)
- Formal game elements: players, objectives, procedures, rules, resources, conflict, boundaries, and outcome — and how they combine into a coherent experience (Fullerton)
- The full small-game production arc: concept → paper prototype → digital prototype → playable build → iterated release (all three books combined)
- From 'Game Programming Patterns': What problem does the Game Loop pattern solve, and how would you implement one in a Unity project using MonoBehaviour's Update method?
- From 'Game Programming Patterns': Explain the Component pattern. How does Unity's own GameObject/Component system reflect this pattern, and what are its trade-offs versus deep inheritance hierarchies?
- From 'Learning C# by Developing Games with Unity': What is the MonoBehaviour lifecycle, and in what order do Awake, Start, and Update execute? Give a concrete example of what logic belongs in each.
- From 'Learning C# by Developing Games with Unity': How do Prefabs work in Unity, and why are they the practical implementation of the Object Pool pattern described by Nystrom?
- From 'Game Design Workshop': What are the eight formal elements of a game, and how did you apply at least three of them when designing your own prototype?
- Across all three books: Describe your end-to-end process for turning a one-sentence game idea into a playable Unity build — covering design, patterns used, C# scripts written, and at least one playtesting insight that changed the design.
- Pattern flashcard sprint (Nystrom): After each chapter of 'Game Programming Patterns', write a 3-sentence index card — Problem / Solution / Unity analogy. Review all cards weekly until you can recite them without the book.
- Pattern implementation lab (Nystrom + Ferrone): Pick any three patterns from Nystrom (e.g., State, Observer, Object Pool) and implement each as a standalone Unity scene with C# scripts from Ferrone's examples as your coding scaffold. Commit each to a Git repo with a README explaining which pattern it demonstrates.
- Unity mechanic-a-week challenge (Ferrone): For each major chapter in 'Learning C# by Developing Games with Unity', extend the book's project with one feature you invented yourself — a new enemy behavior, a scoring system, a simple UI element — to move beyond copy-paste learning.
- Paper prototype first (Fullerton): Before writing a single line of code for your capstone game, build a paper or tabletop version using Fullerton's eight formal elements as a checklist. Run at least two playtests with real people, take written notes, and document one rule change you made as a result.
- Structured playtest session (Fullerton): Once your Unity prototype is playable, conduct a formal playtest following Fullerton's observation guidelines — no coaching the player, written observation sheet, debrief questions afterward. Write a one-page 'what broke and why' report and implement at least two fixes.
- Capstone small game build (all three books): Develop a complete, self-contained small game in Unity (any genre, 5–15 minutes of play). The design doc must cite at least two formal elements from Fullerton, the codebase must consciously use at least two patterns from Nystrom, and all scripts must follow the C# conventions practiced with Ferrone. Share a playable build with at least three people outs
Next up: Completing a full small game — grounded in design theory from Fullerton, clean architecture from Nystrom, and hands-on Unity/C# skills from Ferrone — gives the reader a concrete portfolio artifact and the vocabulary to move confidently into more advanced topics such as game AI, procedural generation, or larger-scale production pipelines in the next stage.
Teaches the software patterns (state machines, component systems, event queues) that underpin every game engine. Read first so the code you write is structured and maintainable from day one.
A hands-on, beginner-friendly guide to Unity — the most accessible engine for indie developers — that teaches C# in the context of actual game features rather than abstract exercises.
Bridges design theory and production practice with structured exercises and playtesting methods. Reading it here, while you are actively building, turns abstract design ideas into testable prototypes.
Finishing: Shipping Your Indie Game
Going deepUnderstand the production, business, and psychological realities of finishing and releasing an indie game — so your first project actually ships.
▸ Study plan for this stage
Pace: 2–3 weeks, ~25–35 pages/day (the book is ~250 pages of narrative non-fiction, readable in focused sittings; allow extra days to pause and journal reflections after each chapter/case study)
- Crunch culture and its true cost — Schreier's case studies (Stardew Valley, Shovel Knight, Diablo III, etc.) repeatedly expose how underestimating scope and ignoring personal limits leads to brutal overtime, burnout, and broken teams
- Scope creep as the silent killer — nearly every game in the book balloons beyond its original vision; recognizing and actively cutting features is framed as a core production skill, not a failure
- The myth of the lone genius — even 'solo' successes like Stardew Valley required years of isolation and sacrifice; understanding what that actually demands prevents romanticizing it
- Publisher and funding dynamics — chapters on games like Pillars of Eternity and Halo Wars 2 illustrate how money sources (Kickstarter, publisher deals, self-funding) shape creative control, deadlines, and survival odds
- The emotional arc of a long project — Schreier documents the psychological phases developers go through: excitement, doubt, despair, and the fragile relief of shipping; anticipating these phases is a coping strategy
- Shipping as a deliberate decision, not a natural finish line — games are never 'done'; the teams that ship are the ones that consciously decide what 'good enough to release' means and hold that line
- Post-launch reality — reviews, player reception, financial returns, and studio survival after launch are shown to be unpredictable and often brutal; planning for post-launch is as important as planning for release
- Resilience and iteration over perfection — the through-line across all case studies is that shipped, imperfect games beat unfinished perfect ones every time
- For at least three games covered in Blood, Sweat, and Pixels, what was the original scope vs. the shipped scope, and what forced each team to cut or change features?
- What specific psychological and physical tolls does Schreier document from crunch, and how did different studios attempt (or fail) to manage them?
- How did the funding model of each featured game (Kickstarter, publisher, self-funded) directly influence the team's creative freedom and their ability to set a ship date?
- What does Schreier's reporting suggest are the warning signs that a project is heading toward an indefinite delay or cancellation — and how can a solo/small indie dev watch for those same signs?
- How did the teams in the book define and defend their 'ship condition' — what made them say 'this is releasable' when the game still had known flaws?
- What post-launch lessons emerge from the book, and how should an indie developer plan for the period immediately after release?
- After each chapter, write a one-page 'autopsy note' for that game: list (1) the original vision, (2) the biggest threat to shipping, (3) the decision or event that saved or sank it, and (4) one lesson you will apply to your own project
- Audit your current or most recent game project: list every feature, then mark each as CORE (game breaks without it), NICE (adds value but cuttable), or DREAM (post-launch or never). Practice the cut Schreier's teams were forced to make — remove everything marked DREAM and half the NICE items
- Write a personal 'crunch contract' with yourself: define your maximum sustainable weekly work hours, your non-negotiable rest days, and the specific warning signs (sleep loss, resentment, creative block) that will trigger a mandatory scope review
- Create a one-page 'ship condition document' for your project — a concrete, measurable list of what must be true for you to press the publish button. Share it with one peer and ask them to hold you accountable to it
- Map out a post-launch week plan: draft your store page, prepare a press/influencer contact list of 20 names, write a day-one patch response template, and set a 30-day post-launch review date on your calendar
- Find one indie game that shipped in the last two years with a public postmortem (GDC Vault, Gamasutra/Game Developer, or the developer's own blog). Compare its development story to a case study in Schreier's book — identify at least three parallels and write up your findings in 300–500 words
Next up: By internalizing the real-world production, business, and psychological patterns behind shipping, the reader is now equipped to move from studying others' journeys to actively managing their own — making the next stage's focus on live operations, community building, or advanced game design systems feel grounded in hard-won, practical reality rather than theory.
Behind-the-scenes accounts of how real indie and studio games got made (and nearly didn't). Reading real war stories at this stage calibrates your expectations and teaches scope management through example.