game-planning ยท diff
git:20260912.89d5894 to git:20260913.dd45fc1
18 added, 11 removed. Audit A to A.
---
name: game-planning
- description: Generic slice planning. At most three pillars. Verb budget before content volume. A slice is done when a player finishes one meaningful loop.
+ description: Use when defining a game's smallest playable slice, limiting feature scope or deciding whether a proposed loop has a meaningful player outcome.
---
# Game planning
- Write column picks into the slice doc so later skills do not guess.
- The slice must demonstrate feel columns, not a menu.
- Fix first: input latency, camera, locomotion. If those are missing, do not grow the map.
+ Record existing genre, target device, input roles and selected modes before expansion. Keep at most three pillars. Budget verbs and decisions before content volume. Do not add combat or locomotion merely to satisfy an action-game template.
- ## Slice accept (play, not features)
+ ## Slice contract
- A slice is done when a player can:
+ The player understands the goal, completes one **core challenge or decision**, perceives its consequence, and knows what to do next. Combat is one possible loop; noncombat games are equally valid.
- 1. Understand the goal
- 2. Finish one meaningful fight
- 3. Take a reward
- 4. Name the next hook
+ | Loop | Core challenge | Observable consequence |
+ |---|---|---|
+ | combat | win or survive an encounter | outcome and next opportunity |
+ | puzzle | solve with taught properties | changed room or new possibility |
+ | building/simulation | build or allocate a limited resource | visible system response |
+ | narrative | make an informed choice | acknowledged consequence or branch |
+ | rhythm/racing | finish a passage or lap | timing/line feedback and retry |
- Grow the map only after `gameplay-validation` / real-input passes that chain. Teleport and cleared-room tests do not count.
+ First stabilize input and feedback relevant to this loop. Camera/locomotion matter only where used. A text-heavy or menu-driven game can itself be the playable slice; a mock menu without the core decisions cannot stand in for it.
+
+ ## Output and acceptance
+
+ Write a slice card: pillars, core challenge, constraints, target/input, scope exclusions, modes, start/end conditions, failure/retry or an explicit no-failure policy, evidence needed and the next milestone. Reuse project facts; ask only for a consequential missing choice.
+
+ Validate the natural start-to-outcome chain with [gameplay-validation](../gameplay-validation/SKILL.md). Mark debug setup, automated drivers and untested segments. Expansion follows demonstrated slice goals, not a claim that every genre must contain a fight or item reward.