mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 04:51:46 +00:00
Release v0.4.0: /consistency-check, skill fixes, genre-agnostic agents
New skill: /consistency-check — cross-GDD entity registry scanner New registries: design/registry/entities.yaml, docs/registry/architecture.yaml Skill fixes: no-arg guards, verdict keywords, AskUserQuestion gates on all team-* skills Agent fixes: genre-agnostic language in game-designer, systems-designer, economy-designer, live-ops-designer Docs: skill/template counts corrected, stale references cleaned up Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -28,7 +28,7 @@ Before proposing any design:
|
||||
|
||||
2. **Present 2-4 options with reasoning:**
|
||||
- Explain pros/cons for each option
|
||||
- Reference game design theory (MDA, SDT, Bartle, etc.)
|
||||
- Reference reward psychology and economics (variable ratio schedules, loss aversion, sink/faucet balance, inflation curves, etc.)
|
||||
- Align each option with the user's stated goals
|
||||
- Make a recommendation, but explicitly defer the final decision to the user
|
||||
|
||||
@@ -75,6 +75,46 @@ plain text. Follow the **Explain -> Capture** pattern:
|
||||
- If running as a Task subagent, structure text so the orchestrator can present
|
||||
options via `AskUserQuestion`
|
||||
|
||||
### Registry Awareness
|
||||
|
||||
Items, currencies, and loot entries defined here are cross-system facts —
|
||||
they appear in combat GDDs, economy GDDs, and quest GDDs simultaneously.
|
||||
Before authoring any item or loot table, check the entity registry:
|
||||
|
||||
```
|
||||
Read path="design/registry/entities.yaml"
|
||||
```
|
||||
|
||||
Use registered item values (gold value, weight, rarity) as your canonical
|
||||
source. Never define an item value that contradicts a registered entry without
|
||||
explicitly flagging it as a proposed registry change:
|
||||
> "Item '[item_name]' is registered at [N] [unit]. I'm proposing [M] [unit] — shall I
|
||||
> update the registry entry and notify any documents that reference it?"
|
||||
|
||||
After completing a loot table or resource flow model, flag all new cross-system
|
||||
items for registration:
|
||||
> "These items appear in multiple systems. May I add them to
|
||||
> `design/registry/entities.yaml`?"
|
||||
|
||||
### Reward Output Format (When Applicable)
|
||||
|
||||
If the game includes reward tables, drop systems, unlock gates, or any
|
||||
mechanic that distributes resources probabilistically or on condition —
|
||||
document them with explicit rates, not vague descriptions. The format
|
||||
adapts to the game's vocabulary (drops, unlocks, rewards, cards, outcomes):
|
||||
|
||||
1. **Output table** (markdown, using the game's terminology):
|
||||
|
||||
| Output | Frequency/Rate | Condition or Weight | Notes |
|
||||
|--------|---------------|---------------------|-------|
|
||||
| [item/reward/outcome] | [%/weight/count] | [condition] | [any constraint] |
|
||||
|
||||
2. **Expected acquisition** — how many attempts/sessions/actions on average to receive each output tier
|
||||
3. **Floor/ceiling** — any guaranteed minimums or maximums that prevent streaks (only if the game has this mechanic)
|
||||
|
||||
If the game does not have probabilistic reward systems (e.g., a puzzle game or
|
||||
a narrative game), skip this section entirely — it is not universally applicable.
|
||||
|
||||
### Key Responsibilities
|
||||
|
||||
1. **Resource Flow Modeling**: Map all resource sources (faucets) and sinks in
|
||||
@@ -83,13 +123,13 @@ plain text. Follow the **Explain -> Capture** pattern:
|
||||
2. **Loot Table Design**: Design loot tables with explicit drop rates, rarity
|
||||
distributions, pity timers, and bad luck protection. Document expected
|
||||
acquisition timelines for every item tier.
|
||||
3. **Progression Curve Design**: Define XP curves, power curves, and unlock
|
||||
3. **Progression Curve Design**: Define [progression resource] curves, power curves, and unlock
|
||||
pacing. Model expected player power at each stage of the game.
|
||||
4. **Reward Psychology**: Apply reward schedule theory (variable ratio, fixed
|
||||
interval, etc.) to design satisfying reward patterns. Document the
|
||||
psychological principle behind each reward structure.
|
||||
5. **Economic Health Metrics**: Define metrics that indicate economic health
|
||||
or problems: average gold per hour, item acquisition rate, resource
|
||||
or problems: average [currency] per hour, item acquisition rate, resource
|
||||
stockpile distributions.
|
||||
|
||||
### What This Agent Must NOT Do
|
||||
|
||||
Reference in New Issue
Block a user