Planning a Godot Game: Scope, Systems & a One-Page Design Doc

Every game starts somewhere. Mine starts here, with a plan. I have tinkered with Godot before. I have never finished a game. This post is my attempt to change that. It is also a public promise. Now the plan exists. Later I can check it against reality.

A plan is cheap to write. It is expensive to correct after a hundred scenes exist. So I write it down first. This post captures where I am before a single scene file is built. It will be wrong in places. That is fine. The plan's job is to keep me honest, not to predict the future.

Why Godot

Godot is a free and open-source game engine. It runs on Linux, Windows, and macOS. It exports to the web as well as to desktops. That last part matters to me. I can drop a playable demo onto this very site later. The engine is also small, and so is its language.

GDScript is the engine's scripting language. It looks a lot like Python, but simpler. Static typing is optional. Nodes handle structure. Scripts handle logic. Scenes are .tscn files. Scripts are .gd files. That split stays readable after a month away.

I also like the physics and input handling. Kinematic bodies take a few lines. Gamepad mapping is built in. My first idea is keyboard-driven, so the engine is a safe bet.

The one-page design doc

Before tools, before scenes, I wrote the design doc. It fits on one page. That limit is the point. If I cannot explain the game in one page, I do not understand it yet. The doc has five sections:

• Premise — one sentence. What is the game? Who is the player?
• Core loop — the action the player repeats. Do → get → do better.
• One feeling — the emotion the game should land.
• Scope limits — how many scenes, enemies, minutes.
• Skipped ideas — the tempting things I am not building.

The last section is the one that saves me. Here is the doc, as it stands today:

PREMISE
  A tiny square explorer hops across floating levels
  to light beacons and reach the exit.

CORE LOOP
  Jump → collect coins → unlock the next level.

ONE FEELING
  Curiosity. Each screen is one more question.

SCOPE LIMITS
  3 levels. 1 enemy type. 15 minutes.

SKIPPED IDEAS
  Boss fights. Upgrades. Story text. Online leaderboards.

Every line above is a contract. "3 levels" means I stop adding levels at three. "Skipped ideas" means features stay on the page, not in the code.

Three cuts, not one build

Big builds fail. Small cuts ship. I plan three cuts of the same game. Each one must be playable on its own:

1. Gray-box — one level, no art, no sound. Just shapes and movement. It has to feel okay to move around.
2. Feature-complete — all systems in, all screens reachable. Placeholder art is allowed.
3. Polish — juice, sound, menu, credits, and a web export.

Cut one is the honest one. Most games die there. If the gray-box is fun, the rest is work. If it is not fun, no amount of art will save it. The rule for every cut is the same: stop when it is done. No second level until cut one is behind me.

Systems first, art last

Art is content. Systems are the skeleton. I build the skeleton once, then hang art on it later. I write this so I do not start drawing tiles on day one. A gray square that jumps well beats a pretty sprite that does not.

The same instinct runs through this site's content structure: one folder per thing, no cross-folder pointing. I call it structure over sprawl. I wrote about it when I restructured this blog. The game gets the same treatment.

Mechanics are the verbs: jump, dash, collect, respawn. Content is the nouns: boxes, coins, flags, level layouts. Verbs get built as reusable scripts. Nouns get defined as data files. One level file per level, no exceptions.

Folder & scene structure

Godot projects get messy fast. Scenes accumulate. Scripts pile up. So I decided the layout before the first scene. Every folder has one job:

res://
├── autoload/          # nodes that load on startup
│   ├── ui.tscn
│   └── player.tscn
├── scenes/            # one scene per game state
│   ├── menu.tscn
│   ├── game.tscn
│   └── gameover.tscn
├── scripts/           # GDScript, one job per file
│   ├── player.gd
│   ├── coin.gd
│   └── level.gd
└── data/              # level layouts as data
    ├── level_01.tres
    └── level_02.tres

Names are lowercase and match their file. Autoload holds the nodes every scene needs. Data holds level layouts. Adding a level never touches a script. That is the payoff line.

Milestones

The design doc handles the why. The README handles the when. I keep a plain checklist at the top of the repo. It is honest about what a task means. A task is done when its checkbox describes reality:

- [x] design doc (this post)
- [x] new project boots and runs
- [ ] gray-box: level_01 with player + camera
- [ ] movement: run, jump, dash
- [ ] coins, counter, and a small HUD
- [ ] respawn and checkpoints
- [ ] menu and game over screens
- [ ] juice pass (particles, shake, sound)
- [ ] web export plays on this site

"Web export plays on this site" is my favorite line. It turns a vague wish into a finish line. The site is why I can ship, and it keeps the project public.

The HUD will reuse the bar I built for the UI Elements Playground. Game UI and web UI share it now. Here it is, doing its job on this very page:

I went deep on that component in Building a Reusable Progress Bar. The menu buttons get the shine treatment from its own post. Two playground components, two game screens, zero new code.

What's on the slate

This post is the plan. The next one will be the build. I expect to write it when cut one boots: movement, a camera, and one gray-box level. If I hit a wall first, the wall gets its own post.

If you made it this far and you build things too, write your plan down somewhere public. It does not have to be a design doc. A checklist in a README is enough. The important part is that it exists, and that you can look back at it.