クレジットとハンガーの設計
敵とボスのコンテンツを拡張したあと（敵12種・3ボスへのコンテンツ拡張）、次に取り組んだのがプレイの継続動機を作るための「クレジット」というゲーム内通貨と、それを使って自機の見た目・性能を変えられる
HANGAR
画面でした。VOID STRIKERは外部アセットも通信も前提にしないシンプルな1枚もののブラウザゲームとして始まったため、この経済システムもまずは完全にオフラインで、localStorage
だけで完結する形（設計上のPhase 1）として組み立てています。
「スコアがそのまま資産になる」設計
クレジットの主要な入手経路は、ゲームオーバー時にその回のスコアを100で割った値を加算する、という単純なルールにしました。複雑な実績システムやミッションを別立てで作るより、既存のスコアという指標をそのまま経済に接続したほうが、既存のプレイループを崩さずに「もっと上手くなりたい」というモチベーションに「クレジットが貯まる」という新しい価値を上乗せできると考えたためです。加算は1プレイにつき一度きりで、リトライ時に何度も加算されないよう
Main.earnedCredits
に直近の獲得額を保持し、次の死亡まで再加算しない設計にしています。
紹介コードのチェックディジット設計
クレジットのもう一つの入手経路として、プレイヤー同士でコードを交換できる紹介コード機能も用意しました。ここで気を配ったのは「他人のコードを総当たりで打ち込んでも、そう簡単には通らない」ようにすることです。8桁の数字のうち下1桁を、残り7桁の重み付き和（1桁目×1 + 2桁目×2 + ... + 7桁目×7 の10で割った余り）から求まる検査数字（チェックディジット）にすることで、ランダムな数字列のほとんどは形式チェックの時点で弾かれるようにしました。自分自身のコードは使えない、同じコードは1度しか使えない、といった細かいルールも、シンプルな数字コードだけで不正利用をある程度抑止するために積み重ねたものです。
HANGAR画面とプレイヤー描画の衝突
HANGAR画面を実装する過程で見つかった小さな、しかし象徴的なバグがありました。VOID STRIKERはタイトル画面で自機のプレビューを兼ねて自機を描画し続けているのですが、この描画処理をHANGARやCODE、OPTIONといった新しい画面でもそのまま流用していたため、画面下部中央に自機が常時表示され、そこに重なる形でBACKボタンのラベルやCODE画面のキーパッド、OPTION画面の選択項目が隠れてしまうことがありました。修正はシンプルで、hangar/code/option
の各状態では自機の描画そのものをスキップし、title
状態でのみ描画するようにしました。「共通処理を安易に使い回すと、思わぬところで視認性を損なう」という典型例で、UI画面ごとに何を表示すべきかを都度見直す必要性を再確認させられた修正でした。
スキンを「見た目だけの課金要素」にしない
HANGARで購入できるスキンは、単に自機の色や形が変わるだけでなく、連射レート・弾のダメージ・追加弾の有無・拡散角といった実際の射撃性能にも差をつけています。見た目だけのコスメにすると、稼いだクレジットをつぎ込む動機が弱くなってしまうと考えたためです。とはいえ性能差が大きすぎるとゲームバランスが崩れるため、価格順に総合火力（DPS）が厳密に増加するよう数値を調整し、「高いスキンを買えば確実に報われるが、無課金でも初期スキンで十分クリアを狙える」バランスを目指しました。詳しい数値は スキン＆武装カタログにまとめています。
この先の展望
現在のクレジット経済はブラウザ内で完結するPhase 1の実装ですが、将来的にはCloudflare
Workers上のバックエンドと連携し、購入したアイテムの所持状態を複数端末で同期する仕組み（Phase
2）も見据えて設計しています。net.js
というオプショナルな通信レイヤーをあらかじめ切り出しておき、
file://
で起動した場合や通信先が未設定の場合は完全に無効化される作りにしているのは、「オフラインで完結する」というVOID STRIKERの大前提を将来にわたって崩さないための設計判断です。