Chapter 3 Key Takeaways

1. The best engine is the one you learn and use.
Tool selection is a practical decision, not a creative one. Godot, Unity, Unreal, GameMaker --- they all produce games. Hollow Knight was made in Unity by three people. Celeste was prototyped in PICO-8's 128 x 128 pixel environment. The engine is the means. The design is the product. Pick a tool, learn it well, and spend your cognitive energy on the game.

2. Godot's node-and-scene architecture mirrors good design thinking.
Games are compositions of smaller parts: characters, environments, UI elements, systems. Godot's architecture --- nodes composing into scenes, scenes instancing into other scenes --- directly reflects this modularity. Build small, reusable pieces. Compose them into larger wholes. Test each piece independently.

3. _physics_process() for movement. Always.
Use _physics_process(delta) for anything involving movement, collision, or physics. It runs at a fixed rate regardless of frame rate, ensuring your game behaves identically on fast and slow hardware. _process(delta) is for visual updates and non-physics logic. Confusing the two introduces bugs that only appear on machines different from yours.

4. Normalize your diagonal movement.
Without normalization, diagonal input vectors have a magnitude of ~1.414, making diagonal movement ~41% faster than cardinal movement. Call .normalized() on your input vector to ensure consistent speed in all directions. This is a small detail that prevents a real gameplay problem.

5. @export is a design tool, not just a code feature.
Exposing variables to the Inspector with @export enables rapid iteration --- the core activity of game design. Every tunable value (speed, health, cooldown, damage, jump force) should be @exported. If you have to open the script editor to change a number, you're iterating too slowly.

6. Signals keep your code modular and maintainable.
The Observer pattern (signals in Godot) lets nodes communicate without knowing about each other. A player emits health_changed; a health bar, a sound system, and a game-over manager all respond independently. Loose coupling means you can add, remove, or modify systems without breaking unrelated code. Tight coupling means changing one thing breaks everything.

7. Paper prototypes test systems; digital prototypes test feel.
Reach for index cards and dice before you reach for the keyboard. If your core loop isn't fun on paper, code won't save it. Paper is fast, cheap, and brutally honest. Use it to test systems, economy, pacing, and strategic depth. Switch to digital when you need to test timing, responsiveness, and game feel.

8. The one-page concept is your most important document.
A one-page design concept forces you to articulate what your game is, who it's for, and why anyone should play it. If you can't fit the answer on one page, you don't understand your game yet. The GDD grows with the project; the concept document precedes the project and keeps it focused.

9. Write the GDD as you build, not before.
A 50-page design document for a game that doesn't exist is speculation, not design. Start with 3-5 pages covering your core mechanic, core loop, and first level. Add sections as features are implemented and validated through play. The GDD should document decisions that survived testing, not decisions that exist only in your imagination.

10. Version control is not optional.
Use Git. Commit early. Commit often. Push to a remote repository. You will lose work at some point --- a corrupted file, an accidental deletion, a change that breaks everything. Version control reduces catastrophe to inconvenience. Set it up now, before you have anything to lose.

11. Constraint drives creativity.
PICO-8 (128 x 128 pixels, 8,192 tokens) and Bitsy (3 colors, dialogue-only interaction) produce focused, elegant games precisely because their constraints eliminate distraction. When you start your project, consider imposing artificial constraints --- limited mechanics, limited scope, limited color palette. Constraints force you to focus on what actually matters.

12. Everything starts with something on screen.
The psychological barrier of the blank project is real. Overcoming it is the hardest step --- not technically, but emotionally. Once you have a character that moves when you press the arrow keys, you have crossed the threshold from thinking about games to making one. Everything from this point forward is iteration.