Every designer starts with a folder of ideas and no answer to the question that decides whether any of them ship: how much of this can one person build in a month? The craft lives in the negotiation between the idea and the build, and most of the learning arrives when a playtest says the idea was fine and the rules underneath it were not.
Where an idea becomes rules
A game designer decides how a game works. Not the story, not the art, not the engine, though the role touches all three. The core of the job is the system: what the player can do, what the world does back, what makes a choice interesting, and what happens when the player fails.
That definition sounds abstract until you sit with a specific case. A designer working on a stealth game is deciding how far a guard can see, how long the player has before a search begins, whether a body can be hidden, what noise costs, and how the player learns any of that without a tutorial. Each of those numbers and rules shapes the experience more than any amount of visual polish.
The work splits differently depending on the studio. At a large one, a systems designer owns the economy, a level designer owns the spaces, a narrative designer owns the story delivery, and a combat designer owns the moment-to-moment feel. At a small one, the same person does all four and also writes the build script. The common skill is the ability to describe a system precisely enough that someone else can implement it, then test whether the description survived contact with players.
Two things make game design hard to learn on your own. The first is that the feedback is expensive: a change to a rule can take a week to test properly, because you need players and you need them to play long enough to stop being polite. The second is that the field is crowded with opinions about what makes a game good, and most of them are not testable. A designer needs the discipline to turn a strong opinion into a question that a playtest can answer.
The job is often mistaken for an ideas job. Ideas are cheap and everybody has them. Design is the work of choosing constraints, writing rules that can be implemented, watching people break them, and revising. A designer who cannot build a paper prototype of a system is still describing rather than designing.
What a build needs from the catalog
A game needs a system, a body, a method, and often a world. The catalog covers each of those separately, and the trick is knowing how much of each a given project actually requires. Most first projects need far less art than their designers think, and far more testing.
Game development, the engine and the finish line
The catalog holds 30 live resources in this area, 28 of them free and 2 paid. This is where the build happens: engines, scripting, level construction, and the long tail of small technical decisions that decide whether a project gets finished.
Start with the design conversation rather than the software. Game Maker's Toolkit (GMTK) (FREE) breaks down why specific mechanics work, with a level of analysis that is rare on video. Extra Credits (FREE) covers the vocabulary of design: loops of play, difficulty curves, pacing, and the relationship between mechanics and theme. Game Developer (formerly Gamasutra) (FREE) is the trade publication where designers write about their own projects after they ship.
Then pick an engine and stay with it. Godot Engine Documentation (FREE) is unusually good technical writing, and Godot itself is free with no revenue terms attached. Brackeys (FREE) has the most approachable beginner courses for the engine it covers, and GDQuest (PAID) goes deeper into Godot with structured project courses. If you prefer a framework to an engine, Phaser Game Framework (FREE) handles 2D browser games, LÖVE (Love2D) Game Engine (FREE) handles Lua-based 2D, and libGDX Wiki (FREE) covers Java. Scratch (FREE) is the fastest way to learn event-driven logic without syntax, and it is not only for children.
Programming knowledge matters more than beginners expect. Game Programming Patterns (FREE) is a free book on the structures that games use repeatedly, and it will save you from inventing a broken version of someone else's solution. Handmade Hero (FREE) is a long, uncompromising series on building a game from scratch, useful once you want to understand what the engine is doing. r/gamedev Wiki (FREE) and GameDev.net (FREE) are where specific technical questions get answered by people who have hit the same wall.
Two more entries matter for the finish line. itch.io Devlogs (FREE) is a culture of small developers publishing work in progress, and reading a few devlogs teaches you what a realistic scope looks like. Ludum Dare (FREE) is a recurring game jam that forces a complete build in a weekend, which is the single most efficient training exercise in this field. PICO-8 Wiki (FREE) covers a fantasy console with hard limits, and limits are a beginner's best friend.
3D & Animation, only as much as the game needs
The catalog holds 30 live resources in this area, 23 of them free and 7 paid. Designers are not artists, but a designer who understands how a model is built and rigged makes better decisions about what the game can afford.
Blender Guru Beginner Donut Course (FREE) is the standard first step into 3D: one project, one finished render, and enough familiarity to talk to an artist without wasting their time. Blender Guru (FREE) continues with lighting and composition, and Blender Official Tutorials Hub (FREE) and Blender Manual (Official Documentation) (FREE) cover the rest of the tool. Blender Artists Community (FREE) and BlenderNation (FREE) are where work gets critiqued and where you find out what the current conventions are.
Animation is its own craft, and the principles matter even when the game is stylized. 11 Second Club (FREE) runs a monthly animation contest with public critique, which is the fastest feedback loop available for character motion. OpenToonz (FREE) and Pencil2D (FREE) cover 2D animation for games that use sprites or cutscenes. Mixamo (Adobe) (FREE) supplies rigged characters and motion capture clips, which is how a small team gets a decent run cycle without an animator.
Paid options are real here too. CG Cookie (PAID) and CG Boost (PAID) are structured 3D courses, Blender Secrets (PAID) is a library of fast techniques, Blender Studio (PAID) is the Blender Foundation's own training and assets, Spline Academy (PAID) covers a browser-based 3D tool for UI-heavy work, and Animator Island (PAID) collects animation exercises. None are necessary for a first game.
The design lesson from this area is cost. A model that is rigged, animated, and textured takes an order of magnitude longer than a shape with a face drawn on it. A designer who knows that will scope a first project around what can actually be produced.
Critical Thinking & Problem Solving, the design method
The catalog holds 30 live resources in this area, 26 of them free and 4 paid. This is the area most designers skip, and it is the one that separates someone who has opinions from someone who can diagnose why a level is not working.
The Decision Lab (FREE) covers how people actually make choices, including the shortcuts and biases that a game either exploits or fights. Cognitive Bias Codex (FREE) and List of Cognitive Biases (FREE) are reference maps of the same territory. Reading them as a designer is different from reading them as a psychologist: you are looking for what players will misread, overvalue, and remember.
Systems thinking is the second half. Donella Meadows Project (FREE) is the clearest free introduction to feedback loops, stocks, and flows, and those ideas describe a game economy as well as they describe a fishery. Systems Innovation (FREE) covers related material with more diagrams. ASQ Five Whys (FREE) is a small technique that turns "the boss fight is bad" into a specific cause after five questions.
Argument analysis is the third piece. Think Again I: How to Understand Arguments (Duke) (PAID) is a structured course in reasoning, and Introduction to Logic (Stanford) on edX (FREE) covers formal logic for free. The Fallacy Files (FREE), LessWrong (FREE), and Farnam Street (FREE) are different styles of the same discipline: noticing when a confident claim is not supported. Kialo (FREE) is a debating tool that maps arguments for and against, which is useful when a team cannot agree on a feature. BrainDen Lateral Thinking Puzzles (FREE) is a warm-up for creative reframing, and it is more fun than it sounds.
A designer uses this material in design reviews. When a colleague says a mechanic is unfun, the useful question is what evidence would settle it, and what the smallest change is that would produce that evidence.
Writing & Storytelling, for worlds that carry weight
The catalog holds 31 live resources in this area, 28 of them free and 3 paid. Even a game with no dialogue needs a fiction: why the player is here, what the world wants, what failure means. Games that skip this feel arbitrary, and players leave without being able to say why.
TV Tropes (FREE) is a working reference for narrative patterns and their subversions, and it is genuinely useful when you need to know what a player expects from a genre. Hello Future Me (FREE) breaks down worldbuilding and magic systems with attention to rules, which is exactly the part a game designer cares about. Writing Excuses Podcast (FREE) covers craft in short episodes, and Brandon Sanderson Creative Writing Lectures (BYU) (FREE) is a full university course on building characters and worlds, available free.
For dialogue and structure, Scriptnotes (FREE) is a working screenwriters' podcast and it teaches scene construction better than most game writing advice. Helping Writers Become Authors (FREE) covers story structure, and Write Your First Novel (Coursera / Michigan State University) (FREE) covers the long-form discipline. Creative Writing Exercises (FREE) is a source of prompts for the days when the world needs a detail and nothing comes.
Craft at the sentence level still matters, because game text is read in small pieces under pressure. The Elements of Style (Project Gutenberg) (FREE) and Purdue OWL (Online Writing Lab) (FREE) cover clarity and convention. Hemingway Editor (PAID) is a paid tool for checking sentence density, useful if your UI text keeps overflowing.
The design-specific lesson is economy. A game can carry an enormous world with very few words if the words are chosen well, and a designer who writes their own item descriptions learns quickly which sentences earn their space.
Prototype order: paper, then pixels
The sequence below is ordered by cost. Each stage is cheaper than the one after it, which means a mistake costs less the earlier you find it. Skipping to the engine is the most common way a first project dies.
Stage one: rules on index cards
Write the rules of your game on cards, one rule per card. If a rule needs a diagram, draw it. Then play it with a friend using coins, dice, or tokens. No computer, no art, no engine.
This stage feels silly and it is the most valuable one. Paper exposes whether the core decision is interesting before you spend a month building a system that supports it. Extra Credits (FREE) covers the vocabulary you need to describe the decision, and Game Maker's Toolkit (GMTK) (FREE) shows how existing games structure the same decision.
Ready when: a game a friend will play twice without being asked. If they will not play twice, the rule set is the problem, not the presentation.
Stage two: one screen, one verb
Build the smallest digital version of that rule set. One screen, one thing the player can do, one thing that happens when they do it. No menu, no save system, no tutorial. The goal is to feel the input latency and the feedback loop with your hands.
Godot Engine Documentation (FREE) or Phaser Game Framework (FREE) will get you there. Brackeys (FREE) has a beginner course that ends with a playable prototype rather than a certificate.
Ready when: a build someone else can play for sixty seconds without instructions.
Stage three: the first playtest
Sit behind a player and say nothing. Watch where they hesitate, where they click twice, where they stop reading. Write down what they did, not what they said. Beginners ask "was that fun" and get a polite answer, which is why the observation matters more than the question.
The Decision Lab (FREE) helps you interpret what you saw, because a player's confusion often comes from a reasonable assumption you did not anticipate. Donella Meadows Project (FREE) helps when the problem is a system that rewards the wrong behavior.
Ready when: three specific observations you did not expect, each tied to a change you can make.
Stage four: cut and rebuild
Most prototypes need something removed, not added. Cut the mechanic nobody used, merge two resources into one, delete the tutorial and teach through level design. Rebuild the smallest version that preserves the decision you care about.
Game Programming Patterns (FREE) is useful here because cutting features often means restructuring code, and the book covers the structures that make that cheap.
Ready when: a build that is smaller than the last one and more fun.
Stage five: ship something small
Finish a game that can be downloaded or played in a browser, with a title screen, an end state, and a way to restart. Ship it to itch.io or a jam. The point is the completed artifact, because a finished small game teaches more than an unfinished ambitious one.
itch.io Devlogs (FREE) shows how other developers present small work, and Ludum Dare (FREE) gives you a deadline and an audience in the same weekend. PICO-8 Wiki (FREE) is a good constraint if you need one enforced.
Ready when: a public page with a build, a screenshot, and a sentence describing what the player does.
A jam entry as the first portfolio piece
A game jam is the closest thing this field has to a driving test. You get a theme, a time limit, and no time to polish. The result is usually rough, and it is also the most honest evidence of what you can do.
Choose a jam with a short duration for the first one. Forty-eight hours is enough to build something small if the scope is chosen in the first hour. The theme arrives and the instinct is to find an idea that uses it cleverly. Resist that instinct. Find the smallest mechanic that fits the theme, then build one level around it.
Plan the weekend before it starts. First hour: rules on paper. Second hour: one screen in the engine. The rest of the first day: the core interaction working. The second day: content, sound, and the end state. Leave the last three hours for the build upload, the page, and the screenshots, because those always take longer than expected.
A jam teaches you the shape of your own working speed rather than a technique. You find out how long a menu takes, how much of the time goes to bugs, and where your ambition outruns your hands. That knowledge is what makes the next project's scope realistic.
Then use the entry. A jam page with a playable build, a short description, and a note about what you would change is more persuasive to a hiring manager than a design document for an unbuilt game. It shows the two things studios care about most at entry level: you finish, and you can talk about your work honestly.
Free engines and the few paid things worth having
The tooling for this field is unusually cheap. Godot is free and open source. Phaser, LÖVE, and libGDX are free. Blender is free. Audacity is free. A designer can build and ship a complete small game without paying for software, which was not true fifteen years ago.
Free also covers the education. The design theory on YouTube is better than most paid courses, the engine documentation is free, and the jam culture provides feedback at no cost. A beginner who spends nothing and ships four small games will be ahead of one who spends a thousand dollars on courses and ships nothing.
Money becomes useful in four places. The first is a course that provides structure and feedback rather than information, which is what GDQuest (PAID) and CG Cookie (PAID) sell. The second is art: a small budget for a character artist or an asset pack can turn a prototype into something presentable much faster than learning to model. The third is audio, where a few dollars on a sound pack saves a week. The fourth is a jam or conference ticket, which buys access to people rather than content, and access is the scarce thing.
What to avoid is the trap of buying tools as a substitute for shipping. A new engine, a new asset bundle, and a new course all feel like progress without the risk of finishing something. The best purchase a beginner can make is usually a deadline.
Why playtests lie and how to make them honest
Playtests produce bad data for predictable reasons, and a designer who does not know them will spend months responding to noise.
The first reason is politeness. Players who know you will tell you the game is fun because they do not want to hurt your feelings. The fix is to stop asking evaluative questions. Ask them to do a specific task and watch. "Show me how you would get past this guard" produces behavior. "Was that fun" produces manners.
The second reason is the wrong player. Testing a hardcore strategy game with your friends who play shooters will produce confusion that has nothing to do with your design. Recruit people who resemble the audience, and test with more than three of them, because a single player's confusion might be about them.
The third reason is the observer effect. When you sit next to someone and explain a mechanic, you have changed the test. Sit behind them, keep quiet, and note when they ask a question. Every question is a design failure, even if the answer is obvious to you.
The fourth reason is that players report the symptom rather than the cause. "The gun feels weak" might mean the sound is thin, the hit feedback is missing, the damage number is too small, or the enemy does not react. Your job is to find which one, and that means changing one variable at a time.
The fifth reason is sample size against a build that keeps changing. If you change three things between tests, you learn nothing about which one worked. Version the build, change one thing, test again, and keep notes that another person could read.
The fix for all five is the same discipline: define the question before the test, change one thing, and write down what happened. That is the same discipline as any experiment, and it is what turns design from taste into craft.
After the first build
The next step is a second game, slightly larger and built with the knowledge of how long things actually take. Keep a design log: what you decided, what you expected, what happened. After three projects the log becomes the most valuable document you own, because it is the only record of your own judgment improving.
From here, the adjacent roadmaps matter more than another tutorial. 3D Animator covers character and motion work if you move toward production. Sound Designer covers the audio layer that makes a build feel finished. Video Editor covers the trailer and devlog footage that gets a small game noticed. Web Designer covers the store page and press kit that decide whether anyone plays it.
The category pages hold the wider shelves: Game Development, 3D & Animation, Critical Thinking & Problem Solving, and Writing & Storytelling. Browse by profession shows where this role sits beside the rest.
The designers who last in this field tend to be the ones who can look at a build, admit that the fun is in a place they did not plan for, and rebuild around it, whatever the size of their ideas. That willingness is trainable, and every small finished game trains it a little more.
FAQ
Do I need to know how to program to be a game designer?
Not at a large studio with dedicated engineers, and yes at almost every other scale. A designer who can build their own prototype can test an idea in a day instead of waiting for a sprint. Scratch (FREE) and Godot Engine Documentation (FREE) are enough to start, and you do not need to become an engineer to be dangerous.
Should I learn Unity or Godot first?
Pick the one that matches the jobs you want and commit for a year. Godot is free, open source, and pleasant to learn, with excellent documentation. Unity has more job listings in some markets and a larger asset ecosystem. Switching engines early is the most common way beginners lose six months without building anything.
Do I need art skills to design games?
No, but you need enough literacy to scope art correctly. Take Blender Guru Beginner Donut Course (FREE) once so you understand what modeling and rigging cost in time. Then use placeholder art, asset packs, or a collaborator, and spend your own hours on the system.
How do I know whether my game idea is good?
You do not, and neither does anyone else before a playtest. The useful question is whether the core decision is interesting, and the cheapest way to answer it is a paper prototype played by someone who is not you. If they play it twice without being asked, you have something worth building.
Would a degree teach me more than shipping?
Rarely more than shipping does, though a good program can be worth it for the network and the structured critique. Studios hire on portfolio, and a portfolio of three shipped small games plus a clear explanation of the design decisions beats a transcript. If you do study, choose a program that makes you ship rather than one that only assigns documents.
Where do I find people to playtest my game?
Local meetups, game jams, Discord communities for the engine you use, and any friend who does not already know how the game works. The last condition matters most. A playtester who has heard you explain the mechanic is no longer testing the game, they are testing their memory.
SkillCache Editors · Updated November 13, 2026
