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>
6.8 KiB
Aspects of the game — design space for GROUND
Authority: this file + catalog.yaml aspects: list.
Catalog contract: 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
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
- Add a row to the tables above (this file).
- If two competing designs exist (or one alternative to r0): register in
catalog.yamlaspects:, createeditions/modules/<aspect>/…. - Do not overload an existing aspect with unrelated rules (e.g. do not put
end-of-game into
problem_stress). - 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 |