PuzzleVaultはHTML、CSS、JavaScriptでブラウザのパズルを構成しています。各ページはナビゲーション、言語選択、結果共有の共通スクリプトと、そのゲームのルールを扱うスクリプトを読み込みます。Canvasに描く盤面もあれば、実際のボタンや文書要素を使う画面もあります。小さなゲームごとに動きを追える構成です。
この選択は、フレームワークより常に高速だという主張ではありません。フレームワークでも快適で利用しやすいゲームを作れます。現在の数値更新、駒の移動、盤面の描画は、コンポーネント用の仕組みを追加しなくても表現できます。入力から表示までの処理を直接調べやすいことが、このプロジェクトでは役立っています。
1. 読み込みはなくなりません
HTML、スタイル、スクリプト、必要な翻訳データはダウンロードが必要です。通信、キャッシュ、端末の性能、ほかのリソースが操作可能になるまでの時間に影響します。フレームワークの実行コードを追加しないことは依存関係を減らす選択であり、待ち時間をゼロにする仕組みではありません。
NumVaultの推理ルールは専用コードにあり、言語選択や共有は共通コードにあります。共通部分の修正を複数のゲームへ届けられる一方、重複処理やスクリプトの読み込み順序を整理する責任も残ります。
2. ゲームに合う描画方法を選ぶ
PatternPopの盤面と立体的なパッドはCanvasで描きます。QuickCalcは回答に実際のボタンを使い、フォーカスや選択の操作を利用します。Canvasでは座標判定やキーボード操作を用意し、文書要素ではレイアウトと更新を管理します。一方の技術だけで操作性が決まるわけではありません。
requestAnimationFrameはブラウザの描画周期に合わせて処理を予約します。固定フレームレートの保証ではありません。端末の負荷、画面の更新頻度、バックグラウンドの状態で間隔が変わります。制限時間の計算には、フレーム数ではなく実際の経過時間が必要です。
3. 依存関係が少なくても保守は続く
現在のゲームコードは、フレームワークのビルド工程を経ずに静的ファイルとして配信できます。そのため配信対象を確認しやすくなります。ただし、遅れて実行される処理の停止、挑戦リンクの検証、保存できない場合の処理、ブラウザごとの確認は必要です。標準APIを使うだけで永久に保守不要になるわけではありません。
サービスワーカーのキャッシュも管理対象です。保存済みのファイルは再訪時に役立ちますが、更新時には古いコードを入れ替える必要があります。異なるバージョンのスクリプトが混在しないことは、最初の画面が表示される速さと同じく重要です。
4. 操作して確かめる
狭い画面、タッチ、キーボードだけの操作、動きを減らす設定を確認します。アニメーション中の再開始や、別のタブから制限時間付きのゲームへ戻る操作も対象です。描画が速くても、押した場所と選ばれる場所が違えば快適には遊べません。
電池の消費量はフレームワークの有無だけでは判断できません。描画頻度、効果の計算、バックグラウンド処理、端末が関係します。不要な処理を減らし、条件をそろえて測ることが大切です。ここで実測の電池寿命や読み込み時間を示しているわけではなく、ゲームと一緒に調べ、直し、検証しやすい構成を説明しています。
PatternPopとNumVaultを比べると描画方法の違いが分かります。共通する目標は、次の操作とその結果を分かりやすくすることです。