Laser Beast’s Programming is Done. Now We Build Levels.

April was the last major programming month for Laser Beast. The goal was to clear known issues, build every remaining system, and get the codebase ready for playtesting. And I believe we are nearly there. This post covers what got built and what May looks like.

What Got Built in April

Systems

• SaveManager: Handles all read/write operations for progress. Save data is stored as JSON across three independent save slots. Each slot tracks per-level state: completion, total deaths, best deaths, and collectible status. Nearly every other system depends on this one, so it had to come first. Writes happen on level complete and on death.
• ProgressionManager: Reads from SaveManager and exposes level/world unlock logic to the rest of the game. Unlock is strictly linear: completing level N unlocks level N+1. A world unlocks when its final level is completed. No system outside of ProgressionManager needs to know how unlock logic works.
• Collectible system: Each collectible sets a local flag on contact. LevelEnd checks all collectibles in the scene for that flag before writing to SaveManager. The collectible does not count until the level is completed. This prevents a player from grabbing a collectible and quitting to record it without finishing the run.
• DeathManager session logger: Tracks deaths per session and manages the respawn sequence. It also handles the fewest deaths logic: fewest deaths only updates when a run is completed and the new count is lower than the current best. This makes a zero-death achievement trackable without any separate tracking system.
• SteamManager + AchievementManager: Full Steamworks integration via Steamworks.NET. AchievementManager subscribes to game events and checks conditions against SaveManager before pushing achievement unlocks to Steam. This was originally planned for June. Moving it into April removes a major unknown from the final month.
• GameBootstrapper: Ensures persistent managers load correctly regardless of which scene is entered first. More on this below.

Scene Flow

The full navigation pipeline is working: Boot → Title → Save Select → Level Select. Each screen transitions correctly and reads from save data where needed.

UI and panel layout across these screens is functional, but not final. Sizing and placement will be adjusted during the art and UI pass. The priority this month was getting the correct data to the correct places.

• Level select grid: Each node tracks LevelNodeState per save file: locked, unlocked, completed, or completed with collectible. The visual state of every node is driven by save data at load time.
• Overworld map: The layout has three panels. A world selector on the left lists all five worlds. The center panel shows a 3×4 grid of level nodes for the selected world. The right panel displays details for the currently highlighted level: completion status, total deaths, best deaths, and collectible status. Navigation between panels and nodes is working. Full testing requires actual levels connected to each node, which comes next month.
• Credits screen: In and functional.
• Options panel: Built as a reusable prefab and shared between the Options scene and the pause menu. Settings write immediately on change and persist to a global JSON file separate from save slots. Preferences like screen flash or haptic toggles survive across sessions without needing to be reset.

The level complete screen is the one remaining missing piece. UI only. It needs to display level name, deaths this run, total deaths, best deaths, and collectible status before fading to the next scene. That gets built in May.

Known Issues

In the update, I called out four known technical debt issues that needed to be resolved before new work could go in: memory leaks in the event subscription system caused by lambda unsubscribes, a handler mismatch in the pause menu, expensive FindObjectsOfType calls scattered through the codebase that needed to be replaced with cached references, and some refactoring to make core systems properly extensible for reuse. Nine commits closed all of it.

With the major programming work wrapped, a second analysis of the codebase is planned before playtesting begins. The goal is to catch anything missed or left incomplete before playtesting begins.

A Note on the Bootstrapper

The GameBootstrapper ended up back in the project. The original plan included it, then I dropped it in favor of a scene template approach, then I added it back in because certain systems needed to be reliably present regardless of which scene loads first. The bootstrapper uses RuntimeInitializeOnLoadMethod to instantiate a CoreSystems prefab before any scene loads. Persistent managers like EventManager, InputManager, SaveManager, and ProgressionManager all live there.

The question I kept running into: which systems should exist in every scene by default, even if they are not actively used in that scene? Take LevelEndManager as an example. It does nothing in the title screen or the options menu. But if it were included in every scene by default, it could never be accidentally missing from a scene that actually needs it. The tradeoff is unused overhead in scenes where it has nothing to do.

I am not sure I landed on the best answer for this project. It works, and that is good enough for now. The takeaway for future projects is to decide that convention early and apply it consistently from the start, rather than resolving it one scene at a time as things grow.

What May Looks Like

The major programming systems are complete. May shifts focus to content and polish:

• Level design: 60 levels across 5 worlds is the target. This is the largest remaining variable and the primary focus of the month.
• Steam page: Originally planned for June, but getting the store page up earlier creates more time to gather wishlists before launch.
• Playtesting: Initial playtesting is expected to start around May 1. The core loop is stable enough to put in front of players.
• Level complete screen: UI build, no new systems required.
• Art and audio: Assets are being added and updated sequentially as level work allows.

The goal heading into June is to have everything built so that month can focus entirely on fixes rather than adding anything new. The next update will cover playtesting results and where the level count lands.