Milestone Godot

From engine basics to a shipped 2D game — one weekly plan at a time.

Overview

How the method works, applied to learning Godot.

The idea

Same method as the running program, applied to game development: a sequence of weekly plans ("milestones"). Each one runs for a week and ends with a validation challenge on day 3 — a small, concrete, playable thing you have to actually build and test. You only move to the next milestone once your build passes the challenge's criterion.

The target engine version is Godot 4.7 (current stable at the time this was written) using GDScript. Any 4.x release works fine — the concepts don't change release to release, only minor API details occasionally do.

Weekly structure

With 7–10 hours a week, split into 3 sessions of roughly 2.5–3h each:

  • Day 1 — learn the new concept in isolation (small throwaway test scene).
  • Day 2 — build the real feature into your project.
  • Day 3 — validation challenge: finish, playtest, and check it against the pass criterion.

Commit your project to git at the end of every session — it costs two minutes and means a bad experiment never costs you a working build.

What "passing" means here

Unlike a 5K, most of these challenges aren't measured by a stopwatch — they're measured by does it actually work under normal play, including the edge cases. Each milestone's criterion tells you exactly what to poke at before calling it done.

The golden rule

Didn't pass the challenge? Repeat the milestone for another week rather than bolting the next feature onto a shaky foundation. Game code compounds — a jump controller with subtle bugs makes every later system (combat, AI, level design) harder to build and debug. Fixing the foundation now is always cheaper than working around it later.

Best practices

The engine patterns this plan is built around.

Composition over inheritance

Godot's scene tree is its composition system. Instead of deep class hierarchies, you build behavior by combining small nodes (a hitbox, a health component, a state machine) inside a scene. Favor building a feature as a small reusable node over subclassing a big base "Character" class.

Signals, not direct references, across systems

A signal is Godot's built-in observer pattern: a node announces "this happened" without needing to know who's listening. Use direct node references within a tightly coupled scene (a player and its own hitbox), but reach for signals whenever two unrelated systems need to talk (an enemy's death updating a HUD score counter).

Cache your node lookups

get_node() or $Node walks the scene tree every time it's called. Doing that inside _process() or _physics_process() means doing it 60+ times a second for no reason. Cache the reference once with @onready var and reuse it.

Use static typing

GDScript is optionally typed — writing var speed: float = 300.0 instead of var speed = 300.0 catches a whole category of bugs at edit time instead of at runtime, and gives you better autocomplete. Type your variables and function signatures by default.

State machines, from 3+ states onward

The moment a character has three or more mutually exclusive states (idle / run / jump / fall / attack), an if/elif chain gets unreadable fast. A small enum- or node-based state machine keeps each state's logic isolated and makes transitions explicit — this is exactly what Milestone 5 builds.

Don't fight the engine

Skip manual object pooling (GDScript is reference-counted, not garbage-collected, so it's rarely needed) and skip building a full ECS framework on top of Godot's node system. The engine already gives you composition, an event system, and a scene format — most beginner projects that feel over-engineered are fighting one of these instead of using it.

Setup ritual

Do this at the start of every session, all 12 milestones.

Before you open the editor

  • Pull up last session's git log or commit message — 1 minute to remember where you left off beats 10 minutes of re-reading code cold.
  • Re-read this week's milestone card: goal, challenge, and criterion. Know what "done" looks like before you start.

First 10 minutes in Godot

  • Run the project once before changing anything, to confirm you're starting from a working state.
  • If this week introduces a new node type or API, open its page in the official Godot docs (F1 search in the editor works offline) before writing code that uses it.

End of session

  • Run the project once more — never end a session on a broken build if you can help it.
  • git add -A && git commit -m "…", even for a rough work-in-progress state.

Practice habits

Complementary habits, outside the 3 build sessions, that make the milestones land faster.

Play with intent (15–20 min, 1–2x/week)

Play a small reference game in the genre you're building (a short platformer or 2D action game) and pay attention to one specific mechanic you're about to implement — how jump height changes if you tap vs. hold, how enemies telegraph an attack. You're mining for details to copy, not just playing.

Read one piece of real GDScript (10–15 min, 1x/week)

Skim a small open-source Godot project or a GDQuest tutorial's finished code. You're not trying to understand everything — just noticing patterns (how they structure a state machine, name their signals) you can borrow.

Keep a one-line devlog

After each Day 3 challenge, write one sentence: what you built, and the ugliest bug you hit. It costs nothing and turns into genuinely useful trail markers once you're past Milestone 8 and forget how Milestone 3 worked.

Optional: a weekend game jam

Once you're past Milestone 6, a 48-hour jam (itch.io hosts free ones constantly) is a great pressure test — it forces you to finish something small end-to-end, which is a different skill than following a structured plan.

Milestones

12 weekly plans, building one 2D action-platformer from an empty project to a shipped build. Tap a milestone to see its sessions and challenge.

References

Sources behind the practices and structure in this plan.

  • Official Godot Engine documentation — 2D physics, CharacterBody2D, TileMap, signals, and the GDScript reference. docs.godotengine.org
  • Official GDScript style guide — naming conventions, code ordering, and the canonical state-machine example. godotengine/godot-docs (GitHub)
  • GDQuest — tutorials and guidelines on GDScript patterns, hit/hurt boxes, and 2D movement, including their published GDScript guidelines.
  • Godot 4.6 / 4.7 changelog and maintenance release notes — godotengine.org