敵の動きを増やす前に、敵の波を読みやすくする
AIを使った横スクロール格闘ゲームを作るなら、まずプレイヤーが1つの攻撃予兆を読み、攻撃範囲を避け、次の敵が攻撃判定を行う前に行動可能へ戻れる部屋から始めます。敵が2体いるだけで公平な遭遇になるわけではありません。予兆、命中判定の時刻、間隔、回復時間が、プレイヤーに意味のある選択を与える必要があります。このガイドではRusherとGuardを1体ずつ使い、最初の部屋の仕様へ落とし込みます。
部屋と以下のタイミングは架空の設計値で、プロンプト結果、ゲームビルド、プレイヤーテスト、SEELEでの観察結果ではありません。実際の実行やプレイ可能な結果が提供されていないため、比較は手計算による時間設計のリハーサルです。文章のスケジュールに矛盾がないかは確かめられますが、ビルドの動作やプレイヤーの予兆理解は証明できません。
最初のループは狭く保ちます。「予兆を読む→レーンを避ける→行動可能に戻る→回復中を攻撃→敵を全員倒す→次の部屋を開く」。主な設計判断は、次の敵をプレイヤーの回避クールダウンに対していつ登場させるかです。これは敵群のタイミング設計チュートリアルであり、反動システムや跳弾パズルではありません。

敵2体の役割と行動順を固定する
部屋をFoundry Walkと呼びます。横方向の位置は0から12、レーンは手前と奥の2つです。プレイヤーは手前レーンのx=2から始め、出口ゲートはx=11にあります。同じ時刻に敵が命中判定をする場合、その時刻のプレイヤーコマンドを先に解決します。レーン移動は0.25秒です。回避は0.25秒で水平方向に1単位動きながらレーンを切り替え、その移動中の判定を避け、終了後0.75秒のクールダウンに入ります。軽攻撃は同じレーンで1.5単位以内にいる最寄りの敵に当たり、回復中の敵には1回攻撃できます。
| キャラクターまたは状態 | 最初の部屋の固定ルール | プレイヤーが読み取れること |
|---|---|---|
| Rusher | 手前レーンのx=0から開始。0.75秒予兆後、手前レーンを+3進む。プレイヤーの行動後に命中判定。t=1.0〜1.75は回復。 | Rusherが動く前に、手前レーンの進路を明確な予兆で示す。 |
| Guard | 遅延dの後に手前レーンx=2.5で登場。0.75秒の薙ぎ払い予兆。両レーンにまたがる固定範囲x=1.5〜3.5を判定後、0.75秒回復。 | 広い薙ぎ払い予兆で、レーン変更だけでは範囲から逃れられないと示す。 |
| プレイヤー | 手前レーンx=2から開始。回避でx=3の反対レーンへ移動。回避終了後0.75秒で再使用可能。 | 行動状態とクールダウンを、攻撃からの回復と別に扱う。 |
| 敵群とゲート | RusherとGuardの両方を倒すとゲートが上がる。触れると同じルールの第2部屋へ移動。リセットで体力、位置、遅延、ゲートを戻す。 | 撃破状態とゲート開放状態を別々に見せる。 |
Rusherの手前レーンの経路はプレイヤーの開始位置x=2を通ります。t=0.75でプレイヤーの回避コマンドが突進の命中判定より先に解決し、位置を(2, 手前)から(3, 奥)へ移します。Rusherは手前レーンを進み続けます。回避はt=1.0に終わり、クールダウンはt=1.75に終わります。部屋が空いて見えるタイミングでGuardを適当に置くのではなく、再使用可能時刻を基準に配置します。

2レーン移動はRusherには有効ですが、常に安全とは限りません。Guardの定義した矩形は両レーンを覆います。この違いはよくある視認性の問題を防ぎます。絵では両レーンを薙ぎ払うのに、ルール上は手前だけに当たるなら、プレイヤーは本当の危険を推測できません。画像、予兆、衝突範囲を一致させます。
観察可能なフィードバックを持つ小さな遭遇を依頼する
有用なプロンプトでは、アリーナ、プレイヤー操作、敵状態の変化、処理順、失敗時の表示、リセットを指定します。まだ加えない機能も伝えます。以下は仮想ゲーム用の設計成果物です。実行しておらず、将来プレイ可能な結果で各仕組みを確認する依頼です。
Foundry Walkというコンパクトな横視点2.5D格闘部屋を作る。横方向0〜12のアリーナに手前と奥の2レーンを用意する。プレイヤーは手前レーンx=2から開始し、閉じた出口ゲートをx=11に置く。同じ時刻では敵の命中判定より先にプレイヤーコマンドを解決する。プレイヤーは同じレーンで1.5単位以内の最寄りの敵に届く軽攻撃を1つ、0.25秒のレーン移動、横方向へ1単位移動して0.25秒でレーンを切り替える回避を持つ。回避中の移動判定を避け、回避終了後に0.75秒のクールダウンへ入る。 手前レーンx=0にRusherを1体出す。手前レーンの明確な0.75秒の予兆後、同レーンを+3進ませ、プレイヤーの行動後に命中判定を行う。t=1.0からt=1.75まで回復させ、この間に軽攻撃を1回受ける。手前レーンx=2.5にGuardを1体、遅延dの後で登場させる。0.75秒の予兆で、両レーンにまたがるx=1.5〜3.5の固定薙ぎ払い範囲を示す。プレイヤーの行動後に範囲を判定し、その後0.75秒回復させ、1回攻撃可能にする。初期の紙上シナリオはd=0.5とし、d=1.5との比較では他の値を固定する。 予兆、回避、被弾、回復、撃破、ゲート開放を別々に表示する。敵2体が両方とも倒れた場合にだけゲートを開く。リセットではプレイヤー体力、敵位置、登場遅延、ゲート状態を戻す。遠距離武器、ボス、成長ツリー、流血表現、ランダムなタイミング、追加の敵は加えない。衝突範囲、時間軸、クールダウン、リセットを簡単に確認できるようにする。これは架空の設計仕様であり、ゲームが生成またはテストされた証拠ではない。
将来生成したら、機能を足す前に最初の部屋を仕様と照合します。RusherとGuardが1体ずついるか、予兆が命中判定より先か、命中矩形が画面上のレーンと一致するか確認します。ツールからプレイ可能な試作が返っても、出発点として扱います。プロンプトだけを根拠に正しいと想定せず、ゲームをテストする必要があります。
0.5秒の登場遅延が回避に重なる理由を追う
「波が速すぎる」と曖昧に言わず、時間軸を使います。基準となるGuardの遅延はd=0.5秒なので、0.75秒の予兆はt=1.25に終わり、命中判定になります。Rusherの冒頭行動はすでにt=0.75で回避を要求しています。回避はt=1.0に終わり、再使用できるのはt=1.75です。したがってGuardの判定は、次の回避が可能になる0.5秒前に来ます。
| 時刻 | 紙上トレースでのプレイヤー状態 | 敵の動きと判定 | 定義した結果 |
|---|---|---|---|
| 0.00〜0.75 | 手前レーンx=2。Rusherの予兆を読める。 | Rusherが手前レーンの突進を予告する。 | 意図した対応は、やみくもな攻撃ではなくタイミングを合わせた回避。 |
| 0.75 | 回避が解決し、奥レーンx=3へ移動。 | Rusherが手前レーンx=0からx=3へ突進し、その後経路を判定。 | レーン変更で手前レーンの攻撃を避ける。 |
| 1.00 | 回避アニメーション終了。クールダウンは1.75まで。 | Rusherが回復時間に入る。 | プレイヤーは反撃を計画できるが、Guardの予定にも注意する。 |
| 1.25 | 回避は使えず、x=3はGuardのx範囲内。 | d=0.5のGuardが両レーンのx=1.5〜3.5を判定。 | この紙上シナリオではプレイヤーが定義上の攻撃を1回受ける。 |
Guardの矩形は手前と奥の両レーンを含むため、Rusherを避けても薙ぎ払いに対して安全ではありません。x=3は横方向の範囲内にもあります。透明な追尾ルールや気まぐれな敵が原因ではなく、固定された登場時刻、クールダウン、範囲から結果が決まります。記録済みプレイではなく、架空のルール確認用トレースです。
タイミングを1つ変えて紙上確認する
Guardの登場遅延だけを0.5秒から1.5秒に変えます。x位置、0.75秒の予兆、両レーンの固定範囲、ダメージ、プレイヤー移動、Rusher経路、ゲート条件は変更しません。Guardの判定はt=1.25からt=2.25へ移ります。回避はt=1.75に再使用可能です。t=2.25にプレイヤーはx=3からx=4へ回避してからGuardの判定を迎えます。x=4は固定範囲x=1.5〜3.5の外なので、攻撃を避けます。
これは1変数だけを変えた紙上計算です。1.5秒が楽しいか、プレイヤーが無理なく反応できるか、実装が意図した順で動くかは確かめません。定義した時刻に回避を使って固定攻撃範囲から出られることだけを示しています。後のビルドでは予兆を読めるか、操作が公平に感じるかもテストします。

完全な結果はこの安全回避だけではありません。RusherとGuardの双方が読みやすい状態に入り、反撃できる時間を設け、明確な撃破状態へ移る必要があります。両方が倒れてからゲートを開けます。上の比較はGuardの時刻だけを切り分け、ダメージ、形状、敵行動を黙って変えずに1つの判断を検証できるようにします。
拡張前に最初の部屋を診断する
将来のビルドで遭遇が意図どおりに動かない場合、画面上の状態がルールから最初に外れた箇所を特定します。登場時刻、予備動作の短縮、回避距離の拡大、攻撃範囲縮小などを同時に変えると、どの修正が効いたか分かりません。この表では診断を観察可能な確認項目に結びつけます。
| 症状 | まず確認 | 焦点を絞った修正 |
|---|---|---|
| Rusherが予兆終了前に当てる。 | 予兆終了、突進開始、命中判定の時刻を比較する。 | 0.75秒の予兆に戻し、プレイヤー行動が命中判定より先か確かめる。 |
| Guardの警告は片レーンに見えるのに両方に当たる。 | 両レーンのx=1.5〜3.5範囲と予兆を比較する。 | 予告と衝突ルールを一致させる。定義した矩形を密かに狭めない。 |
| 同じ回避が別の時刻に使えない。 | クールダウンが0.25秒の回避終了後に始まるか確認する。 | t=0.75の回避後、再使用時刻を1.75に保ち、両方の予定を再確認する。 |
| 敵を倒してもゲートが開かない。 | 敵群クリア条件が両方の撃破状態を待つか確認する。 | RusherとGuardの両方が倒れた場合のみ開き、リセットで閉じることを確かめる。 |
| 回復中の攻撃が外れる。 | 距離、レーン、最寄り敵の選択、1回だけ受ける条件を確認する。 | 同じレーンで1.5単位の射程を維持し、反撃を1つずつ試す。 |
観察結果は紙上スケジュールと分けて記録します。実際の試作なら、ビルド版、正確な入力、見えた予兆、命中判定の結果、リセット状態、ずれた箇所を保存します。プロンプトは観察記録の代わりにならず、生成された1枚の画面もタイミングが機能した証明ではありません。
出発点としてAIゲームメーカーを使う
SEELEの現在のFree AI Game Makerページは、ゲーム案を平易な言葉で説明し、プレイ可能な初版2D・3Dゲームを生成し、ブラウザーで試し、追加プロンプトで改善する一般的な流れを説明しています。送信前にWorkspaceで選択モデル、Koin残高、生成費用を表示し、生成ごとに費用を確認するよう案内しているとのことです。こうした一般的な流れは、この敵の予定、衝突範囲、格闘部屋が正しく実装される保証ではありません。
この設計では、アリーナ、プレイヤー操作、敵の予兆、時刻ごとの処理順、攻撃範囲、クリア条件、リセットを1つの焦点を絞った仕様として伝えます。プレイ可能な結果が得られたら、ビルド内で各ルールを調べ、異なる点を記録します。Workspaceでは送信前に選択モデル、Koin残高、表示費用を確認します。作者が決めた数値は受け入れ確認表に記載し、製品がすでに実現したと主張しないようにします。
この区別が次の手順を有用にします。作成者は幅広い「プロンプトからプレイ可能なゲームへ」の流れで案を試しつつ、実際の出力でゲーム固有のロジックを検証できます。
読みやすい格闘部屋を1つ作る
最初の遭遇はRusher1体、Guard1体、回避ルール1つ、両方を倒した時だけ開くゲートにします。各予兆が攻撃範囲と一致するかを決め、次に登場する時刻と回避再使用時刻を比較します。プレイヤーが波を理解して対応できてから敵を増やします。ここでの時刻は紙上設計値で、テスト済みバランス目標ではありません。
仕様を試作にする準備ができたらFree AIゲームメーカーから始め、現在の生成費用を確認し、部屋の契約に照らしてプレイ可能な結果を見ます。タイミング表を保ち、実際のビルドを確認して、一度に1変数を修正します。
よくある質問
横スクロール格闘ゲームの最初のループは何ですか?
読みやすい予兆、レーン回避、回復時間、敵群クリアの明確な反応から始めます。攻撃がどこへ進み、いつ敵に反撃できるかプレイヤーが分かるべきです。この例では、ボス、武器、成長要素を加える前に間隔とタイミングを教えるため、敵2体で十分です。
Guardの遅延が0.5秒だと攻撃を受けるのはなぜですか?
t=0.75の回避はt=1.0に終わり、再使用はt=1.75までできません。d=0.5のGuardは0.75秒の予兆を終えたt=1.25に判定します。その時プレイヤーは両レーンにまたがる固定範囲x=1.5〜3.5内にいます。これは架空の紙上トレースです。
1.5秒への修正はプレイテストですか?
いいえ。Guardの修正後の判定t=2.25で定義した回避が再使用可能となり、その前にx=4へ移動できることを示す手計算です。生成ビルド、人の反応、遭遇の公平さは示しません。それらにはプレイ可能な結果と観察テストが必要です。
プレイ可能な格闘ゲーム試作では何を確認しますか?
各予兆と実際の攻撃範囲を照合し、同時刻の判定よりプレイヤー操作が先に処理されるか、回避クールダウン、回復中の脆弱性、遭遇全体のリセットを確認します。正確な入力と結果を記録します。ルールが異なれば、複数の時刻を同時に調整せず、変更を1つに絞って再確認します。
AIゲームメーカーはこの敵のタイミングを保証しますか?
一般的な製品ワークフローは特定のタイミング結果を保証しません。平易な言葉の仕様で希望するループを伝え、プレイ可能な2D・3D結果を確認して改善できます。作成者は実際の予兆、衝突範囲、クールダウン、ゲート条件、リセット動作を確認する必要があります。


