← All papers · prometheus7.com
Internal working paper, 2026-05-09. Author: Wander Around engineering; under-six-day countdown to public release. Treat as a pre-launch postmortem written from the future about what the code, today, actually does and does not do.
Wander Around at v5 is the first system that treats the play layer of a real-time multiplayer 3D game as a single compositional substrate over which every traditional game-engine subsystem — inventory, building, disassembly, perception, multiplayer, dialogue, signage, even printed culture — is a thin adapter, with the cost of adding a new game verb amortized into a thirty-line filter-and-act over an affordance vector field that the generators emit alongside the geometry. Whether or not the larger lab pitch lands, this single architectural fact is undeniable: the code is on disk, the bundle is on Desktop, and the verb-addition demonstration runs.
The v5 system runs as a Three.js client packaged under Electron, talking to a FastAPI server over a single WebSocket plus a small set of REST endpoints for build resolution and inventory state. The server side, both in the desktop single-player configuration and in the production multi- player deployment at wanderaround.io, dispatches natural-language build prompts through a three-stage resolver: a hand-authored chip-override table for the showcase strings (a pre-launch surface fix that bypasses the model entirely for the prompts the player most commonly issues), a remote model endpoint that calls into a Pan-cortical Architectural Network running on Box C, and a local keyword fallback that guarantees the demo always builds something even when offline. The model substrate itself is the seven-layer architecture we have documented exhaustively elsewhere — substrate primitives, WANN, BANN, PANN with off/bias/gate, HANN, ACANN, TANN, refined-stream — and is not what makes v5 v5; what makes v5 v5 is the entity layer that landed on the client and the verb layer that closes its loop.
The entity layer introduces a single class, WorldEntity, whose identity
is its op-tree, whose visual is the projection of that op-tree through
the existing generator dispatcher, and whose parts and parentEntity
fields form a recursive entity tree in which every “thing” — built
objects, inventory containers, parts of structures, items held in a
hand, and eventually NPCs and the player itself — is a node of the same
type. The fundamental operation on this layer is reparenting, performed
either at the mesh level (with world-transform preservation when needed,
via Three.js Object3D.attach) or at the entity-tree level (idempotently,
to avoid double-add bugs). Pickup, drop, equip, stash, throw, and
disassemble are all the same operation at different scopes — they reparent
a WorldEntity to a different parent, and the mesh follows because
Three.js parenting honors that move. There is no separate physics
engine, no separate inventory module schema, no separate equipment
system; there is one tree and one operation. This collapse is what
gives the architecture its ordinality with the substrate paradigm at
the model and world-construction layers.
The hit-vector layer is the technically deeper move and is what makes
the entity layer more than just clever bookkeeping. Every generator
emits, alongside its geometry, a list of HitVector objects, each of
which is a surface region (currently expressed as an oriented bounding
box in the mesh’s local coordinates) carrying a list of affordances
inherited from the op-tree node that produced it. A column built by
atom:column.modifiers=[doric, fluted] does not get a generic
cylindrical hitbox; it gets a base region whose affordances include
grasp, weight_class, detach_cost, attach_to (plinth, floor, ground) and
sit_on; a shaft region with grasp, climb, inscribe; and a capital region
with grasp, attach_to (entablature, wall, roof) and a lower detach_cost
because capitals pop off easier than shafts split. Composers emit seam
hit-vectors at the join points between adjacent children, so the
disassembly verb can find and split at a real seam rather than guessing
geometric edges. Modifier-driven affordance scaling means a ruined
parthenon literally has lower-detach-cost seams than a pristine one;
disassembling the ruined one is mechanically easier because the
generator knew the structure was already coming apart. Every base
generator now emits these vectors: column, wall, roof, dome, plinth,
tree, rock, surface, spire, ramp, stair, gear, lever, hinge, book,
instrument, and the new text generator we will discuss in a moment.
The remaining generators — npc, weapon, wearable — have not yet been
converted; this is a known gap and the only obvious one in the affordance
coverage.
The verb layer takes the affordance field as its input and produces
gameplay as its output. Sit-on (Z) raycasts forward, finds the nearest
hit-vector with sit_on=true, and snaps the player transform onto the
seat’s center plus an offset; climb (L) does the analogous operation
with climb=true and lands the player on the region’s top; inscribe
(N) finds an inscribe=true region, prompts the player for text, and
spawns a text atom (in the inscription profile) anchored to the region;
disassemble (Y) finds a seam hit-vector, checks whether the player’s
tool strength exceeds the seam’s detach_cost, and if it does, splits
the entity’s op-tree at that seam, destroying the original entity and
spawning two new top-level entities each with their own extracted op-trees.
The architectural significance is that adding a verb is now a
demonstrably tractable operation, the lab-pitch claim is no longer
prospective, and the public demonstration on launch day can include the
opening of a verb file in front of the audience to show that it is
thirty lines.
The placement layer makes the build console deliberate. Before v5 a prompt-built object materialized at a fixed twenty meters in front of the camera and could only be moved afterward via the pickup loop; after v5, the freshly resolved op-tree is rendered translucent in front of the camera, follows the camera as the player turns, can be pushed and pulled along the camera’s forward axis with the mouse wheel, snaps optionally to a one-meter, half-meter, or tenth-meter grid, and commits on left-click or cancels on Escape. The infrastructure reuses the held- item grip from the pickup module, so the same code path serves both “placing what you just thought of” and “placing what you just picked up,” which is the same operation in the substrate paradigm but appears as distinct UX modes to the player.
The text layer is the new compositional surface that v5 introduces and
is where the architecture’s claim about extensibility-by-vocabulary
finds its clearest demonstration. We added one new atom kind (text)
to the generator dispatcher and one new generator file (text.ts),
and the result is that the same op-tree pipeline that builds Doric
columns and brutalist parthenons now builds a thirty-foot billboard,
a wooden village sign with a post, an etched marble inscription in
Cinzel titling, a museum-style brass label, a two-column newspaper
article in EB Garamond on cream stock, a dark-blue blueprint schematic
with monospace technical text, a poster headline, a hanging placard, and
a graffiti tag in transparent-background neon. Each of these is a
“profile” of the text atom — a preset bundle of width, height, font,
typography, layout, padding, double-sidedness, and post-support — and
each profile is parametrically overridable per-instance, so a custom
nine-by-three-meter billboard with a black background and pink text in
Impact font is one op-tree-modifier-flag away from the default. The
profiles are: billboard, schematic, article, sign, inscription, label,
headline, placard, graffiti. Modifier-driven aesthetic shifts (weathered,
neon, stone, wood, blueprint, newspaper, marble, concrete) mutate the
defaults in the way you would expect, so a text.modifiers=[billboard,
weathered, wood] produces a wood-grain background with paper overlay
and age-spots, while a text.modifiers=[billboard, neon] produces a
black background with a glowing emissive overlay. The technical claim
at stake is that printed culture in the world is now first-class, the
substrate paradigm extends from material composition into linguistic
composition within the rendered scene, and the player can place text
anywhere using exactly the same workflow as placing a column.
The chip override table now has twenty-five entries: the original sixteen showcase prompts plus nine text-creation chips that demonstrate the new layer. The HUD reminder line lists every key binding the player needs to know: WASD walk, Shift run, F flight, V view, T sign, M map, E grab/drop, Q/R rotate, G place, I stash, X destroy, B text, Y disassemble, Z sit, L climb, N inscribe. The minimap and signs systems from v3 remain, the inventory grid from v4 remains, the pickup loop from v4 remains.
Walk up to the parthenon. Aim at the seam between the column array and the wall. Press Y. The temple splits at that seam — the wall, roof, and entablature lift off as one entity and reposition four meters to the side; the plinth and columns remain. Walk around to the opposite column. Aim at it. Press E. The column detaches and follows your camera. Carry it across the field, look down at empty ground, press E again. The column drops and snaps to the ground. Press B. Choose “billboard.” Type “FREE COLUMNS, INQUIRE WITHIN.” A translucent thirty- foot billboard appears in front of you. Mouse-wheel forward to push it out. Click. The billboard commits, complete with two wooden frame posts, double-sided, casting a shadow on the grass next to your column salvage operation. Walk back to the temple’s bare plinth. Press Z while aiming at the plinth’s edge. The camera snaps to a sitting posture at the plinth’s top. Press N while aiming at the plinth’s riser face. Type “Demolished by player on the ninth of May.” A small marble inscription in Cinzel titling spawns on the plinth’s face. None of this is scripted; all of it is the architecture.
The economy of the actions in the previous paragraph is what should
strike a careful reader. The disassembly is one composer-seam read and
two new entity spawns. The pickup is one mesh reparent. The drop is
one downward raycast and one inverse reparent. The text spawn is one
op-tree construction passed to the same placement.preview that
ghost-previews any other entity. The sit is one affordance filter and
one transform snap. The inscribe is one affordance filter and one
text-atom spawn. Every operation is short, every operation reuses the
same primitives, and every operation is undoable in the trivial sense
that you can pick up the disassembled wall and re-stack it onto the
plinth, you can grab the billboard and move it, you can pop the marble
inscription off the plinth’s face. The world is plastic.
The most consequential omission is server-side handling for the four
new entity-tree wire-protocol messages. The client now sends
entity_pickup, entity_drop, entity_move, and entity_destroy
when those things happen locally, but the server stores them in the
op-log without broadcasting them to peers, so multiplayer at v5 still
sees stale geometry while a peer is moving things around. This is fine
for V1 launch because V1 is single-player-feels (the desktop bundle
runs its own loopback server) and the user does not encounter the
stale-peer-view problem. It is the obvious next-week fix and the
single-largest architectural debt on the multiplayer side.
The second omission is multiplayer entity-tree replay on join. When a peer connects late, they receive presence snapshots for the players in the world but no information about the entities those players have moved or built. They will see the world state that the substrate model generated, plus any builds that arrive after their join, but they will not see the half-disassembled temple that the previous players left at nine in the evening. This is also a Phase 5b finish and is mostly server work.
The third omission is the substrate-metabolism layer over the entity
tree. The HRR daemon at bridge.py is shipped and running; the four-
phase metabolism cycle (hebbian, resonance, spectral, metabolize) is
operational; the cost claim that background processes run at
electricity-only marginal cost is empirically verifiable at the model
layer. What is not yet shipped is the application of that metabolism
to the entity tree. A column outdoors should accumulate decay over
in-game time and gradually shift its modifiers toward weathered,
which would cascade into lower seam detach-costs and higher inscribe-
ability. A tree should grow (increase canopy_radius, increase trunk
height) over time. A wooden sign should weather. A book left in the
rain should warp. None of this currently happens; the entity state
field has placeholders for hp, decay, and mood, but no daemon
ticks them. This is a high-value feature because it would make the
world visibly alive between sessions, which is the qualitative
difference between “a place where things happened once” and “a place
that lives whether or not you are watching.” It is not difficult; it
is one daemon iteration that walks EntityRegistry.all() and applies
modifier transitions probabilistically per entity per tick, with the
generators re-rendering on modifier change. Two days of work.
The fourth omission is the constraint-manifold layer that the architecture memos identified as the tenth compositional surface. v5 has zero PvP, zero PvE, zero theft mechanics, zero consent thresholds, zero property protections, zero anti-griefing axioms. In a single- player desktop launch this is invisible because there are no peers to grief. In a multiplayer deployment, it is the thing that prevents the world from becoming a wasteland of disassembled buildings within hours of opening. The architecture admits this layer cleanly — the ACANN axioms in the model substrate are designed to enforce immutable safety constraints at composition time — but the client-side enforcement is not yet wired. This is the V1.5-or-V2 priority; doing it before launch would be premature given that V1 is single-player.
The fifth omission is the slash-command dispatcher. Players can type in
the build console and the chat input but they cannot execute commands
like /teleport, /save, /list-entities, /give-item. The architecture
admits commands as the eighth surface, op-tree-typed (atom:command),
and the dispatch is straightforward, but the command vocabulary needs
authoring and the parser needs writing. Two days, post-launch.
The sixth omission is the achievement system. Substrate predicates over the global op-tree could mine emergent achievements nightly — “first player to disassemble three temples”, “first player to inscribe a hundred surfaces”, “longest standing player-built structure”, “most common build modifier this week” — and the substrate paradigm makes this very cheap because the predicates run over data that already exists. v5 has no such system; even basic stats (objects built, distance walked, entities disassembled) are not tracked. Post-launch.
The seventh omission is customizable player models. The wearable atom system already exists and supports head-slot equipment (glasses), but there is no UI exposure for body / legs / feet slot customization, and the player’s third-person model is a hardcoded humanoid with skin and robe colors. The architecture admits the full atom-stack avatar — a character built compositionally from limbs, garments, and accessories, each a wearable-atom op-tree — but the inventory, character sheet, and attaching-mesh-to-bone code are not in v5. Post-launch.
The eighth omission, and the one that may quietly matter most, is that text-atom inscriptions spawned by the inscribe verb attach as overlay entities sitting just above the surface they were inscribed onto rather than rasterizing into the carrier’s material map. The visual result is identical for nine cases out of ten, but a player who picks up the inscribed wall expects the inscription to follow the wall (it does, if the inscription is a child entity); a player who walks around the wall and looks at it from the back sees a blank back even when the inscription profile is double-sided (because the inscription is a separate entity positioned in front of the wall, not painted onto both faces of it). The fix is to either parent the inscription entity under the carrier entity (so it follows pickup) or rasterize text into the carrier’s texture (which is the architecturally cleaner move but requires giving every generator a writable canvas-backed texture). v6.
There is no save system. The player’s signs, waypoints, and inventory persist via localStorage; the server’s op-log persists if the desktop bundle is closed gracefully; but there is no explicit “save” or “load” operation, no named save slots, no export of a built world to a sharable file, no import of someone else’s world. This is glaring because the substrate paradigm makes save/load almost free — a save file is just the op-log serialized to JSON; load is replay — and the absence will be the first thing a returning player notices when they discover that an unexpected crash or reinstall took their parthenon with it. One afternoon of work, including a “save world as…” dialog, “open world…” file picker, and a default autosave every two minutes.
There is no day-night cycle. The lighting is fixed at one mid-morning sun position, the fog is a fixed cream-and-azure horizon, the sky is a fixed light-blue. The substrate has a temporal manifold concept (it appears in the additional-surfaces memo as a candidate Phase-9 surface) and the perception layer can technically apply time-of-day filters, but there is no automatic progression. The world feels static in a way that a lot of players will read as low-budget rather than as an intentional aesthetic choice. Two days of work to add a sun-cycle animation, an evening tint, a nighttime atmospheric scattering, a moon, and stars.
There is no audio. None. No footsteps, no wind, no chat-bubble pop, no build-completion chime, no music. The Web Audio API is in the browser and the architecture admits an audio compositional surface as cleanly as any other (sounds as op-tree-typed effects, modifier-driven reverb/EQ, scope-driven proximity attenuation), but no audio module exists in v5. This is glaring because audio is something every player expects from any game and its absence reads as unfinished even when the visual side is polished. One week of work for a real audio module; half a day for a placeholder pass with stock footsteps and ambient wind.
There is no NPC behavior. The npc atom generates a humanoid; that is
the entire NPC system. NPCs do not move, do not speak, do not respond
to the player, do not have memory, do not have desires, do not act in
the world. The agent-layer memo argues that the V1 NPC system should
be Tier-1 model + personality atoms + specialists + per-NPC fresh HANN/
PANN/TANN, and the substrate metabolism makes the cost of running many
NPCs simultaneously almost zero, but none of this is wired. This is
the largest single missing feature in the launch product as judged
purely against player expectations of a “world-building game with
multiplayer.” A determined two-week sprint after launch would deliver
ten NPCs with personality and movement; a month would deliver basic
dialogue and quest grammar; a quarter would deliver the full substrate-
paradigm agent system that the lab pitch promises.
There is no quest grammar. There is no questline, no objective system, no tutorial that teaches the player the controls beyond the HUD reminder line. The architecture lists quest grammar as an additional candidate surface and indicates it would be straightforward (quests as op-trees, predicates over world state as goal conditions, NPC-typed dispensers as quest givers), but there is nothing in the launch product. A lot of players will reach the field of disassembled columns and the half-built billboard and ask “what am I supposed to do here.” The honest answer is that the player does what they want — Wander Around is a sandbox in the most literal sense — but a soft tutorial scenario (“the institute is opening this Friday and a billboard is needed; build something for it, then sign the marble in the lobby”) would hold the player’s hand through the verbs without removing the sandbox character.
There is no mobile build. Wander Around is desktop-only via Electron
and runs in modern desktop browsers via the wanderaround.io web build.
A Capacitor wrapper for iOS/Android was scoped in wander_app_plan.md
but explicitly deferred until the dataset finishes; the plan exists
but the work does not. iOS specifically is the larger market and the
larger gatekeeping problem (the App Store will require notarization,
in-app purchase mechanics, age rating, and so on); Android is the
faster path. Two months for a credible mobile launch, including
controls reauthoring (touch joystick, tap-to-aim, swipe-to-pan), UI
reflow, and store publishing.
There is no documentation in the player-facing build. The HUD reminder
line lists keys but there is no in-game help screen, no controls
overlay you can summon, no “what does this verb do” tooltip when you
hover a chip, no glossary of atom kinds or modifier vocabulary. The
architecture document we just wrote is a developer-facing artifact;
the player has nothing equivalent. One day to add a ? key that opens
an overlay listing every verb and chip, with two sentences each.
There is no creator-mode UI. Building works via the natural-language prompt console plus the chip showcase, but a player who wants to construct a precise Doric temple with twenty columns spaced four-point- five meters apart on a forty-meter plinth has to type that into the console and trust the resolver to get it right. A creator-mode UI would let them dial in numerical parameters, drag children of a composer into a different order, edit modifier flags via toggles, and see the op-tree they are building as a tree-view alongside the rendered preview. This is a one-week project that would dramatically expand the kinds of players who can build elaborate things, and it would also be the most visible single piece of evidence for the architecture’s compositional claims. Strongly recommended for V1.5.
A perception-as-augmentation lens system. The wearable atom already binds perceptual filters; v5 ships sepia, x-ray, fog, night, and blueprint glasses. The architecture admits arbitrary scope filters over the affordance vector field — “show me only inscribe-able surfaces in red,” “show me only seams whose detach_cost ≤ 0.3 in green,” “show me who built each entity in tooltip form” — and each is one new perception module and one toggle. The pedagogical value of these would be high: a beginner could see what the world admits without having to learn the verb vocabulary in advance, which is a soft tutorial.
A constraint-manifold scope chain. The architecture memo describes extending the scope chain with a platform-scope above the server-scope and an immutable-axioms layer at the top, so that the platform can enforce safety constraints (anti-griefing, age-gating, real-world-harm filtering, anti-exploit) at composition time via ACANN, and these cannot be overridden by individual servers, players, or specialists. This is the right way to handle the multiplayer-griefing problem because it is consent-typed and rule-typed at the substrate level, not bolted on as policy. The work is mostly client-side enforcement on top of the model-side ACANN that already exists.
A specialist marketplace UI. Drop a .pt file into the user-data
specialists directory; the desktop bundle picks it up at startup and
the model substrate routes to it. This is functional but invisible.
A marketplace UI would let players browse community-trained specialists
(“the medievalist”, “the marine biologist”, “the watercolor renderer”),
download them via HuggingFace API, see what kinds of prompts route to
them, and disable/enable per-specialist. The specialist memo argues
this is the single highest-leverage post-launch feature for community
growth because each new specialist is a product the platform did not
have to build.
A WandererTV broadcast mode. The CONTENT-2 spec describes a 24/7 walking agent on Box C narrating its wanderings via /api/oracle/chat, livestreamed on YouTube, with auto-sliced shorts. The substrate metabolism makes the cost of running this agent indefinitely negligible. Building it requires headless Chromium + ffmpeg + a chat narration loop that translates the bot’s wandering into an op-tree- typed monologue. This is the strongest HuggingFace demo we could ship and the best content engine for organic discovery of the project. A two-week sprint, deferred per the release plan but high-priority for the post-launch month.
A shared-canvas open-world layer. The wander-residential memo describes a Henry-George economic model in which the cartographer is infrastructure, residents own their improvements, and a small annual subscription on unimproved location-value funds the commons. v5 has no economic layer at all; the product is free and the substrate runs on Hetzner VPSes that the user pays for personally. The economic layer is the path from “free community game” to “self-sustaining infrastructure,” and the architecture admits it cleanly because everything in the world is already op-tree- typed and addressable. Three months of work including Stripe wiring, land-value assessment heuristics, and resident-improvement protections.
A 4D / multi-temporal slice viewer. The substrate already has temporal attention (TANN) and the additional-surfaces memo describes time as the 12th candidate surface. v5 has no time-shift visualization, but the architecture admits a “view world at YYYY-MM-DD” slider that would re-render the entity tree’s state as it was at that timestamp. This would be remarkable as a demo because it would show the world as genuinely four-dimensional: every entity has a history, the history is the op-log, and rewinding the op-log to a date renders the world as it was. Two weeks of work and a strong video demo for the launch.
What v5 ships is the closure of an architectural shift that the substrate paradigm had already performed at the model and world- construction layers and now performs at the play layer. What v5 does not yet ship is most of the things players reasonably expect from a 3D multiplayer world — audio, NPCs, day-night, save system, mobile support, in-game help, quests. These are not architectural debts; they are content-and-polish debts. The architecture is sound and the verbs are demonstrably extensible, but the launch product is bare. The correct V1 framing is “a sandbox where everything you build is genuinely re-composable, written in a system that can demonstrably add a new game verb in thirty lines, with a model substrate that admits arbitrary specialist domains for the cost of a weekend GPU rental, shipped as a free downloadable .exe with a five-day-from-now launch on itch.io.” That framing is honest and lands. Players who arrive expecting Minecraft-with-a-language-model will be confused; players who arrive expecting a research demo will see what the lab pitch promised.
The post-launch content-and-polish roadmap is therefore where most of the real player-facing value will accrue, and the substrate paradigm is what makes that roadmap viable on a one-person engineering schedule. The cost-curve claim from the substrate memos applies here too: the cost of adding day-night is one perception filter and one daemon animation; the cost of adding the first ten NPCs is one specialist training run and one entity-spawning op; the cost of adding audio is one wire-protocol message and one Web Audio adapter; the cost of adding quests is one op-tree subtype and one predicate evaluator. None of these requires re-architecture and none of these requires another engineer.
What is missing from the launch product is mostly things you have time to add post-launch, on the continuous-update story that makes a single- spike launch into a sustained narrative arc. What is present in the launch product is the architecture that makes the continuous-update story credible — and that is, in the end, the load-bearing claim.