Inside the Engine

NullG is built around a clean race-session core. Input is sampled and mapped into participant controls, the race advances at a fixed 60 Hz cadence, and each tick publishes structured state for the rest of the engine. Rendering, audio, HUD, multiplayer, replay, inspection tools, physical feedback, and simulator outputs all read from that shared stream of race data.

This architecture gives NullG a strong product shape: gameplay owns the truth, presentation stays flexible, and tools can inspect the same data that powers real racing.

Simulation-first data flow

GameSession owns participants, race progression, rescue, independent random streams, weapon inventories, projectiles, events, and source-specific movement. Each frame produces an immutable racing snapshot plus ordered semantic events. Rendering can interpolate visuals, audio can place engine and weapon cues, multiplayer can replicate authority, and tools can capture repeatable evidence.

The engine supports multiple movement personalities through explicit physics routes. Exact WipEout preserves source-authentic behavior at the boundaries. XL uses its native movement character. NullG/Jolt systems provide SI-unit movement, combat, collision foundations, and physical telemetry for authored modern handling.

All positions converge into one world-space convention: right-handed, +Y up, -Z forward, and one world unit per metre. Source-specific position data is transformed at load time before gameplay, rendering, audio, tools, and physical feedback consume it.

NullG physics goals

NullG physics is the modern handling layer for the project's original racing identity. It is built around SI units, craft mass, thrust, drag, hover support, wall/floor authority, combat impulses, damage events, boost behavior, and clean motion samples. The goal is a handling model that feels responsive at race speed while producing meaningful physical signals for audio, camera, haptics, replay, and simulator output.

That opens a fun design space: ships can feel different through mass, acceleration, air-brake authority, shield behavior, collision response, and weapon impulse. Race telemetry can describe what the player should hear, see, and feel. The same tick stream can drive a HUD bar, a camera shake, a controller pulse, a speaker cue, or a motion-platform command.

Motion simulator direction

The motion-simulator goal is one of NullG's most distinctive threads. The target experience is a cockpit-style anti-gravity racing pod where the player's body feels the race: pitch under acceleration and braking, roll through corners, heave over elevation changes, surge and sway from impacts, and tactile cues for surface, boost, shields, and collisions.

The engine architecture supports that direction by publishing ordered race frames and motion-friendly physical quantities. A motion output backend can consume the same world-space data used by rendering and audio, keeping the simulator layer connected to real gameplay. Controller feedback, physical telemetry, and simulator hardware all share the same race-event vocabulary, which keeps the feel of the craft consistent from screen to body.

Positional audio direction

Audio in NullG is event-driven and race-aware. Engines, weapons, impacts, warnings, UI sounds, and music come from structured gameplay state. Multiplayer already balances sound by viewport, which is a useful stepping stone toward richer spatial presentation.

The long-term audio goal is a positioned sound field where nearby ships, weapon launches, impacts, track ambience, announcer calls, and cockpit cues all live in a believable space around the driver. In a simulator setup, audio reinforces the same forces the motion platform and displays are communicating.

Multi-display rendering direction

NullG's renderer is organized around isolated view resources, which fits naturally with multi-display ambitions. Split-screen uses per-view cameras, render targets, lighting candidates, post-processing histories, HUDs, and audio placement while sharing the scene extraction that every view needs.

That same shape extends toward simulator displays: a primary forward view, side/peripheral displays for wider awareness, and auxiliary screens for speed, lap data, weapon state, track map, diagnostics, and cockpit controls. The architecture keeps each view explicit so display layouts can grow while the race session remains the single source of truth.

The four-player capture shows the renderer's view isolation in motion: four cameras, four HUDs, independent timing/position data, and one shared race world composed into a single local multiplayer output.

Rendering and scene ownership

Gameplay scenes own presentation objects through an ECS registry, while the authoritative race state stays in the session. The render bridge publishes triple-buffered snapshots so Vulkan work can run cleanly against stable frame data.

The renderer uses modern Vulkan patterns: dynamic rendering, bindless sampled images, GPU-driven draws, depth pre-pass, particles, lighting, shadows, HDR, and post-processing. Track visibility and resource lifetime are coordinated through source-aware asset identities so WipEout, XL, and core UI resources can sit side by side in one coherent engine.

Source-qualified assets

NullG treats asset ownership as a first-class engineering concern. Application-owned core content lives separately from user-imported game content. Core assets power menus, UI icons, controller previews, original fallback music, and the asset acquisition flow. Legacy game sources stay in their own source-qualified paths and retain their provenance.

That separation makes the engine easy to reason about. Game selection can load the correct tracks, ships, sounds, music, and metadata for each source. Multiplayer can fingerprint gameplay-critical content. Packaging can keep core resources clean. Authored NullG content can grow with its own identity.

Custom 3D asset pipeline

NullG also has an original 3D asset pipeline for the engine-owned models that give the menus, controls, and simulator-facing UI their own identity. The workflow combines prompt-driven concept exploration, Meshy model generation, Blender MCP cleanup, technical review, and reproducible promotion scripts.

Blender MCP is especially useful in the refinement stage. It helps inspect model scale, orientation, contour, material choices, naming, bounds, and presentation angles while keeping the work grounded in the runtime asset contract. Models can move from concept to reviewed runtime form with clear provenance, repeatable exports, and practical triangle/texture budgets.

The graphics monitor model shows how original UI props move from visual exploration into engine-owned content. The same workflow supports menu scenery, controller previews, cockpit-adjacent interface pieces, and simulator-facing presentation assets.

The original robot-brain model shows the creative side of the workflow: generated reference, Blender cleanup, centered/normalized export, runtime preview, and promotion into the core asset set. This is the direction for NullG's original visual language: engine-owned models with documented provenance and a consistent path from idea to game-ready asset.

Legacy disc and asset import

The import flow is designed to feel practical and transparent. A user supplies their own game media, NullG detects the edition, reviews the content, extracts the expected files, records hashes and manifests, normalizes runtime paths, and activates the playable generation in the user data library.

For original WipEout PSX media, the importer reads mixed-mode BIN/CUE data, exports native files under the expected source layout, converts CD audio ranges into runtime-readable WAV masters, and keeps source manifests with the activated generation. Runtime then uses the established WipEout adapters for models, textures, tracks, sound banks, cues, and start metadata.

WipEout XL follows its own prepared asset path with track geometry, texture metadata, ship resources, soundtrack handling, and source-specific presentation. The result is a flexible asset pipeline that keeps classic content organized while giving NullG a polished modern engine around it.

How the goals connect

The best part of this architecture is how directly it supports iteration. A gameplay improvement can benefit rendering, audio, replay, multiplayer, physical feedback, and simulator output because they all consume the same authoritative frames. An asset import records provenance once and benefits menus, runtime, review, and compatibility checks. A new visual feature can plug into stable race data instead of reshaping the game loop.

NullG feels like a racing project, but under the hood it is also a careful content, simulation, audio, display, learning, and simulator platform.