Diff: BackroomsEngine

The engine is built as a C++20 CMake project. Its main public-facing targets include '''BackroomsMMO''' for the game client, '''BackroomsServer''' for online shards, and '''BackroomsTests''' for automated regression coverage. It also includes tools for model inspection, animation work, mod packaging, replay playback, launch workflows, load testing, and internal game operation.

BackroomsEngine is organised into shared engine libraries, application targets, renderer support, runtime assets, tools, and tests. The shared engine code contains core systems such as world generation, networking, assets, save data, replay capture, audio, chat, AI, modding, configuration, security, and gameplay state.

=== Shared engine code ===

The shared engine code is where systems that need to be reused across the game, server, tools, and tests are kept. This includes world generation, chunk streaming, physics helpers, asset loading, replay data structures, audio mixing, online configuration, and save/runtime state.

Keeping these systems in shared code matters because BackroomsMMO uses the same concepts in several places. A chunk generated by the server, a chunk streamed by the client, and a chunk tested by an automated regression test need to agree on the same basic layout and data rules.

=== Application targets ===

The application layer builds separate programmes for the game client, dedicated server, replay player, launcher, model tools, animation tools, mods tool, admin utilities, message utilities, load testing, and test execution. This keeps development tools close to the runtime while still separating them from the player-facing game.

The result is a project that behaves more like a complete game platform than a single executable. The engine can run the game, host a shard, inspect assets, validate packages, play replays, test runtime systems, and support development workflows from the same source base.

=== Dependencies ===

The engine uses vcpkg-managed dependencies for windowing, logging, serialisation, networking, cryptography, compression, navigation, asset handling, maths, and data-oriented systems. These libraries support the native runtime without forcing every subsystem to be written from scratch.

The dependency choices reflect the engine's needs: realtime networking, structured JSON configuration, binary asset loading, secure account-related flows, navigation data, and native graphics integration.

BackroomsEngine contains a native renderer used by the game runtime and related tools. On Windows, the renderer uses DirectX 12. The rendering code is split into modules so frame lifecycle, scene work, post-processing, UI drawing, and resource state can be managed separately.

=== DirectX 12 renderer ===

The DirectX 12 renderer is responsible for scene rendering, swapchain presentation, GPU resources, shader pipelines, UI resources, post-processing, lighting, shadows, reflections, visual effects, and streamed world geometry. The engine uses a renderer-side frame lifecycle rather than treating drawing as a single black-box call.

That split is important for stability. It lets the engine detect failure at several points in a frame, retire resources safely, rebuild renderer state when required, and keep game state separate from graphics state.

=== Shader loading ===

The renderer loads runtime HLSL shader files for base scene rendering, physically based scene rendering, cascaded shadow maps, visual effects, post-processing, game-post passes, and UI drawing. This gives the project a practical development workflow where shader changes can be staged and tested without turning the renderer into one monolithic file.

Shader loading is also part of the recovery path. After a renderer rebuild, shader resources are brought back as part of normal renderer initialisation rather than requiring the game session to restart.

=== Runtime resources ===

BackroomsEngine has to render large streamed environments, repeated structural chunks, props, doors, lights, player avatars, UI, and effects. Runtime resources therefore include world meshes, static model GPU resources, streamed chunk models, texture descriptors, UI resources, VFX shaders, and post-processing buffers.

The engine tries to reuse stable source tags and texture resources where possible. That is especially important for streamed chunks, because allocating fresh resources for every repeated floor, wall, ceiling, or material would make long sessions unstable.

=== Stability safeguards ===

The renderer can use safer startup settings before heavier features are restored. It can also bypass unsafe post-processing for a few frames, prune stale streamed GPU resources, and use fallback geometry when assets are not ready.

BackroomsEngine supports live renderer recovery for DirectX 12 failures. The feature is designed to keep the current game session alive when the graphics device is lost, reset, hung, or when presenting a frame fails.

=== Device-loss detection ===

The recovery path begins in the DirectX 12 RHI. Common device-loss HRESULT values such as device removed, device reset, and device hung are detected and marked as a lost device.

When this happens, the RHI records the DXGI reason, asks the D3D12 device for GetDeviceRemovedReason, and logs Device Removed Extended Data where available. This gives the engine useful diagnostics without repeatedly calling into a graphics device that has already failed.

=== Frame failure handling ===

The renderer checks for lost-device and stalled-queue states at several points in the frame lifecycle. It can reject a frame before recording work, after BeginFrame, after EndFrame, or after Present.

In those cases RenderFrame returns failure to the game loop instead of continuing to push commands into a broken swapchain. That failure becomes the signal for the game layer to start a clean recovery attempt.

=== Rebuild process ===

During recovery, the game loop resets post-processing state, invalidates temporal caches, and requests a short game-post safety bypass. This stops the next frames from reusing stale TAA, temporal ambient occlusion, ray tracing history, exposure, or heavy post-process state.

The runtime then updates the renderer configuration from the current window size and native window handle, shuts down the renderer, and initialises it again. The rebuild reuses the current runtime configuration, reapplies the optional view-model preview, and reapplies the world asset set from the current game state.

=== Session continuity ===

This is a renderer-side rebuild, not a game-session restart. The player does not need to reload the game, reconnect to the server, or discard the current world state just because the DirectX 12 device had to be recreated.

Once the renderer is back, normal resource warm-up resumes. That includes shader setup, post-processing resources, world assets, static model GPU prewarm, UI resources, VFX shaders, and runtime scene resources.

=== Retry policy ===

The retry policy is conservative. The first few failures can trigger immediate rebuild attempts, but repeated failures are throttled so the game does not spin in a rebuild loop.

After repeated device-loss presents, the runtime disables DXGI tearing and exclusive fullscreen preference for the current session, because those presentation options can make recovery less stable on some drivers. If the rebuilt renderer then completes 120 clean frames, the game marks renderer recovery as stable and clears the recovery-attempt counter.

=== Fallback visibility ===

BackroomsEngine also uses simpler visible fallback paths while renderer resources or streamed assets catch up. The runtime can use placeholder models, fallback chunk materials, generated proxy geometry, and safe post-process bypass frames so the player is not left staring at a blank white window or an empty void while GPU resources are being recreated.

Active-instance loading can fall back to a small unit-cube placeholder model, world geometry can use fallback materials when authored assets are missing, and startup can use a temporary safe renderer profile before heavier lighting, post-processing, shadows, volumetrics, TAA, and DXR features are restored.

=== Deterministic worlds ===

BackroomsEngine uses seeded generation so the same world configuration can produce the same layout. This is useful for testing, server bootstrap, replay consistency, and shared online worlds.

Deterministic generation also helps the engine reason about streamed chunks. The client and server can work with chunk coordinates, floor indices, seeds, and world profiles instead of relying only on hand-authored rooms.

=== Level modules ===

The world generator is organised around level modules. Source review shows module support for Level 0, hotel, poolrooms, factory, mall, island, and dungeon-style spaces.

Each module can define its own style of rooms, chunk rules, templates, props, lighting, surface treatment, and instance content. That lets the engine support different Backrooms spaces without rewriting the whole generator for each level.

=== Rooms, doors and props ===

The generator is built to make streamed chunks line up with neighbouring chunks. Door openings, corridors, stairs, pitfall openings, wall mounts, lights, props, and room boundaries need to match across chunk edges so the world feels continuous rather than randomly stitched together.

World configuration can define floors, walls, ceilings, lights, doors, props, clutter, and loot markers. The engine can use built-in Backrooms assets or project-specific asset tokens, which lets the same generator support different spaces and themes.

=== Spawn safety ===

Spawn handling is treated as a runtime concern rather than a fixed coordinate. The engine includes server and world-profile work around spawn height, safe spawn placement, and starter area generation.

This matters because a generated Backrooms level can contain floors, stairs, doors, pits, props, and collision. A spawn point has to place the player into usable space rather than inside a wall, under a floor, or outside the streamed starter area.

BackroomsEngine streams world chunks around the player. The world streaming system decides which chunks should be visible, which should be simulated, which should be generated next, and which old chunks should be removed.

=== Chunk priority ===

The streaming controller computes priority rings around the player. Chunks near the player are treated differently from chunks that are only useful as visual prefetch.

The config separates render distance, simulation distance, visual prefetch distance, and priority radius. This lets the engine keep nearby space responsive while still preparing likely future movement.

=== Async chunk building ===

Chunk generation and mesh building can be submitted to the job system. This keeps expensive generation work away from the main thread where possible.

Pending results are then committed back into the loaded chunk map. This staged approach helps the engine avoid large stalls when the player changes area, changes floor, or joins an online shard.

=== Commit budgets ===

Committed chunks are limited by per-frame budgets. The streaming controller can cap how many chunks are committed, how much main-thread time is spent, and how many collider installs happen in one update.

This is important because a technically correct chunk can still cause a bad frame if all of its renderer, physics, and scene work is installed at once. The engine favours steady intake over sudden spikes.

=== Eviction and memory control ===

The stream keeps track of loaded chunks, pending jobs, last-touched frames, and loaded revisions. Old chunks can be evicted when they are too far away, too old, or outside a memory target.

Eviction also has to mirror related state. When a chunk leaves the loaded set, renderer resources, navigation data, physics colliders, and debug proxies may also need to be dropped or refreshed.

=== Authoritative chunks ===

The engine supports authoritative streamed chunks. In online play, a shard can provide or correct chunk data for connected clients.

Authoritative chunk upserts let the client accept server-owned world data while still using the same mesh, collider, and stream lifecycle systems. That matters when a shared world cannot be treated as purely local.

=== Physics and renderer mirroring ===

Loaded chunks contain structural mesh data, static colliders, world-space colliders, floor layers, mesh fingerprints, and object fingerprints. These fields help the stream know what needs to be rendered, collided with, or rebuilt.

The stream also supports commit and eviction listeners for systems that mirror chunk lifetime. This is how renderer uploads, navigation caches, and physics state can stay aligned with the world stream.

=== Shard bootstrap ===

The dedicated server can bootstrap an online shard with a configured world, seed, spawn point, server identity, player limits, and gameplay rules. It can run as an unattended service or as an interactive local/private server depending on deployment context.

For a multiplayer Backrooms game, the shard is more than a relay. It owns or checks important state and provides the shared runtime context that players connect to.

=== World metadata and spawn setup ===

The server stores world metadata and can pregenerate a starter area around spawn. This gives new joiners a real world region to enter rather than a blank test coordinate.

Spawn setup also supports safer entry into generated spaces. The engine has specific work around spawn height, remote world bootstrap, and world-profile runtime ranges so the player begins in usable geometry.

=== Heartbeats and live config ===

The dedicated server can report heartbeat status, player counts, world metadata, runtime metrics, authority-worker information, and shard health to the website control layer. It can also receive live config updates and apply safe values without a full restart.

Live config can cover things such as player limits, tick rate, persistence interval, chat limits, movement validation, combat settings, voice runtime state, director settings, and other server-owned rules. This keeps live shards manageable without exposing a public inbound admin endpoint.

=== Private server mode ===

The engine supports private server behaviour distinct from official hosted shards. Private installs can be forced into private mode so they do not present themselves as official public BackroomsMMO shards.

This distinction matters for trust. Official servers can enforce official rules, content policy, and mod restrictions, while private servers can be used for controlled local or community sessions.

=== Linux server builds ===

BackroomsEngine includes Linux dedicated-server support. The server can be built without dragging the full game/editor renderer stack into the build.

Linux support is useful for hosted shards because production-style game servers are often deployed headlessly. The server still needs networking, website verification, heartbeat reporting, and runtime authority even when no local renderer is present.

Networking in BackroomsEngine covers online clients, online servers, network messages, transport, authentication support, content sync, state broadcasts, admin data, and diagnostics.

=== Website authentication ===

The online flow supports website-backed authentication for real MMO accounts. The client can sign in, resume a session, receive character data, and join the selected shard through a staged launch flow.

The dedicated server can verify a connecting session before accepting it into gameplay. This avoids treating the native realtime port as enough proof that a player should be trusted.

=== Join tickets ===

BackroomsEngine supports short-lived join tickets for selected characters and shards. A ticket helps connect the website account layer, selected character, selected shard, and native server login.

The client can refresh join target information before entering gameplay. That helps avoid cases where a stale browser row or bootstrap payload points to the wrong host, port, content library, or shard identity.

=== Shard selection ===

The online menu can load shard information from the website, let the player choose a shard, and carry the selected shard through the launch flow. The native client then uses the resolved shard metadata rather than assuming a local test server.

This staged flow is important because the website knows account state, character state, shard availability, content payloads, and restrictions that the native game should honour.

=== Content synchronisation ===

BackroomsMMO shards can expose content metadata such as an asset manifest and file base. The client can sync required content before handing off to gameplay.

The engine's asset resolver can search the BackroomsMMO content cache so downloaded shard models and assets are available at runtime. This reduces invisible geometry, missing props, and black-screen joins caused by absent local content.

=== Authority corrections ===

The server can own or check important runtime state such as movement, player vitals, inventory, persistence, chat, combat, loot, and streamed world data. Authority messages can correct clients when local state drifts too far from server-approved state.

Movement validation includes limits for position delta, velocity, acceleration, correction thresholds, and authoritative chunk radius. These settings help keep public multiplayer from relying only on client honesty.

=== Packet hardening ===

The networking layer includes hardening against malformed or oversized shard frames. This is important because packet parsing should reject bad data rather than allowing a bad message to crash the client or server.

Runtime diagnostics also track connection state, authentication state, instance assignment, state traffic, byte counts, movement corrections, combat acceptance, chat acceptance, chunk builds, tick timings, and worker activity.

=== Player state ===

Player state includes position, velocity, floor, instance state, selected hotbar slot, flashlight state, health, stamina, sanity, hunger, thirst, shields, armour, and life state. These values are important for movement, survival, replays, networking, and server authority.

The engine also tracks identity and account-related state for online play. This lets the runtime connect a player in the world to the selected MMO character and shard session.

=== Inventory and persistence ===

BackroomsEngine includes inventory, stash, equipment, loot, persistence, and item-stack rules. Server authority can merge, cap, and validate item lists before accepting them into persistent state.

That matters for a live MMO because inventory cannot be treated as a purely local convenience. Loot, stash contents, equipment, and long-term progress need to survive sessions without allowing easy client-side abuse.

=== Chat and social systems ===

The engine includes chat, party, clan, trade, and social systems. Chat can be shard-mediated so clients submit messages to the shard and receive approved broadcasts back.

Social systems support group play and shared identity. In a Backrooms setting, parties, clans, safe rooms, trades, and communication all help turn exploration into a persistent online experience.

=== Combat and vitals ===

Combat and vitals are part of the server-authority surface. The runtime can enforce combat range, cooldowns, damage caps, rate limits, movement correction, and vitals correction.

This gives the server a way to reject impossible or abusive actions while still allowing moment-to-moment gameplay to feel responsive. It also makes combat, stamina, hunger, thirst, sanity, shields, and armour part of the same online state model.

=== Director systems ===

The runtime includes director-style systems for mimic encounters, paranormal events, noclip separation, threat values, cooldowns, intensity, active limits, and sanity damage. These systems help the game create pressure without relying only on static room layouts.

Director behaviour is especially relevant to the Backrooms theme. The world should be procedural and hostile enough to feel unpredictable, but still constrained by runtime rules that can be tested and tuned.

=== Biotic orbs ===

Biotic orbs are represented in gameplay and replay data. The engine tracks orb kind, position, energy, lifetime, healing or damage behaviour, target rules, and per-player active limits.

They are an example of how the engine handles support-oriented mechanics as first-class runtime data rather than as a visual effect only. Their state can be simulated, limited, captured, and replayed.

BackroomsEngine has a custom audio layer called TAudio, plus higher-level audio systems for ambience, emitters, buses, spatial sound, acoustic profiles, voice, and replay capture.

=== TAudio backend ===

TAudio provides playback for WAV, OGG, MP3, and FLAC assets. It consumes engine-agnostic mix items and uses a custom in-engine PCM mixer, bus state, spatial pan and attenuation, and a preload cache.

On Windows the backend can use XAudio2, while Linux server or tool contexts can use available native output paths where relevant. The aim is to keep audio logic under engine control while still using native output.

=== Audio buses ===

The audio system separates sound into buses such as SFX, music, ambience, UI, and voice. Each bus can have volume and mute state, which lets the game treat menu music, world ambience, interface sounds, and player voice differently.

Bus separation is important for both gameplay and settings. A player may want quieter music without losing voice, or muted UI without removing environmental sound.

=== Spatial sound ===

Audio emitters can be spatial. The engine computes attenuation, pan, distance, and source category so a sound can behave differently depending on where the listener is and what kind of sound is playing.

This supports the Backrooms atmosphere. Distant ambience, nearby footsteps, machinery, voice, radio-like sound, and hidden events can all feel different in the mix.

=== Acoustic profiles ===

The acoustic system can apply scene modifiers such as obstruction, muffling, distance, and intelligibility. Voice has its own realism handling because speech clarity matters differently from general ambience or music.

Acoustic profiles let the game make a space feel enclosed, open, blocked, or distorted without needing every sound to be hand-authored for every room.

=== Asset preloading ===

TAudio can queue asset preloads and rebuild its indexed audio roots when newly downloaded shard content becomes available. This means synced content can become playable without forcing the player to restart the game.

Preloading keeps decode work away from gameplay-critical frames where possible. That is useful when a new shard or newly loaded area needs sound assets quickly.

=== Replay capture ===

The audio system can emit replay audio events with tick, time, event id, asset path, bus, position, volume, pitch, pan, spatial state, and loop state. Voice frames can also be captured for replay data.

This makes audio part of the replay rather than a loose side effect. A replay can reconstruct not only player movement, but also important sound and voice timing.

BackroomsEngine includes replay capture and replay playback support. Replays are designed to capture gameplay state, camera data, audio events, voice frames, and selected runtime context.

=== Replay ring ===

The replay ring stores recent gameplay snapshots using a bounded capture window. The default capture behaviour is designed around recent activity rather than unlimited recording.

This is useful for capturing incidents, debugging issues, or saving a recent moment without keeping an unbounded history in memory.

=== Captured state ===

Replay snapshots can include fixed tick, frame timing, floor index, instance id, private-instance state, camera position, camera yaw and pitch, player positions, velocities, vitals, shields, armour, flashlight state, selected hotbar slot, and orb state.

That data gives the replay enough context to reconstruct what happened in the world. It is not just a video capture. It is structured runtime data from the game simulation.

=== Audio and voice frames ===

Replay audio events can record sound event timing, asset path, bus, position, volume, pitch, pan, spatial state, and loop state. Voice frames can include account id, sample rate, channels, gain, pan, echo values, radio state, and payload data.

This lets replay playback include more of the session context. For a multiplayer Backrooms game, where voice and sound can be part of the experience, that matters.

=== Sanitisation ===

Replay data is sanitised before it is stored or written. The replay system clamps invalid ranges, rejects non-finite values, limits capture frequency, limits players and orbs per frame, limits text and metadata length, and bounds audio or voice payload sizes.

Sanitisation protects the replay path from corrupt or unreasonable runtime data. It also makes replay files more predictable for playback and tooling.

=== Replay player ===

The repository includes a replay player target. This separates replay playback from the main game client and gives the project a tool for reviewing captured sessions.

Replay-specific rendering can also be wired differently from live gameplay. Source notes show work around replay-oriented rendering and path-tracing support without making that the normal live-game rendering path.

BackroomsEngine includes asset loading, model inspection, animation tooling, package support, and runtime content-cache integration. These tools help turn the engine into a usable production workflow rather than only a runtime.

=== Asset loading ===

The preferred runtime model format is GLB, with GLTF, OBJ, and FBX used for development or conversion workflows. The asset loader and resolver handle model files, buffers, textures, material data, transforms, and runtime asset paths.

The runtime asset resolver can also search downloaded shard content. That is important for online worlds where the server's content library may not already exist in the player's local base install.

=== Model tooling ===

BackroomsModels is the local model viewer and editor for Backrooms projects. It can import common model formats, preview models in Backrooms-style room templates, show validation warnings, inspect dimensions, inspect animation counts, estimate runtime cost, and help adjust transforms.

It also includes patch tools for filling visible openings and quick fit tools for framing, dropping, and scaling models against BackroomsEngine references. These features support practical content preparation rather than just passive viewing.

=== Quality sets ===

The model tools can export BackroomsEngine quality sets with folders for very low, low, medium, high, and very high model quality. This gives the runtime a structured way to use different asset quality levels.

Quality sets are useful because the game has to handle different hardware, render distances, and streamed scenes. A single maximum-detail asset path is not always the right answer.

=== Texture exports ===

The tools can export model textures into a standalone texture export folder with a manifest, alpha-channel information, and source details redacted where needed. This supports asset review and texture debugging without exposing unnecessary source data.

Texture handling matters for a Backrooms game because repeated walls, ceilings, lights, props, and floors depend heavily on correct material behaviour.

=== Animation tooling ===

The project includes animation tooling and avatar-focused tests. Model inspection can show skinning, node counts, bone influences, animation clips, playback speed, sample rate, root-motion lock, and clip timing.

This supports player avatars, bodyguard characters, animated props, and runtime character presentation. Animation data has to fit both the renderer and the gameplay state model.

=== Shard content cache ===

Online shard content can be downloaded into a BackroomsMMO content cache and resolved by the runtime asset manager. This lets the game use shard-synchronised models instead of falling back to local-only content.

The content cache is part of avoiding invisible geometry and missing assets during online joins. It connects the website bootstrap, content manifest, native client, and runtime asset resolver.

=== `.brmod` packages ===

The `.brmod` format packages mod content for BackroomsEngine. A package can contain a manifest, scripts, assets, and documentation.

The package workflow gives mods a defined shape. That is easier to validate and install than a loose folder of arbitrary files.

=== Manifest format ===

Mod manifests include fields such as id, name, version, author, description, enabled state, dependencies, asset path, native plugin, managed plugin, legacy script fields, and multi-script entries.

Dependencies can be represented as simple identifiers or as objects with version requirements. This gives the modding system enough information to reason about load order and compatibility.

=== Supported content ===

Content-only mods can provide assets such as models, textures, audio, and prefabs. Script mods are also represented in the manifest format.

The engine separates content, scripts, managed plugins, and native plugins because they carry different levels of risk. A replacement texture is not the same security concern as native code.

=== Package safety ===

Mod packages are validated before installation. Absolute paths, path escapes, installers, shell scripts, and undeclared native binaries are rejected.

Installation uses a staging approach so a failed install does not partially overwrite an existing mod. Native binary mods are blocked by default unless explicitly trusted.

=== Private-server support ===

Mods are intended for singleplayer and private servers that allow them. The runtime policy can decide whether script mods, managed mods, native mods, or content mods are allowed in a given context.

This gives private communities room to experiment while preserving the integrity of official online play.

=== Official-server restrictions ===

Official BackroomsMMO servers can ignore and block mods. This is important because public MMO play needs consistent rules, trusted content, and predictable authority.

The distinction between official shards and private servers keeps modding useful without turning public multiplayer into an uncontrolled client-side mod environment.

BackroomsEngine includes a broad regression test tree. The tests reflect how connected the systems are: a change to chunk generation can affect rendering, navigation, physics, doors, saves, online state, and replays.

=== Chunk tests ===

Chunk tests cover core streaming, island runtime behaviour, chunk objects and doors, runtime memory and materials, and chunk rendering regressions. These tests help protect streamed world behaviour from changes that create invisible geometry, bad transforms, or excessive resource churn.

Chunk tests are especially important because world streaming sits between generation, physics, rendering, assets, and online authority.

=== Runtime tests ===

Runtime tests cover acoustics, bodyguard AI, camera/audio/animation interactions, local online performance harnesses, runtime materials, TAudio, and voice systems.

These tests help catch regressions where a system still compiles but no longer behaves correctly during actual gameplay.

=== Network tests ===

Network tests cover admin commands, live MMO smoke paths, and official server identity. They are aimed at the parts of the runtime where account state, server identity, shard behaviour, and remote control can break in ways that are hard to see from a local-only run.

Online game systems need tests because a simple local scene can miss authentication, server authority, shard selection, content sync, and packet handling faults.

=== Audio and voice tests ===

Audio and voice tests cover TAudio behaviour, acoustic systems, runtime audio, and voice-specific paths. These tests are useful because audio is stateful, timing-sensitive, and tied to both gameplay and replay capture.

A Backrooms game relies heavily on sound. Broken voice, muted ambience, missing emitters, or unstable audio preloading can damage the experience even when rendering still works.

=== Gameplay tests ===

Gameplay tests cover alignment and NPC missions, chat, director systems, graphics persistence, instance saves, player inventory, player state, world loot, progression, reputation, and safety tracking.

These tests reflect the MMO side of the engine. They cover long-term systems rather than only immediate movement and rendering.

=== Asset and modding tests ===

Asset tests cover model audits, runtime prop fit, security-room props, stair and replay regressions, avatar import manifests, bodyguard avatars, runtime model usage, and related workflows.

Modding tests cover package validation, installation, profile behaviour, and asset-root discovery. This helps keep mod support useful without weakening package safety.

=== Live MMO smoke tests ===

Live MMO smoke tests check broader online paths that cannot be reduced to a single small unit test. They are useful for catching integration problems around login, shard behaviour, online bootstrap, and runtime state.

Smoke tests do not replace detailed subsystem tests. They make sure the main path still holds together when the subsystems are wired into the MMO flow.

BackroomsEngine is in active development alongside [[BackroomsMMO]]. It has undergone repeated hardening and refactoring work around rendering, world streaming, server authority, online login, client stability, runtime diagnostics, assets, modding, audio, replays, and test coverage.

* [[BackroomsHost]]

* [[Thunder_Panel]]

* [[Cameron_Lobban]]

This page is based on direct review of the BackroomsEngine source tree, including the CMake build, vcpkg dependency manifest, world generation configuration, runtime tools, tests and BackroomsMMO integration files. Public project pages are included below where available.

* Source review: BackroomsEngine CMakeLists.txt and vcpkg.json.

* Source review: BackroomsEngine world generation modules, WorldStream, chunk mesh builder, chunk collider builder, instance generation, physics and runtime-space files.

* Source review: BackroomsEngine DirectX 12 RHI, renderer runtime frame loop, renderer recovery path, shader loading logs and renderer stability documentation.

* Source review: BackroomsEngine OnlineSettings, dedicated server bootstrap/runtime files, server control-panel code and MMO authority documentation.

* Source review: BackroomsEngine TAudio, audio system, acoustic system, replay data structures, replay writer and replay sanitisation files.

* Source review: BackroomsEngine BackroomsModels, BackroomsModsTool, asset resolver, GLTF loader and regression test tree.