Diff: BackroomsEngine

== Purpose ==

== Purpose ==

The purpose of BackroomsEngine is to provide a custom native runtime for BackroomsMMO. A general web application cannot render the game, simulate realtime movement, process audio, stream world chunks, or maintain low-latency multiplayer state. Those responsibilities belong to the engine.

The purpose of BackroomsEngine is to provide a custom native runtime for BackroomsMMO. A general web application cannot render the game, simulate realtime movement, process audio, stream world chunks, or maintain low-latency multiplayer state. Those responsibilities belong to the engine.

The engine gives the project control over the exact shape of the game. It can define how Backrooms spaces are generated, how players move, how worlds are streamed, how server authority works, how replays are recorded, how voice behaves, and how tools fit the project's workflow.

The engine gives the project control over the exact shape of the game. It can define how Backrooms spaces are generated, how players move, how worlds are streamed, how server authority works, how replays are recorded, how voice behaves, and how tools fit the project's workflow.

Because BackroomsMMO is an online game, the engine also has to work with a website and account platform. The engine does not exist in isolation. It is built to talk to the BackroomsMMO web layer for login, character selection, server discovery, session verification, replay support, and online state.

Because BackroomsMMO is an online game, the engine also has to work with a website and account platform. The engine does not exist in isolation. It is built to talk to the BackroomsMMO web layer for login, character selection, server discovery, session verification, replay support, and online state.

== Architecture ==

== Architecture ==

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.

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 ===

=== 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.

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.

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 ===

=== Application targets ===

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.

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 ===

=== 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 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.

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.

== Rendering ==

== Rendering ==

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.

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 ===

=== 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.

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.

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 ===

=== 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.

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.

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 ===

=== 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.

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.

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 ===

=== 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.

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.

== Live Renderer Recovery ==

== Live Renderer Recovery ==

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.

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 ===

=== 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.

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.

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 ===

=== 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.

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.

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 ===

=== 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.

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.

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 ===

=== 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.

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.

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 ===

=== 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.

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.

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 ===

=== 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.

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.

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.

== World Generation ==

== World Generation ==

World generation is one of the central systems in BackroomsEngine. The engine supports deterministic chunk-based generation, world seeds, floors, chunk sizes, render distances, simulation distances, instance doors, edge doors, corridors, loot spots, props, biomes, and templates for world assets.

World generation is one of the central systems in BackroomsEngine. The engine supports deterministic chunk-based generation, world seeds, floors, chunk sizes, render distances, simulation distances, instance doors, edge doors, corridors, loot spots, props, biomes, and templates for world assets.

=== Deterministic worlds ===

=== 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.

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.

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 ===

=== Level modules ===

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.

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 ===

=== 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.

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.

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 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.

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.

== World Streaming ==

== World Streaming ==

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.

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 ===

=== 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 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.

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 ===

=== 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.

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.

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 ===

=== 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.

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.

=== Eviction and memory control ===

=== 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.

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.

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 ===

=== Authoritative chunks ===

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

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

=== Physics and renderer mirroring ===

=== 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.

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.

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.

== Dedicated Server Runtime ==

== Dedicated Server Runtime ==

BackroomsEngine includes the '''BackroomsServer''' dedicated server. The server accepts clients, verifies online sessions, manages player state, tracks connected players, runs server authority, reports runtime status, and sends world or gameplay updates to clients.

BackroomsEngine includes the '''BackroomsServer''' dedicated server. The server accepts clients, verifies online sessions, manages player state, tracks connected players, runs server authority, reports runtime status, and sends world or gameplay updates to clients.

=== Shard bootstrap ===

=== 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.

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.

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 ===

=== 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.

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.

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 ===

=== 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.

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.

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 ===

=== 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.

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.

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 ===

=== 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.

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.

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 ==

== Networking ==

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

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

=== Website authentication ===

=== 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 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.

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 ===

=== 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.

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.

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 ===

=== 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.

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.

=== Content synchronisation ===

=== 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.

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.

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 ===

=== 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.

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.

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 ===

=== Packet hardening ===

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.

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.

== Gameplay Systems ==

== Gameplay Systems ==

BackroomsEngine contains a wide range of gameplay systems used by BackroomsMMO. The game state includes players, identities, world configuration, dungeon and instance data, ambience, director state, progression, missions, reputation, alignment, stashes, challenges, safe rooms, respawn anchors, clans, explored map data, searched loot, chalk marks, blood traces, investigation evidence, waypoints, chat, and safety tracking.

BackroomsEngine contains a wide range of gameplay systems used by BackroomsMMO. The game state includes players, identities, world configuration, dungeon and instance data, ambience, director state, progression, missions, reputation, alignment, stashes, challenges, safe rooms, respawn anchors, clans, explored map data, searched loot, chalk marks, blood traces, investigation evidence, waypoints, chat, and safety tracking.

=== Player state ===

=== 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.

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.

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 ===

=== 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.

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.

=== Chat and social systems ===

=== 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.

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.

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 ===

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.

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.

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 ===

=== 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.

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.

=== Biotic orbs ===

=== 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.

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.

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.

== Audio and Voice ==

== Audio and Voice ==

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.

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 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.

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.

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 ===

=== 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.

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.

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 ===

=== 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.

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.

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 ===

=== 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.

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.

=== Asset preloading ===

=== 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.

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.

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 ===

=== 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.

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.

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.

== Replays ==

== Replays ==

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.

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 ===

=== 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.

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.

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

=== Captured state ===

=== 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.

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.

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 ===

=== 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.

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.

=== Sanitisation ===

=== 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.

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.

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

=== Replay player ===

=== 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.

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.

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.

== Assets and Tools ==

== Assets and Tools ==

=== Asset loading ===

=== 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 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.

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 ===

=== 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.

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.

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 ===

=== 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.

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.

=== Texture exports ===

=== 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.

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.

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

=== Animation tooling ===

=== 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.

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.

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 ===

=== 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.

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.

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.

== Modding ==

== Modding ==

BackroomsEngine includes modding support through a `.brmod` package format and a BackroomsModsTool executable. The tool can create, validate, pack, install, enable, disable, list, and self-test mod packages.

BackroomsEngine includes modding support through a `.brmod` package format and a BackroomsModsTool executable. The tool can create, validate, pack, install, enable, disable, list, and self-test mod packages.

=== `.brmod` packages ===

=== `.brmod` packages ===

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

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.

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

=== Manifest format ===

=== 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.

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.

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 ===

=== Supported content ===

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

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.

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 ===

=== Package safety ===

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

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.

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 ===

=== 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.

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.

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

=== Official-server restrictions ===

=== Official-server restrictions ===

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

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

== RealBot System ==

== RealBot System ==

BackroomsEngine includes a RealBot test system for exercising BackroomsMMO as if the game were being played by real users. The bots connect from outside the shard process, log in through BackroomsMMO.com using dedicated bot accounts, request join tickets, connect to the selected shard, and then play through normal runtime systems.

BackroomsEngine includes a RealBot test system for exercising BackroomsMMO as if the game were being played by real users. The bots connect from outside the shard process, log in through BackroomsMMO.com using dedicated bot accounts, request join tickets, connect to the selected shard, and then play through normal runtime systems.

RealBots are different from simple unit tests. A unit test can check one function or subsystem in isolation. A RealBot run checks whether the website, account flow, shard login, networking, movement, world streaming, gameplay commands, voice, persistence, and monitoring still work together under live conditions.

RealBots are different from simple unit tests. A unit test can check one function or subsystem in isolation. A RealBot run checks whether the website, account flow, shard login, networking, movement, world streaming, gameplay commands, voice, persistence, and monitoring still work together under live conditions.

=== External player simulation ===

=== External player simulation ===

RealBots connect like external clients rather than being injected directly into the server process. This means they go through the same broad path as a player: website login, character/session preparation, join-ticket handling, native shard connection, server authentication, authoritative spawn, and normal gameplay traffic.

RealBots connect like external clients rather than being injected directly into the server process. This means they go through the same broad path as a player: website login, character/session preparation, join-ticket handling, native shard connection, server authentication, authoritative spawn, and normal gameplay traffic.

=== Bot roles ===

=== Bot roles ===

Those roles are used to spread coverage across the game. A builder does not behave like a scout, and a looter does not behave like a medic. This makes a RealBot run closer to a mixed live session than a crowd of identical clients walking in the same direction.

Those roles are used to spread coverage across the game. A builder does not behave like a scout, and a looter does not behave like a medic. This makes a RealBot run closer to a mixed live session than a crowd of identical clients walking in the same direction.

=== Player personalities ===

=== Player personalities ===

RealBots also have personality profiles. The source includes slower, cautious, social, accessibility-limited, casual, completionist, roleplay, support, looter, speedrunner, route-leader, and high-skill style profiles.

RealBots also have personality profiles. The source includes slower, cautious, social, accessibility-limited, casual, completionist, roleplay, support, looter, speedrunner, route-leader, and high-skill style profiles.

The personality system changes movement speed, sprint bias, look rate, action timing, pauses, scanning cadence, retargeting, and hesitation. This helps the bots create more realistic traffic than a perfectly regular scripted loop.

The personality system changes movement speed, sprint bias, look rate, action timing, pauses, scanning cadence, retargeting, and hesitation. This helps the bots create more realistic traffic than a perfectly regular scripted loop.

=== Movement and navigation ===

=== Movement and navigation ===

RealBots use deterministic navigation data and local world knowledge to choose walk targets, route towards loot, inspect doors, move through rooms, and handle stairs or streamed chunks. They can spread across floors, levels, instances, and topology modes such as clustered or split groups.

RealBots use deterministic navigation data and local world knowledge to choose walk targets, route towards loot, inspect doors, move through rooms, and handle stairs or streamed chunks. They can spread across floors, levels, instances, and topology modes such as clustered or split groups.

Movement testing is not just about sending position packets. The bots test whether the world they see is walkable, whether streamed chunks contain usable tiles, whether route steps can be found, whether doors and stairs can be reached, and whether server authority accepts the resulting movement.

Movement testing is not just about sending position packets. The bots test whether the world they see is walkable, whether streamed chunks contain usable tiles, whether route steps can be found, whether doors and stairs can be reached, and whether server authority accepts the resulting movement.

=== Doors, instances and travel ===

=== Doors, instances and travel ===

RealBots exercise door and instance travel flows. They track travel requests, travel responses, acknowledgements, rejected travel, cooldown responses, route failures, stale doors, natural locked-door flows, synthetic harness doors, child instance doors, and authority floor mismatches.

RealBots exercise door and instance travel flows. They track travel requests, travel responses, acknowledgements, rejected travel, cooldown responses, route failures, stale doors, natural locked-door flows, synthetic harness doors, child instance doors, and authority floor mismatches.

This gives coverage for one of the most fragile parts of a Backrooms MMO: moving between spaces without losing the player, desynchronising floor state, breaking streamed geometry, or leaving a client in the wrong instance.

This gives coverage for one of the most fragile parts of a Backrooms MMO: moving between spaces without losing the player, desynchronising floor state, breaking streamed geometry, or leaving a client in the wrong instance.

=== Loot and inventory ===

=== Loot and inventory ===

RealBots can route to loot, send loot requests, receive loot responses, inspect inventory, use consumables, equip and unequip gear, perform full equipment cycles, drop low-priority items, multi-drop items, and verify authority echoes.

RealBots can route to loot, send loot requests, receive loot responses, inspect inventory, use consumables, equip and unequip gear, perform full equipment cycles, drop low-priority items, multi-drop items, and verify authority echoes.

=== Safe rooms and buildables ===

=== Safe rooms and buildables ===

Safe-room builder bots collect or receive materials, build storage, use storage commands, leave the safe room, go on loot excursions, return through doors, consume food and drink after returning, and track safe-room journey completion.

Safe-room builder bots collect or receive materials, build storage, use storage commands, leave the safe room, go on loot excursions, return through doors, consume food and drink after returning, and track safe-room journey completion.

This tests safe rooms as a gameplay loop rather than a static feature. The RealBot path can cover buildables, storage, return travel, looting outside the room, and whether the safe room still works as a recovery point after other systems have changed.

This tests safe rooms as a gameplay loop rather than a static feature. The RealBot path can cover buildables, storage, return travel, looting outside the room, and whether the safe room still works as a recovery point after other systems have changed.

=== Team and social flows ===

=== Team and social flows ===

RealBot runs can exercise social behaviours, squads, trade supply flows, clan or group-related commands, challenge lobbies, party-style movement, and support roles. Some bot personalities are specifically designed to stay near others, guide routes, revive, trade, or organise group activity.

RealBot runs can exercise social behaviours, squads, trade supply flows, clan or group-related commands, challenge lobbies, party-style movement, and support roles. Some bot personalities are specifically designed to stay near others, guide routes, revive, trade, or organise group activity.

=== Voice traffic ===

=== Voice traffic ===

RealBots can generate voice traffic and track voice packets and broadcasts. This lets a run cover the voice transport path while movement, doors, looting, and online authority are also active.

RealBots can generate voice traffic and track voice packets and broadcasts. This lets a run cover the voice transport path while movement, doors, looting, and online authority are also active.

Voice testing in a live-style run is valuable because voice is timing-sensitive and shares the same session context as movement and gameplay. A voice system can pass small local tests while still exposing problems under multiplayer load.

Voice testing in a live-style run is valuable because voice is timing-sensitive and shares the same session context as movement and gameplay. A voice system can pass small local tests while still exposing problems under multiplayer load.

=== Death, respawn and revival ===

=== Death, respawn and revival ===

RealBots can exercise damage, downed-state recovery, respawn commands, revive-start commands, revive-complete commands, and related support behaviour. The sample output tracks respawn commands, respawn success, revive start, and revive completion.

RealBots can exercise damage, downed-state recovery, respawn commands, revive-start commands, revive-complete commands, and related support behaviour. The sample output tracks respawn commands, respawn success, revive start, and revive completion.

This tests whether failure and recovery states work under live multiplayer conditions. The engine has to handle the player's state change, server authority, chat or command handling, movement reset, and continued session state afterwards.

This tests whether failure and recovery states work under live multiplayer conditions. The engine has to handle the player's state change, server authority, chat or command handling, movement reset, and continued session state afterwards.

=== Challenge and private-server probes ===

=== Challenge and private-server probes ===

Real account runs can test website-backed challenge lobby flows and private server hosting flows. The probe paths can create or join challenge lobbies, start official challenge sessions, simulate challenge completion, rent private servers, add members, update private server settings, request private join tickets, and probe export behaviour.

Real account runs can test website-backed challenge lobby flows and private server hosting flows. The probe paths can create or join challenge lobbies, start official challenge sessions, simulate challenge completion, rent private servers, add members, update private server settings, request private join tickets, and probe export behaviour.

These tests cover the boundary between the native engine and the BackroomsMMO.com account/control layer. They are deliberately broader than a shard-only load test because many failures happen at the edge between website state and native runtime state.

These tests cover the boundary between the native engine and the BackroomsMMO.com account/control layer. They are deliberately broader than a shard-only load test because many failures happen at the edge between website state and native runtime state.

=== Coins and private-server progression ===

=== Coins and private-server progression ===

RealBots can test a full official-to-private progression path. In this flow they join official servers, find and collect coins through normal gameplay, wait for the account economy state to update, and then spend those coins through the website-backed private-server flow.

RealBots can test a full official-to-private progression path. In this flow they join official servers, find and collect coins through normal gameplay, wait for the account economy state to update, and then spend those coins through the website-backed private-server flow.

After the private server has been bought or rented, the bots request private join tickets and move from the official shard into their own private server. This gives coverage for coin collection, balance updates, purchase or rental handling, private-server provisioning, member access, private shard readiness, and transfer behaviour.

After the private server has been bought or rented, the bots request private join tickets and move from the official shard into their own private server. This gives coverage for coin collection, balance updates, purchase or rental handling, private-server provisioning, member access, private shard readiness, and transfer behaviour.

=== Replay and media probes ===

=== Replay and media probes ===

RealBot runs can capture private replays, upload private replay data, wait for remote players, embed scene chunks, use rendezvous behaviour, exercise theatre-camera style replay capture, and probe replay export or deletion flows.

RealBot runs can capture private replays, upload private replay data, wait for remote players, embed scene chunks, use rendezvous behaviour, exercise theatre-camera style replay capture, and probe replay export or deletion flows.

Replay testing benefits from RealBots because a useful replay needs actual session context: players moving, voice frames, audio events, streamed chunks, state snapshots, and multiplayer timing.

Replay testing benefits from RealBots because a useful replay needs actual session context: players moving, voice frames, audio events, streamed chunks, state snapshots, and multiplayer timing.

=== Dashboard and metrics ===

=== Dashboard and metrics ===

The RealBot dashboard reads run samples and server status data so a test run can be watched while it is active. It tracks node state, target clients, connected clients, authenticated clients, rejected clients, visible players, loot counts, travel counts, safe-room builders, build attempts, trade commands, challenge activity, private-server activity, respawn results, malformed frames, CPU, memory, thread counts, network throughput, disk activity, and warnings.

The RealBot dashboard reads run samples and server status data so a test run can be watched while it is active. It tracks node state, target clients, connected clients, authenticated clients, rejected clients, visible players, loot counts, travel counts, safe-room builders, build attempts, trade commands, challenge activity, private-server activity, respawn results, malformed frames, CPU, memory, thread counts, network throughput, disk activity, and warnings.

The sample output is JSONL, which makes it suitable for both dashboards and later analysis. This gives the project a way to spot regressions in live-style behaviour rather than waiting for a user to describe the failure manually.

The sample output is JSONL, which makes it suitable for both dashboards and later analysis. This gives the project a way to spot regressions in live-style behaviour rather than waiting for a user to describe the failure manually.

=== Distributed load runs ===

=== Distributed load runs ===

RealBot runs can be distributed across several nodes and a local desktop client. The run script stages private load-test tooling, starts bot clients, collects samples, monitors shard health, and writes summaries for later review.

RealBot runs can be distributed across several nodes and a local desktop client. The run script stages private load-test tooling, starts bot clients, collects samples, monitors shard health, and writes summaries for later review.

== Testing ==

== Testing ==

BackroomsEngine includes a broad regression test tree alongside the RealBot live-style test system. The regression tests protect specific systems, while RealBot runs check whether the website, shard, client-facing protocol, gameplay loops, voice, replay, and monitoring paths still work together. The tests reflect how connected the systems are: a change to chunk generation can affect rendering, navigation, physics, doors, saves, online state, and replays.

BackroomsEngine includes a broad regression test tree alongside the RealBot live-style test system. The regression tests protect specific systems, while RealBot runs check whether the website, shard, client-facing protocol, gameplay loops, voice, replay, and monitoring paths still work together. 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 ===

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 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.

=== Runtime tests ===

=== Runtime tests ===

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

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.

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

=== Network tests ===

=== Network tests ===

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

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 ===

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.

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 ===

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.

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.

=== Asset and modding tests ===

=== 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.

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.

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 ===

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.

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.

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.

== Development Status ==

== Development Status ==

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.

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.

== See Also ==

== See Also ==

* [[BackroomsMMO]]

* [[BackroomsMMO]]

* [[BackroomsHost]]

* [[BackroomsHost]]

* [[Thunder_Panel]]

* [[Thunder_Panel]]

* [[Cameron_Lobban]]

* [[Cameron_Lobban]]

== Source Notes ==

== Source Notes ==

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

* 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 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 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 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 TAudio, audio system, acoustic system, replay data structures, replay writer and replay sanitisation files.

* Source review: BackroomsEngine BackroomsLoadBot, RealBot dashboard, distributed RealBot run tooling and live-style JSONL sample metrics.

* Source review: BackroomsEngine BackroomsLoadBot, RealBot dashboard, distributed RealBot run tooling and live-style JSONL sample metrics.

== References ==

== References ==

* [https://backroomsengine.com BackroomsEngine public homepage]

* [https://backroomsengine.com BackroomsEngine public homepage]

* [https://backroomsmmo.com BackroomsMMO public site]

* [https://backroomsmmo.com BackroomsMMO public site]

[[Category:Backrooms]]

[[Category:Backrooms]]

[[Category:Projects]]

[[Category:Projects]]

[[Category:Game engines]]

[[Category:Game engines]]

[[Category:Software]]

[[Category:Software]]