HTMLとZIPで公開できるゲームと、サーバーが必要なゲームの違い

静的ファイルホスティングとは何か

Webブラウザは、HTML・CSS・JavaScript・画像・音声ファイルといった静的ファイルを受け取り、ブラウザ自身の中で実行する。サーバー側でプログラムを動かして結果を生成する必要がなければ、配信側はファイルをそのまま返すだけでよい。このような配信方式を「静的ホスティング」と呼ぶ。

HTMLゲームの多くは、ゲームロジックをJavaScriptとして記述し、描画をCanvasやDOMで行う。これらはすべてブラウザ内で完結するため、静的ファイルとして配信できる。アソバースでは、HTMLファイルの直接投稿、複数ファイルをまとめたZIPファイルの投稿、または公開済みURLの登録という方法で、こうした静的ゲームを公開できる。

静的ファイルだけで動くゲームの条件

次のすべてに当てはまるゲームは、静的ファイルだけで公開できる。

• ゲームのロジックと描画処理がすべてJavaScript（またはWASM）として記述されており、ブラウザ内で完結している
• 外部サーバーにリクエストを送らない。必要なデータ（マップ、テキスト、設定）はファイルに含まれているか、ブラウザ内で生成される
• セーブデータを扱う場合、ブラウザの localStorage または IndexedDB に保存する（そのブラウザ・端末内にのみ保存される）
• 同一画面での2人プレイ（ローカルマルチプレイ）や、ひとりで完結するパズル・アクション・音楽ゲームなど、リアルタイムのサーバー通信が不要

代表的な構成として、Phaser・p5.js・KAPLAYといったゲームライブラリを使ったもの、Three.jsでの3D表現、あるいはライブラリなしのVanilla JSも含まれる。ビルド後に単一HTMLとして出力するツール（Twine、GDevelopのHTML出力など）も同じカテゴリに入る。

localStorageに保存されたセーブデータは、そのブラウザとオリジン（ドメイン）に紐づく。ゲームのURLが変わると別のストレージになる。異なる端末間での同期には対応しておらず、プライベートブラウジングでは閉じると消える。

サーバーが必要になる機能

ゲームに次のような機能が含まれていると、静的ファイルだけでは動かせない。ブラウザ外に常時稼働するサーバーが必要になる。

リアルタイムオンライン対戦・協力プレイ

離れた端末同士がゲーム内の状態をやり取りするには、WebSocketなどのプロトコルを使って双方向通信を維持するサーバーが必要になる。WebSocket接続は、対応したサーバーエンドポイントがなければ確立できない。静的ファイルホスティングはHTTPによるファイル配信に特化しており、WebSocketサーバーの役割は果たさない。

全ユーザー共有のランキングや統計

複数プレイヤーのスコアをまとめて管理する機能は、データを蓄積・照合するサーバーとデータベースが必要になる。localStorageはその端末・ブラウザにしか存在しないため、他のプレイヤーのデータを参照できない。

ゲーム内でのアカウント認証・クラウドセーブ

「ログインして続きから遊ぶ」という機能を実現するには、認証トークンを発行・検証するサーバーとセーブデータを保持するデータベースが必要になる。アソバースへのログインはプラットフォームのアカウント管理として機能するものであり、ゲーム内部のロジックに自動で適用されるわけではない。

アソバースはゲームアカウント連携SDKを提供しており、このSDKを利用することで、独自のサーバーやデータベースを用意せずにプレイヤーのセーブデータをアソバースのクラウドに保存する機能を実装できる。ただし、SDKの導入はゲーム側での明示的な接続実装が必要であり、アソバースへのログインのみで自動的に適用されるわけではない。詳しくはゲームアカウント連携の説明ページを参照してほしい。

サーバーサイドでの処理を前提とする機能

不正防止のためにスコア計算をサーバー側で行う構成、外部APIの秘密鍵をブラウザに渡さずに使う構成、大きなデータを動的に生成する構成なども、サーバー側の処理を必要とする。これらはゲームのジャンルというよりも、実装上の設計の問題である。

自分のゲームがどちらか判断する手順

「サーバーが必要かどうか」を確認するには、ゲームのコードの中で外部への通信が発生しているかどうかを調べるのが最も確実だ。以下の手順で確認できる。

1. ブラウザの開発者ツール（F12）を開き、[ネットワーク] タブを表示した状態でゲームを起動し、ひと通り操作する。
2. 表示されるリクエストの一覧を確認する。自分が用意したファイル（JS・CSS・画像・音声）以外への通信が発生していないかを見る。
3. WebSocket接続（[WS] または [WebSocket] として表示される）や、外部のAPIサーバーへのfetch・XHRリクエストがなければ、静的ファイルで動く可能性が高い。
4. 外部への通信があった場合、その通信先が何をしているかをコードで確認する。CDNからライブラリを読み込んでいるだけであれば、そのファイルをローカルにコピーすれば通信は不要になる。ゲームの状態をサーバーに送受信しているなら、サーバーが必要な設計だと判断できる。

外部通信がなく、ローカルで開いたHTMLファイルを使ってゲームが正常に動くことが確認できれば、そのままZIPにまとめて投稿できる状態に近い。

ローカルの file:// 環境と、HTTPSで配信される環境では、localStorageの動作やCORS制限の挙動が異なる場合がある。ローカルで動いていてもHTTPS配信後に問題が出ることがあるため、可能であれば簡易HTTPサーバー（例：npx serve）を使ってローカル確認することを勧める。

ZIPで投稿するときの基本構成

複数ファイルで構成されるゲームをアソバースに投稿する場合は、ZIPにまとめて投稿する。ZIP内のファイル構成はゲームが正しく動く形にする必要がある。以下は基本的な構成例だ。

mygame.zip
├── index.html        ← ゲームのエントリーポイント
├── game.js           ← ゲームのスクリプト
├── style.css         ← スタイルシート（使う場合）
├── assets/
│   ├── bg.png
│   └── se.wav
└── lib/
    └── phaser.min.js ← ローカルにコピーしたライブラリ

エントリーポイントは index.html という名前のファイルにするのが一般的だ。ZIPのルートに index.html があれば、投稿先のホスティング環境はそこから読み込みを開始する。サブディレクトリにのみ index.html がある構成は、環境によってはルートとして認識されないことがある。

ファイルパスは 相対パス で書く。「/assets/bg.png」のような絶対パスは、別のオリジンで動かすと壊れることがある。「./assets/bg.png」や「assets/bg.png」と書いておけば、配信先が変わっても動く。

判断に迷う構成と対処の考え方

実際には「ほぼ静的だが一部だけ外部通信がある」という構成も多い。代表的なケースとその対処を整理しておく。

CDNからライブラリを読み込んでいる

Phaser・p5.js・KAPLAYなどをCDNから読み込んでいる場合、CDNが停止するとゲームが動かなくなる。ライブラリをダウンロードしてZIPに同梱し、相対パスで読み込む形に変えれば外部依存を排除できる。容量が増える分、ZIPファイルサイズの上限に注意する。

BGMや画像をfetchで非同期読み込みしている

同じZIP内のファイルをfetchで読む構成は、HTTPSで配信されていれば通常は動く。ただし file:// で直接開く場合はCORSエラーになることが多い。これはHTTPSホスティングに投稿することで解決する。

外部のゲームエンジンでビルドした場合

GodotのHTMLエクスポート、Unity WebGLビルドなどは、出力されたファイル群をそのままZIPにまとめて投稿できる。これらは基本的に静的ファイルだが、SharedArrayBufferを使う構成（Unityのスレッドモードなど）は、ホスティング側でHTTPレスポンスヘッダーに特定の設定が必要になる場合がある。投稿先の仕様を確認した上でビルド設定を選ぶ必要がある。

サーバー処理が必要だと判断した場合は、Firebase Realtime Database・Supabase・Cloudflare Workersといった外部サービスをゲーム側から利用し、静的ファイルとして配信しながらサーバー機能を実現する方法がある。ただし、それらのサービス自体のコスト・利用規約・接続制限は各サービスの公式情報を確認する必要がある。この記事ではアソバースの投稿形式の範囲のみを扱い、外部バックエンドサービスの選定については別の機会に取り上げる。

静的ファイルで完結するゲームは、投稿から公開までのステップが最も少ない。自分のゲームにサーバーが必要な機能が含まれているかどうかを、開発者ツールの ネットワークタブ とコードの確認で一度整理してみると、投稿前の見通しが立てやすくなる。