clay-borg/research/CB-RES-0010-game-aspects-and-design-space.md

id	capability	status	tier	date	upstream	related
CB-RES-0010	design.space.aspects	adopted — terminology and structure for ground-game catalog schema 2	M	2026-08-08	ground-game editions/ASPECTS.md, editions/CATALOG.md	CB-RES-0009 (extensive form), CB-RES-0007 (design instrument), ADR-0012

CB-RES-0010 — Game aspects, design space, and composable rules modules

Research digest for clay-borg as the simulator and design environment. ground-game owns edition content and the normative catalog; this note records the concepts and sources so selection APIs, panels, and recordings evolve around a shared model of design dimensionality.

---

1. Problem this solves

GROUND rules experiments began as monolithic packages (H1, H2): each bundled several independent design decisions. That blocked:

• measuring one change at a time;
• combining two good ideas without rewriting a third package;
• naming what point in design space a trial actually played.

ground-game schema 2 replaces mega-experiments with:

configuration = baseline content
              × aspect₁ (one module)
              × aspect₂ (one module)
              × …

clay-borg must select, apply, record, and report configurations in those terms.

---

2. Core vocabulary (normative for this fleet)

Term	Meaning	Clay-borg duty
Aspect	Orthogonal design dimension of the game (e.g. end condition, problem→stress routing)	List known aspects; enforce ≤1 module each
Module	One concrete design on one aspect (problem_stress.scoped)	Load rules_delta + overlays; implement kernel deltas
Default module	Printed / r0 answer when no experiment is selected	Implicit when aspect omitted from selection
Profile	Named list of modules (h2, scoped_plus_attack_soothe)	Expand to modules; do not treat as separate rules source
Baseline	Content package (ground-darvo-r0)	Vendor CSVs; pin digests (ADR-0011)
Configuration	Baseline + resolved module list	Persist on every game / replay / panel cell

Independence rule: a module owns only its aspect. Cross-aspect behaviour is an explicit profile (or a new aspect), never a hidden dependency.

Synonym: early ground-game drafts said axis for aspect. Prefer aspect in UI, docs, and state fields; accept axis only as a deprecated alias when reading old configs.

Authoritative inventory for GROUND:
../ground-game/editions/ASPECTS.md (sibling checkout) or the vendored copy when present under editions/.

---

3. Is there an established concept? (sources)

There is no single standard named “aspects of a game” with a fixed ISO list. Several traditions describe the same idea: games as a point in a multi-dimensional design space.

3.1 Game design (primary fit)

Source	Idea	Use for us
Tracy Fullerton, Game Design Workshop — formal elements	Players, objectives, procedures, rules, resources, conflict, boundaries, outcome	Coarse checklist; maps to Structure / Economy groups in ASPECTS.md
Hunicke, LeBlanc, Zubek — MDA (Mechanics–Dynamics–Aesthetics)	Mechanics generate dynamics; dynamics produce aesthetics	Module = mechanic change; panel = dynamics; design intent = aesthetics. Findings (ADR-0012) sit on dynamics.
Elias, Garfield, Gutschera — Characteristics of Games	Games differ along independent dimensions (player count, outcome type, information, length, skill/chance, diplomacy, …)	Closest published match to “dimensionality of a game” as separable choices
Design space / possibility space (common practice; e.g. Salen & Zimmerman Rules of Play discourse; modern “explore the design space”)	Varying parameters yields a space of games	Configuration = coordinates; modules = values on coordinates
BoardGameGeek mechanics taxonomy	Named mechanisms (worker placement, …)	Vocabulary only — overlapping, not an orthogonal basis

3.2 Game theory (analysis substrate, not the aspect list)

Source	Idea	Use for us
Extensive-form games (von Neumann–Morgenstern lineage; modern texts e.g. Osborne, An Introduction to Game Theory)	Histories, information sets, chance, terminal payoffs	Formal object for analysis (see CB-RES-0009). Simultaneous moves = sequenced + hidden.
Normal / strategic form	Players, action sets, payoff matrices	Too coarse for multi-round DARVO sequences and hidden Problems
Mechanism design	Choosing rules to induce outcomes	Useful metaphor for “we design modules to shift incentives”; not a list of aspects

Do not derive the aspect list from game theory alone. Derive aspects from what designers vary; use game theory to measure incentives inside a fixed configuration (e.g. “does ATTACK pay?”).

3.3 AI / general game playing (implementation relatives)

Source	Idea	Use for us
Ludii GDL / general game systems	Declarative game description; universality results for extensive form	Confirms EFG as lingua franca (CB-RES-0009); not a substitute for aspect modularity
OpenSpiel, RBG, etc.	Multi-game research APIs	Comparable “game + parameters” thinking; our parameters are design modules, not only RNG seeds

3.4 What we claim (and do not)

Claim: Treating GROUND rules variation as modules on aspects is consistent with design-space practice and Characteristics of Games dimensional thinking, operationalized for edition + simulator work.

Do not claim: That “aspect” is a reserved term in game theory, or that our aspect list is complete for all games forever.

---

4. GROUND aspect groups (summary)

Full tables live in ground-game editions/ASPECTS.md. Groups:

Group	Examples	Modular today?
A. Structure	end condition, turn structure, setup, information	end_condition modular; others mostly fixed r0
B. Content economy	problem deal, solution economy, action set	problem_deal modular (proposed pressure deck)
C. Pressure & regulation	problem_stress, attack_relief, DARVO, GROUND	problem_stress, attack_relief modular
D. Relationships	bonds, rivalry, network scoring	fixed r0; bond-scope via problem_stress.scoped
E. Product / frame	scenario fiction, safety, difficulty, medium	mostly content / process

Registered modular aspects (must be in selection validation):

1. problem_stress — default none; also flat_any_open, scoped
2. attack_relief — default none; also self_soothe_ge4
3. end_condition — default fixed_rounds_5; also hybrid_clear_collapse (proposed)
4. problem_deal — default fixed_setup; also pressure_deck (proposed)

---

5. Implications for clay-borg (design environment)

5.1 Selection API

Prefer:

baseline: ground-darvo-r0
modules: [problem_stress.scoped]
# or
profile: h2

Legacy experiment ids (h1-problem-stress, h2-scoped-problem-stress) remain aliases → expand to profiles. Prefer module/profile ids in new code.

5.2 Application order

Apply module rules_delta in the order of aspects: in ground-game/editions/catalog.yaml. Refuse two modules on the same aspect.

5.3 Recording and panels

Every trial cell, replay, and cb-play session should store:

• baseline_id
• modules: [ ... ] fully resolved (defaults filled or explicit)
• optional profile_id if one was requested

Panel reports should facet by aspect when comparing (e.g. all configs with problem_stress.scoped vs none), not only by legacy experiment name.

5.4 Measurement hygiene (ties to design instrument)

• Prefer one non-default module when isolating a mechanism (alone).
• Use profiles when the hypothesis is interaction (scoped × hybrid end).
• Criterion tables in evidence should name module ids, not only “H2”.
• Policies that cannot see an aspect (e.g. bots that ignore bond scope) cannot test aspect-specific motivation claims — report untested, not failed (CB-EV-0032 criterion 4 pattern).

5.5 Kernel / UI evolution

Surface	Direction
cb-play / trials	--profile / --module flags; show active modules on the table
State hash / recordings	include configuration identity
HTML table	label which modules are live (CB-WP-0044 family)
Finding register	findings may be scoped to an aspect or module
Future	aspect-aware policy panel; “compose and sweep” harness

5.6 Proposed modules (draft only)

Until status leaves proposed and a kernel path exists:

• end_condition.hybrid_clear_collapse
• problem_deal.pressure_deck

Do not report measurements for unimplemented modules. allow_proposed should refuse or no-op loudly.

---

6. Legacy map

Legacy experiment	Profile	Modules
h1-problem-stress	h1	problem_stress.flat_any_open + attack_relief.self_soothe_ge4
h2-scoped-problem-stress	h2	problem_stress.scoped

H1 mixed two aspects; H2 was already one aspect. Schema 2 makes that decomposition explicit so the next change is not H3-the-blob.

---

7. Relation to other clay-borg research

Doc	Relationship
CB-RES-0007 design instrument	Findings attach to configurations; aspects name which rules class moved
CB-RES-0008 could-we-have-won	Winnability is one dynamic; hold aspect coords when comparing
CB-RES-0009 extensive form	Formal analysis language under a fixed configuration
ADR-0011 vendor edition	Baseline content; modules add deltas on top
ADR-0012 design instrument	Admissible findings still need failing reproductions

---

8. Bibliography (digest-level)

Primary design:

1. Fullerton, T. Game Design Workshop — formal elements of games.
2. Hunicke, R., LeBlanc, M., Zubek, R. “MDA: A Formal Approach to Game Design and Game Research.”
3. Elias, G. S., Garfield, R., Gutschera, K. R. Characteristics of Games. MIT Press.
4. Salen, K., Zimmerman, E. Rules of Play — rules, play, culture; design space discourse.

Game theory / GGP (analysis, not aspect inventory):

5. Osborne, M. J. An Introduction to Game Theory.
6. Piette et al. / Ludii literature on GDL universality and extensive form (see CB-RES-0009).
7. OpenSpiel documentation — multi-game research environments.

Fleet documents:

8. ground-game editions/ASPECTS.md, editions/CATALOG.md, editions/catalog.yaml (schema_version: 2).
9. ground-game history/260808-modular-variants.md.

---

9. Adoption checklist (clay-borg)

• Parse ground-game catalog schema 2 (aspects, modules, profiles).
• Selection: profile or modules[] + baseline; fill defaults.
• Validate one module per aspect.
• Apply deltas in aspect order; with_variant-style setup for modules that assign owners.
• Persist resolved module list on state / replay / panel output.
• UI: show active modules.
• Deprecate bare experiment-only APIs only after alias coverage.
• Optional: panel sweep “hold all aspects fixed, vary one.”

---

10. One-sentence summary

A GROUND rules configuration is a point in a multi-aspect design space; clay-borg’s job is to select, run, record, and compare those points without collapsing independent aspects into opaque experiment blobs.