V1 / Terminal exploration
One of the first four directions: green terminal graphics and a command-like list of actions.
The version timeline
Every numbered release recorded in the changelog, plus the documented experimental series through 0.11.3.6. Open a version to explore what it introduced, how it improved the engine or game, and why those changes mattered.
Browse all 84 versions
0.1 / Project foundations
-
0.1.0 · Engine + foundations
The first commit
On 17 September 2026, Lowfi Engine began as a repository and a development workflow, before it had a world to render.
Explore the changes and improvements
What changed
- Strict TypeScript and Vite provided a typed application with a development server and hot reload; gl-matrix supplied vector and matrix operations.
- The engine and game lived in separate directories from the start, with import aliases for both. This established the boundary between reusable systems and the example game.
- ESLint, Prettier, editor settings and Git hooks made formatting, type checks and commit conventions part of normal development. Git LFS handled source assets.
Why it mattered
This was the base that later rendering, physics and gameplay could grow on without putting every system into one application file.
-
0.1.1 · Engine + foundations
Tests before the world
The project added executable checks while the engine was still small, rather than waiting for a complete game.
Explore the changes and improvements
What changed
- Vitest introduced repeatable unit tests and a watch mode. Early cases covered gl-matrix basics and the planned weapon time-to-kill calculation.
- GitHub Actions ran linting, formatting, type checks, tests and a build for pushes and pull requests.
- A local check command reproduced the continuous integration pipeline. Pre-commit checks ran tests related to the files being changed.
Why it mattered
An intended rule could now become a test before a visible feature existed. A working demo alone would no longer be the only evidence that a change was correct.
-
0.1.2 · Engine + foundations
A heartbeat and three states
A fixed-step simulation loop and a state machine gave the demo its first runtime structure.
Explore the changes and improvements
What changed
- Simulation advanced at a fixed step while rendering used an interpolation factor between steps. Catch-up work was capped to prevent an overloaded frame from creating endless extra work.
- The state machine declared transitions between menu, playing and paused. State-scoped listeners could be cancelled when leaving a state.
- Rate counters exposed runtime activity, while the demo showed simulation and render frequencies. A favicon gave the page its first small visual identity.
Why it mattered
Separating simulation time from display refresh was foundational for later physics and networking. Menu and pause behaviour also became explicit state transitions.
-
0.1.3 · Engine + foundations
The first automated web releases
The built application gained an automated path to the web after its checks passed.
Explore the changes and improvements
What changed
- Cloudflare Pages deployment was connected to successful continuous integration, with a production address and branch previews.
- The production build was opened in a headless-browser smoke test, checking the packaged application rather than only the source files.
- Cache headers were shipped with the page, and a commit identifier was injected into the build and displayed in the demo.
Why it mattered
A bug report could identify the deployed revision, and the version people opened online could be checked as an actual build.
0.2 / First pixels and experiments
-
0.2.0 · Engine + foundations
The first triangle
The first visible rendering milestone was a coloured triangle rotating in a WebGL2 canvas.
Explore the changes and improvements
What changed
- WebGL2 context creation included a readable explanation when the browser or graphics driver could not provide it.
- The viewport followed the canvas display size and device pixel ratio, with a cap on rendering density and an updated aspect ratio.
- Shader compilation reported readable GLSL errors. The triangle rotated only while playing, with its rendered angle interpolated between simulation steps.
Why it mattered
This joined the earlier loop and state machine to a real graphics pipeline: resizing, shader failures and paused rendering were observable behaviours.
-
0.2.1 · Engine + foundations
A first-person view into 3D
A perspective camera and physical-key input turned the flat triangle demo into a space that could be explored.
Explore the changes and improvements
What changed
- The camera supported yaw and limited pitch. Horizontal movement stayed horizontal even while looking up or down.
- Keyboard state used physical key positions and released held keys when focus was lost. Pointer lock provided mouse-look with filtering for abnormal input jumps.
- The scene contained a grid floor, boxes and the rotating triangle. Losing pointer lock paused the demo instead of letting it keep moving unattended.
Why it mattered
There was now a first-person frame of reference for judging scale, movement and later collision. The earlier triangle remained in the 3D scene rather than disappearing from the project.
-
0.2.2 · Engine + foundations
The project starts telling its story
Development gained a public place for discussion alongside the private code repository.
Explore the changes and improvements
What changed
- A community discussion forum provided a place for questions, feedback and development updates.
- The first devlog introduced the project outside the source tree, creating the beginning of a public development record.
- Forum buttons in the demo menu and pause screen connected the running application to that community.
Why it mattered
This step was about making the project followable and giving feedback a destination. It did not add a new rendering or multiplayer system.
-
0.2.3 · Engine + foundations
Before multiplayer: a network experiment
A disposable test page investigated peer connections before networking was built into the game.
Explore the changes and improvements
What changed
- The prototype compared Trystero torrent and Nostr signalling strategies rather than assuming one would work reliably everywhere.
- It measured connection establishment, ping, throughput, packet loss and the kind of route between peers, and produced a report that could be copied.
- The network experiment used the separate strategy packages, allowing the project to test how peers found each other independently of gameplay.
Why it mattered
The later room system had evidence to work from. A connection on one local network was distinguished from a real route between different networks.
-
0.2.4 · Engine + foundations
Seeing how the demo runs
An on-demand overlay made the runtime inspectable before the renderer grew more complex.
Explore the changes and improvements
What changed
- The overlay displayed frame timing, CPU cost, draw calls, geometry counts, simulation rate, missed frames and graphics hardware information.
- A frame-time graph made occasional slow frames visible rather than hiding them inside an average.
- Frame statistics and a draw-call counter were hooked into the loop. The overlay was loaded only when requested, and the status line updated less frequently.
Why it mattered
Later optimisation work could ask which part of the runtime cost time instead of treating every slowdown as a rendering problem.
0.3 / Rendering
-
0.3.0 · Engine + foundations
A reusable rendering pipeline
The demo moved from one-off drawing code to reusable GPU resources, meshes and shader programs.
Explore the changes and improvements
What changed
- RenderDevice owned the WebGL2 context and tracked resources so they could be recreated after context loss.
- ShaderProgram introduced typed uniform updates and checked declared uniform types when linking programs.
- Mesh and MeshBuilder provided validated geometry and reusable GPU buffers. The demo reused a cube mesh with different transforms and colours.
Why it mattered
Drawing an object became a combination of shared geometry, a shader and object data. Context recovery became a responsibility of the engine instead of a page reload.
-
0.3.1 · Engine + foundations
Textures and linear colour
Textured surfaces replaced the bare grid and established a consistent approach to colour.
Explore the changes and improvements
What changed
- Texture loading gained mipmaps, filtering presets, anisotropy, wrapping and explicit sRGB or linear interpretation.
- Shader includes introduced reusable colour-space functions. Texture colour was decoded before lighting calculations and converted for display afterward.
- A generated metre-grid texture made surface scale and UV orientation visible. Runtime presets let the demo compare filtering choices.
Why it mattered
Texture detail now had a physical scale, and later lighting could operate on linear values rather than multiplying display-encoded colours.
-
0.3.2 · Engine + foundations
Light, materials and tone mapping
The scene gained a lighting model with ambient illumination, sunlight and local lights.
Explore the changes and improvements
What changed
- Hemispherical ambient light distinguished sky and ground contributions. A directional sun and point lights added diffuse and normalised Blinn-Phong specular lighting.
- Point lights had bounded influence and distance attenuation. The engine selected useful lights for the scene and uploaded their data through array uniforms.
- ACES tone mapping handled bright overlapping illumination. A day/night toggle and orbiting coloured lights made the differences visible in the demo.
Why it mattered
The renderer could describe shape through lighting rather than colour alone, while controlling highlights that would otherwise clip to flat white.
-
0.3.3 · Engine + foundations
A sky around the world
A cubemap sky replaced the empty background and connected the scene to a day or night environment.
Explore the changes and improvements
What changed
- Cube textures validated matching square faces, supported mipmaps and sRGB, and participated in GPU resource restoration.
- The sky renderer used camera orientation without camera translation, so looking around changed the view while walking did not move the sky closer.
- Generated day and night skies included clouds, sun, stars and moon. Their conventions were shared with the scripts that produced the images.
Why it mattered
The scene acquired an environment beyond its geometry. Sky imagery and lighting could be compared together instead of feeling like unrelated background and foreground.
-
0.3.4 · Engine + foundations
Sun shadows
Directional shadow mapping added the first explicit relationship between occluding geometry and light.
Explore the changes and improvements
What changed
- A depth pass from the sun supplied a shadow map, sampled through hardware comparison and a PCF filtering kernel.
- The shadow region followed the camera and aligned to texels to reduce visible movement in the shadow pattern.
- Slope bias and normal offsets addressed self-shadowing artefacts. Shadow resources were recreated after context loss, and the demo exposed a shadow toggle.
Why it mattered
Objects could cast shadows on other surfaces, improving contact and scale. The implementation also established the shadow pass used by later scene and animation features.
0.4 / Scenes and assets
-
0.4.0 · Engine + foundations
Objects become a scene graph
A hierarchy of scene nodes replaced an unstructured set of object transforms.
Explore the changes and improvements
What changed
- Nodes combined translation, quaternion rotation and scale, and inherited their world transform from a parent.
- Dirty tracking recalculated only affected branches. Traversal, searching, visibility, reparenting and cycle prevention made the hierarchy usable as an engine system.
- The demo used nested pivots and arms to animate objects at several levels, showing local and inherited motion together.
Why it mattered
Complex objects could be assembled from parts and moved as a unit. This was the structural base for imported models, articulated characters and map content.
-
0.4.2 · Engine + foundations
Models arrive through glTF
A custom glTF loader connected Blender-produced assets to the browser renderer.
Explore the changes and improvements
What changed
- The parser handled glTF and GLB containers, scene nodes, buffers, vertex attributes, materials, textures and several accessor layouts.
- GPU geometry was uploaded once and could be instantiated into separate scene hierarchies. Asset failures identified the file involved.
- A scripted Blender streetlamp exercised hierarchy, mirrored nodes, materials and different normal styles. Asset budgets became executable checks.
Why it mattered
The engine could consume authored content instead of building every visible object as a procedural cube.
-
0.4.3 · Engine + foundations
Do not draw what cannot be seen
Frustum culling used object bounds to avoid submitting geometry outside the useful view.
Explore the changes and improvements
What changed
- Meshes gained CPU-side axis-aligned bounds, transformed conservatively into world space, including negative scales.
- Frustum planes came from the view-projection matrix. Point and box tests determined whether an object could contribute to the image.
- The main and shadow passes used different relevant volumes: an off-camera object could still cast an on-camera shadow.
Why it mattered
Visibility became a decision made before sending geometry to the GPU, without incorrectly discarding shadow casters.
-
0.4.4 · Engine + foundations
Shared materials and fewer state changes
The renderer began organising work by shared appearance rather than repeating material setup for every object.
Explore the changes and improvements
What changed
- Materials carried colour, textures, specular response, emission, face settings and UV behaviour, with an identity suitable for sorting.
- MeshRenderer sorted visible draws by material. Object transforms still changed per draw, while repeated material state could be sent once.
- Uniform, texture-binding and face-state caches avoided redundant WebGL calls. Counters exposed the effect rather than only the final frame rate.
Why it mattered
This reduced repeated CPU-side setup while retaining the same scene. It complemented culling: one removes unnecessary draws, the other makes required draws less repetitive.
0.5 / Physics
-
0.5.0 · Engine + foundations
Rapier gives the world a physical counterpart
The engine gained a fixed-step WebAssembly physics world with bodies, colliders and queries.
Explore the changes and improvements
What changed
- Rapier was loaded on demand. Dynamic, fixed and kinematic bodies supported primitive colliders, triangle meshes and ray tests.
- Body operations included velocity, impulses, forces, teleporting and kinematic targets. Rendering interpolated body poses between physics steps.
- Static collision meshes could be generated from the same geometry that was drawn. The demo became a sandbox with throwable and falling cubes.
Why it mattered
Visible scenery could now stop or move physical objects, and the later character controller had a world to query.
-
0.5.1 · Engine + foundations
The camera gains a colliding body
A kinematic capsule controller turned free-flying camera movement into grounded movement through obstacles.
Explore the changes and improvements
What changed
- A swept capsule computed allowed displacement each fixed step. It handled gravity, jumping, floor contact and wall contact.
- Autostep, ground snapping and optional wall sliding addressed common cases when moving through level geometry.
- The demo could switch between walking and flying, with the camera following an interpolated capsule when walking.
Why it mattered
A player could be tested against the physical space instead of moving an eye point through walls.
-
0.5.2 · Engine + foundations
Walking slopes instead of hovering above them
Ground movement gained explicit rules for inclines, steep surfaces and contact recovery.
Explore the changes and improvements
What changed
- Desired movement was projected onto the ground plane to maintain sensible speed when climbing or descending.
- The controller exposed slope and ground-normal information, combining contact detection with a downward query where appropriate.
- Steep surfaces stopped counting as walkable ground: falling speed accumulated along them and jumping was refused.
Why it mattered
The difference between a staircase, a ramp and a slideable slope became a physical rule rather than an accidental camera motion.
0.6 / Engine systems
-
0.6.0 · Engine + foundations
Actions replace hard-coded keys
Input moved behind an action map, separating what the game asks for from which physical key performs it.
Explore the changes and improvements
What changed
- Actions could have several bindings, and configuration validation recovered individual bad entries rather than rejecting all controls.
- Defaults, shipped configuration, saved rebindings and URL overrides formed distinct layers. Sensitivity, inverted look and raw mouse input were configurable.
- Displayed instructions came from active bindings. One action dispatcher replaced separate hard-coded toggle handlers.
Why it mattered
Controls could be changed without rewriting movement and UI code, and the interface could describe the controls the player actually used.
-
0.6.1 · Engine + foundations
Sound enters the scene
A reusable audio system connected the listener and positional sounds to the world.
Explore the changes and improvements
What changed
- Audio unlocked after a user gesture, with master volume, mute and a listener following the camera.
- Positional playback used distance attenuation and panning. The engine could both load sound files and synthesise tones and noise.
- The demo gained a sound beacon, distance-based footsteps and impacts when throwing cubes. Its status explained why audio might be silent.
Why it mattered
Position could be communicated through hearing as well as graphics. Browser autoplay restrictions became a handled state rather than an unexplained failure.
-
0.6.2 · Engine + foundations
Debug tools, a temporary menu and parkour
The demo gained tools for understanding the world and a first dedicated movement course.
Explore the changes and improvements
What changed
- Wireframe, collider and culling views made three different descriptions of the same scene inspectable.
- An in-game console supported commands such as teleporting, changing maps and rebinding actions, with history and completion.
- A temporary Demo / Parkour / Forum menu exposed the new content. Platform spacing came from movement formulas rather than unrelated hand-tuned distances.
Why it mattered
The project could investigate collision and navigation problems in the running application, and movement had a practical course to test.
-
0.6.3 · Engine + foundations
Skeletal animation and GPU skinning
Animated glTF models gained a complete path from sampled clips to deformed geometry and shadows.
Explore the changes and improvements
What changed
- Skin joints, weights and inverse bind matrices were loaded with translation, rotation and scale animation channels.
- Clip sampling supported several interpolation modes, while playback exposed looping, speed, reverse playback and scrubbing.
- GPU skinning had a corresponding shadow variant, so an animated body cast an animated shadow. The parkour course also expanded into a longer timed route.
Why it mattered
Animation became an engine capability that game characters and viewmodels could share.
-
0.6.4 · Engine + foundations
Particles without an object per particle
A bounded particle system introduced smoke, sparks and the reusable effects needed for later combat.
Explore the changes and improvements
What changed
- A pool stored particle properties in preallocated typed arrays. Removing a particle reused its slot instead of building a new chain of objects.
- Emitters supported continuous rates, bursts, cones, drag, gravity and changes of size and colour over a particle lifetime.
- Instanced camera-facing quads rendered each effect, with depth testing and optional additive blending. A full pool refused new particles and counted the refusals.
Why it mattered
Effects gained a predictable memory and rendering structure. They could be reused later for muzzle flashes and impacts without inventing another system.
-
0.6.5 · Engine + foundations
A hardware checkpoint
The project added a repeatable scene and measurement controls for discussing its hardware demands.
Explore the changes and improvements
What changed
- Render scaling separated the displayed canvas size from the resolution actually drawn, making resolution a measurable quality lever.
- A fixed benchmark scene combined geometry, lights, shadows, particles and physics bodies rather than testing an empty frame.
- GPU timing was separated from CPU loop timing, and the browser check exercised combinations of rendering and throttling settings.
Why it mattered
Performance work had a defined workload and a way to distinguish a CPU limit from a GPU limit.
-
0.6.6 · Engine + foundations
Optimisation checked against the image
Rendering work was reduced where the recorded benchmark showed a benefit, with image comparison as a guard.
Explore the changes and improvements
What changed
- Point-light selection moved to individual objects so surfaces did not evaluate distant lights that could not affect them.
- Some colour conversion work moved from fragment to vertex processing where this preserved the intended output.
- Texture filtering remained a quality lever. A depth prepass was implemented as an experiment but left disabled when it made the measured scene slower.
Why it mattered
Optimisation was treated as a comparison with a control, including the possibility that a plausible optimisation should not ship enabled.
-
0.6.7 · Engine + foundations
Loading before the first hitch
Preloading and quality presets moved expensive first-use work away from active play.
Explore the changes and improvements
What changed
- A preloader ran named tasks with weighted progress, per-task timing and independent failure handling.
- Warm-up drew representative pipelines and advanced physics while loading, so their first-use setup did not fall into the first ordinary frame.
- Minimal, Standard and High presets combined measured controls such as resolution, shadows, particles, filtering and light limits. The loop could discard elapsed loading time instead of catching it all up.
Why it mattered
The loading screen became part of runtime preparation, rather than a label that disappeared before expensive work actually began.
Archived engine test scene associated with the second devlog; the exact screenshot build was not recorded. Open original resolution 0.7 / First-person combat
-
0.7.0 · Game + engine
Arcade movement becomes a game system
Running, sprinting, crouching, sliding and mantling established the playable movement layer above the capsule controller.
Explore the changes and improvements
What changed
- Acceleration, friction and air control supplied distinct movement rules rather than moving the camera at a constant speed.
- Crouching and sliding changed the player state, while mantling handled a reachable ledge as a deliberate action.
- A greybox course and browser-driven key sequences exercised the same movement that a player would use.
Why it mattered
The engine supplied physical collision; the game now supplied the feel and rules for traversing it.
-
0.7.1 · Game + engine
The first weapons and a real shooting range
Two weapons turned movement through the greybox into an FPS combat prototype.
Explore the changes and improvements
What changed
- The initial rifle and sidearm had fixed recoil patterns, ammunition, reloading, automatic or semi-automatic fire and deterministic spread.
- Hitscan originated at the eyes: the shot used the aim direction before recoil moved the view. Weapon cadence advanced from scheduled fire times rather than drifting with frames.
- Practice targets measured time-to-kill inside the game. Mouse buttons became bindable actions, and the page displayed aim and weapon state.
Why it mattered
Weapon rules could be exercised against targets rather than existing only as numbers in a design table.
-
0.7.2 · Game + engine
Damage, death and respawning
Combat gained a player life cycle and a shared interpretation of hits.
Explore the changes and improvements
What changed
- Damage zones distinguished head and body using the position of the hit on the target body, including a crouched target.
- PlayerLife controlled health, death and respawn, disabling movement and attacks while dead.
- Map bounds gave leaving the world the same death-and-return path as being shot. The shooting range used player-shaped target regions.
Why it mattered
Death was no longer just a number reaching zero; the prototype could return a player to play consistently.
-
0.7.3 · Game + engine
Combat becomes readable
Crosshair behaviour, hit confirmation, effects and sound began explaining what each shot did.
Explore the changes and improvements
What changed
- Crosshair spacing represented the actual projected spread cone, while recoil affected a different part of the reticle.
- Body, head and kill feedback used distinct hit markers. Tracers, muzzle flashes and impact effects reused the particle system.
- Combat sounds distinguished weapons and hit outcomes. Sliding was revised from play feedback to be easier to trigger and clearer to see.
Why it mattered
The player gained visual and audible evidence of accuracy and damage instead of having to infer everything from the target disappearing.
-
0.7.4 · Game + engine
An animated weapon in the player’s hands
A first-person viewmodel tied weapon state to visible motion.
Explore the changes and improvements
What changed
- Procedural weapon parts formed the on-screen model, with a magazine that moved during reload.
- Idle, aim, reload and additive fire clips used the existing animation sampler. Clip blending began from the displayed pose, allowing a transition to be interrupted safely.
- Aiming moved the weapon into position while narrowing the camera view. Pause gained an explicit screen with resume and return-to-menu actions.
Why it mattered
Handling an action acquired a visible duration and state: a reload or an aiming transition could be understood from the weapon itself.
Archived range image associated with the third devlog; it illustrates the period rather than every change in this release. Open original resolution -
0.7.5 · Game + engine
Tactical audio and distinct weapon silhouettes
Sound began conveying movement choices and obstruction, while each weapon gained its own pose.
Explore the changes and improvements
What changed
- Footstep audibility depended on movement style, using an attenuation rule that actually reached silence at its intended range.
- Walls reduced volume and removed high frequencies through an occlusion query and low-pass filtering.
- The sidearm gained a separate shape and aiming pose. Tracers and muzzle flashes followed the animated muzzle of the held weapon rather than the screen centre.
Why it mattered
Players could reason about what others might hear, and shots visibly belonged to the weapon being carried.
0.8 / Multiplayer
-
0.8.0 · Game + engine
Peers can find a room
The networking experiment became a usable connection flow between game clients.
Explore the changes and improvements
What changed
- Short room codes and invitation links let one browser find another through Trystero signalling.
- A protocol version was separated from the application version, so cosmetic patches did not automatically make peers incompatible.
- The lobby reported connection progress and failure, offered retry, and established one host identity for the session.
Why it mattered
The game gained a front door for multiplayer and a clear place to reject incompatible messages before gameplay saw them.
-
0.8.1 · Game + engine
The host simulates the shared world
Connected browsers could see players moving through a world whose results were computed by the host.
Explore the changes and improvements
What changed
- Guests sent inputs, while the host moved their physical capsules through the same movement system as its own player.
- A shared binary schema described encoding and decoding. Messages had explicit directions and did not let clients dictate health or match results.
- Remote avatars initially used box bodies matching the player dimensions, allowing the existing damage zones to apply.
Why it mattered
The authority boundary became concrete: a client requested an action, and the host decided the resulting state.
-
0.8.2 · Game + engine
Move now, reconcile afterward
Client prediction reduced the delay between a guest pressing a movement key and seeing movement.
Explore the changes and improvements
What changed
- The guest simulated its own unacknowledged inputs immediately, then reconciled them with the authoritative result.
- Inputs were retained per fixed step and sent in batches, so the host could reproduce their order rather than only receiving a recent direction.
- A configurable artificial delay made local browser tests resemble a delayed connection.
Why it mattered
Responsive local control no longer required waiting for a round trip, while the host remained responsible for the accepted result.
-
0.8.3 · Game + engine
Smooth the other players
Remote entities gained buffered interpolation instead of jumping directly between incoming states.
Explore the changes and improvements
What changed
- Position and orientation were sampled slightly behind the newest network state, allowing intermediate render frames to show continuous motion.
- Limited extrapolation bridged a late packet before stopping rather than inventing motion indefinitely.
- Angles interpolated along the shorter rotation. Discrete states such as alive, dead or crouched stayed discrete.
Why it mattered
Prediction helped the local player; interpolation addressed the different problem of drawing everyone else between network ticks.
-
0.8.4 · Game + engine
Disconnections and background tabs
The session could react to departures and continue simulation when the host’s browser lost the foreground.
Explore the changes and improvements
What changed
- A deterministic host election used the remaining participants rather than depending on a final transfer message from a departing host.
- Notices explained player departure, host replacement and the end of an empty match.
- An Away state muted local sound without pausing everyone else. A background-clock mechanism addressed browsers suspending animation callbacks in hidden tabs.
Why it mattered
Losing focus or closing a tab became an explicit multiplayer event instead of an unexplained frozen scene.
-
0.8.5 · Game + engine
Resolve the shot the shooter saw
Lag compensation connected authoritative hit detection to the delayed scene visible to the shooter.
Explore the changes and improvements
What changed
- The host retained a short history of player poses and rewound the target state for a shot.
- Health, death and respawn remained host decisions for both the guest and the hosting player.
- The host measured network timing and limited how far history could be used, rather than accepting a client’s claimed hit as a result.
Why it mattered
A player could aim at the target on their screen rather than guessing where the host had already moved it.
-
0.8.6 · Game + engine
A single validation gate
Incoming network messages gained a central boundary for validation and rate limits.
Explore the changes and improvements
What changed
- The gate checked known message types, sender permissions, size and replay rules before game code received a decoded value.
- Token buckets limited each peer and message type without the burst loophole of fixed time windows.
- Typed violation reasons and a bounded log made rejected traffic inspectable. A scripted hostile client and seeded fuzzer exercised the real gate.
Why it mattered
Future network defences could be added at one boundary instead of being scattered across handlers.
0.9 / Maps and match flow
-
0.9.0 · Game + engine
A complete Team Deathmatch
The first structured multiplayer mode and Quartier gris turned the combat prototype into a match that could be played to completion.
Explore the changes and improvements
What changed
- Team Deathmatch tracked team kills, a score limit, a time limit and respawns as rules separate from weapons and physics.
- The host assigned arriving players to the smaller team. Blue and orange whole-body colours made allegiance visible on the actual opponent.
- Quartier gris introduced a street arena with routes and team spawns. Both clients received the same match-end result from the host.
Why it mattered
Combat acquired a goal, opposing sides and an ending. The same mode interface could later support other rules.
-
0.9.1 · Game + engine
A combat HUD and the start of localisation
The interface began presenting combat state as something readable while aiming.
Explore the changes and improvements
What changed
- Health and ammunition used bars with supporting numbers, making changes visible without requiring every value to be read.
- A bounded killfeed displayed recent eliminations and team context. A smoothed ping indicator reported connection timing.
- An English dictionary and text lookup function moved interface wording out of markup. Missing translations displayed their key instead of silently producing blank space.
Why it mattered
The HUD became both a player-facing system and the first foundation for later localisation.
-
0.9.2 · Game + engine
Ligne de crête, the first outdoor alternative
A longer arena introduced a ridge, side routes and a different distance profile from the street map.
Explore the changes and improvements
What changed
- The initial layout contrasted exposed longer sightlines with crossing routes and positions at different heights.
- Shared map-building helpers let a map use its own coordinates and be placed in the world independently.
- Common map tests covered every playable map. The welcome message named a map using a short string rather than an index that would change whenever content was added.
Why it mattered
Adding an arena became a content operation instead of automatically changing the network protocol’s map list.
-
0.9.3 · Game + engine
Entrepôt, a close-range arena
The third map deliberately focused combat inside a compact warehouse.
Explore the changes and improvements
What changed
- A single interior full of shelving created close corners instead of the ridge’s long sightlines.
- Starting positions were distributed around the edge, making direction and nearby cover central to opening engagements.
- Skylights admitted sunlight into the warehouse aisles, giving the initial interior its lighting.
Why it mattered
The map set gained a close-range counterpoint to the existing outdoor layouts.
-
0.9.4 · Game + engine
Voie ferrée, a long narrow battlefield
The fourth layout explored combat along a linear rail yard.
Explore the changes and improvements
What changed
- Teams started at opposite ends of an elongated arena, with platforms dividing the overall length into sections.
- Two flanks offered different exposure rather than making the full map one uninterrupted firing lane.
- Wagons broke the longest sightline, while passages between them required crouching and made the rail side different from the slower, more obstructed platform route.
Why it mattered
The four-map set now covered streets, terrain, a dense interior and a narrow longitudinal arena.
-
0.9.5 · Game + engine
A lobby that can carry two matches
Profiles, readiness and a persistent room connected separate matches into a multiplayer session.
Explore the changes and improvements
What changed
- Player names had explicit allowed characters and length rules, and a default identity let someone try the game before answering a profile prompt.
- The lobby and results view shared one room: players could see teams, mark readiness and continue without leaving the session.
- Map rotation, invitation links and a rejoin action supported consecutive matches. Profile and roster messages were sent when their data changed, not in every simulation snapshot.
Why it mattered
The session became more than a single match followed by a dead end.
-
0.9.6 · Game + engine
A lightweight killcam
The game could show the moments before a death from the killer’s side.
Explore the changes and improvements
What changed
- The replay used recent network states already received by clients, avoiding a separate match-recording protocol.
- Playback ran within the respawn interval rather than adding another waiting period afterward. Players could skip it.
- The reconstruction showed where participants were and looked, while acknowledging that state snapshots did not contain exact weapon animation or aim between ticks.
Why it mattered
A death could explain the opponent’s position without requiring a full replay infrastructure.
-
0.9.7 · Game + engine
Keep a clip locally
The browser gained an optional rolling capture of recent canvas output.
Explore the changes and improvements
What changed
- MediaRecorder captured the canvas into a local ring of recent video chunks.
- The first capture action started recording; later actions saved a clip without stopping the ring.
- The video stayed on the player’s machine. The feature was opt-in because capturing and encoding the canvas was real work.
Why it mattered
A player could save a moment for review or sharing without a game-owned upload service.
-
0.9.8 · Game + engine
One loaded map, with its own light
Maps became independent scenes rather than accumulating together in the same runtime world.
Explore the changes and improvements
What changed
- Changing maps removed the old scene’s meshes and collision bodies. Sandbox objects disappeared when a match arena was active.
- Each map carried its own sky, sunlight, ambient light and lamps.
- The warehouse became a night interior lit by suspended lights, replacing the temporary reliance on daylight through roof openings.
Why it mattered
Content could set its own atmosphere, and a new map stopped paying for invisible objects from every previous arena.
-
0.9.9 · Game + engine
Quartier gris becomes a modelled place
The street arena became the first full map produced through the Blender-to-glTF pipeline.
Explore the changes and improvements
What changed
- A code plan was exported for Blender, which generated a textured arena consumed by the engine loader.
- Three connected routes combined sheltered market spaces, a central square and a higher walkway. Named places made the environment easier to describe.
- Collision came from the drawn mesh, with the plan retained as the reference for dimensions and route intent.
Why it mattered
The asset pipeline was demonstrated on an arena, rather than only on an isolated prop.
-
0.9.10 · Game + engine
Ligne de crête becomes terrain
The ridge arena moved from stacked shapes to a sampled heightfield landscape.
Explore the changes and improvements
What changed
- A rocky ridge, sunken paths and farms created a genuine exposure-versus-travel-time choice.
- The plan, Blender geometry and collider shared the same triangle layout rather than comparing a smooth mathematical surface to a different triangulated floor.
- An evening sky and aligned sunlight gave the ridge its own atmosphere. The map-generation scripts were generalised to accept different map names.
Why it mattered
The terrain’s routes began behaving differently in play, not merely looking different.
-
0.9.11 · Game + engine
Entrepôt becomes a lit interior
The warehouse received an authored model with repeated shelving and an inspected lighting setup.
Explore the changes and improvements
What changed
- Shelving bays reused shared glTF geometry through separate nodes, reducing duplicated mesh storage.
- A CPU light probe mirrored the renderer’s lighting calculations to inspect player visibility around the floor.
- The room gained its own indirect-colour approximation and hanging lighting, while preserving the close-range layout.
Why it mattered
The engine demonstrated asset reuse and indoor content while exposing the difference between a lit surface and a clearly distinguishable opponent.
-
0.9.11.1 · Game + engine
More coherent buildings and weapon handling
World presentation and first-person handling evolved together, with clearer architecture and more expressive weapon motion.
Explore the changes and improvements
What changed
- Quartier gris was reorganised into more coherent buildings while retaining its route plan.
- Weapons gained distinct parts and animations for magazines, moving actions, empty reloads, drawing and pulling back from a wall.
- A barrel-clearance query prevented a weapon embedded in geometry from firing. The host independently refused a client that bypassed the local check.
Why it mattered
The update responded to what was actually visible and awkward in play, rather than only to numerical map specifications.
-
0.9.12 · Game + engine
Voie ferrée becomes a dawn rail yard
The fourth arena completed the first modelled map set.
Explore the changes and improvements
What changed
- Rails, wagons, platforms, halls and covered crossings defined two flanks with different sightlines.
- Repeated rail and wagon geometry shared storage through instances. The update distinguished memory reuse from a reduction in draw calls.
- A cold dawn sky and a revised retaining wall created the rail yard’s lighting and horizon.
Why it mattered
The linear layout became a readable location, with repeated content and map-specific light.
-
0.9.13 · Game + engine
Consistent arrivals and map transitions
Multiplayer placement gained a shared flow for arriving, respawning and following the host to a different map.
Explore the changes and improvements
What changed
- Guests followed the host’s map selection and loaded the destination world as part of the session transition.
- Player placement occurred after the destination geometry was available, with the correct spawn and camera position.
- Prediction history was reset across a relocation, keeping ongoing movement aligned with the new world.
Why it mattered
The same room could move between arenas while keeping its participants together and placing each player in the active world.
0.10 / Modes and the front end
-
0.10.0 · Game + engine
Zone Control
A second ruleset rewarded occupying space rather than only eliminating opponents.
Explore the changes and improvements
What changed
- Teams captured points progressively, held them for score and contested them through their physical presence.
- The host decided point ownership and capture progress; guests supplied inputs rather than claiming capture results.
- Mode identity and compact point state were added to the network format, allowing the lobby and HUD to describe the same match.
Why it mattered
The mode interface from Team Deathmatch supported another objective without replacing weapons, physics or transport.
-
0.10.1 · Game + engine
Kill Confirmed
Eliminations created an opportunity to score rather than granting the point immediately.
Explore the changes and improvements
What changed
- A defeated player left a tag: the opposing team could confirm it for score, while the victim’s team could deny it.
- The host placed tags on actual ground and controlled their lifetime and collection.
- Snapshots carried tags and denial counters. Announcements followed state changes, avoiding duplicate messages when state packets were missed.
Why it mattered
Movement after a fight became part of the scoring decision: securing or denying the tag mattered as much as the shot.
-
0.10.2 · Game + engine
Free-for-all
A solo deathmatch ruleset removed teams and introduced an individual match result.
Explore the changes and improvements
What changed
- Players could explicitly have no team, making opponent identification meaningful without assigning everyone an artificial side.
- The mode tracked kills and deaths per player and produced a deterministic individual ranking.
- Spawn selection considered exposure to living enemies and could use a collision-probed pool of positions rather than only team endpoints.
Why it mattered
The game supported an individual match structure while retaining the same shared simulation.
-
0.10.3 · Game + engine
Host-run stand-in players
Bots filled sessions using the same input and movement paths as human peers.
Explore the changes and improvements
What changed
- The host filled requested player slots with bots and removed a bot when a human needed the place.
- Bot decisions received visible and audible perceptions instead of unrestricted access to every opponent. The host rechecked line of sight when firing.
- A collision-probed lattice and A* supplied routes; mode objectives selected fights, capture points or visible tags. Difficulty changed reaction, aim and turn behaviour.
Why it mattered
A single person could exercise the real multiplayer rules with opponents, while a bot remained subject to the game’s action boundary.
-
0.10.3.1 · Game + engine
The V8 menu becomes the game’s front door
The temporary menu was replaced by the poster direction developed through the earlier visual studies.
Explore the changes and improvements
What changed
- Large Host and Join tiles led to room creation, rejoining and code entry. Smaller actions handled the player name and community forum.
- A screen state machine connected menu, loading, room, play and results. Static illustrated backgrounds avoided running a 3D match behind the front end.
- The developer drawer and debug controls became explicit options. The game still used the temporary GAME TITLE label while the engine appeared as a credit.
Why it mattered
The application gained a deliberate route into a match and a visual identity across its surrounding screens.
-
0.10.4 · Game + engine
Water is both a surface and a rule
The ridge gained water whose effects were shared by movement, weapons, sound and bots.
Explore the changes and improvements
What changed
- Map plans described water volumes separately from solid geometry. Shallow wading and deeper swimming had distinct movement rules.
- Swimming stowed the weapon, added underwater visual and audio treatment, and supported exits through banks or reachable ledges.
- Water affected bullet travel, footstep audibility and bot route cost. A lightweight rendering pass animated the surface with sky reflection and depth tint.
Why it mattered
Water could no longer be a picture that the simulation ignored.
-
0.11 / Nexus and experimental development
-
0.11.0 · Game + engine
The arsenal grows, and the game is named Nexus
The example game received its own name while completing the first broader set of weapon roles.
Explore the changes and improvements
What changed
- An SMG, shotgun and scoped precision weapon joined the rifle and sidearm, with separate handling, models and intended engagement ranges.
- Damage falloff, pellet distribution, scope behaviour and loadout choices became shared rules between the range and the host.
- Nexus replaced GAME TITLE in the game interface. Lowfi Engine stayed the engine’s name, displayed separately.
Why it mattered
The game’s identity and combat choices became distinct from the technology it demonstrated.
-
0.11.0.1 · Game + engine
A revolver, a knife and a clearer in-match menu
Loadout selection and weapon switching became more visible and consistent.
Explore the changes and improvements
What changed
- A revolver joined the primary choices, and a short-range knife could replace the sidearm.
- Primary and secondary selections appeared as separate controls in the room and Escape menu. Wheel and keyboard actions switched between them.
- Bots used the broader arsenal according to its firing and distance behaviour. Loadout changes during play waited for the next life instead of granting fresh ammunition immediately.
Why it mattered
Choosing equipment became an explicit interface action without turning a menu visit into a combat reset.
-
0.11.1 · Game + engine
Grenades and tactical feedback
Combat gained physical thrown equipment and a more coherent HUD.
Explore the changes and improvements
What changed
- Frag grenades bounced in the host’s physics world; smoke obstructed aimed sight and bot vision; flash effects depended on whether the viewer could see the burst.
- Health, ammunition, loadout and equipment were regrouped, with match state above the fight.
- Connection failures distinguished unreachable peers, unavailable signalling and stale pages, rather than waiting without a useful explanation.
Why it mattered
Equipment introduced decisions about cover and visibility, while the interface made its state understandable.
-
0.11.1.1 · Game + engine
World-aware spawn placement
Spawn placement became a shared world-aware system, locating suitable ground and checking the space a player needs.
Explore the changes and improvements
What changed
- The map’s spawn coordinate became a starting suggestion: a world query located the floor and checked room for the player capsule.
- The host, guests and subsequent respawns used the same placement logic.
- Free-for-all candidates that could not hold a body were excluded, and team spawn orientation faced into the arena.
Why it mattered
Arrivals and respawns used the physical world itself to place the player, across the host, guests and supported maps.
-
0.11.1.2 · Game + engine
Other players become people in motion
Multiplayer presentation gained articulated figures and shared weapon effects.
Explore the changes and improvements
What changed
- Remote figures gained equipment, crouching, a gait driven by travelled ground distance and a two-handed hold on the actual weapon.
- Every remote shot carried visible and positional sound feedback, including missed shots. Deaths fell to the ground instead of leaving a standing body.
- Play now with bots started a session immediately. Respawns moved beyond fixed team endpoints, equipment used cooldowns, and bots reacted to gunfire and raised objectives.
Why it mattered
A match conveyed what other participants were doing instead of drawing only moving damage boxes.
-
0.11.1.3 · Game + engine
Clearer team information and elevated objectives
Team identity and bot objectives became clearer across the match interface and the playable space.
Explore the changes and improvements
What changed
- Team colours carried consistently through scores, room lists, collected tags and the killfeed.
- Bots gained paths and objective handling for raised capture positions, including the ridge bridge and other elevated platforms.
- Join notices were positioned above the room panel, keeping the roster and its text readable.
Why it mattered
Players could read team context across screens, while bots could participate in objectives located above the main floor.
-
0.11.1.4 · Game + engine
A match that survives the room flow
The release added an in-match scoreboard and explicit rules for what happens when a host leaves.
Explore the changes and improvements
What changed
- Holding Tab showed players, teams, kills, deaths, ratio, ping, bots and the match context.
- A host option chose whether another player could continue the session after the original host departed.
- Normal play offered completed maps and kept developer controls behind the debug path.
Why it mattered
The player-facing game flow became clearer, and host replacement became an intentional session policy.
-
0.11.1.5 · Game + engine
Experimental builds identify themselves
A clear build channel and match-start countdown separated testing from normal release play.
Explore the changes and improvements
What changed
- A synchronised countdown held movement, shooting and throwing until the match actually began.
- Experimental builds displayed a persistent identifying banner and distinct menu treatment. Work-in-progress maps were explicitly labelled experimental.
- A debug report could export a readable session record with performance samples and events. Completed maps’ obsolete box versions were retired.
Why it mattered
Players could recognise a test build and start together, while debugging gained a shareable session artefact.
-
0.11.2 · Game + engine
Visible equipment variants and separate web identities
Weapons gained authored models and trade-off-based variants, while engine and game addresses were separated.
Explore the changes and improvements
What changed
- Optics, magazines and stocks changed handling through host-approved selections applied between lives.
- Blender models, textures and visible attachments brought those choices into first- and third-person presentation.
- Nexus used its own public and experimental sites; the former shared address became the Lowfi Engine showcase. Weapon designations and nicknames were updated.
Why it mattered
The game and engine could be presented independently, and loadout choices became visible equipment rather than only statistics.
-
0.11.2.1 · Game + engine
A stable release assembled through seven betas
This release combined a richer armoury, loadout UI development and improved connection choices; its Monastère layout remained experimental.
Explore the changes and improvements
What changed
- Monastère introduced an experimental courtyard-and-crypt box plan. The burst rifle Cadence and delayed-shot sidearm Crater broadened the weapon set.
- Loadout selection gained a main-menu entry, 3D weapon previews, readable trade-offs and separate primary/sidearm tabs.
- MQTT replaced torrent as the alternate signalling strategy. Room-code copying, adjustable reticle size and damage-scaled hit feedback improved everyday use.
- Successive betas refined weapon models, smoke, grenade drawing and balance; replay showed the historical positions of the world rather than a past camera aimed at the present.
Why it mattered
The release brought weapon choices, equipment presentation and connection options together through successive improvements.
-
0.11.2.2 · Experimental development
Serre’s water routes and movement-focused weapons
The experimental series added a greenhouse layout and weapons with distinct movement trade-offs.
Explore the changes and improvements
What changed
- The Serre box plan centred on a deep basin with swim, wade and dry routes, plus raised capture positions.
- Hover rewarded airborne and sliding play with an inverse spread rule, while Swarm was a rapid sidearm that strongly punished firing on the move.
- Attachments offered explicit capacity, sight or handling trade-offs rather than a strictly better upgrade.
Why it mattered
The new arena reused water as a route decision, while the weapons asked players to choose different movement habits.
-
0.11.2.3 · Experimental development
See through glass, fight around it
Labyrinthe introduced an experimental data-centre layout and a difference between sight and physical passage.
Explore the changes and improvements
What changed
- Server rows and perpendicular corridors surrounded a core behind bullet-resistant glass, with separate offices and cooling areas.
- The glass allowed vision and flashes while blocking players, bullets and grenades. Bots could see through it without treating it as an open route.
- Spike introduced visible travelling projectiles that could be dodged, while Scrap added a compact two-barrel sidearm with a spread attack.
Why it mattered
A material could have different answers for visibility, collision and weapons, and combat gained an alternative to immediate hitscan.
-
0.11.2.4 · Experimental development
Grue puts navigation on several floors
A dry dock and crane arena stressed movement, bots and weapon handling at different heights.
Explore the changes and improvements
What changed
- The box layout combined a dock floor, a quay and high crane structures connected by stairs, narrow passages and suspended containers.
- Surge added a held charge after an initial shot. Outlaw added a lever action, per-round reload and limited penetration through marked thin cover.
- Bot navigation retained several floors at the same horizontal position, checked support near edges and kept objective heights meaningful.
Why it mattered
The arena exposed assumptions that worked on mostly flat maps but failed on stairs and raised control points.
-
0.11.2.5 · Experimental development
Nuit Blanche, ground fog and suppression
The experimental game gained a foggy night arena and weapons built around control or sustained fire.
Explore the changes and improvements
What changed
- Height-dependent fog affected scenery, sky, water and glass. Bot visibility used the same loss of transmission rather than seeing freely through the fog.
- Nuit Blanche’s box plan placed a clear viaduct over a fog-filled park lit by sodium-style lamps.
- Snare slowed a target instead of killing it, while Bastion increased its firing rate during sustained fire. Both gained models and attachment choices.
Why it mattered
Visibility and movement control became active parts of combat, instead of cosmetic filters applied only to the player’s image.
-
0.11.3 · Experimental development
Gun Game
A new free-for-all mode made progression depend on changing weapons during a life.
Explore the changes and improvements
What changed
- Each kill advanced the player through a weapon cycle, with the host granting the new loaded weapon immediately.
- A completed cycle ended the match; the HUD showed the current stage and leader progress, and bots advanced through the same rules.
- Gun Game used its own respawn and replay policy, while a loadout selected during the match waited for another mode.
Why it mattered
The broader arsenal became the structure of a match rather than a choice made only before spawning.
-
0.11.3.1 · Experimental development
Nexus V9 across menus and HUD
The interface was rebuilt as one experimental visual system instead of a set of unrelated screens.
Explore the changes and improvements
What changed
- Condensed self-hosted type, dark surfaces, cut corners and team accents connected menu, hosting, joining, loadout, room, loading and results.
- Real map stills replaced most illustrated backgrounds. Keyboard navigation followed the command stack, and equipment selection kept its own scrolling column.
- The HUD grouped health, ammunition and grenade icons, with team scores and clearer objective states. Escape, Tab, killcam and countdown received the same design language.
Why it mattered
The game acquired a coherent interface family, while existing game rules and network behaviour remained outside the redesign’s intended scope.
-
0.11.3.2 · Experimental development
Monastère becomes stone, timber and winter light
The experimental monastery moved from a box plan to a modelled environment.
Explore the changes and improvements
What changed
- Blender-built geometry introduced pale stone, frosted paving, columns, tombs and timber while retaining the layout’s dimensions and objectives.
- A winter-noon mountain sky placed a low sun over the courtyard and left colder shade around the cloister.
- The crypt relied on its own candle lighting rather than borrowing an outdoor illumination pattern.
Why it mattered
The plan became a recognisable place without deliberately changing its movement and capture structure.
-
0.11.3.3 · Experimental development
Serre becomes an abandoned greenhouse
The water-centred layout gained materials and an overhead structure that explained its light.
Explore the changes and improvements
What changed
- Concrete, mossy tile, pool mosaic and timber terraces gave the ground surfaces distinct identities.
- Reeds, hedges and beds preserved the blocking volumes used by the layout rather than adding foliage that silently changed sightlines.
- The broken greenhouse frame stood above the playable space, casting late-afternoon stripes without closing the routes below.
Why it mattered
The model carried the original basin and route decisions into a more specific environment.
-
0.11.3.4 · Experimental development
Labyrinthe becomes a data centre
The earlier server-maze plan received a modelled material and structural treatment.
Explore the changes and improvements
What changed
- Perforated raised floors, acoustic walls, server racks, indicators and cooling units made the interior readable as a data centre.
- The central bullet-resistant glass retained its sight-versus-shot behaviour, now framed by visible metalwork without deliberately narrowing doors.
- The experimental batch added a night-vision visor for this arena, using a rechargeable battery and an explicit HUD state.
Why it mattered
The visual environment became more descriptive while the existing glass and route rules remained the basis of play.
-
0.11.3.5 · Experimental development
Grue becomes a working-scale dockyard
The multi-level box arena acquired its dock, crane and container identity.
Explore the changes and improvements
What changed
- Tide-stained concrete, yellow crane surfaces, galvanised stairs, rusted containers and timber supports replaced the plan’s generic blocks.
- The model preserved the arena’s three movement levels, stair routes and elevated capture objectives.
- Marked thin panels retained their penetrable-cover role rather than becoming visually similar but mechanically different scenery.
Why it mattered
The map’s material language and structures could explain the same vertical decisions already present in the prototype.
-
0.11.3.6 · Experimental development
The current experimental snapshot
Nuit Blanche’s model and a further set of play-feedback changes completed the recorded development series.
Explore the changes and improvements
What changed
- The viaduct and park gained asphalt, paving, concrete, wrecks, kiosks and hedges while retaining the fog and the bots’ corresponding sight rules.
- A battery-limited thermal visor joined the night arena, showing warm bodies through fog as a local visual tool.
- Gun Game moved to a shuffled progression with two sidearm stages and a final knife kill. The non-lethal Snare was excluded from the kill cycle.
- The menu exposed more of its map background; joining codes used fixed-width characters, and death/respawn feedback followed the player’s team colour.
Why it mattered
The latest snapshot combined five modelled arenas with refinements to the interface and game modes informed by play feedback.
Menu V1 to V9
The route from a temporary menu to the Nexus interface. V1–V8 are design iterations around the 0.10.3.1 menu project, not engine release numbers. The archive includes alternative concepts; a study is not proof that a design shipped.
Before the visual studies
Version 0.6.2 used a temporary menu with Demo, Parkour and Forum buttons. The following studies came later. V8 became the reference for the real 0.10.3.1 menu; V9 shows a subsequent experimental game interface.
V2 / The tile hub
The selected F direction gave hosting a large tile, with joining and secondary actions beside it.
V3 / Refining the hub
A further iteration of the F tile direction, before the visual exploration moved to illustrated scenes.
V4 / A poster behind the interface
The poster concept put cut-corner panels over low-poly dusk artwork. Hub and cinematic alternatives were explored alongside it.
V5 / Continuing the poster direction
The poster layout continued through another archived visual iteration.
V6 / Beyond the opening screen
The archive also includes join, pause, results and developer screens, extending the design across different states.
V7 / Several worlds behind the menu
Multiple background variants explored how the same controls could sit over different environments.
V8 / The basis of the shipped redesign
The approved poster study became the implementation reference for 0.10.3.1. The picture still shows the prototype's temporary GAME TITLE label.
V9 / Nexus, with a shared UI language
An archived capture of the real game UI after the V9 implementation. This is the 0.11.3.1-era interface family, still evolving in experimental development.
Reading the archive
The images are genuine archived screenshots, resized for this page. Prototype titles and controls remain as they were. Exact capture builds were not recorded for every image, so the illustrations are not presented as pixel-exact snapshots of a particular release.
Older images sometimes call the game “Lowfi Engine” or “GAME TITLE”. The game received the name Nexus in 0.11.0. Lowfi Engine remains the engine it runs on.