趣味のゲーム開発が迷走していく様子を3パターン見てきました。それぞれが、失敗の跡を残すことで、正しいセットアップの姿を教えてくれます。
失敗その1:スコア管理をブラウザ任せにする
最もよくある、そして最も避けやすい失敗です。誰かがリーダーボード付きのゲームを作り、マルチプレイ用にWebSocketを組み込み、最終スコアの計算をクライアント側で行わせてからサーバーにPOSTする。受信側に検証は一切なし。実際にこれが起きる瞬間を見たことがあります——退屈したプレイヤーがDevToolsを開き、ネットワークタブを見つけて、9桁のスコアを送信し始めるまで、わずか4分。ハッカーだったからではありません。ゲーム側が採点用のペンをプレイヤーに渡して、自己採点させていたからです。
対策は巧妙なものではなく、地道なものです。クライアントを一切信用しない、それだけ。すべてのアクションはサーバー側で再検証し、すべての物理演算のティックはサーバー側の判定と照合し、ローカルでレンダリングして裏をかかれないよう祈るのではなく、状態を往復させるレイテンシのコストを受け入れる。だからこそ、サーバーサイドの権威性はここではあれば嬉しい程度の項目ではなく、必須基準です。ブラウザのコンソールから攻略できてしまうゲームは、クラッシュと同じ重大度の欠陥として扱われます。機能的にはそれと同じことだからです。
失敗その2:canvas要素とビープ音を「ゲーム」と呼んでしまう
これはデモ映えする一方、実際にプレイすると90秒で崩れます。CSSトランジションがいくつか、当たり判定、パンチ音代わりのサイン波——画面収録では問題なく見えますが、最初の本物のプレイヤーが「動きがおかしい」と言い、その理由をうまく説明できません。原因は物理演算です。「重なったら跳ね返す」式の自作コードは、質量、摩擦、衝突反応を正しく再現できず、プレイヤーは名前を付けられなくても、その違和感を感じ取ります。
ここでのゲーム開発では、代わりに実際のエンジンによるレンダリングを使用します。
- 物理演算とレンダリング — Web向けにはthree.jsによる本物の物理シミュレーション、より重い処理にはラボで本物のUnity 6を使用。
- アート — ストックアセットパックではなく、デザインディレクターが手がけます。
- オーディオ — 足音を頑張って再現するオシレーターではなく、サンプリングされた楽器を使用します。
これが選択肢ではなく必須である理由の詳細は、Real engines, real buildsで解説しています。
検証チェーンは、スクリーンショットでは見抜けない不具合を捉えます。
- キーを押す。
- スコアが実際に変動するか確認する。
- 音声出力をチェックする。
こんな基本的なことが役に立つのかと思うかもしれませんが、イベントリスナーが登録されずに最初のフレームは完璧に描画された後、静かにフリーズしてしまうビルドがどれだけ多いか知れば納得できるはずです。静止画ではそれを見抜けません。3ラウンド分のプレイに耐える必要がある検証なら、それを見抜けます。
失敗その3:友達にサーバーを立ち上げさせないとゲームで遊べない
優れたマルチプレイのプロトタイプは、この段階でよく息絶えます——ゲームが面白くないからではなく、「まずサーバーをnpm installして、この3つの環境変数を設定して」というのが、火曜の夜に誰かに頼むには荷が重すぎるからです。せっかく面白いものを作ったのに、セットアップガイドの下に埋もれさせてしまうのです。
ここでは、ソロプレイのゲームはどのサイトも同じ方法で公開できます——ワンクリックでライブなサブドメインへ、別途学ぶ手順もありません。マルチプレイは事情が異なります。どこかで動き続ける必要のある実際のサーバープロセスが存在するため、ホスティングを代行した上で公開用プレイページとして公開します。目的はシンプルで、「遊びたい?」への答えがREADMEではなく、グループチャットに貼れる1本のURLであるべきということです。
この対比から見えてくること
上記3つの失敗すべてに共通して欠けているものに注目してください——ローカル2人プレイです。1台のキーボード、2人のプレイヤー、たいていWASD対矢印キー、肘がぶつかり合う——配信の問題が一切ないという理由で過小評価されがちなモードです。リンクも、サーバーも、夜11時に何かをクリックしてくれる友達も不要。ただ隣に誰かが座って、「いや違う、あなたはプレイヤー2だから矢印キーね」で30秒。
| ローカル2人プレイ | オンラインマルチプレイヤー | |
|---|---|---|
| オンボーディング | 「いや違う、あなたはプレイヤー2だから矢印キーね」——30秒 | マッチメイキング、「対戦相手を待っています」の空虚な画面 |
| 配信 | ゼロ——リンクもサーバーも不要、夜11時に誰かがクリックする必要もない | 公開プレイページと、同時にオンラインの誰かが必要 |
| コンバージョン | ほぼ100%——障壁は「椅子を回すだけ」 | 対戦相手を待っている間に離脱 |
ショーケースのエアホッケーやアリーナ乱闘系のビルドは、まさにこの点を活かしています。
この3つの解決策——サーバー主導の権威性、本物のゲームエンジン、ホスティングされた公開プレイページ——に、ローカル2人プレイならではの強みを組み合わせると、実際にこのツールが対応できる範囲が見えてきます。
- シングルプレイヤー——基本形。
- ローカル2人プレイ——労せず得られる勝利パターン。
- オンラインマルチプレイヤー——DevToolsを開いた退屈な10代の子にも耐えられるよう作られている。
すべてのゲームはゲームごとの公開ステータス付きで「マイゲーム」ライブラリに集約されるので、どのビルドが良かったか、古いチャットのやり取りを掘り返す必要はありません。Androidアプリとしてパッケージ済みなら、そのままストア公開の手順に直結し、二度手間で別プロセスを始めずに済みます。
