tegwick
b590e7fd59
Some checks failed
ci / check (push) Failing after 4s
Eight profiles on a common schema, each marking what was checked against a source this session and what is background recollection. Three are marked unverified in full — Machinations, the play substrates, most of RBG — and say so rather than reading as evaluations. Written straight after three review rounds whose entire yield was claims outrunning what had been checked, so the confidence rule is the first thing in the README. The survey changed the plan, which is what a survey is for. Track C was described in Positioning as open ground. It is not: Browne published 57 criteria for game quality, and Ai Ai already computes designer-facing measures — drama, lead changes, branching factor, completion, duration — from played games. The track becomes adopt, credit and find the gap. The gap looks real: those measures presume a leader, and SHARED GROUND has none — Modes.csv gives its tiebreak as "Not applicable". Track B probably adopts rather than builds. OpenSpiel implements CFR, best-response and exploitability over games that are simultaneous-move, imperfect-information and co-operative, which is all four of GROUND's awkward properties. "Does ATTACK ever pay" is a best-response question, and we spent three review rounds refining a two-policy sweep for it. The first Track B task is now one question — is exploitability meaningful for a co-operative game with a shared threshold — not a build. The cost of not surveying earlier is therefore measurable, and is recorded rather than glossed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
156 lines
7.7 KiB
Markdown
156 lines
7.7 KiB
Markdown
# Intent
|
||
|
||
Clay-Borg is a rebuild-from-scratch simulation and games engine framework: it
|
||
assimilates and optimizes techniques and implementations useful for games,
|
||
simulations, and robotics.
|
||
|
||
It is not another monolithic game engine. It is a capability-assimilating
|
||
development engine with four distinct properties:
|
||
|
||
1. **Clay** — its canonical models, contracts, rules, and tools remain malleable.
|
||
2. **Borg** — mature, optimized libraries are assimilated behind controlled
|
||
interfaces rather than copied or exposed directly.
|
||
3. **Product-driven evolution** — abstractions are extracted from working
|
||
games, beginning with **GROUND — A Game of Bonds and Rivalry: DARVO
|
||
Edition**, rather than invented in isolation.
|
||
4. **Instrument** — the engine is rigorous enough that it cannot proceed
|
||
past a rule that does not decide. What it cannot execute, it reports:
|
||
findings about the *game's* design are a product of building the
|
||
simulator, not a side activity, and they are carried back to the game's
|
||
owner with the artifact that produced them. *(ADR-0012. A restatement of
|
||
what has already happened six times, made a duty. If a pass ever
|
||
tolerates an undecided rule by quietly picking a default and not raising
|
||
it, this property is false.)*
|
||
|
||
A fifth property, added 2026-08-08 because three adversarial review rounds
|
||
made it undeniable:
|
||
|
||
5. **The instrument is under the same discipline as the engine.** Twelve
|
||
fatal defects were found in one measurement, **every one in our
|
||
apparatus and none in the game**, and several had already been written
|
||
into evidence as conclusions. A tool that reports design findings
|
||
without treating its own measurements as claims is reporting its bugs
|
||
at the same volume as its results. *(See [`specs/Taxonomy.md`](specs/Taxonomy.md)
|
||
for what "defect" now means, and where.)*
|
||
|
||
The central rule:
|
||
|
||
> **Own the semantics; assimilate the implementation.**
|
||
|
||
And the second, which says what the product actually is:
|
||
|
||
> **Clay-borg is a design-evidence instrument.** Its output is not a
|
||
> number about a game; it is an auditable answer to *what does this rule
|
||
> do at the table, and how much should you trust that* —
|
||
> [`specs/Positioning.md`](specs/Positioning.md).
|
||
|
||
Clay-Borg owns what an entity, object, command, event, card, zone,
|
||
relationship, game, simulation, asset, plugin, and capability *mean*.
|
||
External libraries (wgpu, Rapier, Bevy ECS, Wasmtime, Quinn, egui, Serde,
|
||
tracing, …) provide optimized implementations of rendering, physics,
|
||
networking, serialization, and similar functions behind canonical ports. No
|
||
external library type should leak across a canonical interface.
|
||
|
||
## Vocabulary
|
||
|
||
*"Error"*, *"failure"*, *"finding"* and *"correction"* were each being
|
||
used for the game's design, our formalisation of it, the code, the
|
||
measuring apparatus and the sentences we wrote.
|
||
[`specs/Taxonomy.md`](specs/Taxonomy.md) fixes that: **every defect
|
||
statement names a stratum first** — GAME, MODEL, ENGINE, INSTRUMENT,
|
||
ACCOUNT, PRESENTATION — because "a bug in the simulator" and "a gap in the
|
||
game" have different owners and different fixes.
|
||
|
||
## Where this is going
|
||
|
||
Three tracks, none started, in [`specs/Positioning.md`](specs/Positioning.md) §4:
|
||
**a second game** (which is the falsifier for "GROUND is an example"),
|
||
**game theory as the lens on dynamics**, and **assimilated knowledge about
|
||
why games work**, offered to designers.
|
||
|
||
The field is surveyed in [`simulators/`](simulators) — one profile per
|
||
system, each marking what was checked and what is recollection. **The
|
||
survey already shrank two of the three tracks**: Browne's 57 criteria and
|
||
Ai Ai's authoring metrics mean track three is *adopt and find the gap*,
|
||
not *invent*; and OpenSpiel's exploitability is the standard instrument
|
||
for the question track two exists to ask.
|
||
|
||
## Why GROUND first
|
||
|
||
GROUND requires modest physics but sophisticated social state, simultaneous
|
||
decisions, and constrained sequences (a binding DARVO deny/attack/reverse
|
||
state machine, a typed relationship graph, commit/reveal simultaneous
|
||
resolution). It must stay playable headless — no rendering, no rigid-body
|
||
simulation required to run or test the rules. The 3D tabletop is a
|
||
projection and interaction surface for the game, not the definition of the
|
||
game.
|
||
|
||
## The most important design decisions
|
||
|
||
1. Build GROUND first, not a general engine first.
|
||
2. Keep rules independent from rendering and physics.
|
||
3. Use commands and events as the authoritative mutation mechanism.
|
||
4. Provide null, reference, and optimized implementations of important
|
||
capabilities.
|
||
5. Never leak assimilated-library types into canonical interfaces.
|
||
6. Use server-authoritative physics and deterministic semantic rules.
|
||
7. Treat player visibility as a projection, not a UI afterthought.
|
||
8. Make every defect reproducible as a scenario and replay.
|
||
9. Give coding agents bounded work packets and stable commands.
|
||
10. Attach TargetRevenue phases to versioned improvements and evidence
|
||
bundles.
|
||
|
||
## First product
|
||
|
||
> A headless, replayable, and agent-readable GROUND rules engine that can be
|
||
> projected onto an increasingly physical virtual tabletop, while every new
|
||
> capability remains replaceable, measurable, and financeable through
|
||
> TargetRevenue.
|
||
|
||
## Implementation order
|
||
|
||
0. **Headless GROUND** — full authoritative state, 2–6 players,
|
||
commit/reveal, relationships, DARVO, GROUND practice, CLI player, replay
|
||
and scenario tests, simple bots. No rendering, no physics.
|
||
1. **Inspectable 2D table** — card/token/hand/relationship-graph
|
||
visualization, drag-to-propose, debug inspector, hot-seat play.
|
||
*Open on one human verification, and every run of it so far has found
|
||
something no test could. 2026-08-02, run 1: the drag was broken — drop
|
||
targets were `id`s, which must be unique, so the graph circle held
|
||
`seat-0` and the seat card had none (CB-WP-0016). Run 2: the drag
|
||
worked but the page was **wrong about which moves exist**, showing 5
|
||
cards each claiming all three target kinds where 9 specific commands
|
||
were legal, with no way to see what was pickable, held, or droppable
|
||
(CB-WP-0017). Both fixed. What remains is perceptual and unreachable
|
||
from here by construction (ADR-0010 D5): run `cb-play --serve 0` and
|
||
confirm you can see what can be picked up, what you are holding, and
|
||
where it may go.*
|
||
2. **Physical 3D tabletop** — wgpu renderer, Rapier-backed physics, camera
|
||
and pointer controls, snap zones, asset importer.
|
||
3. **Networked sessions** — authoritative host, private projections,
|
||
commit/reveal protocol, reconnection, replay verification, spectator mode.
|
||
4. **Game creation framework** — object prototypes, scene/zone editors,
|
||
card/deck importer, package validation, Wasm game components.
|
||
5. **Prove generality** — implement one deliberately different fixture game;
|
||
only then promote duplicated GROUND abstractions into the stable Clay
|
||
Canon.
|
||
|
||
> No concept becomes canonical merely because it looks general. It becomes
|
||
> canonical after surviving a second concrete use.
|
||
|
||
## Sister repositories
|
||
|
||
- **`ground-game`** — the authoritative home of the GROUND boardgame itself
|
||
(rules, editions, content). Clay-Borg implements the engine that simulates
|
||
it; game-semantics questions defer to that repo.
|
||
- **`target-revenue`** — the canonical home of the Target Revenue Framework
|
||
and the TRSL license text this repo is released under.
|
||
|
||
## Provenance
|
||
|
||
This intent is distilled from the fuller architectural exploration in
|
||
[`history/260730-InitialExploration.md`](history/260730-InitialExploration.md),
|
||
which also covers the runtime substrate, simulation kernel, physics
|
||
subsystem, world-building layer, tabletop domain framework, networking
|
||
architecture, the agentic inner loop (work packets, CLI surface, quality
|
||
gates), and the TargetRevenue business-control model in full detail.
|