BackroomsEngine

BackroomsEngine is the native C++ engine and runtime used by BackroomsMMO. It provides the game client, dedicated server, renderer, world generation, networking, audio, voice, cinematic playback, cross-world travel, replay capture, gameplay systems, asset loading, tools, and regression tests used by the project.

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, BackroomsCinematics for cinematic authoring and validation, and BackroomsTests for automated regression coverage. It also includes tools for model inspection, animation work, mod packaging, replay playback, launch workflows, benchmarking, load testing, RealBot monitoring, and game operation.

BackroomsEngine is designed around the needs of an online Backrooms survival game. Alongside graphics, it generates and streams spaces, simulates players and entities, connects clients to servers, persists gameplay state, captures replays, and supports multiplayer safety.

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

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.

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, client bootstrap, model tools, animation tools, cinematic editor, mods tool, admin utilities, message utilities, benchmarking, load testing, RealBot monitoring, 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.

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.

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.

Lighting and shadows

The lighting path combines physically based materials with directional, point, spot and emissive lighting. Cascaded shadow maps cover the main scene, while percentage-closer soft shadows, contact shadows, clustered light selection and a local shadow atlas provide detail around players, props and enclosed rooms.

Room irradiance data gives streamed spaces a local lighting response instead of applying one global value to every corridor. Lighting resources are tied to the streamed scene lifecycle so lights and their shadow data can be retired when the owning chunk or instance leaves memory.

Post-processing and ray tracing

The post-processing stack includes temporal anti-aliasing, motion-vector history, bloom, exposure control, ambient occlusion, screen-space global illumination, volumetric shafts and weather-related passes. Temporal systems keep separate history and are invalidated after camera cuts, major world changes or renderer recovery so old frames do not bleed into a new view.

DirectX Raytracing paths provide optional reflections, shadows and lighting. The engine also contains a progressive path-tracing route for controlled offline, replay and screenshot rendering, rather than using it as the normal realtime path for every player.

Water and visual effects

Water has its own rendering path and runtime state, including surface geometry, reflection and refraction inputs, depth-aware presentation and particle interaction. It is used by water-heavy levels as well as local environmental features.

The visual-effects shader set covers fire, smoke, steam, dust motes, blood spray, lava and confetti. Effects are represented as runtime scene data so they can be driven by gameplay, culled with the scene and restored after renderer recreation.

Portal rendering

Cross-world portals use an offscreen remote view which is composited into a world-space aperture. The portal view has its own camera, render target and temporal history so the destination can be shown without replacing the player's current scene.

Portal frames are checked for freshness before presentation. If a valid current view is unavailable, the aperture falls back to a solid or inactive state instead of displaying an old destination frame as though it were live.

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 project includes renderer hardening around startup, shader compilation, graphics profile changes, streamed chunk churn, invalid mesh data, scene resource retirement, lighting, shadows, reflections, and replay-oriented rendering. These safeguards reduce flicker, stalls and scene failures during exploration.

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

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.

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.

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. Current modules cover Level 0, hotel, poolrooms, factory, mall, island, dungeon-style spaces, and the personal hub.

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.

Instances and transitions

The world system can attach generated or authored instances to the wider chunk world. Instance doors carry enough information to identify the destination, place the player correctly and restore the surrounding world when the player returns.

Transitions are handled as gameplay state rather than as a visual loading trick. Dungeon instances, private spaces, personal hubs and shard travel can preserve party, player and world context while the destination is prepared.

Personal hubs

The personal hub is a finite, sealed player-owned space built through the same deterministic chunk and asset systems as the larger world. Its layout uses a central usable room surrounded by solid boundary chunks, preventing the normal infinite generator from extending beyond the hub.

Personal hubs provide a controlled destination for extraction and persistent player activity. They can be addressed as a distinct world profile while still using normal collision, rendering, acoustics, save data and streamed-world rules.

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.

A generated level can contain floors, stairs, doors, pits, props and collision. Spawn validation places the player into usable space rather than inside a wall, under a floor or outside the streamed starter area.

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.

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.

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 therefore 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. Shared online worlds therefore retain the normal chunk pipeline without relying on purely local generation.

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.

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.

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

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.

The staged flow carries account state, character state, shard availability, content payloads and restrictions from the website into the native session.

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.

Transport security

Website authentication and content requests require HTTPS. Native game streams use TLS 1.3 with an exact application protocol, while peer links between worlds can require certificates and a pinned destination identity before accepting portal or authority traffic.

Realtime datagrams are authenticated and encrypted with separate client-to-server and server-to-client session material. Sequence windows reject duplicates and old packets, while altered headers or payloads fail authentication instead of reaching the movement or gameplay decoder.

Packet hardening

The networking layer rejects malformed or oversized shard frames before they can reach normal gameplay processing. A bad message is discarded instead of being allowed 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.

Cross-World Travel and Intersections

BackroomsEngine contains a cross-world travel layer for portals, shard intersections, rescues and authority transfer. It separates what the player sees through a connection from the systems that move ownership of gameplay state between servers.

Remote portal views

A portal can display a live view of a destination world inside its surface. The destination view is rendered independently and then composited through the portal aperture, with its own camera transform, visibility data and temporal history.

The display path treats stale or incomplete views as invalid. A portal can close its live view or show an inactive surface while the destination catches up, rather than presenting an old frame which no longer matches the remote world.

World-view slices

Remote views are assembled from bounded world-view slices. These can describe structural chunks, simplified players and entities, lights, flashlights and referenced assets needed to reproduce the visible part of the destination.

The producing shard signs and sequences the slice, while the receiving side checks identity, bounds and freshness before accepting it. Remote presentation remains separate from local gameplay authority, so a visual proxy cannot grant ownership of the entity it represents.

Cross-shard transport

Portal and intersection traffic is split between a control path and a bulk world-data path. Rendezvous data binds the connection to the intended worlds and session, while sequence checks and bounded queues reject replayed, cross-session, malformed or unexpectedly large frames.

This transport can carry remote-view updates without placing them in the normal player-state stream. It also allows portal presentation to degrade independently if a view update is delayed, while the local shard continues to run the player's current world.

Cross-plane interactions

The cross-plane runtime defines explicit gates for actions which pass through a portal. Supported paths include hitscan checks, selected projectiles, portable AI, reviving, communication and world interaction.

Positions, directions and reach are mapped through a rigid portal transform. Scale, shear and reflected transforms are rejected because they would change physical distance or handedness and could make combat or interaction checks inconsistent between the two worlds.

Projectiles crossing a boundary are converted into an authority-aware form at the destination. Biotic Orb rules are reused where appropriate so damage, healing, lifetime, ownership and per-player limits remain server controlled after the crossing.

Authority handoff

Moving a player between authoritative worlds uses a staged handoff. The destination prepares the arrival, the source freezes transferable state, a snapshot is exchanged, ownership changes through an epoch-protected operation, and the destination activates the player only after it owns the transfer.

The source can remain as an observer long enough to complete or recover the operation. Ownership epochs prevent two shards from both treating the same player as locally authoritative after a reconnect or delayed message.

Cold authority travel

Cold travel handles a full move where a continuous portal view is not required. The player channels the transfer while the destination prewarms nearby world data and searches for a safe arrival position, with a checkpoint fallback if the requested position is unsuitable.

Travel is blocked while state is unsafe to move, including combat, a downed state, cinematics, trades, revives, loot mutation, protected encounters and non-portable instance activity. Before the ownership change the source can resume the player if preparation fails; after the change the destination owns recovery.

Rescue intersections

An intersection can temporarily connect a stranded player with an eligible helper. Selection considers friendship, player preferences, recent assignments and measured network conditions, and excludes helpers who are busy in menus, hubs, safe rooms, cinematics, protected encounters or other state-changing activities.

Both sides receive an authenticated readiness flow and can cancel before the intersection opens. Group members wake together, the rescue has an explicit completion condition, and successful revival or retrieval can produce an exact-once reward followed by a return choice.

Recovery and durable operations

Transfers and intersection rewards use operation records so a timeout or reconnect can be resumed without applying the same grant twice. Persistent mutations are committed only after the responsible authority has reached the appropriate stage.

This area remains under active development. The architecture is designed to fail closed when ownership, identity, sequencing or persistence cannot be confirmed, leaving recovery to the shard which last held durable authority.

Traversal and Vertical Movement

BackroomsEngine supports vertical routes which extend beyond ordinary stairs and doors. The runtime can identify usable ledges, shafts and generated rappel pits, install persistent ropes, move players between depth layers and preserve a route back to the place they left.

Installed ropes and rappelling

Coiled Rope is a durable tool rather than a one-use transition prompt. A player can install it at a valid ledge or shaft, rappel to a lower landing and use the resulting route again while enough rope durability remains.

The interaction checks the edge, drop and available landing space before committing the action. Rope state is represented in the runtime so the line, anchor and active movement can be presented to other systems instead of teleporting the player without context.

Depth transitions

Some rappel pits lead into a deeper generated floor rather than a lower point in the current room. The engine prepares the destination layer, commits the required streamed world data and records a return anchor before moving the player across the floor boundary.

The transition keeps floor, world-layer, instance and return-position state together. Companion travel state can follow the same transition so a bodyguard is not silently abandoned when its owner moves through a vertical route.

Landing and fall safety

Before completing a rappel, the runtime searches for solid ground with enough capsule clearance and rejects positions inside the shaft opening. It can adjust the landing around the lower edge when the direct point is obstructed.

Unroped shafts remain hazards. Entering one can start a fall path with a separate landing and damage outcome, while a prepared rope provides the controlled route through the same kind of vertical space.

Rope rescues

A rope can also be used to pull up a nearby downed player. The rescue has its own reach, duration and durability cost, then returns the target to a valid position near the rescuer rather than merely changing the target's health in place.

Successful rope rescues feed the same rescue-credit and player-stat systems used by other support actions. This makes vertical recovery part of the wider multiplayer lifesaver system.

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.

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.

Loot, stash contents, equipment and long-term progress survive between MMO sessions. The authoritative merge and validation path prevents the client from treating persistent inventory as unrestricted local data.

Safe rooms and building

Safe rooms combine claimed space, permissions, storage and buildable objects. Players can place and maintain practical structures, fortifications and utilities, while ownership rules decide who may alter, use or remove them.

Safe-room state persists beyond the current frame or client. Construction, containers, access settings and respawn-related data are tied to authoritative world state so another player cannot gain control by changing only local data.

Buildable placement checks available space and the surrounding room before committing an object. RealBot scenarios exercise the same placement, storage, permission and utility flows used by ordinary players.

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.

Party Rooms

The Party Room is a generated special room with its own exit, DJ deck, display, disco ball and lighting layout. Players can use the deck to select and control supported music tracks, and the chosen track and playback state are retained with the room.

Music is presented through synchronised room speakers rather than a single flat menu sound. Audio analysis drives restrained light movement, haze and confetti, while sound and coloured light can leak through the room's closed door. Photosensitive-safe lighting keeps the music response but slows and limits rapid changes.

Bodyguard AI

Bodyguards are persistent companion characters rather than simple scene props. Their runtime covers route planning, door use, room searches, target selection, survival needs, consumables, combat support and recovery from difficult terrain or water.

The AI can move between follow, search, protect and engagement behaviour according to the player's state and nearby threats. Animation, inventory, vitals and navigation are connected to the same character state so the bodyguard remains consistent across gameplay and replay capture.

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.

The director adds pressure to procedural spaces while remaining bounded by runtime rules which can be tested and tuned.

Investigation and traces

The world can retain evidence left by players and encounters. Chalk marks, blood footprints, trails, splatter and pools can carry position, direction, freshness and confidence information for later discovery.

Investigation records allow clues to be catalogued and compared instead of appearing only as temporary decals. This gives exploration a readable history and lets missions or players follow activity through connected rooms.

Missions and challenge modes

Mission state covers objectives, progress, reputation, alignment effects and rewards. Planning-desk data gives players a place to review or prepare structured activities before entering the relevant world or instance.

Challenge modes apply their own rules and completion state without replacing the normal character model. They can be exercised by players and RealBots, including the flows used to earn currency, unlock progression and move into private-server play.

Maps and navigation

BackroomsEngine tracks explored areas, player waypoints, safe-room locations and other map state. The map and minimap can present known information without revealing every generated corridor in advance.

Navigation data also supports AI and automated players. World coordinates, floors, doors, instances and streamed chunks must agree so a route remains meaningful as nearby geometry enters and leaves memory.

Downed players and rescue

Life state distinguishes normal play, incapacitation, death, revival and respawn. Revive actions are checked by the authoritative runtime, while respawn anchors and safe locations control where a player can return.

The same state feeds party rescue, lifesaver behaviour and cross-world intersections. A rescue cannot simply overwrite health locally; it must resolve player ownership, eligibility, timing, inventory effects and the destination state before the player becomes active again.

Lifesaver attribution

The Lifesaver system gives visible credit when one character prevents another player from being lost. Direct revives, rope rescues and qualifying support healing can feed the system, with online Biotic Orb saves decided by the authoritative shard rather than by the assisting client.

The rescued player sees `SAVED BY` followed by the rescuer's character name, while the helper sees `SAVED` followed by the character they protected. Several helpers can be combined into one count, repeated credit is rate-limited, and names are cleaned before they reach the HUD. The notification shown as `SAVED BY AUGMENTED THUNDER` is an example of this system using the character's display name.

Safety tracker

The runtime maintains a local safety state of Safe, Caution or Danger. It considers nearby hostile AI in the same gameplay space, whether the player is being hunted and whether the player is downed, while safe hubs can suppress ordinary threat evaluation.

Short hold and reset rules stop the indicator from flickering when a threat crosses a boundary for a fraction of a second. The resulting danger score can be used by interface, ambience and gameplay systems without each of them having to perform a separate hostile search.

Player statistics

BackroomsEngine records persistent gameplay statistics including players saved, deaths, hostile kills, containers looted, items crafted and rooms explored. Singleplayer can store the local totals, while online sessions submit authoritative events associated with the player's account and character.

Statistics which can be triggered more than once during retries use deduplication identities. This keeps reconnects and repeated network delivery from turning one completed action into several recorded achievements.

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.

Progression and Equipment

BackroomsEngine separates long-term account progress from the development of an individual character. It also gives equipment persistent identity through item levels, rarity, rolled bonuses, wear and upgrades.

Account and character progression

Account progress records level, experience, best depth and small permanent bonuses which can apply across characters. Character progress has its own level, experience, chosen specialisation, perks and unspent perk points.

Experience can come from depth, normal play and challenge completion. Level gains are bounded, saved with the relevant profile and used when deciding the range of item levels which can appear as loot.

Specialisations and perks

A character can specialise as a Medic, Scavenger, Engineer, Survivalist or Lightbearer. The choice gives the character a direction without replacing the general perk pool.

Perks cover loot awareness, sanity resistance, carrying capacity, stamina recovery, health, armour, revive speed and specialist abilities. When a perk point is available, the engine produces a deterministic offer of three choices so the same saved offer can be restored consistently.

Item levels, rarity and bonuses

Equipment which supports random bonuses can be generated from Common through Unique rarity. Item level and rarity influence its available bonuses, while a stable roll identity keeps the resulting item consistent when it is saved, moved, dropped or restored.

Bonus types include movement, health, stamina, armour, damage handling, medical finds and other equipment effects. Ordinary consumables and materials remain fixed items rather than receiving unsuitable combat-style affixes.

Equipment and paper doll

The player equipment model includes head, torso, hands, legs, feet, backpack, ring, necklace, two weapon positions and two general equipment positions. Equipped items contribute to the player's derived health, stamina, movement, protection and carrying statistics.

The inventory interface can compare item bonuses before the player changes equipment. This keeps the paper doll, actual runtime statistics and persistent item instances tied to the same data.

Durability and toolbelt

Wearable armour and practical tools have persistent durability. Unequipping and re-equipping armour does not restore it, and a dropped tool keeps its actual wear rather than becoming a fresh copy.

Tools such as Coiled Rope live in the toolbelt so gameplay systems can consume durability directly. Handheld radios also keep their selected channel and active state with the item, allowing that setup to survive inventory movement and persistence.

Workbenches

Workbench interactions cover crafting, armour repair and armour-plating upgrades. The runtime checks the recipe or upgrade requirements, consumes the required materials and synchronises the resulting inventory or equipment state with the authoritative session.

Armour upgrades are stored on the item itself. This allows a particular piece of armour to remain upgraded when it is unequipped, moved between inventory positions or loaded in a later session.

Environmental Survival

Environmental systems connect world conditions to the player's equipment, vitals and recovery options. Air quality, unsafe water, weather and portable respawn points can all affect how a route is planned.

Air quality and protection

Damaged or hostile environmental devices can increase a player's air-quality exposure, while working ventilation can reduce it. Continued exposure lowers the effective health the player can safely maintain until the air improves.

Face protection changes the rate at which exposure reaches the player. Full protective masks can block the modelled air-quality effect, while lighter face coverings provide partial protection.

Rainwater and purification

Generated rainwater volumes can provide a limited number of collectable servings. The collected water is dirty and carries a sickness risk if consumed without treatment.

A purification tablet converts dirty rainwater into purified water before it is used. The interaction is transactional: if the resulting item cannot be added, the consumed inputs are restored instead of being silently lost.

Dynamic weather

Island worlds have a seeded weather cycle with clear, fog, rain, storm and blood-rain states. Weather blends fog, sky and ambient colour, rain intensity and speed, and matching environmental audio rather than changing only a screen label.

Different world seeds offset the weather phase so separate worlds do not all enter the same conditions at the same moment. Weather remains scoped to the relevant island world rather than becoming a global effect across unrelated instances.

Sleeping bags and respawn anchors

Sleeping bags can be placed on clear solid ground and used as owned respawn anchors. Placement checks distance, surrounding space and nearby bags before committing the object to the world.

The owner can later pack the bag back into inventory when space is available. Its respawn data includes the relevant world layer and location so returning from death does not place the character on the wrong generated floor.

Cinematic System

BackroomsEngine has a native cinematic system for scripted scenes which remain connected to gameplay, multiplayer authority and persistence. Cinematics are authored as structured `.brcine.json` documents and can be validated without launching a normal game session.

Tracks and keyframes

A cinematic is divided into segments containing typed tracks and keyframes. Track types cover cameras, actor transforms, animation, gaze, audio, music, subtitles, fades, letterboxing, interface visibility, lights, visual effects, input masks, barriers and gameplay action markers.

Values can use stepped, linear or smoothed interpolation. Cameras and actors can work in world space or relative to named bindings and anchors, allowing one scene to be reused with the correct player, party member, door or destination object.

Branching and choices

Segments can lead directly to another segment or branch according to a choice and a set of conditions. Conditions can inspect earlier choices, progress, missions, alignment, reputation, party size, world state, transitions and server flags.

The branch graph is validated for missing destinations and unsafe paths before use. Runtime choice resolution remains authoritative online, so one client cannot select a different outcome from the rest of the participating group.

Cameras and presentation

Camera tracks support free, constrained and directed presentation. Cuts and large changes reset temporal rendering history, while camera bindings allow a shot to follow a moving actor or world anchor without baking one fixed world position into the scene.

Presentation tracks can coordinate subtitles, music, effects, lighting, interface visibility and input. Gameplay barriers keep participants inside the protected scene state until the authoritative sequence reaches a valid release point.

Accessibility and safe playback

Cinematic documents can provide normal, reduced-motion, photosensitive-safe and combined-safe entry points. Captions are required for spoken or important audible content, and authors can mark safe skip boundaries rather than allowing a skip to interrupt a state-changing action halfway through.

The runtime selects the appropriate entry according to the player's settings. Reduced effects do not change the authoritative outcome, which keeps multiplayer participants synchronised even when their local presentation differs.

Online authority

Online playback begins with an offer and preload stage before the server starts the scene. The server owns the current segment, branch choices and gameplay action markers, while clients report readiness and present the approved timeline locally.

Manifests, allowed action scopes and referenced assets are validated before playback. Local presentation failure does not automatically release a player from an authoritative barrier, preventing a missing asset or closed client window from bypassing protected gameplay state.

Persistence and recovery

Execution journals record state-changing markers and cues so reconnects, retries and authority handoffs do not apply the same event twice. Persistent game changes are prepared against a copy of the current state and replace live state only after the durable save succeeds.

This allows a cinematic to grant progress, move a party or extract a player without leaving half-applied state if saving or network handoff fails. Recovery can resume from the authoritative segment and operation record instead of replaying the entire scene blindly.

Cinematic editor

BackroomsCinematics is the dedicated desktop editor. It provides a timeline, transport controls, a branch graph, track and keyframe editing, undo and redo, segment clipboard operations, renderer-backed preview, autosave recovery and validation for one document or the full cinematic library.

The editor uses the engine renderer for preview, keeping authored cameras, models, lights and effects close to their in-game result. Document limits bound duration, segments, tracks, keyframes and file size so malformed or excessive scenes are rejected during validation.

Authored scenes

The current cinematic library includes arrival in Level 0, door travel, party travel and extraction to the personal hub. These scenes cover both presentation and stateful transitions, making them useful regression cases for camera work, accessibility, party synchronisation, authority transfer and durable progress.

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.

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. Doors, water, room boundaries and portal connections can alter what reaches the listener and how clearly it is heard.

Proximity voice and radios

Ordinary voice is positioned from the speaking player's head and mixed with distance, stereo pan and the acoustic state between speaker and listener. Voice passing through an instance door or portal can emerge from the doorway with reduced range, stronger obstruction and muffled high frequencies.

Handheld radios provide a separate route. A radio carries an active state and channel in the item instance, and matching radio traffic is presented centrally rather than being attenuated as ordinary proximity speech.

Authored character voice

Characters can have authored voice cues for greetings, reviving another player and responding after a successful rescue. The cue library uses categories, priorities and cooldowns so repeated actions do not produce overlapping lines every frame.

Online revive cues are approved by the shard after it checks the action and nearby target. Authored lines remain spatial sounds, and lines heard through a portal use the same doorway position and muffling model as other cross-room audio.

Voice mimicry and consent

Mimic entities can reproduce bounded clips taken from real voice-chat frames, but capture and use are controlled by explicit voice-mimic settings. Recording, mimic use, persistent storage and wider shard use are separate choices, with retention mode and audience scope carried alongside a stored clip.

Disabling consent clears session and pending persistent material which is no longer allowed. If no valid permitted clip is available, the mimic does not invent replacement speech. Payload length, format, queue size and clip duration are bounded before audio is accepted.

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.

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.

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.

Replay playback can therefore preserve the voice and sound context surrounding movement and gameplay events.

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.

Video Capture and Streaming

BackroomsEngine has a native bridge between the live renderer, mixed game audio and BackroomsVideo. It can publish a live session or record it locally without treating an external screen recorder as the only capture path.

Live publishing

The live publisher requests finished RGBA frames from the renderer and receives the mixed stereo audio stream from TAudio. These streams are passed to a dedicated encoder process for RTMP publishing, keeping service credentials and ingest details outside the public gameplay state.

Video and audio use independent pipes so a temporary delay on one input does not require the game to build a single unbounded memory buffer. The runtime can also send a keepalive frame when a new rendered frame is not ready in time.

Local recording

The same capture path can write a local MP4 instead of publishing to a live endpoint. Local recording receives actual renderer output and the same mixed game-audio feed, so it includes the scene and sound produced by the engine rather than reconstructing them from telemetry.

Capture remains separate from structured replays. A video is a viewable recording, while a replay retains simulation, camera, player, audio and voice data which can be inspected or presented again by the replay player.

Capture pacing and monitoring

Frame requests are paced to the selected capture rate and are not stacked while a previous renderer capture is still busy. This prevents the recording path from asking the GPU for an uncontrolled backlog of readbacks.

Publisher status records active dimensions, frame and audio counts, keepalive frames, dropped frames and write failures. The menu can therefore report whether a live or local recording is healthy instead of showing only a start button with no runtime feedback.

Assets and Tools

BackroomsEngine includes asset loading, model inspection, animation tooling, package support, and runtime content-cache integration. The tools share formats and validation rules with the player-facing 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 support different hardware, render distances and streamed-scene budgets without requiring every system to use the maximum-detail asset.

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.

Cinematic tooling

BackroomsCinematics adds a visual authoring workflow for structured scenes, including timeline editing, branch inspection, renderer preview, autosave recovery and batch validation. The same document parser and validation rules are shared with runtime playback and automated tests.

Authored scenes remain ordinary project assets rather than executable scripts. Typed tracks, bounded documents, declared asset references and restricted action markers give the editor useful control without allowing a cinematic file to perform arbitrary native operations.

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.

Settings and Accessibility

BackroomsEngine exposes runtime settings for display, graphics, performance, sound and accessible presentation. These settings are part of the game configuration rather than a separate launcher-only profile.

Graphics profiles

The game can inspect the machine and choose an initial graphics profile, while still allowing the player to select a preset or tune individual features. Controls include model and texture detail, render scale, view distance, raster shadows, water, visual effects, anti-aliasing, ambient occlusion, global illumination, volumetric light, particles and supported ray-tracing features.

Hardware detection also records whether the active runtime can use DirectX Raytracing before offering it as a gameplay option. Unsupported features stay off rather than presenting a setting which the renderer cannot honour.

Display and performance controls

Display settings cover windowed, borderless and fullscreen presentation, resolution, refresh rate, VSync, tearing and frame targets. Performance controls include worker and memory budgets, lighting limits and a target frame rate for time-sliced systems.

Adaptive performance can work towards a chosen frame target by moving within user-defined bounds for view distance and render scale. It changes measured work budgets rather than silently replacing the player's complete graphics profile.

Accessible presentation

Photosensitive-safe lighting keeps music-reactive Party Room effects while limiting fast intensity and colour changes. Reduced motion removes non-essential pulsing and warning motion, and cinematics can use an authored static-camera variant with reduced shake and effect intensity.

Subtitles and closed captions support optional speaker labels, adjustable text scale and background opacity. The controls apply to authored scenes and other captioned presentation without requiring a separate accessibility build.

Audio controls

Audio settings expose acoustic quality, occlusion and muffling, environmental reverb, voice realism, spatial width, reverb scale and the number of acoustic sources available to the mixer. These controls affect world sound, voice travel, portal or door muffling and captured stream or replay audio.

Bus volume and mute controls remain separate, so music, ambience, sound effects, interface sound and voice can be balanced independently.

Configuration persistence

Player settings are sanitised and saved to the game configuration. Values are clamped to supported ranges when loaded, while options which require asset or sampler recreation are marked for restart instead of pretending to apply immediately.

This lets automatic detection provide a starting point without taking ownership away from the player. Manual display, quality, accessibility and audio choices remain available in later sessions.

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.

`.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, preserving consistent rules, trusted content and predictable authority in public play.

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

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.

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

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.

Many MMO failures appear only when the website, content metadata, join ticket, selected shard, network transport and game state are exercised together. A shard can pass isolated logic tests while failing that complete route.

Bot roles

The load bot has role profiles for different kinds of player behaviour, including squad members, lone wolves, safe-room builders, instance scouts, medics and looters.

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

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.

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.

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.

Rappel coverage can reserve routes through known shaft targets, installed ropes, deeper floors and the matching return path. This checks that world streaming, floor authority and traversal state still agree during a vertical transition.

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.

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

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.

The bots also make decisions based on health, stamina, sanity, hunger and thirst. Loot tests therefore exercise survival decisions as well as container responses.

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.

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

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.

Team behaviour creates different traffic patterns, inventory pressure, voice and chat use, and failure cases from isolated clients.

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.

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

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.

Lifesaver probes

A dedicated Lifesaver scenario reserves a target and helper, creates a qualifying critical-health rescue and waits for both authoritative notification directions. It checks that the helper and target receive the correct character names, that one rescue is not delivered several times and that ordinary healing without a later danger event does not falsely award another save.

The probe records attempts, completions, duplicate events and name mismatches in the RealBot output. This covers the complete route from shard-side credit through network delivery to the player-facing attribution data.

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.

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

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.

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.

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

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.

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.

A small local test cannot reproduce all pressure from real traffic. Larger RealBot runs expose timing, networking, heartbeat, content sync, authority and resource problems which appear only when many clients are active together.

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.

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 the boundaries 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, official server identity, portal transport, remote-view slices, intersection bridges, cold travel and authority-transfer protocols. They are aimed at the parts of the runtime where account state, server identity, shard behaviour, ownership 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.

Cinematic tests

Cinematic tests cover document parsing, validation, branching, player timing, server direction, authority sessions, protected gameplay state, durable extraction and personal-hub arrival. The authored cinematic library can also be batch-validated through the editor target.

These tests check both presentation data and state-changing behaviour. A scene is not considered correct merely because its camera plays; choices, barriers, accessibility variants, persistence and reconnect handling must also agree.

Portal and intersection tests

Portal tests cover remote-view freshness, source bridges, cross-plane actions, authority ownership, cold travel and recovery boundaries. Renderer tests also exercise portal presentation alongside streamed-world correctness and grounding.

The test surface is split because a remote view can remain visually valid while authority movement fails, or a transfer can complete while presentation is unavailable. Each layer therefore has its own failure and recovery checks.

Audio and voice tests

Audio and voice tests cover TAudio behaviour, acoustic systems, runtime audio, and voice-specific paths. They check stateful and timing-sensitive behaviour shared by 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 cover long-term MMO state alongside 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.

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.

It is a custom game runtime for BackroomsMMO rather than a general-purpose public engine. Its systems are built around a multiplayer Backrooms survival game: generated and streamed spaces, authoritative shards, portals between worlds, cinematic transitions, persistent characters, voice, group play, replays, moderation and production tools.

Newer cross-world systems, including portal intersections and authority handoff, continue to receive active regression work. Established systems such as world streaming, rendering, audio, server runtime and RealBot testing are also revised as they are connected to new gameplay paths.

See Also

• BackroomsMMO
• BackroomsHost
• Thunder Panel
• Cameron Lobban

Source Notes

Technical details on this page were checked against the BackroomsEngine source tree, including the CMake build, dependency manifest, world generation configuration, runtime tools, tests and BackroomsMMO integration. 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, proximity voice, radio routing, authored character voice and consent-controlled voice mimic files.
• Source review: BackroomsEngine replay data structures, replay writer, replay sanitisation, BackroomsVideo publisher and renderer capture files.
• Source review: BackroomsEngine cinematic documents, player, server director, authority session, editor and cinematic regression tests.
• Source review: BackroomsEngine portal rendering, view-slice transport, cross-plane runtime, intersection rescue, cold travel and authority handoff files.
• Source review: BackroomsEngine rope traversal, rappel depth transitions, fall handling, Lifesaver attribution and player-stat files.
• Source review: BackroomsEngine progression, perks, equipment, item rarity, durability, toolbelt and workbench files.
• Source review: BackroomsEngine air quality, rainwater, weather, sleeping bag, safe-room, bodyguard, investigation, mission, challenge, map, revive and personal-hub systems.
• Source review: BackroomsEngine graphics profiles, adaptive performance, display, audio and accessibility settings files.
• Source review: BackroomsEngine BackroomsModels, BackroomsCinematics, BackroomsModsTool, asset resolver, GLTF loader and regression test tree.
• Source review: BackroomsEngine BackroomsLoadBot, RealBot dashboard, distributed RealBot run tooling and live-style JSONL sample metrics.

References

• BackroomsEngine public homepage
• BackroomsMMO public site