skills-IA/game-designer/references/systems-design-patterns.md

Systems Design Patterns

Concrete patterns for the systems that show up in almost every video game. Use these as starting points, not rigid rules — always tie choices back to the game's stated pillars.

Combat

• Time-to-kill (TTK) as the central tuning lever. Decide target TTK ranges per enemy tier first (e.g. trash: 1-2s, elite: 8-15s, boss: 90-180s), then derive damage/HP numbers from that — not the other way around. See balancing-spreadsheets.md for the calculator structure.
• Damage budget per stat point. Decide how much DPS one point of a stat is worth, and keep it consistent across the kit so player choices stay comparable.
• Rock-paper-scissors / counter relationships. Useful for build diversity and PvP, but every "counter" needs a way for the countered side to respond, or it just feels unfair.
• Readability over realism. Telegraphs, hit-stop, and clear silhouettes matter more than damage-number accuracy. If a player can't tell why they died, the numbers don't matter.
• i-frames / mercy windows. Define explicitly (dodge windows, post-hit invulnerability) — these are usually the actual skill expression, more than DPS optimization.

Progression

• Pick the curve shape on purpose:
  • Linear (XP = base * level): predictable, good for short games or when pacing should feel even.
  • Exponential (XP = base * growth^level): classic RPG feel, makes early levels fast and late levels a grind — only use if the grind itself is meant to be the late-game loop.
  • Logarithmic / diminishing: fast early progress that flattens — good for mobile/casual retention curves.
  • S-curve: slow start, fast middle, slow end — good for matching a 3-act content pace.
• Power curve vs. content curve. Player power should grow roughly in step with content difficulty — if power outpaces content, late game feels trivial; if content outpaces power, it feels like a wall. Plot both curves against each other, not just power alone.
• Decouple narrative pacing from numeric pacing where possible — players forgive a numeric plateau if something new is unlocked (ability, area, story beat).

Economy

• Pick currency count deliberately. Single currency = simple, easy to balance, easy to undermine with monetization. Dual currency (soft earned / hard premium) is the F2P standard specifically to firewall "things you can buy" from "things you must play for." More than 2-3 currencies usually confuses players unless each has a very narrow, clear purpose.
• Every currency needs faucets (sources) and sinks (spends) mapped explicitly. List them in a table. If sinks < faucets over time, expect inflation (currency stops feeling meaningful); if sinks > faucets, expect frustration/quitting. This is exactly what the economy ledger in balancing-spreadsheets.md is for — don't eyeball it, model it.
• Soft caps and sinks for "solved" economies. Late-game players who've maxed everything still need somewhere for currency to go (cosmetics, prestige systems, respec costs) or the economy visibly breaks.
• Monetization sinks must not be the only meaningful sink, or free players feel the economy is hostile by design.

Loot

• Weighted random tables, not flat percentages, for anything with rarity tiers — gives the designer one knob (weight) per item instead of having to keep percentages summing to 100 by hand.
• Pity timers / bad-luck protection for any drop a player can fail to get for a long time — pure RNG without a pity mechanism is the single most common source of player frustration in loot systems.
• Loot budget per encounter, not per item. Decide "this encounter is worth X loot value," then distribute that value across possible drops — keeps reward pacing consistent even as the item pool grows.
• Visible vs. hidden odds. Decide deliberately whether drop rates are shown to the player (trust-building) or hidden (mystery-building) — this is a design choice with real player-trust implications in F2P/gacha contexts, not just a UI detail.

Core loop & "feel"

• State the loop as verbs, and check that each verb has a clear feedback signal (visual/audio/haptic) — a mechanic without feedback doesn't feel like it exists, no matter how well it's balanced.
• Juice is cheap leverage. Screen shake, hit-stop, particle bursts, and sound layering can make an underpowered mechanic feel great, or an overpowered one feel earned — design feedback alongside numbers, not after.