Back to the journey

Interactive documentary map

Four threads into a new engine

Explore how ideas from Phos, Bitcubes, gloom and Kernel Tree lead to written contracts, a first working foundation and new experiments.

Follow an idea

What do we carry forward?

Each earlier project explored a different part of making a world. Follow a thread to see the idea it contributes, the promise Gameloom makes from it, and the experiment that could test that promise.

Four lines of thought meet in GameloomPhos, Bitcubes, gloom and Kernel Tree contribute distinct ideas. Colored threads meet at an open weave labeled Gameloom. This is an illustration of ideas, not a diagram of running software.PhosBitcubesgloomKernel TreeGameloom
An illustrated lineage of ideas. The projects remain distinct; their useful concepts inform a new design.

This map follows the first contract foundation documented on 16 October 2026. Written contracts describe intended guarantees. The working foundation is narrower. Each experiment asks for a stronger comparison than those first checks establish.

Open a thread to follow its connections. Keep several open to compare them.

PhosLet an authored idea take different visible forms.

How much can the rendering change while the world still means the same thing?

  1. Inspected source

    Meaning before pixels

    Phos separates editable content, visual descriptions and device resources. Its recovered source includes browser and native hosts.

  2. Written contract

    Keep the picture meaningful

    A visual product must describe its coordinates, time and content. Picking must refer to the displayed product and view.

  3. Working first foundation

    Different triangles, one deck

    The first foundation checks a flat bridge deck using exact integer geometry. Different triangle layouts can pass when they cover the same rectangle.

    This check validates supplied geometry; it does not itself produce or render a scene.

  4. Open experiment

    One scene, two kinds of host

    Show the same authored scene in a browser and a native app. Compare visible output, camera movement and picking under declared tolerances.

BitcubesConnect a player’s request to a meaningful consequence.

When a request fails, what must everyone agree never happened?

  1. Inspected source

    Rules meet play

    Bitcubes separates engine mechanisms, content meaning and game policy. Multiple games exercise its command and presentation contracts.

  2. Written contract

    Accept the whole change

    The proposed transaction contract stages a game action before accepting it. A successful bridge purchase joins one creation to one settled wood charge.

  3. Working first foundation

    Know which request arrived

    The first foundation validates command shapes and gives a command a stable identity across native and browser consumers.

    Valid input and stable identity do not grant a player permission or accept a shared-world change.

  4. Open experiment

    Interrupt an action midway

    Force a fault while a game action is being prepared. Check that no partial world change or outgoing effect is published.

gloomKeep a world coherent as its machinery changes.

Can one window disappear without taking another person’s world with it?

  1. Inspected source

    Separate use from machinery

    gloom separates logical components from physical execution. Its bounded implementations give worlds, views and shared outputs distinct lifetimes.

  2. Written contract

    Let each view own its use

    Views hold independent rights to use a product. Closing one view must preserve other readers, and resources remain alive until admitted work finishes.

  3. Working first foundation

    Check where an output belongs

    The first foundation records product provenance and checks the exact context before an output can be published.

    These local mechanisms are a starting point. Shared GPU lifetimes and recovery require their own evidence.

  4. Open experiment

    Close a view, keep the world

    Open two views with different representations of one world. Close one while shared work continues, then check the other view and its input mapping.

Kernel TreeGive each part a clear promise and a bounded responsibility.

Can a small part keep its promise when it becomes part of something larger?

  1. Inspected source

    A model of responsibility

    Kernel Tree proposes that a subsystem owns its meaning and grants limited access to its parts. This predecessor is a design model.

  2. Written contract

    Name who owns each promise

    Local rules and rules shared by several parts have explicit owners. Implementations meet through public agreements and scoped permissions.

  3. Working first foundation

    Make some boundaries checkable

    The first foundation restricts delegated rights and checks declared dependency and import rules, including deliberately invalid examples.

    These checks cover trusted code and specified syntax. They do not prove every behavior or create a security sandbox.

  4. Open experiment

    Compose through three levels

    Place two real implementations beneath a subsystem and carry the same lifecycle and conformance rules through three levels. Look for hidden access and unnecessary coupling.