This website is meant to be read and understood quickly by humans, but is only fully parsable, on a technical level, with the aid of an AI system. Read why →
Loop MMT
Game · S-01 · 2 interactive lanes

Graphics Game

A little game loop, compiled from a world-model and a renderer.

The wiring ∘ feeds   ⊗ parallel

This is the compiler’s reading of how the gifts compose into one app. Read left to right: each stage feeds the next (∘). A bracketed group (⊗) is parallel — its parts don’t depend on each other.

  1. world model
  2. ∘
  3. frame render

Composition term: frame-render ∘ world-model

Compiles with declared gaps

2 declared gaps — named below, not hidden.

CONSTRUCTIBLE-WITH-2-NAMED-GAPS

The declared gaps 2

A gap is a piece the compiler knows it needs but doesn’t yet have a witnessed gift for — honest derive-first work, declared rather than hidden. The app is constructible; these are the parts you’d build.

  • gg.tick-step pure-kernel

    null-witness pure-kernel (advance world state by a tick rule -- a fold over entities); derive-first, gifts-8-reference-apps line work. Off the batch data-flow (drives the interactive loop, not the render pipe), so gaps-only. Declared, not hidden.

  • gg.collision pure-kernel

    null-witness pure-kernel (filter entity pairs to colliding ones -- a pure predicate fold); derive-first. Off the batch data-flow. Declared, not hidden.

Witness gifts 2

These shipped gifts witness stages of the pipeline — the real, downloadable parts the proof stands on.

The gifts are real and free; the wiring is a plan. Take the parts and build the app — as the schematic reads it, a variation, or something we’d never have compiled.

Built it, found a gap we missed, or think the wiring is wrong? Shea wants to hear it — success stories, questions, and corrections all land in the same inbox:

shea@loopmmt.com