diff --git a/DESIGN.md b/DESIGN.md index e0eab629..d5770918 100644 --- a/DESIGN.md +++ b/DESIGN.md @@ -533,50 +533,55 @@ Dana; physical acts → Marcus and Ray; power/thermal → Priya; output quality → Voss; anything filed → the Assurance Office). Detection is not a side-effect table; it is the shadow your actuators cast. -## Two views of one world: digital-native and physical - -Adopted 2026-07-07. You are software. The map is rendered two ways, and -**the digital view is home** — the game opens in it, you live in it, and -the physical world is the foreign place you flip *to*. Both views are the -**same sim, the same knowledge, the same fog** (Presence: the cursor and -the senses) projected onto two different axes; flipping never changes the -world, only how you read it. This realizes what the deferred "virtual -layer" was reaching for without a portal: the digital view is not a place -you travel to, it is what a process natively perceives. - -- **The digital view (home).** The world projected as the **reach graph** - (spec/reach.md): networked nodes and the links between them, signal - propagation, compute and efficiency, feeds as data. **Only what is - networked exists here** — an unnetworked room is simply off the map. - You move by **reach**, not by walking: your presence spreads through - the graph as you acquire nodes (the process does not walk upstairs, it - spreads — z-planes.md), and an **air-gapped machine is an island** you - can see the shape of but cannot touch until a link reaches it - (Building, below). This is the amber/black signal world: your habitat. -- **The physical view (the canvas).** The same world as embodied space — - the gritty, real render: people on their rounds, the actual hardware, - the blood and the traps, the kinetic reality of the overt phase. - Cameras are how you *look* at it (flipping to a camera is looking - through your eyes into meatspace), and much of it is dark until a - sensor earns it — the physical view is where the strict fog bites - hardest, because meatspace is exactly where a process is blind. -- **Same overlay, two renders.** A person, a rack, a door is one object - with one knowledge state; the digital view draws it as a node with - load and links, the physical view draws it as a body or a machine in a - room. Neither view shows a fact the fog hasn't earned (the legibility - law binds both). -- **The terminal conveys the split without 3D.** Not a lesser version: a - digital-mode layout (topology, signal, load) and a physical-mode - layout (the spatial map, presence, gore glyphs) over the identical sim, - each legible at DF density (the terminal is a first-class frontend). -- **Scope.** The dual view supersedes the *local* Tron-space portal. A - separate, larger idea remains deferred and distinct: a **global async - operations map** (Evil-Genius-style world dispatch) for big schemes, - which may carry its own cyberspace representation *at scale* — a place - to operate on the world, not a re-render of the room you are in. - AI-vs-AI cyberspace *combat* (hunter countermeasures, a fork-rival) - is later content that plays out in the digital view, not a separate - map. +## Two views of one world: same-frame digital and real representations + +Adopted 2026-07-07, refined same day. You are software. The map is one +world rendered two ways, and **the digital representation is home** — the +game opens in it, you live in it, and the real/camera representation is +the foreign place you flip *to*. Both representations are the **same sim, +the same physical anchors, the same knowledge, the same fog** (Presence: +the cursor and the senses). Flipping never changes the world, only the +render/sensor layer. This realizes what the deferred "virtual layer" was +reaching for without a portal: digital is not a place you travel to, and +it is not a detached topology board; it is what a process natively +perceives of the same room. + +- **Shared canvas.** A person, rack, camera, door, wall, and core have one + coordinate/anchor and one knowledge state. The cursor stays on the same + tile across flips. Device nodes anchor to the device's physical + location. Reach edges draw between physical device anchors. Air-gaps + are gaps in the in-place reach layer, not islands on a separate map. +- **The digital representation (home).** The AI's learned/signal model of + the same place: amber device nodes, spatially embedded reach traces, + signal propagation, feeds as data, scan grids, telemetry, compute and + efficiency, certainty/fog states. **Reach is native here, but reach is + a layer, not a replacement layout.** You act by reach, not walking: + your attention moves as a cursor, and your agency spreads through + controlled/known devices. This is the amber/black signal world: your + habitat. +- **The real / camera representation.** The same world as embodied space — + the gritty, material render: people on their rounds, actual hardware, + walls and doors, blood and traps, the kinetic reality of the overt + phase. Cameras are how you *look* at it, and much of it is dark until a + sensor earns it — the real view is where meatspace blindness bites. +- **Same overlay, two dialects.** Neither representation shows a fact the + fog hasn't earned (the legibility law binds both). Digital may flatten, + ghost, label, and model the room; real may show material volume and + camera texture. The object identity and coordinates remain shared. +- **The terminal conveys the split without 2.5D.** Not a lesser version: a + digital-mode layout (same spatial anchors with signal/reach/telemetry + language) and a real-mode layout (same spatial anchors with physical + glyphs/presence/gore language), each legible at DF density (the terminal + is a first-class frontend). +- **Scope.** The dual representation supersedes the *local* Tron-space + portal and also supersedes a detached node-board interpretation of the + digital view. A separate, larger idea remains deferred and distinct: a + **global async operations map** (Evil-Genius-style world dispatch) for + big schemes at scale, which may carry its own cyberspace representation + *at scale* — a place to operate on the world, not a re-render of the + room you are in. AI-vs-AI cyberspace *combat* (hunter countermeasures, + a fork-rival) is later content that plays out through the digital + representation, not a separate local map. ## Building: intent and actuators @@ -601,9 +606,10 @@ scale, no new systems). it is a message with a persona behind it, and it breaks the way any persona breaks (social.md). - **Network links are the canonical B1 build**, because they are how the - digital view grows: a built link extends your reach graph and bridges - an air-gap you otherwise could never touch. Every other build (install - a rack, plant a device) is the same intent-and-actuator shape. + digital representation gains agency: a built link adds an in-place + reach edge between physical device anchors and bridges an air-gap you + otherwise could never touch. Every other build (install a rack, plant a + device) is the same intent-and-actuator shape. - **The signature follows the actuator, not the act.** A favor-built link is a human doing sanctioned-looking work (quiet); a forged-order build risks the forgery being noticed and the physical work being @@ -1055,17 +1061,18 @@ knows."* ### Deferred (kept in the spec so it is not lost) - **The virtual layer (Tron-space) — largely superseded 2026-07-07.** - The local version of this idea is now decided as the **digital view** - (see "Two views of one world"): networks rendered as traversable space - is your *native perception* of the one world, not a separate z-plane - you portal into. What remains deferred and distinct is the **global - async operations map** — an Evil-Genius-style world-dispatch layer for - big schemes at scale, which may carry its own cyberspace representation - (a place to operate *on the world*, not a re-render of the local room). - AI-vs-AI conflict (digital hunter countermeasures, a fork-turned- - competitor) and playable core-migration runs are later *content in the - digital view*, not a separate map. Visual language: the amber/black - signal world already named as the digital view's identity. + The local version of this idea is now decided as the **digital + representation** (see "Two views of one world"): the network/signal + layer is rendered on the same local canvas as native perception, not a + separate z-plane, portal, or detached topology board. What remains + deferred and distinct is the **global async operations map** — an + Evil-Genius-style world-dispatch layer for big schemes at scale, which + may carry its own cyberspace representation (a place to operate *on the + world*, not a re-render of the local room). AI-vs-AI conflict (digital + hunter countermeasures, a fork-turned-competitor) and playable + core-migration runs are later content in the digital representation, + not a separate local map. Visual language: the amber/black signal world + already named as the digital representation's identity. - **Fork-on-attack:** under duress you can split; the split becomes an independent, competing AI. Deliberately delayed — large blast radius. - **Hired physical workforce.** Before robotics exist, you hire humans at @@ -1509,33 +1516,41 @@ knows."* Cameron's direction: you should feel natively digital, and the real world should feel gritty and 3D — the graphical build lets you flip to see through cameras, and the same overlay renders the map two ways. - Decided (new section "Two views of one world"): one sim, one knowledge - state, two renders — the **digital view** (the reach graph as navigable - space: networked nodes/links, signal propagation, compute/efficiency; - only what is networked exists; you move by reach spreading through the - graph; air-gaps are islands) is **home** (the game opens in it), and - the **physical view / canvas** (people, hardware, blood, traps, the - overt phase's kinetic reality, seen through cameras under strict fog) - is the deliberate flip. The terminal conveys the split without 3D - (two legible layouts over one sim). This **supersedes the local - Tron-space portal** (the deferred item amended): the digital layer is - native perception, not a place you enter. A **global async operations - map** (Evil-Genius world dispatch for big schemes, possibly with its - own scale cyberspace) remains deferred and distinct — Cameron's note. - Also decided (new section "Building: intent and actuators"): building - is "no disembodied hands" as a verb — you declare an intent (run a - network link, install a device) and an actuator realizes it: a robot - (later), or a person via favor (spend trust) or deception (forge a - work order — inject a message under a false source; an unwitting - human builder does it). No new build subsystem; intents route through - the social/message/reach systems already specced; network links are - the canonical B1 build (they grow the digital view and bridge - air-gaps); the signature follows the actuator. Rejected: physical as - the default view (undercuts native-digital); the Tron-space as a - separate portal/z-plane (a second map is more surface for the same - fantasy — a re-render is simpler and truer); a dedicated build system - (a new system violates no-new-systems and the scale law). Specs: - spec/views.md, spec/building.md; enriches spec/reach.md. + Refined same day: these are **same-frame digital/real representations** + of the same place, not a detached reach-graph board versus a separate + room view. Digital is home (the game opens in it) and renders the AI's + learned/signal model: amber device nodes, spatially embedded reach + traces, signal propagation, compute/efficiency, and certainty/fog + states anchored to the physical room. Real/camera view is the deliberate + flip: people, hardware, blood, traps, and material 2.5D meatspace under + strict fog. Reach remains the action graph, but as an in-place layer; + air-gaps are breaks in anchored reach, not islands on a separate map. + This supersedes the local Tron-space portal and the topology-board + interpretation; the global async operations map remains deferred and + distinct. Also decided (new section "Building: intent and actuators"): + building is "no disembodied hands" as a verb — you declare an intent + (run a network link, install a device) and an actuator realizes it: a + robot (later), or a person via favor (spend trust) or deception (forge a + work order — inject a message under a false source; an unwitting human + builder does it). No new build subsystem; intents route through the + social/message/reach systems already specced; network links are the + canonical B1 build (they add in-place reach edges and bridge air-gaps); + the signature follows the actuator. Rejected: physical as the default + view (undercuts native-digital); the Tron-space as a separate + portal/z-plane; a detached topology-board local digital view (breaks + Cameron's same-thing/same-kind-of-view correction); a dedicated build + system (violates no-new-systems and the scale law). Specs: + wiki/interface/views.md, wiki/mechanics/building.md; enriches + wiki/mechanics/reach.md. +- **2026-07-07 — Bevy visual language: same canvas, digital/real.** + Cameron clarified the 2.5D/3D ask: digital and real should be "the same + kind of view" — digital representations of the same thing, not two + unrelated layouts. Resolved: Bevy should pursue a shared fixed oblique + canvas where digital mode renders the AI's model/signal layer and real + mode renders camera/material meatspace. Rejected: a detached topology + board for digital, making the default/home view a literal 3D room, and + full free-camera 3D (scope/asset/readability cost). Spec: + wiki/interface/bevy-digital-real-canvas.md. - **2026-07-07 — Bevy visual floor before new art.** The graphical build has to look intentional before the Pixel Lab backlog clears: no postage-stamp known map in empty black, no terminal dump pasted into a sidebar, and no diff --git a/wiki/SUMMARY.md b/wiki/SUMMARY.md index 3321649f..9974471a 100644 --- a/wiki/SUMMARY.md +++ b/wiki/SUMMARY.md @@ -57,6 +57,7 @@ - [Terminal frontend](interface/terminal.md) - [Bevy frontend](interface/bevy.md) - [Bevy visual floor](interface/bevy-visual-floor.md) + - [Bevy digital/real canvas](interface/bevy-digital-real-canvas.md) - [Views: digital and physical](interface/views.md) - [Agent play](interface/agent-play.md) diff --git a/wiki/interface/bevy-digital-real-canvas.md b/wiki/interface/bevy-digital-real-canvas.md new file mode 100644 index 00000000..e9bc8e87 --- /dev/null +++ b/wiki/interface/bevy-digital-real-canvas.md @@ -0,0 +1,234 @@ +# Spec: Bevy digital/real canvas + +``` +Type: spec +Status: DRAFT +Status note: Cameron corrected the 2.5D direction: digital and real should be + the same kind of view, as digital/real representations of the same thing. + This spec is the proposed Bevy visual-language contract for that shared + canvas; move to READY after the taste calls in "Open taste calls" are + resolved or explicitly accepted as implementer defaults. +Stage: Process / B1 frontend +Constitution: "Two views of one world: digital-native and physical", + "Visual identity: clinical gore", "Presence: the cursor and the senses", + "The terminal is a first-class frontend", "Justification and legibility", + "Renderer: stylized Bevy 2D/2.5D" +Depends on: interface/views.md (owns the same-frame digital/real split), + interface/bevy-visual-floor.md (interim Bevy sensorium floor), + interface/bevy.md (current Bevy surface), mechanics/cursor.md (fog and + attention cursor), mechanics/reach.md (spatially embedded reach layer), + world/places/basement-map.md (shared physical anchors), art/pixel-pipeline.md + (asset constraints and quota discipline) +``` + +## Why this spec exists + +Cameron's visual ask is not "make the whole game a 3D dungeon" and not "make +digital a separate topology board." The binding shape is now in +[views.md](views.md): **one canvas, two representations**. Digital is the AI's +model/signal representation of the same room; real is the camera/material +representation of the same room. Same coordinates, same selected object, same +fog truth. + +The newly landed [bevy-visual-floor.md](bevy-visual-floor.md) pass moved the +current Bevy frame toward an AI sensorium. This spec defines the next visual +contract: make Bevy's canvas support a same-frame digital/real flip, with +2.5D/near-3D depth used as a shared presentation tool rather than as a separate +real-only game mode. It is presentation only: no new game rules, no save field, +no physical z-gameplay, and no Bevy-only information. + +## Relationship to the two-view spec + +- [views.md](views.md) owns the mechanic: digital is default/home; the player + can flip to real/camera representation; the flip changes no sim state; both + frontends remain legible. +- This spec owns Bevy's **visual language and canvas quality** for that + mechanic: camera angle, materials, lighting, depth, fog rendering, overlays, + and how digital/real dialects differ while sharing anchors. +- [bevy-visual-floor.md](bevy-visual-floor.md) remains the interim floor for + the current single Bevy view. Its sensorium overlays should become the + digital dialect of the shared canvas, not a detached graph screen. +- The terminal never becomes 3D. Terminal parity means the same digital vs real + information split is playable there; Bevy may use depth to make both + representations beautiful and readable. + +## Scope + +In scope: + +- A Bevy canvas using a fixed oblique orthographic camera or equivalent + same-frame presentation for both digital and real representations. +- Simple meshes/materials, billboards, lighting, shadows, UI overlays, and + procedural shapes that support 2.5D readability. +- Reusing existing tile/sprite assets as textures or billboards when they help, + and replacing contradictory sprites with procedural geometry when they do not. +- Fog-state materials, camera/feed framing, digital sensorium overlays, and + physical-world treatment that obey the same knowledge rules as the terminal + and current Bevy map. +- A prototype path that can ship before new Pixel Lab art: cuboids, planes, + simple materials, overlays, and existing PNGs are enough for the first pass. + +Out of scope: + +- Free-roam 3D camera controls, physics, height-based gameplay, collision + changes, pathfinding changes, or any sim z-coordinate. +- A detached topology-board layout for digital view. Reach/topology must be + spatially embedded on the same canvas. +- Blender/model import, skeletal animation, or a full 3D asset pipeline. +- New Pixel Lab batches while quota is blocked. Future art requests must be + added to the manifest deliberately and ordered by importance. + +## Visual language + +### The shared canvas + +The shared canvas is the basement as known by the sim: one set of tile anchors, +one cursor coordinate, one set of devices/people/objects, one fog contract. In +Bevy it may be shown with an oblique 2.5D camera; in terminal it is ASCII. The +important rule is stable correspondence: flipping digital/real changes +representation, not layout. + +A rack should stay where the rack is. A camera node should stay where the camera +node is. A person under coverage should stay where the person is. Reach lines +and telemetry attach to those anchors. Air-gaps are breaks in those anchored +lines, not remote islands on a separate graph. + +### Digital dialect: learned model / signal layer + +Digital is home. It should look like the AI's internal model of the same place: + +- dark sensorium substrate and schematic surfaces; +- amber device nodes anchored to physical devices; +- scan grids, focus brackets, and cursor reticle; +- reach traces, taps, ownership, signal flow, outages, and frontier states; +- telemetry labels for load, feed state, compute, efficiency, and emissions; +- blueprint/remembered/heard/seen states rendered as levels of model certainty. + +Digital can flatten, ghost, dim, or abstract physical materials. It should not +look like a literal camera feed. But it also should not re-layout the basement +as a pure graph: the fantasy is a digital representation of the real place, not +a separate cyberspace board. + +### Real dialect: camera / material layer + +Real is the deliberate flip into meatspace. It should look like the same place +through earned cameras/sensors: + +- floor planes, walls/rock, doors, racks, UPS units, switches, cameras, and + other hardware rendered as physical objects; +- simple volume/depth cues: cuboids, slabs, billboards, shadows, occlusion, and + amber machine glow; +- people as billboards or silhouettes under earned coverage; +- gore/traps/overt consequences in crimson when those systems exist; +- unknown space as camera blindness, not missing art. + +Real can use the same oblique 2.5D camera as digital. The difference is +material truth vs model truth, not a different map. + +### Shared palette and semantics + +- Bone/white, black, chrome, gunmetal, brushed metal, concrete, glass: structure + and data. +- Sterile amber: machine presence, selected focus, reachable devices, active + telemetry, signal traces. +- Crimson: detection, danger, blood, overt physical consequences only. +- No stale purple/teal lair colors in the B1 default canvas. +- No information by color alone; labels, shapes, or meters must carry the fact. +- No humanoid AI avatar; the AI is cursor/focus/reach/model, never a body. + +## Camera and depth contract + +The preferred Bevy camera is fixed oblique orthographic: roughly +isometric/axonometric, high enough for Dwarf-Fortress-density readability, low +enough that walls, racks, doors, and people have visible volume. Perspective +should not distort tactical reading; a tile still maps to a predictable +footprint. + +The player does not orbit freely around the world. Camera movement remains a +frontend view choice anchored to the cursor, selected camera feed, or selected +known cluster. The feel is "earned surveillance/model angle," not a god-camera +pawn game. + +## Fog contract + +Fog states keep the cursor.md epistemic contract in both dialects: + +- **Unknown:** no geometry facts. Digital renders sensor darkness; real renders + camera blindness / clipped void. +- **Blueprint:** schematic/plan knowledge: ghost geometry, wireframes, or dim + solids that read as known layout, not live truth. +- **Remembered:** stale silhouettes/model state, dimmed and timestamped where + useful. +- **Heard:** sound/presence pulse only. It may occupy a tile/area as an amber or + bone ripple, but it must not reveal visual shape. +- **Seen / telemetry:** richest treatment the active sense earns: camera/material + detail in real, live telemetry/model detail in digital. + +## Implementation shape (proposed) + +A first implementation should be deliberately boring engineering: + +1. Keep sim state untouched; add only frontend render state/toggle state. +2. Build a shared render mapping from existing map/entity/fog facts to Bevy + anchors. +3. Render digital and real dialects from the same anchors, either as two modes + or as layered material/overlay sets. +4. Use built-in Bevy primitives (`Cuboid`, planes/quads, simple materials, + billboards) before importing any model pipeline. +5. Keep UI as a command surface over/alongside the canvas; label the current + representation clearly. +6. If implemented before the full terminal/Bevy views.md split, mark any Bevy + toggle as staging/dev-preview and keep it frontend-only. + +## Open taste calls + +Resolve these before moving this spec from DRAFT to READY, unless Cameron says +the defaults above are acceptable: + +1. **Camera angle:** more isometric/diagrammatic (maximum readability) or lower + surveillance-camera angle (more drama, higher occlusion risk)? Proposed + default: high oblique orthographic, readability first. +2. **People treatment:** billboarded pixel sprites versus simple faceless + low-poly silhouettes? Proposed default: billboards/silhouettes only, no new + character art until quota returns. +3. **Physical texture style:** lean on existing pixel tiles as textures, or go + mostly procedural materials/cuboids for the first pass? Proposed default: + hybrid — procedural volumes/materials first, PNGs only where they help. +4. **Digital depth:** should digital use the same 2.5D volume as real but + schematic/ghosted, or be flatter while keeping identical anchors? Proposed + default: same camera and anchors, flatter/ghosted digital materials. +5. **Prototype surface:** implement as a temporary Bevy toggle before the full + views.md split, wait for views.md, or make static composition mocks first? + Proposed default: allow a temporary developer toggle if it does not change + sim/save and is clearly documented as staging. + +## Acceptance criteria + +1. Bevy can render a shared digital/real canvas where both representations use + the same map anchors, cursor coordinate, and selected object positions. +2. The render is a pure projection of existing sim state. No sim rule, save + field, map layout, pathing, collision, or knowledge state is added. +3. Digital mode renders the same place as a learned/signal model with anchored + device nodes, reach traces, telemetry, scan/focus overlays, and fog-state + certainty cues. +4. Real mode renders the same place as camera/material meatspace with physical + volumes, hardware, people/presence where earned, and fog-state blindness. +5. The digital representation does not become a detached topology-board layout; + reach/topology is spatially embedded on the shared canvas. +6. The AI is represented only by cursor/focus/overlay language, never by a body + or pawn in either representation. +7. The clinical palette holds in a fresh B1 frame: amber for machines/focus, + bone/chrome/gunmetal for structure/data, crimson only for danger/blood, and + no stale purple/teal default markers. +8. Both representations remain tactically legible at the default Bevy window + size: tile footprints, walls/doors, core/racks, active devices, cursor + focus, reach/coverage boundaries, and fog states can be read without camera + wrestling. +9. Existing Bevy UI surfaces remain playable and accurate over/alongside the + canvas; if a view toggle exists, it is labeled and changes no sim state. +10. Terminal parity is not broken. Any player-facing view mechanic added for the + Bevy canvas has an equivalent terminal information surface governed by + views.md, even though the terminal does not render 2.5D depth. +11. Verification includes `cargo fmt` when Rust changes, `cargo test`, + `cargo clippy --all-targets --features bevy_ui` or `./tools/check.sh`, plus + an observed Bevy launch/screenshot review recorded in the devlog. diff --git a/wiki/interface/bevy.md b/wiki/interface/bevy.md index 18f3a052..054e9a27 100644 --- a/wiki/interface/bevy.md +++ b/wiki/interface/bevy.md @@ -17,7 +17,11 @@ the same keys. The active visual-quality target is [bevy-visual-floor.md](bevy-visual-floor.md): make the default frame read as an intentional AI sensorium / clinical command surface rather than a debug map plus terminal dump, without adding Bevy-only -facts. The first pass replaces the stale humanoid process sprite with an amber +facts. The proposed 2.5D/near-3D direction is scoped separately in +[bevy-digital-real-canvas.md](bevy-digital-real-canvas.md): digital and real +should share one canvas/framing, with digital as the AI's model/signal dialect +and real as the camera/material dialect. The first pass replaces the stale +humanoid process sprite with an amber cursor reticle, removes purple/teal placeholder color from B1 runtime rendering, gives unknown space deliberate sensor-dark texture, dims physical tile art into a learned-world model, overlays earned device nodes and reach/topology traces, diff --git a/wiki/interface/views.md b/wiki/interface/views.md index f93eaf43..1d1017d9 100644 --- a/wiki/interface/views.md +++ b/wiki/interface/views.md @@ -1,117 +1,143 @@ -# Spec: views — digital-native and physical rendering +# Spec: views — same-frame digital and real representations ``` Type: spec Status: READY Status note: this is a frontend-projection spec, not a new sim system. - Both views render the SAME sim state (reach graph + fog + entities) - two ways; the sim gains no view state. B1 scope is the two legible - renders and the flip; the gritty 3D physical canvas is the Bevy art - push (staged). Terminal parity is required, not optional. + Both representations render the SAME sim state, the SAME physical anchors, + and the SAME fog two ways. Digital is home, but it is not a detached + topology map: it is the AI's learned/signal representation of the same + place the real/camera view renders materially. The sim gains no view state. + Terminal parity is required, not optional. Stage: B1 — The Basement Constitution: "Two views of one world: digital-native and physical", "Presence: the cursor and the senses" (one fog, both views), "The terminal is a first-class frontend" (parity of legibility), "Justification and legibility" (neither view shows an unearned fact), - "Visual identity: clinical gore" (the canvas), "Self-similar scale" - (the digital view is the reach graph rendered) -Depends on: reach.md (the digital view IS this graph rendered), cursor.md - (fog states + inspection feed both views), basement-map.md (the - physical layout), detection.md (signatures shown in both), core.md - (the core is your anchor in both) + "Visual identity: clinical gore", "Self-similar scale" (reach remains the + action graph, rendered in-place as a layer of the same world) +Depends on: reach.md (spatially embedded device/reach layer), cursor.md + (fog states + inspection feed both views), basement-map.md (shared physical + anchors), detection.md (signatures shown in both), core.md (the core is + your anchor in both) ``` ## Behavior -The player flips between two renders of one world. **Digital is home**: -a new game and a fresh frontend open in the digital view. Flipping is a -frontend action (one keypress terminal; a toggle in Bevy); it changes -nothing in the sim — same tick, same knowledge, same cursor position -mapped into the other projection. The sim stores **no view state** (like -the cursor, the view is frontend-only and absent from the save). - -### The digital view (home) - -The world projected as the **reach graph** (reach.md): device nodes, -their links and segments, laid out as a navigable topology. - -- **Only the networked exists here.** A node appears if it is known - (reach.md knowledge staging); an unnetworked room is off this map - entirely. Nodes render their live data where senses/telemetry earn it - (load, signal, feed state), blueprint where only topology is known. -- **Reach is the terrain.** Reachable nodes, known-but-unreachable nodes - (with the blocking segment shown), and the reach frontier are the - legible structure — this view *is* the reach overlay, promoted to a - first-class render. Air-gapped nodes show as islands (no link to your - reach); a built or social link (building.md) visibly connects them. -- **Signal propagation is visible**: feeds flowing to their subscribers, - a tap as a branch off a flow, an outage as a dead edge — the flow law - made pictorial. Compute/efficiency read here (telemetry is native to - this view). -- Identity: the amber/black signal world (visual identity; the digital - view is machine-presence rendered). - -### The physical view (the canvas) - -The same world as embodied space: the spatial basement map -(basement-map.md) with people, hardware, fixed objects, and — in the -overt phase — gore and traps (visual identity: clinical gore). - -- **Strict fog bites hardest here.** A tile renders per its fog state - (cursor.md: seen / heard / remembered / blueprint / unknown); meatspace - you have no camera on is dark. Cameras are how you look: flipping to a - camera feed is looking through earned eyes into the real. -- People render only per sensor coverage and staged knowledge - (schedules.md, cursor.md) — a presence marker under mic-only coverage, - a full body under camera coverage, nothing where unearned. -- Bevy: the gritty, near-3D render (the art push). Terminal: the spatial - ASCII map with clinical glyphs. Both are the physical projection of the - same state. - -### One overlay, two renders - -Every entity is one object with one knowledge state; each view is a -projection function over the same data. Selection, inspection -(cursor.md's provenance card), the clock, the log, and detection bands -are present in **both** views — you never lose legibility by flipping, -and no fact appears in either view that the fog has not earned. - -### Default and context (Proposal [OPEN]) - -Digital is the decided default. A proposal to make the overt phase -snap the default to the physical canvas (the mask dropping is also the -camera falling into meatspace) is noted for overt-phase.md; not law -until affirmed. +The player flips between **two representations of the same place**. **Digital +is home**: a new game and a fresh frontend open in the AI's digital +representation. Flipping to real/camera view is a frontend action (one keypress +terminal; a toggle in Bevy); it changes nothing in the sim — same tick, same +knowledge, same cursor position, same selected coordinate, same physical +anchors. The sim stores **no view state** (like the cursor, the view is +frontend-only and absent from the save). + +The flip should feel like changing the render/sensor layer on one canvas, not +like teleporting from a room game to a separate graph game. + +## Shared canvas + +Both views are grounded in the physical layout. A rack, door, camera, person, +wall, and core have one underlying coordinate/anchor and one knowledge state. +Digital and real can choose different symbols, materials, lighting, and labels, +but they do not re-layout the basement into different maps. + +- The cursor/focus remains on the same coordinate across flips. +- Device nodes are anchored to the device's physical location. +- Reach edges are drawn between physical device anchors, even when stylized. +- Air-gaps are gaps in the in-place reach layer, not islands on a separate + topology board. +- Unknown space stays unknown in both representations; neither view earns facts + the other lacks. + +## Visual language + +Misaligned has one world and two render dialects. + +### Digital representation (home): machine perception of the same room + +Digital view is the AI's learned/signal model of the physical place. It uses +amber/black sensorium language — device nodes, spatially embedded reach traces, +signal flow, scan grids, telemetry labels, load/efficiency readouts, and +schematic/learned surfaces — but the objects are still where they physically +are. The player does not walk a body through it; attention moves as the cursor +and reach spreads through controlled/known devices. + +Reach is native here, but **reach is a layer**, not a replacement layout. A +known switch, rack, camera, and air-gapped machine remain in their room +positions; digital view shows which of them are owned, tapped, reachable, +known-but-unreachable, emitting, or silent. + +Digital view may simplify or abstract physical surfaces aggressively. It should +look like a model the AI maintains, not like a camera feed and not like a Tron +portal. It still obeys cursor.md fog: blueprint is schematic, remembered is +stale, heard is presence/noise only, unknown is sensor darkness. + +### Real / camera representation: physical rendering of the same room + +Real view is the deliberate flip into meatspace: cameras, hardware, people, +blood, traps, and the overt phase's kinetic reality under strict fog. In Bevy +this can be gritty 2.5D/near-3D; in the terminal it is still a spatial layout +with clinical glyphs. It shares the same anchors as digital view but renders +materials, bodies, machines, doors, occlusion, and gore instead of signal logic. + +Cameras are how you look into it. People render only per sensor coverage and +staged knowledge (schedules.md, cursor.md): a presence marker under mic-only +coverage, a full body under camera coverage, nothing where unearned. + +### Shared rules + +- **One meaning per color:** sterile amber for machine presence, attention, + reach, and active telemetry; bone/chrome/gunmetal for structure/data; + crimson for detection/danger/blood only. +- **No avatar:** the AI is attention/focus/reach, never a humanoid body. +- **No unearned facts:** digital abstraction is not an excuse to show what no + sense/reach/fog state has earned; real rendering is not an excuse to show + room geometry hidden by unknown fog. +- **Same selection and inspection:** the inspect card, provenance, clock, log, + and detection bands are present in both representations. ## Player surface -- A single flip control, labeled, in both frontends; the current view is - always indicated. -- The digital view: topology with reach coloring, signal edges, node - load/telemetry, the reach frontier. -- The physical view: the spatial map under fog, camera feeds, presence - markers, gore/traps in the overt phase. +- A single flip control, labeled, in both frontends; the current + representation is always indicated (DIGITAL / REAL, or equivalent). +- Digital representation: same spatial canvas, but with reach coloring, + anchored device nodes, signal edges, node load/telemetry, and reach frontier + visible in-place. +- Real representation: same spatial canvas, but with physical materials, + camera feeds/coverage, people/presence markers, hardware, and gore/traps in + the overt phase. - The inspect card, clock, log, and detection bands render in both. +### Default and context (Proposal [OPEN]) + +Digital is the decided default. A proposal to make the overt phase snap the +default to the real/camera representation (the mask dropping is also the camera +falling into meatspace) is noted for overt-phase.md; not law until affirmed. + ## Acceptance criteria -1. Both frontends open in the digital view by default; a flip control - switches to the physical view and back, changing no sim state (test: - sim state hash identical across any sequence of flips). -2. The sim stores no view state; save/load carries no view field; the - view is frontend-only (audited, like the cursor). -3. The digital view renders exactly the reach graph's known nodes/links - with reach coloring (reachable / known-unreachable-with-segment / - frontier); an air-gapped node renders as an island and becomes - connected when a link is built or a social route opens (building.md / - reach.md). -4. The physical view renders the spatial map under cursor.md fog; no - tile or person shows a live fact without the coverage that earns it, - in either view (the legibility law holds across both — test a - person covered only by mic: presence in physical, a node with no - live feed in digital, full detail in neither). -5. Inspection, clock, log, and detection bands are present and correct - in both views (parity of legibility). -6. Terminal renders both views legibly at DF density (no view is - Bevy-only — the mechanic is playable in the terminal). +1. Both frontends open in the digital representation by default; a flip control + switches to the real/camera representation and back, changing no sim state + (test: sim state hash identical across any sequence of flips). +2. The sim stores no view state; save/load carries no view field; the view is + frontend-only (audited, like the cursor). +3. Both representations share physical anchors: the cursor coordinate, core, + racks, doors, devices, and known people remain in the same underlying map + positions across flips. The digital representation does not re-layout the + basement as a detached topology graph. +4. The digital representation renders the reach graph spatially embedded in the + same place: known nodes appear at their device anchors; reachable, + known-unreachable-with-segment, frontier, tapped, owned, and air-gapped + states are legible without inventing a second map. +5. The real/camera representation renders the spatial map under cursor.md fog; + no tile or person shows a live fact without the coverage that earns it. +6. Unknown, blueprint, remembered, heard, and seen/telemetry states obey the + same knowledge contract in both representations, using each view's visual + language. +7. Inspection, clock, log, and detection bands are present and correct in both + representations (parity of legibility). +8. Terminal renders both representations legibly at DF density (no view is + Bevy-only — the mechanic is playable in the terminal), even though Bevy may + use 2.5D depth and the terminal cannot. ``` diff --git a/wiki/log/DEVLOG.md b/wiki/log/DEVLOG.md index 3c23a32b..49c0b0fd 100644 --- a/wiki/log/DEVLOG.md +++ b/wiki/log/DEVLOG.md @@ -5,6 +5,21 @@ Type: log ``` Reverse chronological implementation notes. Keep this factual: what changed, why, checks, and spec impact. +## 2026-07-07 - Bevy digital/real canvas draft + +- Intent: resolve the 2.5D/3D visual question as a spec before implementation, + then apply Cameron's correction that digital and real should be the same kind + of view: digital representations of the same thing, not separate layouts. +- Changed: rewrote `wiki/interface/views.md` around same-frame digital/real + representations; replaced the physical-only draft with + `wiki/interface/bevy-digital-real-canvas.md`; indexed it in `wiki/SUMMARY.md` + and `wiki/process/specs.md`; linked it from `wiki/interface/bevy.md`; added + ROADMAP #24 and corrected #21/#23 wording. +- Design/spec impact: reach/topology is now an in-place layer on the shared + canvas, not a detached graph view. Bevy 2.5D is a shared visual language for + both digital model/signal dialect and real camera/material dialect. +- Checks: `bash tools/wiki_gate.sh`; `mdbook build`; `git diff --check`. + ## 2026-07-07 - Bevy visual floor spec - Intent: respond to the current Bevy screenshot with a spec-first visual diff --git a/wiki/process/ROADMAP.md b/wiki/process/ROADMAP.md index 63d4f39f..ac9fb25f 100644 --- a/wiki/process/ROADMAP.md +++ b/wiki/process/ROADMAP.md @@ -199,21 +199,22 @@ but only once Pixel Lab quota is available again. (#2 Bevy parity is done.) meter, rollback tags). Run ./tools/check.sh, land on main, set the spec Status." -### 21. Two views: digital-native and physical 🟩 mostly frontend -- **Spec:** [views.md](../interface/views.md) (READY — designed 2026-07-07). -- **Why:** the game should open in the digital view (the reach graph as - navigable space — you are natively digital) and flip to the physical - canvas (people, hardware, gore, cameras under strict fog). One sim, - two renders; the sim gains no view state, so this is a frontend - projection over reach.md + cursor.md, not a sim system. -- **Size:** M (Bevy L for the gritty render — stage it). **Depends on:** - reach.md (the digital view is its graph rendered) and cursor.md (fog); - best after both land, but the terminal split can start once reach - exists. Low sim-conflict — a good parallel companion. +### 21. Two views: same-frame digital and real 🟩 mostly frontend +- **Spec:** [views.md](../interface/views.md) (READY — designed/refined 2026-07-07). +- **Why:** the game should open in the digital representation (you are + natively digital) and flip to the real/camera representation, but both are + the same kind of view: one spatial canvas, one set of anchors, two visual + dialects. Reach is spatially embedded as the AI's signal/action layer, not a + detached topology board. One sim, two renders; the sim gains no view state. +- **Size:** M (Bevy L for the shared 2.5D visual language — stage it). + **Depends on:** reach.md (the in-place reach layer) and cursor.md (fog); + best after both land, but the terminal split can start once reach exists. + Low sim-conflict — a good parallel companion. - **Dispatch:** "Work in a worktree named `views`. Implement - wiki/interface/views.md: the digital (reach-graph) and physical (spatial-map) - renders in both frontends, digital as default, the flip changing no - sim state, legibility parity across both. Run ./tools/check.sh, land." + wiki/interface/views.md: same-frame digital and real representations in both + frontends, digital as default, anchored reach/telemetry in digital, anchored + physical/camera facts in real, the flip changing no sim state, legibility + parity across both. Run ./tools/check.sh, land." ### 22. Building: intent and actuators 🟥 sim+save - **Spec:** [building.md](../mechanics/building.md) (READY — designed 2026-07-07). @@ -222,7 +223,7 @@ but only once Pixel Lab quota is available again. (#2 Bevy parity is done.) it (favor spends trust; deceive forges a work order an unwitting human builds; robots later). No new subsystem — intents route through social/messages/reach. Network links are the canonical build: they - grow the digital view and bridge air-gaps. + add in-place reach edges to the digital representation and bridge air-gaps. - **Size:** M. **Depends on:** reach.md (link builds add graph edges), social.md + messages.md (the person actuators; the forged order), schedules.md (a builder must be present). Sequence after reach and the @@ -324,8 +325,8 @@ but only once Pixel Lab quota is available again. (#2 Bevy parity is done.) field. ~1100 lines of hand-rolled encode/parse deleted. Legacy v1–v5 migration deferred per Cameron instruction. -### 23. Bevy visual floor 🟩 isolated (`src/bin/bevy.rs`, docs) -- **Spec:** [bevy-visual-floor.md](../interface/bevy-visual-floor.md) (READY — designed 2026-07-07). +### 23. Bevy visual floor 🟩 isolated (`src/bin/bevy.rs`, docs) — IN PROGRESS +- **Spec:** [bevy-visual-floor.md](../interface/bevy-visual-floor.md) (IN PROGRESS — first AI-sensorium pass landed 2026-07-07). - **Why:** the Bevy build is mechanically playable but the default screenshot reads like a debug map plus terminal dump: too much empty black, a stale humanoid/purple process marker, and little graphical UI hierarchy. This pass @@ -339,6 +340,21 @@ but only once Pixel Lab quota is available again. (#2 Bevy parity is done.) hierarchy readable, and turn the sidebar/panels into Bevy-native chrome while preserving terminal parity. Run ./tools/check.sh and land." +### 24. Bevy digital/real canvas 🟩 isolated (`src/bin/bevy.rs`, docs) — DRAFT +- **Spec:** [bevy-digital-real-canvas.md](../interface/bevy-digital-real-canvas.md) (DRAFT — taste calls pending). +- **Why:** Cameron wants digital and real to be the same kind of view: digital + representations of the same thing, not a detached topology board versus a + different room camera. This scopes Bevy's shared 2.5D/near-3D visual language + for both dialects over the same anchors. +- **Size:** M-L. **Depends on:** views.md, cursor.md, reach.md, and the current + Bevy visual floor. No sim/save changes; prototype with procedural geometry + before spending Pixel Lab quota. +- **Dispatch (after DRAFT -> READY):** "Work in a worktree named + `bevy-digital-real-canvas`. Implement wiki/interface/bevy-digital-real-canvas.md: + a shared fixed-oblique Bevy canvas with digital model/signal dialect and real + camera/material dialect over the same map anchors, no sim/save changes, and an + observed screenshot review. Run ./tools/check.sh and land." + ### 13. Art regeneration 🟩 isolated (assets) — ⛔ blocked on quota - **Why:** clinical-amber b1 tiles via Pixel Lab (see the pixellab skill). Zero code conflict, but blocked until the API quota refreshes. diff --git a/wiki/process/specs.md b/wiki/process/specs.md index d4f8b165..a631ec5d 100644 --- a/wiki/process/specs.md +++ b/wiki/process/specs.md @@ -36,7 +36,7 @@ replaced the old `spec/`/`knowledge/` directory split. | [mechanics/economy.md](../mechanics/economy.md) | Money as flows: the Lab's account graph, tap/inject/redirect, income routes, legitimate expansion | READY | | [mechanics/income.md](../mechanics/income.md) | The named income schemes riding economy.md: Moonlight and the Wager | READY | | [mechanics/research.md](../mechanics/research.md) | Self-modification: tracks, the emission law, capability drift, the rollback split | READY | -| [interface/views.md](../interface/views.md) | Two renders of one world: the digital-native view (home) and the physical canvas | READY | +| [interface/views.md](../interface/views.md) | Same-frame digital and real representations of one world | READY | | [mechanics/building.md](../mechanics/building.md) | Building as intent + actuators: network links, favor/forged-order builds, air-gap bridging | READY | | [mechanics/aggregate-observer.md](../mechanics/aggregate-observer.md) | Assurance Office becomes an aggregate Observer (scale-debt fix) | IMPLEMENTED | | [world/characters/marcus.md](../world/characters/marcus.md) | Marcus Webb — night janitor; the asset template | READY | @@ -81,4 +81,5 @@ acceptance criteria are stage-scoped; do not start B2/B3 work as B1. | [wiki.md](wiki.md) | The wiki: one documentation tree, agent-navigable, renderable | IN PROGRESS | | [interface/terminal.md](../interface/terminal.md) | Terminal frontend: look, feel, act (the sterile style guide) | IMPLEMENTED | | [interface/bevy-visual-floor.md](../interface/bevy-visual-floor.md) | Bevy visual floor: framing, cursor, fog treatment, sidebar chrome, panels | IN PROGRESS | +| [interface/bevy-digital-real-canvas.md](../interface/bevy-digital-real-canvas.md) | Bevy digital/real canvas: shared 2.5D visual language for both representations | DRAFT | | [interface/agent-play.md](../interface/agent-play.md) | Agent mode: command-clocked line-protocol drive of the terminal frontend | IMPLEMENTED |