Milestone Godot 3D

From camera basics to a shipped third-person game — one weekly plan at a time.

Overview

How the method works, applied to 3D game development.

The idea

Same method as the 2D Godot program, moved into three dimensions: 12 weekly plans, each ending in a day-3 challenge that decides whether you're ready for next week's system. This plan assumes you already know Godot's nodes, GDScript, and signals from the 2D track — it skips straight to what's genuinely new in 3D: cameras, navigation meshes, animation blending, and lighting.

Target engine: Godot 4.7 (current stable at the time this was written), GDScript. The project: a small third-person action-adventure — chosen because, like the 2D platformer before it, it touches nearly every core 3D system (camera, character controller, navigation AI, combat, lighting) without needing the narrower systems a shooter or racer would require.

Weekly structure

With 4–6 hours a week, split into 3 sessions:

  • Day 1 (~1.5h) — learn the new concept in a throwaway test scene.
  • Day 2 (~2h) — build it into the real project.
  • Day 3 (~2h) — validation challenge: finish, playtest, check against the pass criterion.

Commit to git at the end of every session, same as before — 3D scenes with imported meshes get large and messy fast, and a clean commit history is the difference between "revert" and "rebuild from scratch."

The golden rule

Didn't pass the challenge? Repeat the milestone. 3D compounds even harder than 2D: a camera that clips through walls or a character controller with sloppy ground detection makes every later system (navigation AI, combat, level design) actively fight you. Fix the foundation before building on it.

Best practices

The 3D-specific patterns this plan is built around.

Game-scale gravity, not real gravity

Earth gravity (9.8 m/s²) feels floaty and unresponsive in a 3D game. Most third-person controllers use something in the 20–30 range instead — it's not realistic, but it's what makes jumps and falls feel snappy and controllable.

Move relative to the camera, not the world

In a third-person game, pressing "forward" should mean "away from the camera," not "toward positive Z." Transform your input vector by the camera's flattened basis (its forward/right vectors projected onto the ground plane) before applying it to the character — skipping this is the single most common reason a first 3D controller feels wrong.

Let SpringArm3D handle camera collision

A naive third-person camera clips through walls the moment the player backs into one. SpringArm3D solves this for free: it casts a ray from the pivot to the desired camera distance and pulls the camera closer when it would hit geometry. Don't hand-roll this with your own raycasts.

Air control is a feel decision, not a physics one

How much steering the player keeps mid-air (0.0 = none, 1.0 = full ground-level control) has no "correct" physical answer — it's a game-feel dial. Most action games land somewhere around 0.2–0.4; full control feels floaty, zero feels like steering a brick.

Bake a navmesh, let NavigationAgent3D do the pathing

For a grounded enemy that needs to path across floors, ramps, and stairs, bake a NavigationMesh inside a NavigationRegion3D, then read get_next_path_position() from a NavigationAgent3D once per physics frame and move the character yourself. You almost never need to touch the pathfinding math directly.

Pick the cheapest lighting model that looks right

Godot 4 gives you three global illumination options: LightmapGI (baked, best quality, cheapest at runtime, but static — best fit for this program's small hand-built levels), VoxelGI (real-time, best for indoor scenes with lighting that changes), and SDFGI (real-time, infinite range, best for large open outdoor scenes but limited to one directional light). Don't reach for SDFGI on a small level just because it sounds more advanced.

Setup ritual

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

Before you open the editor

  • Check your last commit message to remember exactly where you left off.
  • Re-read this week's milestone card: goal, challenge, and criterion.

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 3D node (SpringArm3D, NavigationAgent3D, AnimationTree), open its page in the editor's built-in docs (F1) before writing code against it — 3D APIs have more moving parts than their 2D counterparts and are easy to misconfigure.

End of session

  • Run the project once more before stopping.
  • git add -A && git commit -m "…" — imported 3D meshes and materials make repos heavier, so commit deliberately rather than constantly.

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 short third-person or action-adventure game and pay attention to one thing you're about to build: how the camera settles behind the character after they stop turning, how far an enemy can "see" before it notices you. You're mining for reference, not just playing.

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

Skim a small open-source Godot 3D project or a GDQuest 3D tutorial's finished code. Notice how they structure the camera rig, the navigation agent setup, or the animation tree — details you can borrow later.

Keep a one-line devlog

After each Day 3 challenge, write one sentence: what you built, and the ugliest bug you hit. 3D bugs (camera clipping, navmesh edge cases, animation popping) are easy to forget the fix for once you've moved past them.

Optional: grab free 3D assets instead of modeling

This plan is about systems, not 3D modeling. Kenney.nl and similar CC0 asset packs give you ready-made characters, props, and environment kits so every session goes toward code and design, not sculpting meshes.

Milestones

12 weekly plans, building one third-person action-adventure from an empty 3D scene 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 — 3D navigation overview, SpringArm3D, CharacterBody3D, AnimationTree. docs.godotengine.org
  • GDQuest — "Character Movement in 3D" library tutorial and third-person controller resources. gdquest.com
  • Coding Quests — Godot 4 3D character controller guide (game-scale gravity, camera-relative input, air control values). codingquests.io
  • Generalist Programmer — Godot 3D game development guide covering VoxelGI, SDFGI, and LightmapGI trade-offs. generalistprogrammer.com
  • Vav Labs / community guides on NavigationRegion3D and NavigationAgent3D setup for grounded pathfinding.