Designing Credits and the Hangar
After expanding the enemy and boss content (Expanding the Content to 12 Enemies and 3 Bosses), I next worked on an in-game currency called credits to provide a reason to keep playing, along with a HANGAR screen where players can spend them to change their ship's appearance and performance. VOID STRIKER began as a simple, single-page browser game that assumes neither external assets nor network access, so this economy was first built as a completely offline system using only localStorage, referred to in the design as Phase 1.
Designing Score to Become an Asset Directly
The main way to earn credits follows a simple rule: at game over, the run's score divided by 100 is added to the balance. Instead of building a separate, complex achievement or mission system, connecting the existing score directly to the economy preserves the current gameplay loop while adding the new value of accumulating credits to the motivation to improve. Credits are awarded only once per run. Main.earnedCredits stores the most recent amount, preventing repeated awards on retries until the next death.
Check-Digit Design for Referral Codes
Referral codes that players can exchange provide another source of credits. The main concern was preventing brute-force entry of other people's codes from succeeding too easily. Of the eight digits, the last is a check digit derived from the weighted sum of the first seven (first digit×1 + second digit×2 + ... + seventh digit×7, modulo 10). This rejects most random digit strings during format validation. Rules that prevent using your own code or using the same code more than once add further safeguards against abuse while keeping the code itself a simple number.
A Collision Between the HANGAR Screen and Player Rendering
A small but representative bug appeared while implementing the HANGAR screen. VOID STRIKER continuously draws the player's ship on the title screen as a preview. Reusing that drawing process unchanged on the new HANGAR, CODE, and OPTION screens left the ship visible at the bottom center, where it could obscure the BACK button label, CODE keypad, or OPTION selections. The fix was simple: skip player rendering in the hangar/code/option states and render it only in the title state. It was a typical example of how casually reusing shared logic can unexpectedly reduce readability, and reinforced the need to review what each UI screen should display.
Making Skins More Than Cosmetic Purchases
Skins purchased in HANGAR change not only the player's color and shape, but also practical weapon performance such as fire rate, bullet damage, extra projectiles, and spread angle. If they were purely cosmetic, there would be less reason to spend earned credits on them. At the same time, large performance gaps would undermine the game's balance. I tuned the values so that overall damage per second increases strictly with price, aiming for a balance where an expensive skin provides a reliable benefit while the starter skin remains capable of clearing the game without purchases. Detailed values are listed in the skin and weapon catalog.
Looking Ahead
The current credit economy is a browser-only Phase 1 implementation, but its design also anticipates a future Phase 2 that connects to a Cloudflare Workers backend and synchronizes purchased-item ownership across devices. An optional networking layer called net.js was separated in advance and becomes fully disabled when the game runs from file:// or when no endpoint is configured. This design decision preserves VOID STRIKER's fundamental premise of remaining fully functional offline in the future.