The fortress has depth now. That is the clearest way to describe what happened over this sprint. Wreckhold already had walls, turrets, traps, wave hazards, structure upgrades, and a test suite that reached 4,564 assertions at the end of devlog-04. This sprint did not add more systems. It completed the ones already in place, introduced the beacon, and expanded the screenshot harness from 360 to 623 batches to prove that everything still holds.
Four thousand five hundred sixty-four assertions. Six hundred twenty-three screenshot batches. Zero failures. The PLAYTESTING gate is open.
Closing Out the Sprint-04 Backlog
Devlog-04 shipped with several mechanics in place but not fully polished. The wave hazards were functional. The structure upgrades were functional. The dusk audio crossfade was in the codebase. What that sprint did not do was confirm that all of them worked together in every combination the night phase can produce. That confirmation was the first task of this sprint.
Wave composition variety was the most visible gap. The weighted template system — which separates probe-heavy early waves from mixed middle waves from specialist-heavy late waves — had been built and unit-tested, but the screenshot coverage did not yet include runs that progressed far enough to exercise the late-night composition weights. Sprint-A of the screenshot expansion addressed this directly: batches 361 through 420 are explicitly late-night progression runs, and three of those batches include wave seven or later, where the full specialist pool is live.
Upgrade VFX passed its own assertion block in devlog-04 but the visual read on the night renderer had not been screenshot-verified at scale. The secondary glow ring on wall-brace activation and the upgrade-ring icon on the day map both look different under night-phase lighting conditions than they do during the day build phase. Batches 421 through 460 (sprint-B) covered this: upgraded structures under night ambient, under TREMOR start-stun, and under CORROSION active-state acid rain. All three read clearly.
Dusk audio crossfade was the one item that could not be screenshot-validated. It is verified through assertion — the audio state machine transition test confirms that day ambient volume reaches zero and night ambient reaches full within the crossfade window — and through manual play sessions. The crossfade runs over the build phase duration. The day audio fades out. The low-frequency night drone fades in. The boundary is no longer audible as a technical cut.
The Beacon: Geometry of the Night
Beacons were introduced in devlog-04 as a structural outline. This sprint completed them.
The beacon is a fourth deployable structure, placed in the day build phase with the N key. It does not fight. It does not absorb damage as a priority. It changes the geometry of what you can see and what you can do.
Light Radius
The beacon projects a 70-pixel light radius — the widest illumination footprint of any placeable in the game. At night, Wreckhold’s render limits visibility outside the player’s own torch range and the structural lights attached to walls. Raiders that appear at the edge of the dark give you a narrow reaction window. Raiders that step into beacon light at 70 pixels give you more. A beacon placed at a perimeter corner doesn’t just illuminate that corner — it pulls the effective visibility line outward across the whole flank.
This is not a passive bonus in a game where light is cosmetic. Wreckhold’s night renderer renders dark zones as genuinely dark. A runner that enters turret range from the dark side of a wall will not trigger turret acquisition until it crosses into the light cone. Beacons close that gap.
Amplifier Upgrade
The beacon upgrade (also triggered with G, same as structure upgrades) adds two effects. First, the light radius expands. Second, an aura component activates: turrets within the expanded coverage zone receive a targeting range buff that partially offsets INTERFERENCE.
The INTERFERENCE hazard halves turret targeting range. An upgraded beacon within range of a turret restores some of that. The math is not full cancellation — the buff is a partial offset — but it changes a INTERFERENCE + beacon layout from “your ranged coverage collapses” to “your ranged coverage contracts and you manage it.” That is a different problem. It is a solvable problem.
The tactical cost of building toward this is real. Upgraded beacons are expensive. The upgrade uses scrap that the economy already needs for structural repair, wall bracing, and trap replacement. You are trading day-phase resource pressure for night-phase coverage geometry.
Sapper Hunt
The sapper is the raider type that explicitly prioritizes beacons. Sappers do not attack walls unless there are no beacons on the field. They path toward beacons first, and they ignore the player unless engaged at close range.
A perimeter with four beacons is a perimeter with a raider priority target. Sappers will route around walls to reach the nearest beacon. If your turret coverage is oriented toward the main approach corridors, the sapper’s flanking route may not be covered by it. This is not a bug. The beacon creates a target that redirects enemy attention — which is both a threat (your light infrastructure is fragile) and a mechanic (you can use beacon placement to manipulate raider pathing).
Sapper behavior is config-driven. The unlock threshold, the path priority weight, and the range at which a sapper will abandon a beacon target to engage the player are all table values. They are also all covered by assertions.
HUD and Dawn Integration
The beacon was integrated into three existing systems this sprint.
The HUD shows beacons in the structure count display. Dawn repair — the post-night scrap spend that patches structures before the next day cycle begins — covers beacon HP. The day-phase build menu includes the beacon as a selectable item with placement cost and upgrade path displayed.
Night render includes beacon light as a proper light source, not a post-process layer. The light attenuates with distance the same way torch light does. Beacon placement at distance from the player’s torch does not create an isolated floating glow — it extends the lit frontier as a continuous gradient from the player outward.
How To Play was updated to describe beacons in the structure section. This is a small thing and it mattered during QA: two early screenshot runs produced coherence failures because the documentation pass had not landed yet, and the test that cross-checks in-game structure help text against the known structure list caught the gap.
Screenshot Expansion: 360 to 623
The screenshot suite grew in four labeled sprints plus a set of coherence passes that ran after each one. The structure was deliberate. Each expansion sprint targeted a specific system or progression zone. Each coherence pass then checked that the new coverage didn’t introduce inconsistencies with the coverage already in place.
Sprint-A (batches 361–420) — Late-night progression. Wave 7+, specialist compositions, late economy state. This was the coverage that devlog-04’s wave composition templates most needed.
Sprint-B (batches 421–460) — Night renderer under active hazards and upgrade visual states. Upgraded structures under CORROSION, TREMOR, INTERFERENCE. The goal was confirming that the upgrade visual indicators read correctly under conditions that affect the renderer in other ways.
Sprint-C (batches 461–540) — Beacon coherence. Beacon light radius behavior at placement, at upgrade, under sapper pressure, and at dawn. The dawn repair state includes beacon HP, so the dawn render batches needed to include at least one run where a beacon took damage during the night.
Sprint-D (batches 541–623) — Cross-system balance. Runs that combine wave hazards, upgraded structures, and beacons in simultaneous use. DROUGHT + Volatile traps + beacon coverage. INTERFERENCE + REINFORCED barricades + amplifier beacon. SUPPLY DRAIN + sapper wave + no beacon. The goal was not to find failures — the individual system tests had already passed — but to confirm that the combinations don’t produce unexpected emergent states.
Coherence Passes VI through XII
Seven config coherence passes ran across the sprint, interleaved with the screenshot expansion blocks.
Pass VI and VII were already in place from devlog-04 and are counted in the 4,564 assertion total. Passes VIII through XII are new and contributed 231 assertions to a revised total.
Pass VIII: multi-system balance projection. Simulates ten-night campaigns and checks that projected economy, wall integrity, and raider density stay within design-intent ranges. This is not a unit test — it’s a projection. The design-intent ranges are wide enough to accommodate variance. The test catches configurations where the variance pushes a value outside the plausible zone.
Pass IX: beacon-specific coherence. Confirms that beacon light radius, amplifier buff range, and sapper hunt priority weight are internally consistent — that the buff range is not wider than the light radius, that the sapper hunt bonus does not create a situation where a single beacon makes the sapper type inert at base upgrade level.
Pass X: wave hazard probability table validation. The five hazards share a 35% trigger probability pool. Restructuring the composition templates required re-validating that the per-hazard weights still sum correctly.
Pass XI: upgrade cost cross-validation. Upgrade cost tables checked against economy difficulty scaling to confirm that no difficulty tier makes an upgrade unaffordable at the point in the night cycle where it would be tactically relevant.
Pass XII: dawn repair budget validation. Dawn repair scrap costs for all structure types at all upgrade tiers, under all difficulty levels, checked against the projected scrap carry from a median-performance night. If the dawn repair budget exceeds what a median run earns, the economy breaks. Pass XII confirmed it does not.
Persistent Runner
The QA runner now writes intermediate results to disk during execution. This was introduced in devlog-04 and is worth emphasizing now that the suite takes longer to run.
Six hundred twenty-three screenshot batches is a long run. The runner does not hold results in memory until completion. Every batch writes its result. If the process is interrupted at batch 590, batches 1 through 590 are on disk and do not need to be re-run. The final merge step reads all written results and aggregates them.
This matters less for the assertions — which run in seconds — and more for the screenshots, where each batch has real capture overhead. An interrupted run at 590 of 623 is a 94% complete result, not a zero. The runner treats interruption as a checkpoint, not a failure.
Where Wreckhold Stands
The loop is complete. Day phase: salvage, build, upgrade, place beacons, brace walls. Dusk: audio crossfades, hazard rolls, wave composition selected. Night phase: turrets acquire, beacons extend the frontier, sappers route for the lights, hazards modify the calculus, upgrade VFX confirm the player’s structural investments at a glance. Dawn: repair budget math, scrap spend, survival tally.
Every layer of that loop has been in the game in some form for several sprints. What changed this sprint is that they connect. Beacons interact with INTERFERENCE. Volatile traps interact with SCRAP DROUGHT. Amplifier beacons interact with the sapper’s priority routing. The connections are tested — not just individually, but in combination, under late-night conditions, under screenshot verification.
The assertion count is now 4,564 + 231 from the new coherence passes. The screenshot batches are 623. Zero failures across both.
Wreckhold is in PLAYTESTING. The ai_initial gate is PASS. What it needs now is human hands.
