ajout du game-designer

game-designer/references/balancing-spreadsheets.md

@@ -0,0 +1,44 @@
+# Balancing Spreadsheets
+
+Balance numbers belong in a live spreadsheet, not a markdown table — the point is the user can change one input and watch everything downstream recalculate. Always build these with the `xlsx` skill (read its SKILL.md first) so formulas, not hardcoded values, drive every derived column.
+
+## TTK (time-to-kill) calculator
+
+Columns:
+| Weapon/Enemy | Base Damage | Fire Rate (shots/s) | DPS (=Damage*FireRate) | Target HP | TTK (=HP/DPS) |
+
+- Put Base Damage, Fire Rate, and Target HP as the only hand-entered cells; everything else is a formula.
+- Add a second small table of **target TTK ranges per enemy tier** (trash/elite/boss) so the user can see at a glance which weapons fall outside the intended range — conditional formatting (red/green) on the TTK column against those targets is worth setting up.
+
+## XP / progression curve generator
+
+Columns:
+| Level | XP to Next | Cumulative XP | Power Stat (optional) |
+
+- `XP to Next` as a formula off Level using whichever curve shape was chosen (see `systems-design-patterns.md`): e.g. linear `=Base*Level`, exponential `=Base*Growth^(Level-1)`, log-style `=Base*LN(Level+1)`.
+- Put `Base` and `Growth` in labeled, separate cells (not buried in the formula) so the user can tune them directly.
+- A line chart of `Cumulative XP` vs. `Level` is the single most useful gut-check — always add one. If a "Power Stat" column exists, chart it against a separately-entered "Content Difficulty" column to visualize the power-vs-content curve match.
+
+## Economy ledger (faucets & sinks)
+
+Columns:
+| Day/Session | Faucet: Source A | Faucet: Source B | ... | Sink: Spend A | Sink: Spend B | ... | Net Flow (=sum faucets - sum sinks) | Running Balance (=prior balance + Net Flow) |
+
+- One column per named faucet/sink (pulled straight from the table built in the systems-design doc), not a single "income" blob — the point is to see which specific source or sink is driving the trend.
+- Model at least 30-90 days/sessions of simulated play to see whether Running Balance trends flat, up, or down — flag explicitly which it does and what that implies (inflation risk if up and unchecked; frustration risk if down to zero with no recovery).
+- If there's a premium currency, give it its own mini-ledger — don't mix premium and soft currency in the same running balance.
+
+## Drop tables
+
+Columns:
+| Item | Rarity Tier | Weight | Cumulative Weight | Probability (=Weight/TotalWeight) |
+
+- Probability is always a formula off Weight, never hand-entered — keeps it correct when items are added/removed.
+- If using a pity system, add a small separate table: `Pity Counter Threshold`, `Pity Bonus Weight Multiplier`, and a worked example row showing probability at counter=0 vs counter=threshold.
+- Add a `SUM` check cell on the Probability column that should always read 100% — useful as a built-in sanity check the user can glance at after any edit.
+
+## General spreadsheet hygiene
+
+- Hand-entered inputs and calculated outputs should be visually distinct (e.g. light fill on input cells) so the user knows what's safe to edit.
+- Name the tabs by function (`TTK Calc`, `XP Curve`, `Economy`, `Drop Tables`), one model per tab, so the file stays navigable as it grows.
+- Prefer a chart over a wall of numbers wherever the question is "does this curve look right" — that's a visual judgment, not a numeric one.

game-designer/references/gdd-structure.md

@@ -0,0 +1,38 @@
+# GDD Structure & Right-Sizing
+
+A GDD's job is to get read and used, not to be exhaustive. Pick the right size before picking the sections.
+
+## Which size to use
+
+| Size | When | Length |
+|---|---|---|
+| **One-pager / pitch doc** | Early concept, pitching to a publisher/team lead, internal greenlight | High concept, pillars, core loop, hook, target audience/platform, comparable titles. ~1 page. |
+| **Lean GDD** | Most indie/small-team projects, vertical slices | Adds: detailed core loop breakdown, primary systems (not exhaustive), progression overview, art/audio direction notes, scope/milestones. ~5-15 pages. |
+| **Full GDD** | Larger teams, publisher-facing, complex systems that need shared source of truth | Every section below, fully detailed, often split into separate system-specific docs linked from a master doc. |
+| **Systems-only spec** | User just wants one system nailed down (e.g. "write up the crafting system") | Skip the rest of this file — go straight to the relevant pattern in `systems-design-patterns.md` and write a focused spec: goal, player-facing rules, edge cases, open questions. |
+
+Default to **lean GDD** unless the user's request or stated team size clearly calls for more or less.
+
+## Full section list (use what's relevant, cut the rest)
+
+1. **High Concept** — one sentence. What is this game, in genre-comparison shorthand if useful ("X meets Y").
+2. **Pillars** — 3-4 design pillars that every feature decision gets checked against. Concrete, not generic ("readable chaos in combat," not "fun gameplay").
+3. **Target Audience & Platform** — who, and where they'll play it. Drives UI scale, session length assumptions, monetization model if any.
+4. **Core Gameplay Loop** — the verb loop the player repeats minute-to-minute, and how it nests into a session-level loop and a meta/long-term loop. Diagram this as a simple cycle if it helps (explore → fight → loot → upgrade → repeat).
+5. **Mechanics** — the verbs themselves: what the player can do, moment to moment. Keep this to player-facing rules, not implementation.
+6. **Systems** — the underlying machinery: combat system, progression system, economy, crafting, AI behavior, etc. Each gets its own subsection or its own doc once it's non-trivial — point to `systems-design-patterns.md`.
+7. **Progression** — how player power/unlocks/narrative reveal unfolds over the full game. Pacing of new mechanics, not just numeric power.
+8. **Level/World Design** — structure (linear, hub-and-spoke, open world), how levels teach and escalate. See the Stage 5 guidance in the main skill file.
+9. **Narrative & World** — setting, tone, story structure, how much story is delivered vs. emergent. Skip or keep minimal for mechanically-driven games.
+10. **UI/UX** — key screens, HUD philosophy, accessibility considerations (colorblind modes, remappable controls, difficulty options).
+11. **Art & Audio Direction** — mood references, visual style pillars, audio's role (diegetic feedback, music adaptivity). Light touch unless the user is the art/audio lead.
+12. **Monetization** (if F2P/mobile) — currency types, what's sold, what's earnable, and explicitly how monetization doesn't undercut the core pillars. Cross-reference the economy section in `systems-design-patterns.md`.
+13. **Technical Considerations** — engine, platform constraints, anything that bounds design choices (e.g. mobile thermal/battery limits, online vs. offline).
+14. **Scope & Milestones** — what's in the vertical slice vs. full release; biggest risk items first.
+
+## Writing conventions
+
+- Player-facing language for mechanics ("the player can dodge-roll for 0.4s of i-frames"), not engineering language.
+- Every section should answer "why" as much as "what" — tie back to pillars.
+- Use tables for anything enumerable (enemy types, item tiers, currencies) rather than prose paragraphs.
+- Flag open questions explicitly (`**Open question:**`) rather than silently picking an answer the user didn't ask for, when a decision has real design tradeoffs.

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

@@ -0,0 +1,40 @@
+# 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.