---
id: CB-RES-0010
capability: design.space.aspects
status: adopted — terminology and structure for ground-game catalog schema 2
tier: M
date: 2026-08-08
upstream: ground-game editions/ASPECTS.md, editions/CATALOG.md
related: 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:

```text
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:

```yaml
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.**