tegwick
bff64053ca
The maintainer's observation decided the design: aspects partition the GAME, strata partition our apparatus, and they are orthogonal. A module is one coordinate change in aspect space with an obligation in every stratum. So aspect identity must NOT be Rust types -- an aspect ground-game adds would make clay-borg fail to parse a configuration rather than fail to run it, welding the two coordinate systems at the one place they must stay independent. Chosen: identity as data (Configuration round-trips anything the catalog names), behaviour exhaustive (Rules, no catch-all), resolve() between. Decisive argument: the catalog ALREADY ships modules with a rules_delta and status: proposed, so a per-aspect enum would report them as "unknown module" -- indistinguishable from a typo, a false statement about the edition, and this project's signature failure shape. Two facts need two errors. Federating design authority is permanent, so the representation must outlive the implementation. Legacy ids alias forever through the catalog's own legacy_experiment_id, on the standard-Np precedent: 26 recordings name them and the expansion is exact, so there is nothing to deprecate. T00 done: the schema-2 mirror had arrived with no digests (19 files) and edition-check was red. Digests are now generated by WALKING editions/, not typed -- two reviews already found hand-written lists that made their own controls vacuous, and a mirror that grows a directory is what breaks a maintained list. PROVENANCE-catalog.md was a file inside the mirrored tree that upstream does not have; folded into our own PROVENANCE.md, since provenance about the mirror does not belong inside the thing it describes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
146 lines
6.7 KiB
Markdown
146 lines
6.7 KiB
Markdown
# Aspects of the game — design space for GROUND
|
||
|
||
**Authority:** this file + [`catalog.yaml`](catalog.yaml) `aspects:` list.
|
||
**Catalog contract:** [`CATALOG.md`](CATALOG.md)
|
||
**Research (simulator side):** clay-borg `research/CB-RES-0010-game-aspects-and-design-space.md`
|
||
|
||
An **aspect** is an orthogonal **design dimension** of the game: a family of
|
||
questions you can answer independently when defining or varying rules.
|
||
A **module** is one concrete answer on one aspect. A **profile** is a named
|
||
point in multi-aspect space (a combination of modules).
|
||
|
||
Terminology: **aspect** is the human and catalog term (schema 2). Older
|
||
text said *axis*; treat them as synonyms until references are gone.
|
||
|
||
This is **game design structure**, not a game-theory taxonomy. Game theory
|
||
supplies formal objects (players, actions, payoffs, information) used when
|
||
*analyzing* a configuration; it does not list edition-level modules.
|
||
|
||
---
|
||
|
||
## Vocabulary
|
||
|
||
| Term | Meaning |
|
||
|------|---------|
|
||
| **Aspect** | A dimension of design space (e.g. how the game ends, how stress is routed). |
|
||
| **Module** | One implementable choice for an aspect (`problem_stress.scoped`). |
|
||
| **Default module** | The r0 / printed answer when no experimental module is selected. |
|
||
| **Profile** | Named list of modules (e.g. `h2`, `scoped_plus_attack_soothe`). |
|
||
| **Baseline** | Content package (`ground-darvo-r0`) + all default modules. |
|
||
| **Configuration** | Baseline + resolved module list — what a sim or table actually plays. |
|
||
|
||
**Rule:** at most **one module per aspect**. Cross-aspect behaviour is an
|
||
explicit **profile**, never a silent dependency inside a single module.
|
||
|
||
---
|
||
|
||
## Full aspect map for GROUND
|
||
|
||
Aspects marked **modular** have entries under `editions/modules/`.
|
||
Aspects marked **fixed (r0)** are part of the baseline until someone
|
||
proposes a competing module.
|
||
Aspects marked **product** may never need a kernel module.
|
||
|
||
### A. Structure — when and how the session runs
|
||
|
||
| Aspect id | Question | GROUND today | Modular? |
|
||
|-----------|----------|--------------|----------|
|
||
| `player_structure` | Who plays? seats? teams? | 2–6 seats; modes redefine who wins | fixed (r0) |
|
||
| `objective_scoring` | What is success / who wins? | Modes: co-op / semi / coalition + thresholds | fixed (r0 modes cards) |
|
||
| `turn_time_structure` | How does play advance? | Simultaneous select–reveal–resolve; Lead | fixed (r0) |
|
||
| `end_condition` | When does the game stop? | Fixed 5 rounds + score | **modular** |
|
||
| `setup` | What is on the table at start? | Scenario + mode; mats; start Stress 2 | fixed (r0); future difficulty card |
|
||
| `information` | What is hidden vs public? | Hidden Problems; face-down actions; DENY | fixed (r0) |
|
||
|
||
### B. Content economy — what enters play
|
||
|
||
| Aspect id | Question | GROUND today | Modular? |
|
||
|-----------|----------|--------------|----------|
|
||
| `problem_deal` | How do Problems enter play? | Surface + hidden 1..k at setup | **modular** |
|
||
| `solution_economy` | Hands, draws, suits | Solution deck; INVESTIGATE draws | fixed (r0) |
|
||
| `action_set` | What may a seat choose? | Investigate, Solve, Support, Attack, GROUND | fixed (r0) |
|
||
| `legality_filters` | What is offerable when? | SOLVE legality; Stress 4–5 gate | fixed (r0 rulings) |
|
||
|
||
### C. Pressure and regulation
|
||
|
||
| Aspect id | Question | GROUND today | Modular? |
|
||
|-----------|----------|--------------|----------|
|
||
| `individual_state` | Stress, Freedom, arming | Stress 0–5; Freedom token | fixed (r0) |
|
||
| `problem_stress` | Unclaimed Problems → who gets Stress? | None (until module) | **modular** |
|
||
| `interaction_stress` | Attack/Support stress numbers | As printed on Actions | fixed (r0) |
|
||
| `attack_relief` | Does ATTACK soothe the attacker? | No | **modular** |
|
||
| `reflex_sequences` | Multi-round binding chains | DARVO DENY→ATTACK→REVERSE | fixed (r0); future pacing module |
|
||
| `regulation_practices` | How you exit pressure | GROUND GR/OU/ND; Bond Support | fixed (r0); future GROUND-sequence module |
|
||
|
||
### D. Relationships
|
||
|
||
| Aspect id | Question | GROUND today | Modular? |
|
||
|-----------|----------|--------------|----------|
|
||
| `relation_structure` | Bonds, Rivalries, slots | 2 slots; Bond/Rivalry | fixed (r0) |
|
||
| `relation_scoring` | Do networks win? | Coalition mode | under `objective_scoring` / modes |
|
||
| `relation_stress` | Shared liability via Bonds | Bond-scope under `problem_stress.scoped` | via problem_stress modules |
|
||
|
||
### E. Product and frame (often outside kernel)
|
||
|
||
| Aspect id | Question | GROUND today | Modular? |
|
||
|-----------|----------|--------------|----------|
|
||
| `scenario_fiction` | Thematic conflict | Scenarios.csv | content, not rules module |
|
||
| `safety_teaching_frame` | How DARVO is framed | Rules_Text safety; INTENT | product |
|
||
| `difficulty_accessibility` | Learning vs mastery | WP-0005; H2 scope mix as dial | future modules |
|
||
| `medium` | Print vs digital | Edition CSV vs clay-borg | product |
|
||
|
||
---
|
||
|
||
## Registered aspects (have module directories)
|
||
|
||
These appear in `catalog.yaml` `aspects:` and accept non-default modules:
|
||
|
||
| Aspect | Default module | Other modules |
|
||
|--------|----------------|---------------|
|
||
| `problem_stress` | `problem_stress.none` | `flat_any_open`, `scoped` |
|
||
| `attack_relief` | `attack_relief.none` | `self_soothe_ge4` |
|
||
| `end_condition` | `end_condition.fixed_rounds_5` | `hybrid_clear_collapse` (proposed) |
|
||
| `problem_deal` | `problem_deal.fixed_setup` | `pressure_deck` (proposed) |
|
||
|
||
---
|
||
|
||
## Configuration as a vector
|
||
|
||
```text
|
||
playable configuration =
|
||
baseline content (ground-darvo-rN)
|
||
× problem_stress
|
||
× attack_relief
|
||
× end_condition
|
||
× problem_deal
|
||
× …future modular aspects…
|
||
```
|
||
|
||
Missing aspects use defaults. clay-borg should **persist the full resolved
|
||
module list** (and baseline id) on every game so measurements name the
|
||
point in design space, not only a legacy experiment slug.
|
||
|
||
---
|
||
|
||
## Adding an aspect
|
||
|
||
1. Add a row to the tables above (this file).
|
||
2. If two competing designs exist (or one alternative to r0): register in
|
||
`catalog.yaml` `aspects:`, create `editions/modules/<aspect>/…`.
|
||
3. Do not overload an existing aspect with unrelated rules (e.g. do not put
|
||
end-of-game into `problem_stress`).
|
||
4. Prefer measuring a new module **alone**, then in profiles with others.
|
||
|
||
---
|
||
|
||
## Relation to external frameworks
|
||
|
||
See clay-borg **CB-RES-0010** for sources. Short map:
|
||
|
||
| Framework | How it maps here |
|
||
|-----------|------------------|
|
||
| Formal elements (Fullerton et al.) | Coarse checklist → our Structure / Economy groups |
|
||
| MDA (Hunicke et al.) | Module = Mechanics; panels = Dynamics; intent = Aesthetics |
|
||
| Characteristics of Games (Elias/Garfield/Gutschera) | Independent dimensions → our aspects |
|
||
| Design space | Configuration = point in multi-aspect space |
|
||
| Extensive-form game theory | Analysis substrate (CB-RES-0009), not the aspect list |
|