Devlog #009 — Earn the Look, Never the Edge
PULSE//ZERO has a progression system, and it never makes you stronger. Everything you unlock is cosmetic — grid themes, ship skins, kill effects, engine trails, display modes. Here is why we drew that line, and how the data-driven systems behind it keep it honest.
The last few entries built the game you play. Devlog #002 introduced the cast — the five enemy archetypes that each ask one clear question. Devlog #003 wired up the conductor, the Adaptive Director that decides who shows up and how hard. Devlog #005 brought in the bosses, and Devlog #006 gave it all a stage. This entry is about what you earn for mastering all of that — and the one hard rule we refuse to bend about it.
The pillar: progression is cosmetic, full stop
PULSE//ZERO has a long-term progression layer. It does not contain a single stat boost. No permanent damage upgrades, no permanent health, nothing that nudges a combat number in your favour. Everything you unlock is expression — grid themes, ship skins, HUD themes, kill effects, engine trails, display modes. The look of your run, never its difficulty.
We wrote that down as a non-negotiable design rule before we built any of it:
- No permanent damage or health upgrades.
- No pay-to-win progression.
- High scores stay comparable regardless of what’s unlocked or equipped.
- Anything that touches readability is optional and reversible — equip or unequip at will.
The consequence is the whole point: a fresh save and a 100%-complete save play identically on the scoreboard. A newcomer on their first run and a veteran with every cosmetic unlocked are facing the exact same game.
Why we drew the line here
Twin-stick arena shooters live on a leaderboard. The moment progression touches power, that leaderboard stops measuring skill and starts measuring playtime. A score posted on hour fifty isn’t comparable to a score posted on hour one, and everyone quietly knows it. We didn’t want to build a game where the honest answer to “how do I get better?” is “grind more upgrades.”
So we kept skill as the only variable that moves. What you unlock can’t help you survive longer; it can only make surviving look like you. Rewards express identity, not advantage. That framing turned out to be freeing — because nothing we add to the unlock pool can ever unbalance the game, we can be generous with it.
How it stays honest: data, not code
Under the hood there are two cooperating systems, and the split mirrors the data-vs-brain pattern we’ve leaned on throughout this project.
Each unlockable is a plain UnlockDefinition resource — a .tres data file with
no logic in it. It declares what it is and how it’s earned:
id = "blueprint_grid"
display_name = "Blueprint Grid Theme"
category = GRID_THEME
trigger = STAT_THRESHOLD
trigger_stat = "grid_surges"
trigger_threshold = 10
equippable = true
equip_slot = "grid_theme"
apply_value = "blueprint"
The UnlockManager autoload scans those definitions at boot, listens to game
events, and accumulates progress — kills, runs, best multiplier, dashes, bombs,
grid surges, survival time. When a trigger’s condition is met it fires
unlock_earned, and it owns the unlocked/equipped state, persisted to the save.
Adding a new unlock on an existing stat needs zero code: you drop in a .tres
and it appears in the gallery, tracks live progress, and equips. Returning players
are even seeded from their existing lifetime stats, so past play counts toward
what they unlock.
Applying a cosmetic is the job of a second autoload, the CosmeticManager. It resolves whatever’s equipped — plus any transient menu preview — into a single signal:
cosmetic_changed(slot, config) # config == null means "built-in default"
Every consumer subscribes to that one signal and never cares whether the change came from a real equip or a hover-preview. The Living Grid lerps its palette toward the new theme. The ship lerps hull, core and outline toward a skin. The HUD recolours its labels — text only, so readability is preserved. The death burst swaps its spark silhouette per kill effect. Configs load once into dictionaries at boot, nothing is allocated per frame, and an unequipped slot always falls back cleanly to its hard-coded default. Smooth, cheap, and completely separate from the simulation.
To make earned cosmetics feel like they matter, freshly unlocked items get flagged NEW: the main-menu Cosmetics button shows a dot, the menu shows a per-item badge, and opening the screen marks them viewed.
What’s wired, and what’s waiting
Live today and equippable: display modes, grid themes, ship skins, HUD themes, engine trails, and kill effects — every visible slot has a runtime consumer actually applying it. A few categories exist in the data model but are deliberately hidden until their feature lands — codex, gallery, badge and music-mode unlocks all persist correctly but have no consumer yet, so we gate them out of the gallery and the completion count rather than show a reward that does nothing. When the consuming feature is ready, un-hiding a category is a one-line change. We’d rather ship the honest subset than fake the rest.
Display modes are the headline slot — each one is a total visual reinterpretation of the whole game, not a filter dropped on top:

Forge — warm amber, the grid rendered as radiating heat.

Vector — the arena stripped back to pure monochrome wireframe.

Blueprint — the whole game re-skinned as a cold engineering drawing.
Next time
If everything here is the reward, the obvious question is what you do to earn the interesting ones. That’s Devlog #010 — Directives: the in-game challenge layer that sits above unlocks and gives you specific goals to chase, the structured counterpart to “just play more.” It’s where progression gets its sense of purpose.
Cosmetic only, no power creep, all of it data you can read top to bottom. That’s the deal we made with the leaderboard, and we intend to keep it. As always: we build in the open.
- pulse-zero
- design
- progression