TOP > BLOG

Development Blog

This blog records the bugs, design decisions, and trial and error encountered while developing VOID STRIKER independently. For details on how the game works, see the gameplay guide as well.

The four articles published so far record, in chronological order, real issues encountered during development: a debugging session that tracked down a touch-coordinate offset reproducible only on physical smartphones, a content expansion that rebuilt the enemy and boss roster from new bullet primitives, the design of a credit economy that turns score directly into an asset alongside the HANGAR screen UI, and accessibility work on the OPTION screen covering volume, screen effects, and data reset. Each article covers decisions made at a different stage of development.

• How I Fixed Misaligned Touch Coordinates on Physical Phones

  Published: 2026-07-11

  VOID STRIKER was originally built for keyboard controls only, with touch added later. This article investigates reports such as, "I tapped START on the title screen but opened HANGAR," and, "I tapped an item in HANGAR but selected the one below it," tracing them to a mismatch between tap positions and hit-detection positions caused by CSS transform:scale and a mobile browser's automatic zoom both being applied at once. The fix began with a debug overlay, triggered by adding debugtouch to the URL, that draws a crosshair at the internal tap coordinates so the offset could be measured on a physical device. The root fix replaced transform:scale with directly setting the #frame element's width and height to actual pixel values based on the computed scale, and a follow-up change updated the keyboard cursor position on tap so the highlighted item always matches the one actually selected. The article also reflects on the investigation process itself: because the bug was difficult to reproduce with emulators or developer-tool touch simulation and only appeared on physical devices, building a visualization tool before chasing the root cause proved to be the right order of operations.

• Expanding the Content to 12 Enemies and 3 Bosses

  Published: 2026-07-11

  A look back at expanding the enemy roster from four basic types and a single boss (now the vanguard archetype) to 12 enemy types and three boss archetypes. The work began by adding four new bullet primitives, orb, mine, homing, and wall, to the existing G.Bullets module so new bullets could reuse the collision code untouched. Those primitives supported six new enemies, weaver, sniper, splitter, bomber, aegis, and miner, along with two new boss archetypes, serpent and fortress, with stage-based unlock timing and difficulty scaling keeping the growing roster balanced. Each new enemy was also designed around a distinct role so the actions demanded of the player overlap as little as possible: sniper tests reaction speed by requiring a dodge after its telegraph, weaver tests patience by rewarding players who wait instead of chasing, and splitter tests anticipation by requiring a plan for the enemies it spawns on death. It also records a staged approach to introducing content: showing all 12 enemies at once would overwhelm first-time players, so stage 1 uses only the four basic types, later stages unlock newcomers gradually, and even within a single stage, waves are split into an opening 35%, a middle 40%, and a final 25% act, each drawing from a different pool.

• Designing Credits and the Hangar

  Published: 2026-07-11

  A look back at designing credits, the in-game currency that gives players a reason to keep playing, and the HANGAR screen where they are spent. Rather than building a separate achievement or mission system, connecting the existing score directly to the economy was chosen so it would preserve the current gameplay loop while adding the new value of accumulating credits to the motivation to improve. The article covers the simple rule of adding score divided by 100 to the balance at game over, plus a check-digit scheme built into eight-digit referral codes to discourage abuse. It also describes a bug where reusing the title screen's ship-preview rendering on the HANGAR, CODE, and OPTION screens hid UI elements, and the decision to tune skin performance so overall DPS increases strictly with price. The current credit economy is a Phase 1 implementation that works entirely through localStorage, but the article also looks ahead to a Phase 2 that would sync owned items across devices through a Cloudflare Workers backend, noting that an optional networking layer, net.js, was already separated out in preparation.

• Implementing Volume, Reduced Effects, and Data Reset

  Published: 2026-07-11

  A look back at implementing the OPTION screen, which brings together volume, screen-effect, and data-reset settings. It covers a three-stage volume-mixing design, with dedicated SFX and BGM gain nodes beneath a master gain so muting and volume adjustment never interfere with each other, and a SCREEN FX setting that reduces screen shake and flashes to about 25% strength without changing any existing shake or flash API. It also touches on making sure muting and volume adjustment never interfere, so volume settings remain stored while muted and setting volume to 0% never toggles the mute button, plus the choice to apply slider changes to BGM immediately rather than waiting for the next note, for the sake of responsive feedback. The article also describes a two-step WIPE DATA confirmation flow, built without alert or confirm, that only erases data if the player confirms again within three seconds. Settings are stored under the voidstriker_settings key, separate from economy data in voidstriker_meta, with each read and write protected by try/catch so that a failure in one does not affect the other, a small separation the article credits with keeping the save system easier to extend.