tegwick
3045eb03f8
Some checks failed
ci / check (push) Has been cancelled
objective() reads GroundState::score (now public) rather than restating
what winning is; a copy in the bot would disagree with the kernel the
first time ground-game rules on F28.
Working out WHERE the modes can differ was most of the task and it
bounds the result: SOLVE always claims for the actor, so own-score and
group-score want the same SOLVE nearly everywhere. That is a fact about
GROUND's action set, not a shortcoming of the bot. Two real divergences,
both readable off the table: SUPPORT regulates someone else (worth less
against a rival, worth MORE under coalitions where a Bond merges them
into my side), and SOLVE's value is the card's value, which greedy
ignores entirely.
THE RESULT — F27 splits in two:
group success UNCHANGED in 34 of 36 cells
who wins MOVES: BONDED COALITIONS at 4p goes 2.04 -> 2.98,
2.12 -> 3.29, 2.05 -> 3.01 winning seats per game
So "the competitive modes are scoring lenses over cooperative play" was
too strong and is withdrawn. The sharper claim: GROUND's scoring modes
change WHO WINS, not WHETHER THE GROUP SUCCEEDS. And the effect is
seat-band dependent -- 2p none, 4p largest, 6p none under coalitions;
two relation slots capping network growth is a candidate explanation and
is untested.
The panel now prints BOTH policies side by side. That was a correction
mid-task: the first version printed only the new one and I compared it
against a figure remembered from CB-WP-0047 -- a comparison against a
board nobody re-ran.
Control that makes the numbers mean anything: under SHARED GROUND the
two policies agree at all but <=2 decision points across 12 boards, so a
moving column is mode-awareness and not simply a different bot.
Also: two T01 tests keyed on `status: proposed`, which ground-game
renamed to `ready-for-implement` mid-session. They now find the module
by asking resolve() -- the structural property is ours and does not move
when another repo edits its vocabulary.
Also: `make vendor` replaces three hand re-vendors with a tool that
regenerates digests by walking editions/, and reports one-sided files
rather than resolving them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
146 lines
6.8 KiB
Markdown
146 lines
6.8 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 finished:** Standard thresholds only; dial via `problem_stress` / `problem_deal` modules, not Learning/Mastery threshold cards | future if needed |
|
||
| `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 |
|