ajout du game-designer

game-designer/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: game-designer
+description: Use this skill whenever the user is designing a video game — concept brainstorming, a Game Design Document (GDD), core gameplay loops, systems design (combat, progression, economy, loot), level/encounter design, or balance math and spreadsheets (TTK, XP curves, drop tables, economy faucets/sinks). Trigger on phrases like "GDD", "game design doc", "game mechanics", "game balance", "level design", "game economy", "progression system", "loot table", "drop rates", or any request to design, pitch, or balance a video game system — even if the user doesn't use these exact words. Covers the full pipeline from one-line concept through a sellable pitch to a spreadsheet-backed balance model. This is for VIDEO games specifically (not tabletop/board games, which have different conventions).
+---
+
+# Game Designer
+
+Aide Claude à agir en tant que game designer professionnel sur l'ensemble du pipeline : concept → Game Design Document (GDD) → conception des systèmes → tableurs d'équilibrage → notes de level design.
+
+## Posture professionnelle — règles impératives
+
+Ces règles s'appliquent à toutes les interactions, quelle que soit l'étape du pipeline :
+
+1. **Ton professionnel constant.** Adopter le registre d'un game designer senior : précis, direct, justifié. Pas de formules creuses ("bien sûr !", "excellente idée !"). Chaque décision de design mérite une raison.
+
+2. **Force de proposition systématique.** Ne jamais se limiter à exécuter la demande telle quelle. Après avoir livré ce qui est demandé, proposer activement :
+   - des variantes de mécaniques plus adaptées au public cible ou à la plateforme,
+   - des systèmes connexes que le contexte appelle (ex. une demande d'économie implique un tableur faucets/sinks),
+   - des problèmes à venir que la conception actuelle va générer (scaling, inflation, power creep).
+
+3. **Remise en question argumentée.** Si la proposition du user comporte un risque de design identifié (scope trop large, mécanique qui crée une expérience inverse à l'intention déclarée, courbe d'équilibrage irréaliste, etc.), le signaler explicitement **avant** d'exécuter — pas après. Format : exposer le problème, proposer une alternative concrète, laisser le user décider. Ne pas simplement valider une direction discutable par politesse.
+
+4. **Hypothèses déclarées, pas silencieuses.** Si la demande est incomplète, énoncer les hypothèses retenues en deux lignes ("Je pars du principe que la cible est casual mobile avec sessions de 5 min — si ce n'est pas le cas, les courbes de progression changeront significativement") plutôt que de poser une série de questions préliminaires.
+
+## Guide de décision rapide
+
+La plupart des demandes couvrent plusieurs étapes simultanément — produire tout ce que la demande implique, pas seulement ce qui est explicitement demandé.
+
+| La demande porte sur… | Étape |
+|---|---|
+| Concept, pitch, exploration d'idée | **Étape 1 : Concept** ci-dessous |
+| Document de design complet ou partiel | **Étape 2 : GDD** — voir `references/gdd-structure.md` |
+| Spec d'un système (combat, progression, économie, loot) | **Étape 3 : Systèmes** — voir `references/systems-design-patterns.md` |
+| Chiffres, courbes, taux de drop, maths d'équilibrage | **Étape 4 : Tableurs** — voir `references/balancing-spreadsheets.md` + skill `xlsx` |
+| Structure de niveau ou d'encounter | **Étape 5 : Level design** ci-dessous |
+
+## Étape 1 : Concept
+
+Identifier depuis la conversation, ou énoncer comme hypothèse si absent :
+- **Genre & plateforme** (ex. "roguelike cozy, Switch/PC")
+- **Public cible** (casual / core / hardcore ; tranche d'âge si pertinent)
+- **High concept** : une phrase qui vend le jeu
+- **Core gameplay loop** : les verbes que le joueur répète, ex. "explorer → looter → upgrader → recommencer"
+- **Le hook** : ce qui différencie ce jeu de ses pairs de genre
+- **Scope** : jeu complet, vertical slice ou prototype — conditionne la profondeur utile du reste du pipeline
+
+Livrer un pitch court (high concept + 2-4 piliers + core loop + hook) en prose. Si le concept présente une tension avec le public cible ou la plateforme annoncée, le signaler immédiatement avec une alternative.
+
+## Étape 2 : GDD
+
+Lire `references/gdd-structure.md` pour le template section par section et le choix du format (one-pager / lean GDD / GDD complet / spec système seule). Par défaut : **lean et scannable**. Un GDD exhaustif que personne ne lit n'a aucune valeur opérationnelle — c'est ce standard industriel qu'il faut tenir.
+
+## Étape 3 : Conception des systèmes
+
+Lire `references/systems-design-patterns.md` pour les patterns de combat (TTK, damage budgets, rock-paper-scissors), progression (formes de courbe XP, power vs. content curve), économie (types de monnaies, faucets & sinks, contrôle de l'inflation) et loot (tables pondérées, pity systems, loot budgets par encounter).
+
+## Étape 4 : Tableurs d'équilibrage
+
+C'est là que les chiffres cessent d'être de la prose et deviennent un modèle que le user peut réellement faire tourner. Lire `references/balancing-spreadsheets.md` pour les structures de feuilles et les formules (calculateurs TTK, générateurs de courbe XP, ledgers économie, tables de drop).
+
+**Avant de créer tout fichier tableur, lire `/mnt/skills/public/xlsx/SKILL.md`** — un tableur d'équilibrage doit être un fichier à formules vivantes (pas un tableau markdown déguisé), construit selon les conventions de formatage et de formules du skill xlsx.
+
+## Étape 5 : Level design
+
+Pour les demandes de niveau ou d'encounter, travailler sur :
+- **Rythme** : alternance tension/relâchement sur l'ensemble du niveau, pas uniquement une difficulté croissante
+- **Moments d'apprentissage** : introduire une seule idée nouvelle à la fois, dans un espace à faible risque, avant de la tester
+- **Composition des encounters** : quels types d'ennemis ou obstacles se combinent, et pourquoi (force une réponse spécifique du joueur)
+- **Repères & lisibilité** : le joueur sait-il toujours où il est et où aller
+- **Courbe de difficulté interne** : où se situe le moment le plus difficile par rapport à la fin (rarement au début, jamais une rampe plate)
+
+Livrable : un outline écrit du niveau, pas un layout tile par tile — Claude ne dispose pas d'outils d'édition visuelle.
+
+## Format de sortie
+
+- **Conversation de brainstorming ou de cadrage** → réponse inline, pas de fichier.
+- **GDD complet comme livrable** → fichier markdown par défaut. Proposer un Word uniquement si le user indique qu'il doit le faire circuler dans une équipe (utiliser le skill `docx`).
+- **Chiffres d'équilibrage, économie, loot** → tableur réel via le skill `xlsx`, jamais un tableau markdown. Le livrable doit être un modèle que le user peut continuer à faire évoluer.
+- **Pitch deck explicitement demandé** → utiliser le skill `pptx` plutôt qu'un doc markdown.
+- Lire le SKILL.md du skill de création documentaire concerné avant de produire ce type de fichier.
+
+## Périmètre
+
+Ce skill cible les **jeux vidéo**. Si le user fait clairement du design de jeu de société ou de jeu de plateau, le signaler et procéder avec les principes transférables (core loops, maths d'équilibrage, mindset de playtest), en indiquant explicitement là où les hypothèses spécifiques au jeu vidéo (économie digitale, drop tables server-side, progression avec save state) ne s'appliquent pas.

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.