ブラウザネイティブゲームは本格化している：オープンソースの戦闘プロジェクトが示すもの

この調査を始めたときは、興味深いブラウザ戦闘の実験がいくつか見つかれば十分だと思っていた。ところが実際には、はるかに広いエコシステムが存在していた。ロックオンによるターゲティング、分岐するコンボツリー、ジャストパリィ、回避中の無敵、体勢システム、空中攻撃、ボスの予兆動作、モーションワーピング、ヒットストップ、武器同士の物理的な衝突、ゲームパッド対応、タッチ操作、決定論的シミュレーションまで備えた、本格的な三人称アクションのプロトタイプがある。

重要なのはそこだ。もはや、たまたまWebページ内で描画されるだけの小さなゲームではない。従来のアクションゲームと同じ工学的な問題に取り組みながら、URLとして配布され、すぐに遊べるものまで出てきている。

Web開発者として特に面白いのはこの点だ。従来のゲーム像では、インストーラー、大容量ダウンロード、パッチャー、ランチャーが当たり前で、ゲームを見つけてから実際に触るまでに時間がかかった。ブラウザはその経路を大きく圧縮する。リンクを開き、アセットを読み込み、そのままプレイを始められる。

今回の調査では、ブラウザで実際に遊べるビルドがあり、ソースコードも公開されているプロジェクトに絞った。Unity WebGLの書き出しは意図的に除外した。単にWeb向けにエクスポートされたゲームではなく、Web技術を前提に作られたゲームを調べたかったからだ。

見つけた中で特に優れていたプロジェクト

有用だったプロジェクトは、すべて同じ理由で優れていたわけではない。最も深いコンボシステムを持つものもあれば、三人称アクションの設計、戦闘シミュレーションの明快さ、物理的なヒット感で優れるものもあった。

結果が予想外だった理由

驚いたのは、単にグラフィックスがきれいだったからではない。洗練されたシーンを描画することは、ゲーム開発の一部分にすぎない。目立っていたプロジェクトは、入力バッファリング、戦闘状態の遷移、ターゲット選択、攻撃時の移動、アニメーションのタイミング、ヒット検出、敵のリアクション、防御受付時間、カメラ挙動、ヒット時のフィードバックといった、ごまかしでは説得力を出しにくい仕組みを実装していた。

ここから、いくつか重要な区別が見えてくる。

• アニメーションのタイミングと戦闘のタイミングは同じではない。
• 描画フレームレートとシミュレーションレートは同じではない。
• 衝突したからといって、自動的に有効なヒットになるわけではない。
• アニメーションが必ずしも移動の決定権を持つわけではない。
• 見た目上の接触と、体感としてのインパクトは同じではない。

こうした違いは優れたプロジェクトで何度も現れており、READMEに載っているレンダラーのロゴより重要だ。

Voxel Musou：ブラウザ戦闘にも本物の技の文法を持たせられる

Voxel Musouは、ブラウザ戦闘が「1つのボタンに1つの攻撃アニメーションを割り当てるだけ」である必要はないことを最も分かりやすく示す例の一つだった。ソースはmike007jd/voxel-musouで公開されている。

このプロジェクトは、単純な一直線のコンボではなく、長い通常攻撃チェーンとチャージ分岐を使っている。アーキテクチャ上これが重要なのは、システムを次のようにモデル化できるからだ。

current move + buffered input + combat state -> next move

特殊ケースの条件分岐を増やし続けるより、キャラクターアクションゲームの基盤としてははるかに優れている。空中攻撃、特殊シーケンス、複数キャラクターの技構成、ボスの挙動、ヒットストップ、大量の敵との戦闘も実装されている。

より一般化できる工学的な教訓は、技をデータとして扱い、遷移を明示的にするべきだということだ。そうすれば、新しいキャラクターを追加するたびに戦闘コントローラー全体を書き直す必要はなくなる。

Long Wind：現代的なブラウザアクションゲームに最も近い例

Long Windは、三人称移動に弱攻撃・強攻撃、ロックオン、ガード、ジャストパリィ、回避無敵、体勢への圧力、処刑、打ち上げ・ノックダウンのリアクション、飛び道具、ボス、複数の敵アーキタイプを組み合わせており、単一プロジェクトで全体像を追うための特に強い参考例の一つだった。ソースはjbang2004/long-windで公開されている。

個々の機能がすべて前例のないものだから価値があるわけではない。これらが一つのブラウザネイティブなアクションプロトタイプ内で共存していることに価値がある。入力からターゲット選択、攻撃状態、アニメーション、接触、リアクション、ヒットストップ、カメラフィードバックまでの一連の流れを追う参考になる。

モーションワーピングは、Webデモが見落としがちな問題を解決する

Samurai Third-Person Template ThreeJSが特に興味深いのは、三人称近接戦闘に古くからある問題を扱っているからだ。ソースはachrefelouafi/SamuraiThirdPersonTemplateThreeJSで公開されている。

作り込まれた攻撃アニメーションは、攻撃が接触フレームに到達した瞬間、ターゲットが特定の距離にいることを前提としている。しかし実際のゲームでは、ターゲットが完璧な位置にいることはほとんどない。キャラクターがその場でアニメーションを再生するだけなら、ゲーム上はダメージが入っていても剣が見た目では外れることがある。逆に、キャラクターを正しい位置へ瞬間移動させれば、攻撃は不自然に見える。

モーションワーピングは、よりよい解決策になる。攻撃中の回転と移動を調整し、正しいタイミングで想定された接触位置にキャラクターを到達させる。

重要なのは次の区別だ。

animation intent != movement authority

作成済みアニメーションの視覚的な意図を保ちながら、キャラクターが実際にどこへ移動するかについてはゲームプレイコントローラーが決定権を持ち続けられる。

衝突検出とヒットの妥当性判定は別の問題

Stick & Steelは、かなり異なる戦闘モデルを試している。ソースはRabneba/stick-steelで公開されている。

剣を主に「ダメージ判定を伴うアニメーション」として扱うのではなく、このプロジェクトは武器に物理的な存在感を持たせている。接触速度、武器の向き、身体の部位、ガード、武器同士の衝突、ノックダウン、武器落としがすべて意味を持つ。

最も応用しやすい教訓は、すべてのアクションゲームが完全な物理ベースの武器を採用すべきだということではない。重要なのは次の点だ。

衝突は、2つのものが触れたことを示すだけだ。それが意味のあるヒットだったかどうかまでは示さない。

説得力のある戦闘システムには、接触に十分な速度があったか、方向が正しかったか、武器の正しい部位が当たったか、タイミングが適切だったか、ターゲットの状態が有効だったかを判定し、ダメージとして成立するか決める第二のレイヤーが必要になることが多い。

戦闘判定を一元化すると、複雑な防御を理解しやすくなる

Hollowmereは、euuuuuuan/hollowmere-publicでソースが公開されており、派手な見た目よりもソフトウェアアーキテクチャの面で目立っていた。

戦闘シミュレーションは描画から分離され、防御判定は一元化されている。これにより、回避システム、パリィシステム、被弾リアクションシステム、アニメーション層が、同じ攻撃が命中したかどうかについてそれぞれ別の結論を出してしまうという、アクションゲームでよくある失敗を避けられる。

より整理された考え方は次のようになる。

incoming attack -> evade | parry | hit

レンダラーの役割は結果を表示することであり、戦闘の事実を別バージョンとして作り出すことではない。

戦闘が複雑になるほど、この区別は重要になる。決定論的シミュレーションや明示的な状態遷移は派手な機能ではないが、複雑な戦闘をテスト、デバッグ、拡張しやすくする。

ゲームフィールは装飾ではなく、工学的なシステム

Fabled Revolutionsは、ソースがericrius1/FabledRevolutionsで公開されており、攻撃に重みを感じさせる効果を切り分けて見せているからこそ有用だ。

論理的に正しい戦闘システムでも、弱く感じることはある。衝突判定が正確で、正しいフレームでダメージが適用されていても、2つのモデルが互いをすり抜けただけのように感じられることがある。

体感上のインパクトは、短時間だけ発生する複数の効果を重ねることで生まれることが多い。

• ヒットストップ。
• カメラシェイクやキック。
• 武器の軌跡。
• ヒット時のパーティクル。
• 被弾フラッシュ。
• ノックバック。
• アニメーションリアクション。
• 適切なタイミングの効果音。

ここからも重要な区別が分かる。戦闘として正しいことと、戦闘として気持ちよく感じることは同じではない。ブラウザゲームには両方が必要だ。

戦闘品質の主な指標はレンダラーではなかった

調査で見えた興味深い傾向の一つは、最も優れた戦闘が、最新のレンダリングAPIを使っているかどうかで決まっていなかったことだ。

Three.jsは何度も登場した。WebGPU関連のレンダリング技術を使うプロジェクトもあれば、従来のWebGLベースのスタックを使うものもあった。物理エンジン、TypeScript、JavaScript、Vite、WebAssembly、さまざまなレンダリング手法が調査全体に現れた。

それでも高度な戦闘をより一貫して支えていたのは、固定ステップシミュレーション、明示的な状態、信頼できるターゲティング、妥当なアニメーション制御の責任分担、データ駆動の技、ダメージ判定の一元化、良好なヒットフィードバックといったアーキテクチャだった。

これはWeb開発者にとって心強い。すべてのユーザーが最新のグラフィックススタックを使えるようになるまで待たなくても、本格的な戦闘設計を試し始められる。

ブラウザ配布が前提を変える理由

ブラウザには、グラフィックスとはほとんど関係のない強みがある。配布時の摩擦が非常に小さいことだ。

従来のゲームでは、発見してから操作するまでにいくつもの段階が入ることが多い。ストアページを探し、大きなパッケージをダウンロードし、インストールし、起動し、アップデートを待ち、ときには意味のあるゲームプレイに到達する前にアカウントまで作る。

ブラウザゲームなら、その経路を1本のリンクまで縮められる。

これは、プロトタイプの共有やテストのやり方を変える。開発者はビルドを公開し、URLを送り、相手に同じバージョンをすぐ触ってもらい、フィードバックを受け取り、テスターに新しいパッケージを手作業でインストールしてもらうことなく次のイテレーションをデプロイできる。

この強みは、実験的なゲームやインディー開発で特に重要になる。ブラウザは単なるランタイムではなく、配布システムでもある。

それでもブラウザが不利なところ

今回の調査で、ブラウザがネイティブのゲームプラットフォームを置き換えたと確信したわけではない。実際、置き換えてはいない。

重要な制約はいくつも残っている。

• 大容量のアセットペイロード。初回に非常に大きなダウンロードが必要なら、「すぐ遊べる」という感覚は失われる。
• メモリ圧力。ブラウザは他のタブやOSと共存する必要があり、メモリの挙動は専用のネイティブプロセスほど予測しやすくない。
• モバイル端末の熱制約。技術的には動作する3Dゲームでも、長時間のセッションでは大きくスロットリングすることがある。
• ブラウザ間の差。グラフィックス、オーディオ、ポインターロック、フルスクリーンの挙動、コントローラー、性能特性は完全には統一されていない。
• シェーダーとアセットの準備。パイプラインを慎重に設計しなければ、コンパイルやアップロード処理によって目に見える停止が起こることがある。
• オフラインとローカル永続化の制約。大規模なローカルインストールやファイルについては、ネイティブアプリケーションの方が直接的な制御を保ちやすい。
• 対戦ゲームのセキュリティ。クライアントがWebアプリケーションの場合、本格的なアンチチートや敵対的クライアントを前提とした設計は、はるかに難しくなる。

これらの制約は、現在ブラウザゲームがどこで最も強いかを決めるため重要だ。即時アクセス、高速なイテレーション、クロスプラットフォーム配信、管理可能なアセット／ランタイム予算の恩恵が大きいゲームに向いている。

AIはプロトタイプからURLまでのループを大幅に短くする

ここでAIが関係するのは、文章を1つ入力すれば高品質な完成ゲームへ魔法のように変わるからではない。より現実的な利点は、イテレーション速度だ。

現代のゲーム開発には、個別には小さくても合計すると高コストになる作業が多い。ステートマシンの構築、デバッグビューの作成、テストの記述、敵の挙動の試行、技のデータ形式の作成、入力コードのリファクタリング、シェーダーのプロトタイピング、物理バグの調査、一時コンテンツの接続などだ。

AIはそうしたループの多くを短縮できる。Web配布と組み合わせると、ワークフローはかなり直接的になる。

idea -> prototype -> deploy -> open URL -> test -> iterate

ブラウザはすでにデプロイを高速にしている。AIは同じループの実装側もさらに速くできる。

ただし重要な注意点がある。生成が速くなっても、センスや検証の代わりにはならない。生成された戦闘コントローラーの構造が間違っていることもある。アニメーションのタイミングには依然として人の判断が必要だ。物理は依然としてデバッグが必要で、性能も測定しなければならない。AIが下げるのはアイデアを試すコストであり、どのアイデアが良いかを決める必要まで消すわけではない。

Web開発者にとって何を意味するのか

Web開発とゲーム開発の境界は、以前ほど明確ではなくなりつつある。

本格的なブラウザゲームは、慣れ親しんだWebツールを使いながら、古典的なゲーム工学の概念も必要とする。

• 固定シミュレーションステップ。
• ステートマシン。
• 入力バッファリング。
• アニメーショングラフ。
• 空間クエリ。
• 物理。
• フレーム予算。
• GPUリソース管理。
• オーディオタイミング。
• 決定論的システム。

同時に、ブラウザを対象とするゲーム開発者は、Webがもともと非常に得意としているものも得られる。URL、即時デプロイ、CDN配信、高速な更新、テレメトリ、アカウントシステム、レスポンシブなインターフェース、摩擦のない共有だ。

今回の調査で、自分自身の見方も変わった。ブラウザゲームを、主にネイティブゲームの簡易版として捉えることはもうない。ブラウザは、即時配布、高速なイテレーション、ますます本格化する3D機能、そして巨大な既存の開発エコシステムという異なる強みを持ち、能力を高め続けているゲームプラットフォームだと考えている。

Webは、別の場所で作られたゲームを表示するのが上手くなっているだけではない。本格的なゲームシステムを設計し、実装し、テストし、配布し、そのまま直接プレイできる場所になりつつある。