/// DEV JOURNAL

ENGINEERING THE AFTERMATH


Explore the systems behind FINALDAYZ, where weather, decay, sound and survival work together to bring a collapsing Chernarus to life.

the end of the world

Chernarus kept decaying after civilisation fell. Buildings rot, roads disappear beneath wrecks and overgrowth, and the places people once depended on hold the remains of failed escapes. FINALDAYZ builds survival around what was left behind.

| the world responds

Weather, sound and environmental effects respond to your surroundings. Rain drums on nearby wrecks, wind reaches through broken windows, and fog changes how far you can see. Moving from open ground into a ruined building changes what you hear and experience.

| a shared state

Connected systems draw on common information about weather, location and conditions. The server controls gameplay, loot and physical hazards, while each client streams visual detail and effects within its performance budget. Together, they give Chernarus a consistent sense of place.

01 / WEATHER WORLD RESPONSE

weather
director


Weather moves through authored states, from building pressure to storms and recovery. Saved state allows the cycle to continue after a server restart.

World
director


Controls world lighting and colour palette, feeding changing conditions into the daytime and night-time observer.

day/night
observer


Provides context for flickering lights, temperature, fog, animal sounds and fireflies. Fireflies appear near water at night when conditions are calm.

system detail

The Environmental State Director owns the server’s weather. Each state defines targets for cloud, rain, fog, wind and storms, along with transition timings and atmosphere settings. Weighted choices introduce variation within an authored progression, while persistence carries the current state across restarts.The World Director coordinates lighting and colour, feeding the daytime and night-time observer so other systems can respond to the conditions. Together, these layers help weather, visibility, lighting and ambient wildlife feel connected. A change in the world can influence several effects through shared information.

02 / PROCEDURAL BUILDINGS

BUILDING
CATALOGUE


A shared catalogue records canonical building positions and references. Multiple systems reuse this information when placing scenes, dressing and gameplay objects.

LOCAL
DRESSING


Authored templates place clutter and environmental detail around matching buildings. Each client streams nearby visual objects within its performance budget.

SERVER
SCENES


The server validates building references before creating authoritative loot and related gameplay items. Collected items are tracked to prevent immediate replacement.

system detail

Building templates describe objects relative to a known structure. The runtime transforms those local positions into placements at matching buildings across Chernarus. This allows carefully authored interiors to be reused while maintaining consistent alignment with floors, openings and furniture.When a client activates a procedural building, it sends a READY message containing the building class and catalogue index. The server validates that reference and activates the relevant scene managers. UNLOAD releases temporary scene ownership, while consumed-slot records prevent taken items from immediately returning.

03 / LOOT & WORLD SCENES

PANIC
SITES


Hospitals and shops become scenes of failed refuge. Bodies, wrecks and clutter tell the story of places people rushed to during the collapse.

LOOT
DIRECTOR


Authored survivor-death templates place supplies within scenes. Their arrangement gives players something to investigate and interpret.

COASTAL
DEBRIS


Beach loot is owned by the server, while clients add seeded visual debris. Both layers contribute to the same abandoned shoreline.

system detail

FINALDAYZ uses authored scenes to give supplies a setting and a history. Panic Sites build hospital and store environments, while the Loot Director places survivor-death scenes using the Building Catalogue. Other systems create breakdowns, selected convoy scenes and a restart-selected aircraft crash site.Gameplay items remain under server authority. Decorative objects can be handled locally where appropriate, allowing greater visual density around the real supplies. The audit’s Loot Director configuration used an inspection setting with unusually dense placement, so those recorded quantities do not define the intended release balance.

04 / ROADS & WRECKS

WRECK
CACHE


The server places added physical wrecks and records existing map wrecks as anchors. Existing map objects are registered without being duplicated.

WRECK
DRESSING


Clients use the shared anchor registry to add nearby visual decay. The same positions also support rain-on-wreck audio.

ROAD
DETRITUS


Weeds, stones, twigs, decals and damaged surface patches appear along suitable roads. Detail is generated locally and cleaned up with distance.

system detail

The wreck registry combines authored additions, existing map wrecks and records contributed by other scene systems. Physical wrecks remain authoritative, while their surrounding visual dressing is streamed by each client. Position and template data are delivered in paced batches.Road Detritus uses player location, road-surface checks, movement and deterministic cells to select nearby detail. Looking ahead along travel helps prepare the road in front of the player. The audited physical road-stone companion is dormant, so the active Road Detritus system is described here as visual surface detail.

05 / SOUNDSCAPE & LOCAL EFFECTS

WORLD
CELLS


Cached world cells classify the surroundings using buildings, wrecks and vegetation. The player’s location profile is combined with the current weather.

CONTEXTUAL
AUDIO


Rain, wind and nature sounds respond to exposure, nearby anchors, time and conditions. Interiors and open ground can produce different sound layers.

APOCALYPSE
RADIO


A shared server time reference keeps local radio playback synchronized. Underground ambience uses its own network anchor positions.

system detail

The World Soundscape Map divides Chernarus into 150-metre cells with cached environmental classifications. The server combines the player’s current profile with weather information and sends that context to the client. Audio systems can then make consistent decisions without repeatedly scanning the whole surrounding world.Nearby wreck anchors support rain-on-metal loops, while building and exposure information guide indoor rain and wind layers. Nature sounds respond to location, rain, wind and time. Lightning is paired with thunder delayed by distance, and Apocalypse Radio uses a server epoch to coordinate playback across clients.

06 / INVENTORY & PLAYER STATE

PLAYER
MONITOR


Shared snapshots track movement, vehicle and inventory state. Container Leaks and Ruined Clothing Drops reuse this information.

LEAKS &
DROPS


Opened drinks and water-filled cooking containers can leak inside worn cargo. Ruined-container cargo ejection is validated by the server.

NO FREE
CARRY


Server-side restrictions prevent worn backpacks becoming consequence-free hand-carried storage. A client prompt explains the restriction.

system detail

Player Monitor spreads its work across small updates, refreshing different information at different rates. It supplies common movement, vehicle and inventory snapshots to its consumers. This keeps checks inexpensive and helps inventory systems agree on the player’s current state.Container Leaks applies staged quantity loss and dampens affected cargo or its container. Ruined Clothing Drops begins with client detection, then asks the server to validate the condition before selecting and ejecting cargo. Movement, swimming and vehicle state influence the drop chance, giving damaged storage practical consequences.

07 / INFECTED & PERFORMANCE

SITE
BUDGETS


Urban Undead responds when players approach registered encounter sites. The server calculates the infected budget for that location.

CLIENT
WARNING


Before a batch spawns, a warning opens a protection window on the client. Optional visual activation is held back during the encounter’s arrival.

BATCHED
SPAWNS


Infected arrive in small groups. Cleared sites enter a cooldown before they can rearm and respond to another approach.

system detail

Urban Undead uses authored urban sites and generated underground encounter records. Proximity activates a site budget, allowing encounters to respond to player presence. Once cleared, a site enters a twenty-minute cooldown before its budget can return through the rearming process.The encounter also communicates with client performance systems. A warning RPC temporarily holds back optional streaming activation before infected spawn in batches. This coordinates gameplay and visual workloads, reducing the chance that several demanding systems activate together.

08 / UNDERGROUND NETWORKS

PRE-BOOT
GENERATION


Tooling generates or reuses persistent sewer geometry and trigger data before launch. The generated network becomes an input to server startup.

SERVER
AUTHORITY


The server loads geometry, controls airlock access and places authoritative loot. Generated encounter records also feed Urban Undead.

LOCAL
ambience


Clients stream section dressing, fog, lights and ambience. Compact anchor maps connect these effects to the underground layout.

system detail

The underground complexes occupy an elevated spatial layer, with airlocks moving players between the surface and the appropriate network. Pre-boot tooling prepares the persistent layout and trigger data. The server then loads the geometry, access points, loot scenes and associated registries.Clients receive compact maps for dressing and audio, allowing local detail to follow the generated sections. Fog, flickering lights, surface overlays and props build atmosphere around server-owned geometry. The same network data also supplies encounter positions, keeping gameplay and presentation tied to one layout.

09 / FRAMEWORK & STREAMING

PRIME
CONFIG


Central configuration enables and tunes major features. Shared settings keep related systems aligned during testing and development.

SPAWN
controller


Dependent systems start in a controlled order. Catalogues and registries are prepared before systems that need their data.

PERFORMANCE
TIERS


Each client scales visual density, activation radius and per-tick work. Streaming budgets adapt the presentation to the player’s machine.

system detail

Startup is staged across call queues, with shared catalogues and caches prepared before their consumers. Building systems reuse canonical positions, while wreck-producing scenes contribute their anchors before snapshots are delivered. Large data sets are sent through paced clear-and-batch messages.Client streaming uses spatial cells, distance, facing, size tiers and hysteresis to manage activation and removal. The performance manager supplies multipliers for detail and work budgets, and receives active-object costs from major visual systems. This allows local presentation to scale while gameplay objects remain under server authority.

10 / PLAYER ARRIVAL & WAKE-UP

FRESH
ARRIVAL


New characters receive an authored wake-up sequence. The server prepares their position, loadout and initial state before releasing them into play.

FIRST-LIFE
STORY


Client presentation combines blackout, typewriter text, sound and ambience. First-life tracking controls when the full introduction is shown.

RETURNING
SURVIVORS


Existing characters receive a separate login wake-up presentation. Their saved location is retained as they return to Chernarus.

system detail

Fresh character creation follows a controlled server sequence. The character is marked as a new arrival, prepared at a holding position, given the selected loadout and moved into the authored wake-up location or boat sequence. Matching client messages provide the visual and audio presentation.Returning-player wake-up uses a separate path and skips characters still within the fresh-spawn window. It presents a brief transition without relocating the survivor or forcing real unconsciousness. A creation throttle also delays heavier post-login work, helping distribute the load around arrival.

development roadmap


from test shard to final release

The goal is a coherant, immersive, and detailed world with controlled performance and reliable gameplay.

01 /
foundation

Develop the core systems on the original test shard, establish the world’s identity and learn how weather, buildings, loot and survival work together.

02 /
REBUILD

Build the final release on a separate shard. Improve the underlying code, shared services and configuration before moving systems across.

03 /
MIGRATE

Transfer and refine one system at a time. Check gameplay, server authority, persistence and client performance as each joins the new build.

04 /
RELEASE

Bring the systems together through playtesting. Refine survival balance, resolve remaining issues and prepare the world for public release.

Development stages show the direction of work. Release dates will follow testing.

discord


be a part of what comes next

Join the FINALDAYZ community to follow development, share your experiences and help shape the world through feedback. Pull up a seat. There’s more to come.

dev updates / community discussions / player feedback