Alias Archiveアーカイブ更新中
アーカイブ更新中

ウェブ戦闘標本:ゲーム本編から配布可能なDemoへ

ウェブ制作記録01 / SERIES

『守夜人』の移動、攻撃、回避、体勢崩し、処刑のループをウェブDemoへ移植した記録。素材境界、手触りの校正、Web書き出し、読み込み操作までを扱う。

記録日
所属分野
その他
言語版
JA / 閲覧版
Gamesページ内に配置された『守夜人』のウェブ戦闘標本
戦闘標本は独立した宣伝ページではなく、操作可能な制作記録としてプロジェクトアーカイブの中に置いた。

Gamesページには実際に遊べるものを置きたかったが、目標は『守夜人』の縮小版を作ることではなかった。より適切なのは、本編から最小で完全な戦闘ループを切り出すことだ。キャラクターは移動とジャンプ、攻撃と回避ができる。敵には強靭があり、体勢を崩した後に処刑できる。約一分の操作で、基礎となる戦闘のリズムを理解できればよい。

完成したDemoはブラウザ上で直接動作する。閲覧者はGodotもゲームクライアントもインストールする必要がない。ただし本編らしい手触りに至るまでには、典型的な失敗が続いた。キャラクターが後ろ向きに歩く、攻撃中に滑る、敵が瞬間移動して見える、足場が進行を阻むだけで着地できない、密着すると攻撃が当たらない、素早い追加入力が時々消える、読み込み後もゲーム枠をもう一度クリックしなければ操作できない、といった問題である。

これらはすべて同じ結論を示している。戦闘の手触りを移植するとき、動くことは最低条件にすぎない。本当の基準は、挙動が本編の仕様を守っているかどうかである。

この戦闘標本はGamesページに組み込まれており、移動、攻撃、回避、体勢崩し、処刑をブラウザ上で直接試せる。GamesでDemoを試す ↗

目的:ゲーム全体ではなく、一つのループを移す

ウェブDemoの範囲は意図的に狭くした。固定レベルと固定攻撃力、単純な敵一体、高低差のある足場一つ、そして移動、ジャンプ、攻撃、回避、体勢崩し、処刑という六つの操作だけである。セーブ、クエスト、装備、マップ、成長システムには接続せず、本編の実行時スクリプトも共有しない。

目的は二つある。ウェブパッケージを静的配信できる大きさに保つこと。そして、本編側の変更へ暗黙に依存せず、Demo単体で検証できるようにすることだ。

ゲーム本編からウェブ戦闘標本までの移植経路

ただし「分離」は再発明を意味しない。Demoには独立した最小シーンと制御スクリプトがあるが、アニメーション素材、フレーム情報、効果音、書体、主要な戦闘規則については、本編を唯一の基準とする。 これはゲームの断面であり、第二の開発ブランチではない。

素材境界:フォルダ複製ではなく許可リスト

プロジェクトフォルダをそのまま複製する方が速い。しかし、無関係な素材、エディタキャッシュ、本編スクリプトまでウェブパッケージに入り、Demoが実際に何を使っているのか説明できなくなる。

最終的には明示的な許可リストを採用した。同期スクリプトが本編からコピーするのは31項目だけである。プレイヤーの待機、走行、ジャンプ、回避、攻撃、被弾、死亡、敵の各アニメーションとmanifest、森の背景五層、ピクセル書体、斬撃、命中、体勢崩し、ローリング、死亡、咆哮、処刑の効果音が含まれる。リスト外の内容はDemoへ入れない。

単純なファイル整理に見えるが、ここで最も重要な工程境界が生まれた。すべての依存項目を説明し、点検できる。承認済みの本編素材が変われば、同じ経路で再同期できる。

初回実装:動くが、本編とは違う

最初の版はすぐに動き、同じ速さで問題を露呈した。キャラクターの向きが逆で、本編にはない慣性が付き、攻撃中に滑った。足場へ着地すると、しゃがみ姿勢の一枚で止まった。敵は接触時に急に位置を変え、密着した攻撃は当たらない。一度の被弾で長く硬直し、本編に存在する効果音、ダメージ数字、ピクセル書体も欠けていた。

これらは独立した見た目上のバグではない。一般的なプラットフォームゲームの近似実装を、『守夜人』固有の規則の代わりに置いた結果だった。

表面上の症状原因修正方針
キャラクターが逆向きに歩くスプライトの基準方向が一般的な想定と異なる本編の向き規則を読み、そのまま守る
攻撃中に滑る攻撃状態が水平移動を管理していない本編の状態に従って移動を停止または制限する
敵が瞬間移動して見える本編にはない阻害用の身体衝突を追加した押し合いをなくし、攻撃と被弾の関係だけ残す
足場に乗れない / 着地後にしゃがみ姿勢で止まる一方通行足場、着地判定、アニメーション状態が混在している着地処理とアニメーション遷移を分離する
密着攻撃が外れる命中判定が向きと中心間距離に依存しすぎている攻撃到達範囲を使い、距離ゼロの重なりも許可する
一撃ごとに長く硬直するプレイヤーの強靭仕様を省略した強靭を戻し、通常被弾の硬直を短くする
移植の境界

原型が遊べても本編らしくない場合、そこで装飾を止める。向き、状態の時間、衝突層、攻撃距離、強靭、移動規則を本編で確認し、誤った前提を追加パッチで隠さない。

本編へ戻る:戦闘仕様を一つずつ取り出す

修正はDemoの見た目から逆算せず、本編と直接比較した。キャラクターアニメーションは既存のフレーム情報と足元アンカーを使う。攻撃中の移動、ヒットストップ、後退は本編の状態ロジックに沿って再構成した。敵から阻害用の身体衝突を外し、双方が接近して重なれるようにする。接触が意味を持つのは、攻撃が実際に命中した時だけだ。

強靭も戦闘ループへ戻した。通常攻撃は強靭を減らすが、毎回長時間停止させない。強靭がゼロになった時だけ体勢崩しへ移り、処刑が可能になる。処刑の検出範囲は通常攻撃より広い。Xを押すとキャラクターが演出位置まで自動で近づき、その後に処刑を始める。特定の一点へ正確に合わせる必要はない。

連続攻撃には約0.35秒の入力バッファを加えた。現在の攻撃が終わる前に再び攻撃を押すと、その指示を保持し、連携可能な窓が開いた時に実行する。連撃を速くする仕組みではなく、素早い正当な入力がフレーム間で消えるのを防ぐ仕組みである。

プレイヤー、敵、体力、スタミナ、強靭表示を備えたウェブ戦闘Demo
稼働中の戦闘標本。処刑は通常命中ではなく、強靭を削り切った体勢崩しの後に成立する。

本編にある効果音、ダメージ数字、ピクセル書体も戻した。以前欠けていたのはウェブの制約ではなく、「後で加える装飾」と誤って扱ったためだ。斬撃音、ヒットストップ、浮かぶ数字、字形はすべてフィードバックを構成する。どれか一つを外しても、手触りは薄くなる。

Webパッケージ:エンジンをアーカイブの後ろへ置く

分離したGodotシーンは、ブラウザで実行できるWebビルドとして書き出す。現在の公開パッケージは7ファイル、約10.6 MiBである。WebAssembly本体はgzip済みの静的ファイルとして配信し、ブラウザのDecompressionStreamでローカル展開する。閲覧者に必要なのはWebAssembly対応の現代的なブラウザだけで、Godotのインストールは不要だ。

Gamesページを開いた時点では、この10.6 MiBを読み込まない。最初にアーカイブ形式の起動パネルだけを表示し、閲覧者が戦闘標本へ入る操作をした時にiframeを生成して読み込みを始める。遊ばない人にはゲーム素材の通信負担がなく、通常ページの初期表示もエンジンから切り離される。

Godot標準の読み込み画面は隠し、サイトと同じアーカイブ形式の読み込みブリッジに置き換えた。外側ページが実際の転送進捗を監視し、現在のパッケージと割合を表示する。内側のエンジンが初期化を終えるとpostMessageでreadyを送り、ページがcanvasを表示する。失敗時には説明と再試行を残し、理由のない黒画面で終わらせない。

実進捗98パーセントを表示するGodotウェブDemo用の読み込みブリッジ
標準ローダーをアーカイブ式ブリッジへ変更した。画面の98パーセントは装飾アニメーションではなく、実際の転送進捗である。

最後の問題は、読み込み成功後に起きた。デスクトップでは読込完了後もキーボードが反応せず、ゲーム枠をもう一度クリックする必要があった。フォーカスが外側ページに残っていたためだ。現在はready受信時に外側からiframeへフォーカスを渡し、内側でGodot canvasを明示的に選ぶ。起動ボタンを押した一回の操作が、そのままゲーム操作へつながる。

検証:自動化で境界を守り、実機操作で手触りを決める

この作業を一種類のテストだけで検証することはできない。ビルドと自動検査は素材パス、静的出力、ページ状態、メッセージブリッジを確認する。デスクトップとモバイルのプレビューでは、寸法、全画面、スクロール、読み込み失敗、キーボードフォーカスを確認する。移動、攻撃、密着命中、足場着地、体勢崩し、処刑は、連続した実機操作で判断しなければならない。

最も価値のある報告は、自動テストが表現しにくいものだった。「歩行に慣性がある」「攻撃で滑る」「敵が瞬間移動する」「処刑範囲が違う」。これは曖昧な感想ではなく、本編の手触りと移植結果の差分報告である。各差分を状態、衝突、時間の問題へ翻訳することで、初めて移植が完了する。

配信後の第二段階:入力をウェブに合わせる

デスクトップで一局を終えられても、公開用Demoとして完成したとは限らない。配信版をスマートフォンで試すと、別種の問題が現れた。全画面ボタンが反応せず、完了画面に「タップして再開」と表示されても実際には再開しない。デスクトップの操作表示にはショートカットが足りず、モバイル側はボタンが多すぎて文字を読みにくかった。さらに別の障害として、公開版は読み込めるのにローカル開発ページだけが3パーセントで止まることもあった。

3パーセント停止は、同じ不具合の再発ではなかった。一つはGodot 4.7の厳格な型推論検査に由来し、書き出し前にスクリプト解析を通す必要があった。もう一つはディレクトリURLの扱いの差である。Cloudflare Pagesは/game/watchman-demo/を入口文書へ解決したが、Astroのローカル開発サーバーが同じ動作を保証するわけではない。iframeは最終的に/game/watchman-demo/index.htmlを明示して読む形へ変更した。つまり、「公開版が動く」ことと「統合方法が正しい」ことは同義ではない。 エンジン書き出し、開発サーバー、最終配信先をそれぞれ検証する必要がある。

モバイル全画面も、ブラウザのFullscreen APIだけには依存できなかった。iframeを挟むと、全画面、画面方向、ユーザー操作に関する制約が端末ごとに異なる。現在はネイティブ全画面が使えない場合、ページ内の擬似全画面レイアウトへ退避し、常に明確な終了経路を残す。システム全画面を装うのではなく、まずcanvas、操作領域、退出手段を利用可能にするための設計である。

「タップして再開」は、表示上の約束と入力実装がずれた典型例だった。最初の修正では文言だけが変わり、タップ判定は依然として下部の攻撃ボタンの小さな矩形だけを監視していた。完了カードを押しても反応しないのは当然である。修正版では完了状態が新しいタッチまたはマウスクリックを通常操作より先に受け取り、戦闘をリセットする。操作可能な範囲が画面の表現と一致した。

症状実際の原因最終対応
公開版は動くが、ローカルは3パーセントで停止書き出し検査とディレクトリ入口の解決が環境ごとに異なる書き出し前に解析し、index.htmlを明示する
モバイル全画面が反応しない埋め込み全画面の挙動が端末ブラウザで一定しないネイティブ全画面に加えてページ内の代替表示を用意する
「タップして再開」で再開しない文言は画面全体を示すが、コードは一つのボタンだけを監視する完了中は任意の新規クリックでリセットする
ボタンが多く、文字が小さく、役割が重複する本編とデバッグ中のキー割当てをそのまま残したウェブ用の一つのループに合わせて入力を整理する

最終的なキー配置は、完全な本編を模倣しない。方向キーで移動し、ZまたはSpaceでジャンプ、Shiftで回避、Xを唯一の文脈操作とした。通常時のXは攻撃で、敵の体勢が崩れた後は同じXが自動接近と処刑を始め、完了後は再開を担う。モバイル側も左、右、ジャンプ、回避、文脈操作の五領域へ整理し、操作ボタンの表示はSTRIKEEXECUTERESTARTの間で状態に応じて変化する。

第二段階の原則

入力の簡略化は戦闘機構の削除ではなく、文脈判断を状態機械へ移すことである。ウェブDemoに本編の全キー配置は必要ない。キーボードとタッチのどちらでも同じループを完了し、もう一度始められる最小で明確な操作が必要だ。

この段階で検証順序も整った。まずGodotのヘッドレス解析とWeb書き出しを行い、次にAstroの本番ビルドと静的テストを通す。直接入口、埋め込みページ、Cloudflare配信を別々に確認し、最後に実機スマートフォンで一局を完了する。自動化はファイルとメッセージブリッジの接続を証明できるが、「見えているのに押せないボタン」を発見できるのは実機操作である。

結論:Demoは戦闘仕様の標本である

今回の原則
  • 範囲を縮め、規則は変えない:一つのループだけ残しても、その中の挙動は本編から取る。
  • 素材は許可リストから入れる:容量、出所、更新経路を常に追跡可能にする。
  • 見た目の失敗を仕様層で直す:向き、衝突、強靭、入力バッファ、処刑移動を外観だけで近似しない。
  • エンジンをウェブ体験に従わせる:遅延読み込み、実進捗、失敗復旧、フォーカス受け渡しもDemoの一部である。
  • 自動化は工程境界を守り、手動操作が手触りの成立を決める。

このウェブDemoの価値は、サイト内でゲームを遊べることだけではない。『守夜人』の最小の戦闘仕様を完成したプロジェクトから分離し、暗黙だった規則を説明可能、検証可能、配布可能な形にした。本編が変化しても、この標本は直接比較できる対象として残る。すべてを見せるためではなく、最も基本的な戦闘リズムが維持されているか確認するためのものだ。

あわせて読む

04 / LINKS
C01

戦闘の手触り設計:体勢崩し、処刑、リズム制御

『守夜人』が強靱度、体勢崩し、処刑、パリィ判定によってソウルライク戦闘の重量感を構成する方法を記録する。

全文を読む ↗
C02

素材パイプライン:再梱包、マニフェスト、管理ツール

素材の購入は開始点にすぎない。数百の素材パックを扱うための、アトラス再梱包、マニフェスト生成、管理ツールを記録する。

全文を読む ↗
C03

AI支援によるピクセルボス制作:石巨人の制作工程

高精細なコンセプト画像の不整合から、ゲーム内で使用できるピクセルボスへ至るまでの、画風参照、アニメーション制約、反復修正を記録する。

全文を読む ↗
C04

Alias Archive の構築:マルチ Agent 協働、Astro 移行、静的配信

匿名の内容境界と四領域・三言語モデルから、Agent 間の引き渡し、Astro 移行、Impeccable による視覚整理、Cloudflare Pages 公開までを振り返る。

全文を読む ↗