@jgengine/shell 0.11.0 → 0.13.0

package/skills/game-design/references/field-guide.md

@@ -0,0 +1,288 @@
+# Game design field guide
+
+Use this reference when a task needs more than the canonical workflow in [`SKILL.md`](../SKILL.md). It is a synthesis of research and shipped-game practice, not a universal formula. Select the tools that expose the current design risk and validate them with players.
+
+## Contents
+
+1. Experience hypotheses
+2. Actions, feedback, and decisions
+3. Nested loops
+4. Systems and economies
+5. Progression and challenge
+6. Onboarding and accessibility
+7. Multiplayer and social play
+8. Content structure and genre lenses
+9. Prototyping and playtesting
+10. JGengine translation
+11. Diagnostic questions
+12. Research basis
+
+## 1. Experience hypotheses
+
+### Write a working contract
+
+Use a compact table in the issue, task, or conversation. Do not preserve speculative prose as a large design document.
+
+| Question | Useful answer | Weak answer |
+| --- | --- | --- |
+| Who plays, where, and for how long? | “Two friends, 20-minute online co-op runs” | “Everyone” |
+| What do they repeatedly do? | “Scout, plan a breach, improvise when it fails” | “Experience action” |
+| What should dominate the experience? | “Tense coordination, expressive tools, recoverable chaos” | “Fun and immersive” |
+| What must it not become? | “Inventory chores, solved loadouts, long spectator time” | “Not boring” |
+| What proves the loop? | “A new pair completes one objective, explains its failure, and chooses a different second approach” | “Players like it” |
+
+Treat pillars as prioritization constraints. Make each pillar observable and give it an anti-pillar. When two features conflict, the pillar decides which survives.
+
+### Trace experience in both directions
+
+Use the Mechanics-Dynamics-Aesthetics separation as a causal check:
+
+- **Experience:** the intended emotional or social response.
+- **Dynamics:** the behavior that should emerge during play.
+- **Mechanics:** the rules, data, controls, and feedback likely to produce that behavior.
+
+Design backward from experience, then simulate forward from mechanics. A stealth meter does not guarantee tension; examine whether information, enemy response, recovery, and level geometry actually produce cautious planning.
+
+Use autonomy, competence, and relatedness as diagnostics, not mandatory quotas:
+
+- **Autonomy:** choices allow ownership and expression rather than cosmetic branching.
+- **Competence:** players can understand improvement and attribute outcomes to actions.
+- **Relatedness:** players can contribute, recognize others, and form meaningful social context.
+
+## 2. Actions, feedback, and decisions
+
+### Model a playable verb
+
+For every core verb, specify:
+
+1. cue and available information
+2. player intention and input
+3. target and eligibility rules
+4. simulation/state transition
+5. immediate visual, audio, haptic, and systemic feedback
+6. consequence that affects a later choice
+7. skill the player is expected to learn
+8. counterplay, cost, risk, or limitation
+
+An animation without a state consequence is presentation. A state change the player cannot perceive cannot reliably teach. Good moment-to-moment feel combines predictable physical response, amplified event importance, and assistance that honors player intention.
+
+### Test whether a choice is meaningful
+
+A decision usually needs:
+
+- at least two viable options the player can distinguish
+- enough information to form a plan, with uncertainty appropriate to the fantasy
+- a tradeoff rather than a universally dominant answer
+- a perceivable consequence at the promised time scale
+- an effect on future state, knowledge, position, relationships, or opportunity
+
+Not every input needs strategic depth. Execution, expression, discovery, role-play, and timing can carry play. Be precise about which kind of agency the design promises.
+
+Audit common choice failures:
+
+- **blind:** relevant information arrives only after commitment
+- **fake:** outcomes converge without expressive or narrative value
+- **solved:** one option dominates across contexts
+- **noisy:** feedback cannot be attributed to the choice
+- **overloaded:** too many new variables must be evaluated at once
+- **inert:** consequence does not alter anything the player values
+
+## 3. Nested loops
+
+### Loop anatomy
+
+Write each loop as:
+
+`state/cue -> goal -> informed action -> simulation -> feedback -> changed state -> next decision`
+
+The return state must differ in a useful way: new information, depleted or gained resources, changed position, higher mastery, altered relationships, new capability, or escalated world state. “Fight enemies, get loot, repeat” is incomplete until the design explains how loot changes subsequent fights and why choices remain interesting.
+
+### Time horizons
+
+| Horizon | Typical concern | Validation |
+| --- | --- | --- |
+| moment-to-moment | control, targeting, timing, feedback | Can players predict and correct an action? |
+| encounter/task | tactics, puzzle, risk, recovery | Do multiple verbs and resources create decisions? |
+| session/run | pacing, goals, build arc, stopping | Does the session reach a satisfying change or climax? |
+| campaign/meta | progression, variety, mastery, expression | Do unlocks create new play instead of only larger numbers? |
+| community | cooperation, competition, identity, shared stories | Can players contribute and recover from social friction? |
+
+Check coupling. The short loop must feed the long loop, and long-loop rewards must renew rather than trivialize the short loop.
+
+## 4. Systems and economies
+
+### Map flows before tuning
+
+For every tangible or abstract resource, record:
+
+- **source:** creates it
+- **pool/store:** holds it and defines capacity or decay
+- **converter:** changes it into another resource or state
+- **trade:** exchanges resources between owners
+- **gate:** requires a threshold or condition
+- **sink:** removes it from circulation
+
+Include time, attention, space, health, information, social trust, action opportunities, and risk when they behave like resources. Draw connections and simulate several player strategies before choosing numbers.
+
+### Audit feedback structures
+
+- Positive feedback amplifies an advantage; it can make growth satisfying but also cause runaway leaders.
+- Negative feedback resists deviation; it can stabilize play but feel punitive when it erases earned advantage.
+- A loop’s speed, delay, visibility, durability, and cap matter as much as its sign.
+- Randomness changes distribution, not only average outcome. Examine worst cases, streaks, and player control.
+
+Give resources clear jobs. A currency with no recurring sink accumulates into irrelevance; a sink without valued outcomes becomes tax. Use opportunity costs to create decisions, and cap or decay stockpiles only when that behavior supports the experience.
+
+### Balance relationships, not isolated values
+
+Maintain a tuning table with units, baseline, min/max, dependency, player-facing purpose, and test evidence. Derive related values from a small set of legible baselines. Inspect:
+
+- time-to-effect and time-to-recover
+- expected value and variance
+- throughput, capacity, scarcity, and replacement rate
+- breakpoints where an option changes from viable to dominant
+- compounding across upgrades and feedback loops
+- edge cases at zero, maximum, and repeated use
+
+## 5. Progression and challenge
+
+### Separate progression channels
+
+- **Mastery:** the player learns execution, planning, recognition, or social coordination.
+- **Content:** new spaces, problems, opponents, or stories become available.
+- **Breadth:** new tools or combinations expand the possibility space.
+- **Power:** existing actions become numerically stronger.
+- **Expression/status:** appearance, identity, collection, or public accomplishment changes.
+
+Prefer unlocks that create new decisions or recontextualize mastered skills. Numerical power is useful when it makes growth legible, but unchecked vertical scaling invalidates content and narrows viable options.
+
+Build a skill graph: assumed prior skills -> introduced skill -> safe practice -> independent test -> combination -> transformed use -> mastery proof. Provide fast paths or optional refreshers for players who arrive with different prior knowledge.
+
+### Treat difficulty as a vector
+
+Tune cognitive load, precision, timing, planning depth, memory, sensory discrimination, resource pressure, punishment, uncertainty, coordination, and persistence separately. A single easy/normal/hard multiplier cannot serve every barrier.
+
+Failure should answer:
+
+- What happened and why?
+- What can the player try differently?
+- How much meaningful progress is lost?
+- How quickly can the player act again?
+- Does recovery preserve tension without demanding repetition already mastered?
+
+Dynamic adjustment can change pressure frequency, assistance, resource supply, or challenge amplitude, but it must remain predictable enough for players to learn and must not counterfeit achievement.
+
+## 6. Onboarding and accessibility
+
+Teach inside representative play:
+
+1. prime attention before the mechanic matters
+2. invite the action with low failure cost
+3. give immediate, redundant feedback
+4. allow repetition or experimentation
+5. test without step-by-step prompting
+6. combine with one known mechanic
+7. make help recallable and skippable where appropriate
+
+Do not assume genre literacy, dual-stick control, rapid reading, color discrimination, precise timing, hearing, or uninterrupted attention. Preserve the intended experience through remapping, simplified input, adjustable timing, pause, granular challenge assists, redundant cues, readable objectives, and reduced repetition.
+
+## 7. Multiplayer and social play
+
+Design the social system before selecting transport:
+
+- define cooperative and competitive relationships, team sizes, and information boundaries
+- ensure every role has understandable contribution and moments of agency
+- limit involuntary downtime and give eliminated players meaningful next actions
+- specify join, leave, disconnect, reconnect, and uneven-player behavior
+- distinguish team comeback from hidden punishment of skilled play
+- bound griefing, collusion, kingmaking, smurfing, spawn abuse, and reward farming
+- test communication-light play and accessibility of coordination signals
+
+For persistent systems, model inflation, hoarding, market manipulation, time-zone advantage, seasonal resets, and what happens when population is sparse.
+
+## 8. Content structure and genre lenses
+
+Create a content matrix from mechanics and contexts rather than brainstorming isolated features. Useful axes include verb, target, constraint, topology, information state, resource state, opponent behavior, time pressure, social relationship, and consequence. Combine a few axes at a time and reserve unexplored combinations for progression.
+
+Apply genre lenses without treating them as templates:
+
+- **action/combat:** readability, positioning, threat priority, counterplay, recovery, expressive kit
+- **platforming/racing:** movement mastery, line choice, anticipation, risk, restart cost, readable boundaries
+- **puzzle:** information sufficiency, hypothesis formation, state legibility, undo/reset, insight rather than busywork
+- **strategy/management:** forecasts, opportunity cost, feedback loops, viable plans, recovery from early errors
+- **survival/crafting:** scarcity rhythms, transformation chains, expedition risk, homeward payoff, anti-grind
+- **narrative/social:** role expression, relationship consequences, authored versus emergent story, respectful irreversibility
+- **sandbox/open world:** self-directed goals, systemic interaction, discovery density, world response, return value
+
+## 9. Prototyping and playtesting
+
+### Prototype risk, not polish
+
+Name the riskiest assumption: control feel, decision depth, loop renewal, economy stability, social coordination, or content feasibility. Build the smallest slice that can disprove it with real input, real state transitions, and representative feedback.
+
+### Use a test protocol
+
+Record:
+
+- hypothesis and decision the test will inform
+- participant profile and prior skills
+- build/version, scenario, starting state, and task
+- observable success/failure thresholds
+- events and metrics to capture
+- moderator script that avoids teaching or defending the design
+- findings separated into behavior, interpretation, severity, confidence, and proposed cause
+
+Observe before interviewing. Ask players what they thought was happening, what they planned, and what evidence shaped the plan. Preferences are valuable but do not replace behavior. Telemetry describes what happened at scale; it rarely explains why.
+
+Use rapid iterative testing for obvious, high-confidence usability defects: make a small fix, test it with the next appropriate participant, and verify that it solves the problem without creating another. Do not churn balance or appeal based on one participant.
+
+Classify findings:
+
+- **comprehension:** goal, rule, state, or feedback misunderstood
+- **execution:** intention clear but control/precision/timing blocks action
+- **balance:** options or outcomes violate intended tradeoffs
+- **pacing:** pressure, rest, novelty, or payoff arrives at the wrong rate
+- **motivation:** player sees no valued reason to continue
+- **accessibility:** an avoidable barrier excludes a player
+- **technical:** implementation differs from the design contract
+
+## 10. JGengine translation
+
+- Keep the design contract and acceptance criteria in the tracked issue/PR, not a speculative document tree.
+- Put definitions, costs, rewards, tiers, recipes, and formulas in typed catalogs or config.
+- Put mutable state in serializable shared primitives and transitions in systems/commands.
+- Put placement, routes, terrain, markers, zones, foliage, and asset instances in `editor.scene.json` via `jgengine-editor`.
+- Query authored ids and semantics through `jgengine-world`; never copy coordinates into rules.
+- Use deterministic injected randomness and headless tests for loops, economies, and failure states.
+- Add telemetry only for a named design question and avoid collecting unnecessary player data.
+- If a reusable rule is missing, implement the narrow package primitive with the game as first adopter.
+
+## 11. Diagnostic questions
+
+Before calling a design coherent, ask:
+
+- Can a player state the immediate goal, available verbs, and likely consequences?
+- What interesting decision repeats, and how does context stop it becoming solved?
+- What does the player learn in the first minute, first session, and tenth session?
+- Which state changes make each loop worth repeating?
+- What behavior does each reward actually incentivize?
+- Where can positive feedback create a runaway result?
+- Which barriers are intentional challenge and which are accidental exclusion?
+- What happens after failure, success, mastery, interruption, and return?
+- What breaks with one player, the maximum player count, or a disconnect?
+- What evidence would cause the team to remove or redesign the feature?
+
+## 12. Research basis
+
+These sources provide lenses and evidence, not commandments:
+
+- Robin Hunicke, Marc LeBlanc, and Robert Zubek, [“MDA: A Formal Approach to Game Design and Game Research”](https://users.cs.northwestern.edu/~hunicke/MDA.pdf): trace mechanics, runtime dynamics, and intended experience causally and avoid using “fun” as the whole vocabulary.
+- Richard Ryan and collaborators, [Player Experience of Needs Satisfaction](https://selfdeterminationtheory.org/player-experience-of-needs-satisfaction-pens/): empirical motivation lens around autonomy, competence, and relatedness.
+- Joris Dormans, [“Simulating Mechanics to Study Emergence in Games”](https://ojs.aaai.org/index.php/AIIDE/article/view/12477): model resource flows, internal economies, and emergent feedback before implementation.
+- Daniel Cook, [“The Chemistry of Game Design”](https://www.gamedeveloper.com/design/the-chemistry-of-game-design): action/simulation/feedback/learning atoms and skill-chain analysis.
+- Robin Hunicke and Vernell Chapman, [“AI for Dynamic Difficulty Adjustment in Games”](https://users.cs.northwestern.edu/~hunicke/pubs/Hamlet.pdf): difficulty, resource supply, uncertainty, and the limitations of adjustment systems.
+- Christiane Birk and colleagues, [“Designing Game Feel: A Survey”](https://arxiv.org/abs/2011.09201): physical tuning, feedback amplification, and intent-supporting streamlining.
+- GDC, [“Prime, Teach, Observe”](https://gdcvault.com/play/1021120/Prime-Teach-Observe-Tutorializing-Innovative): teach mechanics through player modeling and iterative observation.
+- Microsoft Games Studios, [“Using the RITE Method to Improve Products”](https://jpattonassociates.com/wp-content/uploads/2015/04/rite_method.pdf): rapidly fix and empirically verify high-confidence usability problems.
+- Microsoft, [Xbox Accessibility Guidelines](https://learn.microsoft.com/en-us/xbox/accessibility/guidelines): player-informed guidance for input, objectives, feedback, difficulty, timing, sensory access, and communication.
+- Matthias Worch, [“Decisions That Matter”](https://gdcvault.com/play/1020570/): connect informed choice, agency, consequence, and level context.

package/skills/jgengine/SKILL.md

@@ -9,16 +9,16 @@ Read the repository [README](../../../README.md) for package truth, commands, la
 
 ## 1. Establish the target
 
-Capture only decisions that change architecture:
+Treat the pitch as a unique composition of needs, not a genre to fill in — never reach for a genre kit, preset, archetype, or class template ("default sports car", "default RPG", "default FPS") in the SDK or skills (see [AGENTS.md](../../../AGENTS.md)). Use `game-design` to turn the pitch into a testable player promise, verbs, loops, progression, failure, and completion scenario. Use `level-design` when play depends on authored spaces, routes, encounters, exploration, or spatial pacing. Capture only decisions that change architecture:
 
 - player point of view and controls
 - world shape and authored content
 - core loop, interaction, combat, and progression
 - solo, local, hosted, or persistent multiplayer
-- HUD/menu states and art direction
+- HUD/menu states and **custom** UI art direction (every game owns its presentation — no stock drop-in face)
 - one observable completion scenario
 
-For a new in-repo game, scaffold with `bun run new:game <id> --name "Title"`. Outside this monorepo, start with `npx jgengine create`; never copy `Games/*`.
+For a new in-repo game, scaffold with `bun run new:game "<id-or-title>"` (thin script alias for `jgengine create`, auto-detects the in-repo variant). Outside this monorepo, start with `npx jgengine create`; never copy `Games/*`.
 
 ## 2. Select domains
 
@@ -26,6 +26,8 @@ Load only rows the target needs. Do not preload every domain.
 
 | Need | Skill | Owner |
 | --- | --- | --- |
+| player promise, pillars, verbs, loops, economy, progression, balance | `game-design` | experience and rule intent |
+| metrics, topology, encounters, navigation, spatial pacing | `level-design` | playable space intent |
 | scene placement, terrain painting, paths, asset authoring | `jgengine-editor` | editor document and authoring tools |
 | runtime world, movement, input, interaction, AI, navigation, audio | `jgengine-world` | spatial simulation and world runtime |
 | game state, systems, inventory, crafting, quests, economy, turns | `jgengine-gameplay` | non-combat rules and state |
@@ -34,15 +36,17 @@ Load only rows the target needs. Do not preload every domain.
 | models, sprites, materials, audio files, source licensing | `jgengine-assets` | asset discovery and catalogs |
 | authority, transport, replication, sessions, host persistence | `jgengine-multiplayer` | network topology and persistence adapters |
 
-Scenes normally require both `jgengine-editor` for authoring and `jgengine-world` for runtime consumption. Combat and multiplayer are opt-in, not default intake.
+World content routes editor-first: any request that adds, moves, restyles, or removes something visible in the world — however phrased ("design this world", "place the enemies", "make it look better") — starts in `jgengine-editor`; the other domains consume the authored document. Scenes normally require both `jgengine-editor` for authoring and `jgengine-world` for runtime consumption. Combat and multiplayer are opt-in, not default intake.
 
 ## 3. Discover before designing
 
 Within each selected domain:
 
+0. Fastest start for a common composition: `npx jgengine recipe <name>` prints a vetted, SDK-typechecked snippet (imports + wired code) for `combat-loop`, `boss-telegraph`, `loot`, `quest`, `coop-presence`, `third-person-camera`; `npx jgengine recipe` lists them. Copy that instead of reconning per-file.
 1. Search `capabilities.md` by intent; it maps needs to imports.
 2. Open `api.md` only when exact signatures or export inventory are needed.
 3. Open the linked reference only for a deeper recipe or trap.
+4. For how several primitives wire into a running loop, read the domain's `recipes/` — connected, genre-free walkthroughs organized by composition seam; this skill's own [recipes/minimal-game.md](recipes/minimal-game.md) is the default whole-game walkthrough. Prefer a recipe over reading a game's source; the games under `Games/*` are not templates or references, and a hybrid game is just a different composition of the same primitives.
 
 If no capability fits, identify the upstream package seam before writing game-local code. In this repository, implement a reusable primitive with its first adopter; if editor-owned content cannot be expressed, file the editor gap first.