Build playable prototypes in code and in Godot: game loops, input, collision, physics, state machines, data-driven tuning, jams and publishing.

Game Prototyping & Systems

## Why this matters

Hand-written canvas code is perfect for testing one mechanic in an afternoon. Once a prototype needs animation tools, a tile map editor, audio mixing, physics with many bodies, or builds for consoles and phones, an **engine** saves weeks. Choosing one is a real design decision: it affects what your team can build, how fast you can iterate, what it costs, and which jobs your portfolio points towards. The good news is that the core skills (loops, state, collisions, tuning) transfer between all of them.

## What an engine gives you

- An **editor** for placing objects, building levels and tweaking values while the game runs.
- **Rendering**, **physics**, **audio**, **input** and **animation** systems.
- A **scripting language** for your game logic.
- **Export** to Windows, macOS, Linux, the web, mobile and (with licences) consoles.
- An **asset pipeline**: importing images, models and sounds.

## The big three for indie and studio work

| | Godot | Unity | Unreal Engine |
|---|---|---|---|
| Licence | Free and open source (MIT), no fees or royalties | Proprietary; free tier with revenue limits, paid plans above | Source-available; free to use, royalty on revenue above a threshold for games |
| Languages | GDScript (Python-like), C#, C++ via GDExtension | C# | C++ and Blueprints (visual scripting) |
| Strengths | Small download, fast to open, great for 2D, readable scene/node system | Huge ecosystem and asset store, strong mobile and 2D/3D, very common in industry job ads | High-end 3D graphics, large worlds, used by many AAA studios |
| Watch out for | Smaller asset ecosystem; console export goes through third parties | Licence terms have changed over the years; check the current ones | Heavy downloads and hardware needs; C++ learning curve |

Licensing and pricing change, so always read the official terms before committing a commercial project: godotengine.org/license, unity.com/products/compare-plans and unrealengine.com/eula. Checked on 2026-10-23. In 2023 Unity announced a per-install "runtime fee", faced strong backlash and cancelled it in 2024; the lesson for designers is to read the terms yourself, not to assume they stay the same.

Other tools worth knowing: **GameMaker** (2D, very popular with indies), **Defold** (light 2D and mobile), **Phaser** (JavaScript, browser games), **Bevy** (Rust), **PICO-8** (tiny fantasy console, superb for practice), and **Twine** (interactive fiction, no code required). For pure design exploration, a paper prototype or a spreadsheet still beats any engine.

## How to choose

Ask questions in this order:

1. **What is the prototype trying to learn?** A card-game economy might need only a spreadsheet. A movement feel test needs a real-time loop.
2. **2D or 3D, and how ambitious visually?** For 2D, Godot, GameMaker and Unity are all excellent. For photoreal 3D, Unreal leads.
3. **Target platforms.** Web builds are easiest from Godot, Unity and Phaser. Console work needs a licensed developer account and usually a studio.
4. **Team skills.** A team of C# developers will be productive in Unity or Godot with C#; artists who want visual scripting may prefer Unreal Blueprints.
5. **Licence and cost.** Open source and royalty-free removes a risk for small teams.
6. **Career goals.** Look at job ads for the studios you want to work at. Many mid-size studios list Unity; AAA studios often list Unreal; indie and education roles increasingly list Godot.

## A worked decision

A two-person team wants to make a 2D pixel-art roguelike for a 48-hour jam, playable in the browser, with one programmer who knows Python. **Godot** fits: GDScript reads like Python, 2D tools are strong, web export works, and there are no licence questions. If the same team were building a 3D shooter with realistic lighting for a publisher pitch, **Unreal** would be the stronger choice. A studio porting its mobile line-up would likely stay with **Unity** because its code, tools and staff already use it.

## Engine-agnostic habits

Whatever you choose:

- Keep tuning values in one place (resources, data files, scriptable objects).
- Separate game rules from presentation, as you did with `update` and `draw`.
- Use version control (Git, with large-file support for big assets) from day one.
- Prototype the riskiest question first, not the menu screen.

## Common mistakes

- **Engine-hopping** instead of finishing anything. Pick one for a project and ship.
- **Choosing by graphics demos** when your game is 2D and small.
- **Ignoring licence terms** until a game earns money.
- **Learning the engine instead of designing.** Use the engine to answer design questions.

## Quick recap

- Engines provide editor, rendering, physics, audio, scripting and export.
- Godot: free, open source, great 2D, GDScript. Unity: C#, huge ecosystem, common in jobs. Unreal: C++/Blueprints, top-end 3D.
- Decide by the question you are testing, 2D/3D, platforms, team skills, licence and career goals.
- Always check the current official licence terms.

## Try it

This lesson is quiz only. Next, you will build your first scene in Godot.

Compare Unity, Godot and Unreal on licensing, languages, platforms and fit, and pick a tool for a given project.

Choosing an engine

choosing a game engine is easy, actually

Godot in 100 Seconds

Download the standard Godot 4 build from godotengine.org/download, open it, and in the Project Manager create a new project in an empty folder (Compatibility or Forward+ renderer both work).

Create a new scene with a Node2D root named Main and save it as main.tscn. Set it as the main scene (Project > Project Settings > Application > Run > Main Scene, or accept the prompt the first time you press F5).

Add a StaticBody2D named Floor with a CollisionShape2D (new RectangleShape2D, about 600 by 40) and a ColorRect or Sprite2D so you can see it. Place it near the bottom of the view.

Add a CharacterBody2D named Player above the floor, with a Sprite2D (drag the default icon.svg into its Texture) and a CollisionShape2D sized to fit the sprite. Check that no yellow warning icons remain in the Scene tree.

Attach a script to Player and paste the script from the reading (gravity, jump on ui_accept, Input.get_axis for left and right, move_and_slide). Press F5 and confirm you can walk, fall and jump.

Turn SPEED, JUMP_SPEED and GRAVITY into @export variables, select Player and change them in the Inspector. Try at least three combinations and note which feels best.

Open Project > Project Settings > Input Map, add a jump action bound to Space, W and a gamepad button, and change the script to use "jump" instead of "ui_accept". Run again to confirm it works.

Save the project and, if you use Git, commit it (Godot projects are plain text and diff well; add the .godot/ folder to .gitignore).

## Why this matters

Your canvas prototypes taught you the moving parts of a game: a loop, state, input, collision and gravity. An engine packages those parts so you can spend your time on design. Godot is a good first engine for a designer: it is free and open source, the download is small, it runs on modest laptops, and its language, GDScript, reads like Python. In this lesson you will map what you already know onto Godot's concepts and build a playable scene.

## Getting Godot

Download the **standard** build of Godot 4 from **godotengine.org/download** (the ".NET" build is only needed for C#). On Windows and Linux it is a single executable you can run without installing; on macOS it is an app bundle. Steam and itch.io also distribute it. Use the latest stable 4.x release. Checked on 2026-10-23.

## Nodes and scenes

Everything in Godot is a **node**: a sprite, a camera, a sound, a collision shape, a timer. Nodes form a **tree**. A saved tree is a **scene** (`.tscn` file). A scene can be a whole level, or a single reusable thing like a player or a coin, and scenes can be placed inside other scenes (called instancing). This replaces most of the hand-rolled structure you wrote in JavaScript.

A typical 2D player scene:

```text
Player (CharacterBody2D)      <- moves and collides; holds the script
├── Sprite2D                  <- the picture
└── CollisionShape2D          <- the hitbox (a RectangleShape2D or CapsuleShape2D)
```

A floor:

```text
Floor (StaticBody2D)          <- does not move, but others collide with it
├── Sprite2D (or ColorRect)
└── CollisionShape2D
```

Mapping to what you know:

| your canvas code | Godot |
|---|---|
| `player = { x, y, w, h }` | a `CharacterBody2D` with `position` and a `CollisionShape2D` |
| `update(dt)` | `_physics_process(delta)` (called at a fixed 60 Hz by default) |
| `draw()` | automatic: nodes draw themselves |
| `keys.ArrowLeft` | `Input.is_action_pressed("ui_left")` or `Input.get_axis(...)` |
| AABB + landing code | `move_and_slide()` and `is_on_floor()` |

## Your first script

Select the Player node and click the **Attach Script** button. Godot creates a file starting with `extends CharacterBody2D`. Replace its contents with:

```gdscript
extends CharacterBody2D

const SPEED := 220.0
const JUMP_SPEED := 450.0
const GRAVITY := 1200.0

func _physics_process(delta: float) -> void:
	if not is_on_floor():
		velocity.y += GRAVITY * delta

	if Input.is_action_just_pressed("ui_accept") and is_on_floor():
		velocity.y = -JUMP_SPEED

	var direction := Input.get_axis("ui_left", "ui_right")
	velocity.x = direction * SPEED

	move_and_slide()
```

Read it next to your JavaScript from module 2. `velocity` is a built-in `Vector2` on `CharacterBody2D`. Gravity is added only in the air. `ui_accept` is a built-in input action (Enter and Space by default). `Input.get_axis` returns -1, 0 or 1 from two actions, so opposite keys cancel exactly as yours did. `move_and_slide()` moves the body by `velocity`, handles collisions with the floor, and updates `is_on_floor()`. GDScript uses **tabs** for indentation, like Python uses indentation for blocks.

## Input actions

Hard-coding keys is the mistake you avoided in the input lesson. Godot builds that idea in: **Project > Project Settings > Input Map** lets you define actions such as `jump` and bind several keys and gamepad buttons to each. Your code then asks for `"jump"`, and players or designers can remap without code changes.

## Running and iterating

- **F5** runs the main scene (Godot asks you to choose one the first time). **F6** runs the scene you are editing.
- Change `SPEED` while the game runs and save: many changes apply live. Even better, mark tuning values with `@export var speed := 220.0` and they appear in the **Inspector**, where a designer can tweak them without opening the script.
- Use `print()` for quick debugging; output appears in the bottom panel.

## Common mistakes

- **Forgetting the CollisionShape2D** (Godot shows a yellow warning triangle on the node). Without it, the player falls through the floor.
- **Moving a CharacterBody2D by setting `position`** instead of using `velocity` and `move_and_slide()`, which skips collision.
- **Mixing tabs and spaces** in GDScript.
- **Writing physics in `_process`** instead of `_physics_process`.
- **Not setting a main scene**, so F5 asks every time.

## Quick recap

- Godot organises everything as nodes in trees saved as scenes.
- `CharacterBody2D` + `CollisionShape2D` + `Sprite2D` is a typical player.
- `_physics_process(delta)` is your update; `move_and_slide()` does movement and collision.
- Use the Input Map and `@export` variables to keep controls and tuning editable.

## Try it

Open the Do tab and build the scene step by step. It takes about 30 minutes with the editor open.

Install Godot, build a 2D scene from nodes, and attach a GDScript that moves a character with gravity and input.

First scene in Godot

Godot 4 Crash Course #1 - The Basics

Godot 4 Crash Course #2 - Coding in Godot

## Why this matters

"It feels too hard" is useful feedback, but it does not tell you **which** level, **how much** too hard, or whether your change helped. Studios combine playtest observation with simple numbers: how many players finished each level, how many attempts it took, where they quit. You do not need a data team to do this. A list of session records, a few small functions and a clear target turn vague opinions into decisions you can check.

## What to record

Decide the question first, then log the minimum that answers it. For difficulty, a per-attempt record is enough:

```javascript
const sessions = [
  { player: "p1", level: 1, completed: true,  deaths: 1, seconds: 42 },
  { player: "p1", level: 2, completed: false, deaths: 6, seconds: 180 },
  { player: "p2", level: 1, completed: true,  deaths: 0, seconds: 35 },
  { player: "p2", level: 2, completed: true,  deaths: 3, seconds: 150 },
];
```

In a jam game, these records can come from a notes sheet you fill in while watching, a `console.log` you copy out, or a simple download button. Respect privacy: record play, not personal data, and tell testers what you collect.

## From records to rates

The **completion rate** of a level is completed attempts divided by all attempts:

```javascript
function completionRates(sessions) {
  const totals = {};
  for (const s of sessions) {
    totals[s.level] ??= { done: 0, all: 0 };
    totals[s.level].all += 1;
    if (s.completed) totals[s.level].done += 1;
  }
  const rates = {};
  for (const level in totals) rates[level] = totals[level].done / totals[level].all;
  return rates;
}
// { 1: 1, 2: 0.5 }
```

Look at other numbers too: **average deaths**, **median time** (one stuck player can inflate an average), and **drop-off** (players who never attempted the next level). A level with a fine completion rate but ten deaths per clear may still be frustrating.

## Set a target, then adjust

Numbers need a goal. A designer might decide: "early levels should be completed by about 80% of attempts; the final boss by about 50%." With a target, you can turn a difficulty parameter (enemy speed, spawn interval, timer length) up or down by a small step:

```javascript
function adjustDifficulty(value, rate, target, step, min, max) {
  if (rate < target) value -= step;   // too hard: make it easier
  else if (rate > target) value += step;   // too easy: make it harder
  return Math.max(min, Math.min(max, value));
}
```

Small steps and clamped ranges matter. Large jumps overshoot ("now it is trivial"), and an unclamped value can drift into nonsense like negative enemy speed. Change **one** parameter at a time between playtests, or you will not know which change caused the result.

## Seeded randomness for fair comparisons

Random spawns make two playtests hard to compare: maybe level 2 just rolled more enemies this time. A **seeded** random number generator produces the same sequence every time from the same seed, so you can replay identical conditions and simulate many runs:

```javascript
function makeRng(seed) {           // mulberry32: small, fast, good enough for games
  let a = seed >>> 0;
  return function () {
    a = (a + 0x6D2B79F5) >>> 0;
    let t = a;
    t = Math.imul(t ^ (t >>> 15), t | 1);
    t ^= t + Math.imul(t ^ (t >>> 7), t | 61);
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}

const rng = makeRng(42);
rng(); // always the same first value for seed 42
```

`Math.random()` cannot be seeded, so games that need replays, daily challenges or procedural levels ship their own generator. Many roguelikes let players share a seed to play the same map.

## Simulating before playtesting

With a seeded RNG you can run a crude **simulation**: if a level kills a player with probability `p` per encounter and has `n` encounters, how many of 1,000 simulated runs survive? Simulations are cheap and catch obvious problems, but they model your assumptions, not real people. Use them to choose what to test, then confirm with humans.

## Data is not the whole story

The Extra Credits video makes the point that balance is about meaningful choices, not equal numbers. Data tells you **where** players struggle; watching them tells you **why**. A 40% completion rate might mean the level is too hard, or that the exit is hard to find, or that a control is confusing. Pair every chart with observations.

## Common mistakes

- **Averages hiding outliers**: use medians or look at the distribution.
- **Tiny samples**: five testers is enough to spot big problems, not to tune by 2%.
- **Changing several things at once**, so results cannot be attributed.
- **No target**, so every number looks "about right".
- **Optimising the metric**, not the experience (a level everyone completes because it is boring).

## Quick recap

- Log just enough per attempt: level, completed, deaths, time.
- Completion rate = completed / attempts; also check deaths, medians and drop-off.
- Set targets; adjust one parameter by small, clamped steps.
- Seeded RNGs make runs repeatable and simulations possible.
- Combine numbers with observation.

## Try it

Open the Do tab to write `completionRates`, `hardestLevel`, `adjustDifficulty` and a seeded `simulateRuns`.

Summarise playtest sessions into completion rates, find the problem level, and adjust a difficulty value towards a target.

Tuning with data

Balancing for Skill - The Link from Optimal Power to Strategy - Extra Credits

How Games (Secretly) Adjust Difficulty

Compare Unity, Godot and Unreal, build a first scene in Godot, and tune difficulty from playtest data.