Game development

A game is five crafts stacked in a trench coat: code, art, audio, writing and design — the last being the invisible one, and the one that decides whether the other four amount to anything. A hobbyist does some of these, buys or borrows others, and collaborates on the rest. Almost nobody does all five well and nobody needs to.

The engine is the thing everybody asks about first and it matters least. All the mainstream engines will make a small 2D game comfortably, all of them have enormous free learning material, and switching later is far less painful than beginners fear. Choosing an engine is a decision you can make badly and recover from; choosing a scope is not.

Which is the actual subject of this page. The defining failure of hobby game development is not technical — it is a project that was three times too big by the second week, and which dies six months later with nothing playable. Everything below is organised around that, because it is the difference between a hobby that produces things and one that produces folders.

The thing everybody asks about

The engine

The thing that decides it

Scope

Realistic first-year spend

Nothing

A good first project

Finishable in a weekend

1. 1

   Step 1: Pick an engine in an afternoon and stop thinking about it

   Any mainstream one. The research phase is where an enormous amount of hobby enthusiasm is spent, and it produces nothing. Choose on how much beginner material exists, install it, and move on.

   You will know it worked when: The engine is installed and you have stopped reading comparisons.

2. 2

   Step 2: Make the smallest complete thing that exists

   Something with a start, a middle and an end screen, finishable in a weekend. Not a prototype and not a demo — a complete small thing, because finishing is the skill being practised and it is entirely separate from making.

   You will know it worked when: Somebody else can play it from start to finish without you present.

3. 3

   Step 3: Set up version control before the second project

   One evening, free, and it changes how you work: you can try things without fear and you can always get back. Hobbyists skip it and then lose a week to a change they cannot undo.

   You will know it worked when: You can revert a bad afternoon.

4. 4

   Step 4: Enter a game jam

   A weekend, a theme, and a hard deadline. Jams are the single most effective learning device in the craft, because the deadline enforces the scope discipline that nothing else does, and you finish something. The output is usually bad and that is not the point.

   You will know it worked when: You have shipped something under a deadline.

5. 5

   Step 5: Watch somebody play it without saying anything

   The most uncomfortable and most valuable twenty minutes available. Every place they hesitate is a design problem, and you will want to explain, and explaining is the thing you must not do because the eventual player will not have you sitting there.

   You will know it worked when: You have a list of problems you did not know about.

6. 6

   Step 6: Only now start the thing you actually wanted to make

   And cut it in half. Then cut it in half again. The project you imagined at the start is a five-year project, and the version that gets finished is the one you will be proud of.

   You will know it worked when: The scope is something you could finish in three months.

• An engine, chosen on ecosystem rather than features — What matters for a hobbyist is the volume and currency of learning material, and whether the community answers questions from beginners. Every mainstream engine handles a small 2D game; the differences that get argued about online are almost all irrelevant below a scale most hobby projects never reach. Check the licence terms yourself rather than trusting any page, including this one — they have changed materially in recent years and that is exactly why no engine is named here.
• Visual scripting, or a language — Most engines offer both. Visual scripting is genuinely capable and is not a toy — plenty of released games use it — and it is much the gentler entry. Text code scales better as a project grows. Starting visual and moving across is a completely normal path.
• Version control, from the first day — The single highest-value unglamorous habit in the craft, and the one hobbyists skip because it feels like professional overhead. It is not: it is what lets you try something reckless, and it is the reason "it worked yesterday" is answerable. Free for hobby use, and the setup cost is one evening.
• An image editor and an audio editor — Capable free options exist at both positions and nothing about a hobby project needs more. Pixel art in particular has excellent dedicated free tooling and is the standard route for people who cannot draw, because the constraints do a great deal of the work.
• Placeholder assets, deliberately — Coloured rectangles and free sound effects until the thing is playable. Making art for a mechanic that does not work yet is the most common way to waste a month, and the discipline of keeping it ugly until it is fun is what separates finished projects from beautiful abandoned ones.
• A way to get it in front of somebody — A browser build, a game jam page, a friend with twenty minutes. This is equipment in the sense that matters — you cannot tell whether a game works by playing it yourself, because you know what it wants you to do.
• What you do not need — A powerful computer, paid assets, a course, a team, or a design document longer than a page. All of these are things people acquire instead of starting.

Everybody is told to reduce scope and almost nobody is told how, which is why the advice bounces off. Cutting scope is not deciding to want less; it is a set of specific moves you make on a design, and they can be described.

The first move is naming the loop. Write down, in one sentence, the thing the player does over and over — not the story, not the setting, the verb. If that sentence needs a second sentence, the project is already two projects. Everything that does not serve the loop is a candidate for removal, and asking of each feature "does the loop stop working without this?" is a much sharper question than "is this good?", because nearly everything is good.

The second is the vertical slice: build one complete instance of the experience — one level, one enemy, one weapon, start screen to end screen — rather than building every system to half depth. A slice tells you whether the game is fun. Ten half-built systems tell you nothing at all, and they are what six months of invisible progress looks like.

The third is counting content, not features. Ten levels is not ten times the work of one level; it is one level of design work and ten of production, and production is where enthusiasm goes to die. A hobbyist should be counting how many hours of unglamorous asset-shaped work a decision creates, because that is the number that predicts abandonment.

The fourth is the one nobody likes: cut the thing you started for. Frequently the feature that made you want to build the game is the most expensive thing in it, and the project only ships if it becomes the sequel. This is where scope discipline stops being a technique and becomes a temperament, and it is the difference between a folder of prototypes and a shelf of finished small things.

Signals that the scope is already wrong, in the order they appear:

• You cannot describe the loop in one sentence — The earliest and most reliable signal, available before any code is written.
• There is no playable build in week one — Whatever is being built is not a game yet, and there is no way to find out whether it is fun.
• You are building a system with no content using it — An inventory with nothing to put in it, a dialogue engine with no conversation. Build the content first and let it demand the system.
• The word "just" appears in your plans — "I just need to add saving" is the reliable prelude to three weeks. It is not a lie, it is a category error: the last fifth of a game is most of the work.
• You are excited about version two — A sign the current version has stopped being the project. Ship it small and make version two the next one.

• 2D, which is where nearly everybody should start — Fewer dimensions, fewer problems, and an enormous amount of good learning material. Almost every skill transfers upward and the scope is manageable by one person.
• 3D, which multiplies everything — Not conceptually harder but much larger: modelling, texturing, lighting, animation and performance all become real work. A reasonable second or third project and a poor first one.
• Interactive fiction and narrative games — Little or no art, dedicated free tooling, and the craft is writing and structure. Much the most accessible branch for anybody who wants to make something good quickly, and taken seriously as a form.
• Game jams as the whole hobby — A completely legitimate end state. Some people only ever make jam games, finish dozens of them, and get better faster than anybody working on one long project.
• Modding, which is making games without starting one — Building on an existing game, with its art, engine and audience already present. An excellent route in, and a real craft in its own right.
• Tabletop and physical game design — The same design discipline with no code at all — prototyped with index cards, iterated in an evening. The fastest way to learn what design actually is.

The first milestone is finishing anything, and it is a much larger milestone than it sounds. Finishing is a separate skill from making, it is learned only by doing it, and the last twenty per cent — menus, saving, edge cases — is where it is actually learned.

The second is finishing several things, which is how you discover that your first game's problems were not unique to it. This is the argument for jams: five finished weekend games teach more than one abandoned year-long project, and by a wide margin.

After that the craft branches by what you found you enjoyed. Some people go deeper into design and end up prototyping obsessively; some into engineering and end up writing tools; some into art or audio and become the person a team needs. And some scale up to a long project, which is a genuinely different activity requiring planning, version control discipline and a tolerance for months without visible progress — and which is much more achievable once you have finished five small things than it ever is as a first attempt.