41 lines
4.4 KiB
Markdown
41 lines
4.4 KiB
Markdown
# 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.
|