Game Design

Design games that are fun on purpose

Engine-agnostic game design: mechanics, loops, progression, economy, balance, feel, and the discipline of prototyping and scope. No engine APIs live here — when the design is settled, the implementation belongs to godot, unity, or unreal.

Two premises govern everything below. Fun is discovered, not designed — you cannot reason your way to a fun game on paper, you find it by building the smallest playable version and playing it, so every hour spent planning a mechanic you have not prototyped is an hour spent guessing. And a game is the set of verbs it gives the player plus the loops those verbs live in — art, story, and levels dress that skeleton; if the skeleton is not fun in greybox, nothing dresses it into fun.

Route elsewhere when the ask is not design:

Loops: moment-to-moment → session → meta

A game is loops nested inside loops. Each layer must reward on its own and feed motivation to the layer above it.

moment-to-moment  (seconds)   the primary verb: aim+fire, jump, place, click, parry
        │  feeds
session loop      (minutes)   a run / match / mission: setup → tension → resolution
        │  feeds
meta loop         (sessions)  mastery, unlocks, collection, rank — why you return tomorrow

• Moment-to-moment first. The thing the player does constantly must feel good with no goal attached — jumping in Mario is fun in an empty room. If this layer is flat, no progression system rescues it. (Bungie's "30 seconds of fun" rule: perfect the small loop, then repeat it.)
• Session loop gives a run shape — a beginning, a rising middle, a payoff. It should end on a hook (almost-had-it, one-more-run).
• Meta loop is the reason-to-return: it spends the currency and mastery earned in sessions on lasting change (new verbs, new options, status).
• Reward funding. A reward at one layer should fund desire at the next. Misfunded loops fail predictably: fun moment-to-moment + empty meta = "great but I bounced"; rich meta + flat moment-to-moment = "I grind and I don't know why."

Depth vs breadth of loops, feedback-loop math, and worked loop teardowns: references/mechanics-and-loops.md.

MDA: the working lens

Mechanics → Dynamics → Aesthetics. The designer authors Mechanics (rules, entities, numbers). At runtime those produce Dynamics (emergent behavior as players interact). Players only ever feel the Aesthetics (the emotional response). You design left-to-right; the player experiences right-to-left — so you must reason backward from the feeling you want to the rule that causes it.

• "Fun" is not a design target — name the aesthetic. MDA's vocabulary: sensation, fantasy, narrative, challenge, fellowship, discovery, expression, submission (relaxation). "Make it more fun" is unactionable; "raise the challenge and discovery, drop the submission" is a to-do list.
• Design the verbs, not the features. The verb set is the game. A tight set of verbs with deep interaction (chess, Tetris) beats a wide set of shallow ones. Before adding a feature, ask: does it add a verb, deepen an existing verb, or just add a number?
• Second-order design. Ask what the rule makes players do, not what it literally says. Every incentive is also a de-incentive for everything else — rewarding kills steals attention from exploring.

The eight aesthetics with examples, emergence vs scripted content, and interaction-depth heuristics: references/mechanics-and-loops.md.

Progression & economy

Progression controls the rate at which the game reveals its depth; economy is the currency plumbing underneath it.

• Pacing. Interleave tension and release; teach → test → twist. Run difficulty and novelty as two curves so a lull in one is covered by the other.
• Unlocks earn their keep. Each unlock should add a verb or a meaningful choice, not just +10%. Gate content to pace the complexity the player must hold at once.
• Currencies need distinct jobs. Soft (earned, spent freely) vs hard/premium (scarce). Never add a currency without a distinct sink it exists to feed — currencies without sinks are clutter.
• Sinks and faucets. Faucets create currency; sinks destroy it. Balance the two or the economy drifts.

Model the drift with the core identity — no engine needed, a spreadsheet does it:

net_income_rate = faucet_rate − sink_rate
time_to_afford  = cost / net_income_rate          # tune this against desired pacing
cost(n)         = base × growth^n                 # escalating sink; growth ≈ 1.07–1.15

• Avoiding runaway. If net_income_rate rises over time, costs must rise at least as fast or currency becomes meaningless (hyperinflation, trivialized late game). Fixes: escalating/exponential sinks, consumable sinks, caps, prestige resets.
• Kill snowballs. Positive feedback loops (rich-get-richer) let a leader accelerate out of reach and end matches early. Counter with negative feedback / catch-up (rubber-banding, comeback mechanics, escalating cost of dominance) — tuned so it aids without feeling like punishment for winning.

Currency taxonomies, inflation math, prestige/reset design, and a balancing-spreadsheet layout: references/progression-and-economy.md.

Difficulty & balancing

• The curve is a sawtooth, not a ramp. Rising baseline with peaks (bosses, gauntlets) and valleys (recovery, reward). Aim for the flow channel: challenge tracking skill, between boredom (too easy) and anxiety (too hard).
• Few high-leverage knobs. Most balance lives in a handful of variables (damage, health, spawn rate, cost, cooldown). Identify them, tune one at a time, and never chase a symptom by touching five knobs at once.
• Data-driven balance. Externalize tunables into data (tables/config), not hard-coded constants, so designers iterate without a rebuild and you can diff and A/B numbers. (The engine skill wires the loader; this skill decides which numbers are tunable.)
• Dominant strategies kill choice. When one option strictly beats the rest, all other choices die. Hunt them in playtest data and telemetry; fix by nerfing the outlier or buffing counters toward intransitive balance (rock-paper-scissors: every option beaten by another).
• Perceived ≠ actual difficulty, and difficulty options/accessibility widen the audience — decouple challenge from exclusion.

Flow-channel tuning, dominant-strategy detection, symmetry vs asymmetry, and difficulty-option patterns: references/progression-and-economy.md.

Feel / "juice" (as design intent)

Game feel is the tactile sensation of control — the moment-to-moment made physical. It is a design concern here; the engine skills implement the effects.

• Every input needs an immediate, legible reaction — visual, audio, and/or haptic. Perceived latency is the enemy; responsiveness beats fidelity.
• Juice vocabulary (specify the intent, let the engine do it): hit-stop / hit-pause (freeze a few frames on impact to sell weight), screenshake (scaled to significance, never gratuitous), anticipation & follow-through and squash-and-stretch (animation principles that read intent), particles, easing/tweening curves, and layered sound.
• Feel is often hidden generosity. Coyote time, input buffering, and forgiveness windows make a game feel fair and responsive without the player ever knowing why.
• Design-level, not code-level here. Decide what should feel weighty and why; specify the effect and its trigger. The keyframes, curves, and shaders belong to godot / unity / unreal.