Developing Games

When asked to build a game or game system, follow this decision tree:

1. Identify the platform/engine (explicit or inferred from context: web → HTML5/Canvas/Phaser, Python → Pygame, mentions of Unity/Godot/Unreal → that engine, no constraint → pick the simplest fit for the genre).
2. Identify the genre (platformer, top-down shooter, puzzle, RPG, roguelike, etc.) — genre determines core loop, data structures, and physics needs.
3. Scaffold with a proper game loop first, before any feature code:

JavaScript
// Fixed timestep game loop (prevents physics inconsistency across frame rates)
const FPS = 60;
const STEP = 1000 / FPS;
let lastTime = 0, accumulator = 0;

function gameLoop(timestamp) {
    accumulator += timestamp - lastTime;
    lastTime = timestamp;

    while (accumulator >= STEP) {
        update(STEP / 1000); // deterministic, delta in seconds
        accumulator -= STEP;
    }

    render(accumulator / STEP); // interpolation factor for smooth rendering
    requestAnimationFrame(gameLoop);
}

4. Build systems in this strict order: loop → input → entity/state model → physics/collision → rendering → audio → UI → polish (juice). Never start with graphics/art code.

Progress checklist for any non-trivial game feature or full game:

• Step 1: Define the core loop (what does the player do every 5 seconds? every 5 minutes?)
• Step 2: Choose architecture pattern (ECS for many entity types, OOP state machine for simple games, FSM per-entity for AI/player states)
• Step 3: Implement game loop with fixed timestep
• Step 4: Implement input handling (abstracted from action logic — map keys to actions, not actions to keys)
• Step 5: Implement entity/world model and update logic
• Step 6: Implement collision detection appropriate to need (AABB for simple, spatial hashing/quadtree if >100 entities)
• Step 7: Implement rendering (separate from update logic — never mutate state in render)
• Step 8: Add game feel/juice (screen shake, hit-stop, particle feedback, easing) — do this LAST
• Step 9: Profile and optimize (object pooling, avoid GC pressure in hot loops)
• Step 10: Playtest-driven tuning (numbers like jump height, enemy speed are never right on first guess)

Architecture decision guide

Core systems reference

Collision (AABB, the default for 2D):

JavaScript
function aabbCollide(a, b) {
    return a.x < b.x + b.w && a.x + a.w > b.x &&
           a.y < b.y + b.h && a.y + a.h > b.y;
}

Object pooling (avoid new in hot loops — biggest perf killer in JS/C# games):

JavaScript
class Pool {
    constructor(factory, size) {
        this.factory = factory;
        this.pool = Array.from({length: size}, factory);
        this.active = [];
    }
    spawn(...args) {
        const obj = this.pool.pop() || this.factory();
        obj.init(...args);
        this.active.push(obj);
        return obj;
    }
    release(obj) {
        this.active.splice(this.active.indexOf(obj), 1);
        this.pool.push(obj);
    }
}

Input abstraction (decouple keys from actions):

JavaScript
const keyMap = { ArrowLeft: 'moveLeft', ArrowRight: 'moveRight', Space: 'jump' };
const actions = new Set();
window.addEventListener('keydown', e => keyMap[e.code] && actions.add(keyMap[e.code]));
window.addEventListener('keyup', e => keyMap[e.code] && actions.delete(keyMap[e.code]));
// game logic checks actions.has('jump'), never e.code directly