タイミングルールを追跡できる形にする

精密プラットフォーマーのプロンプトは、移動、タイミング、失敗、勝利とみなす正確な状態を定義するとレビューしやすくなります。短いルートを1つ選び、各操作に所要時間を与え、レベルや見た目を追加する前に成功例とリセットを追跡します。

このガイドでは再利用できる3段階のプロンプト一式と、手計算できる「Beatglass Crossing」の例を紹介します。レベルとルートは独自の架空デザインです。以下のゲーム用プロンプトは送信していません。プレイ可能なビルド、プレイヤーセッション、テスト結果もありません。拍の追跡は、明記した前提に基づく紙上シミュレーションです。

時間制限のあるプラットフォーム操作を1つに絞る

最初の範囲では、1つの設計上の問いに答えられるようにします。プレイヤーは周期的に開閉するシャッターを読み、安全な足場で待ち、開いている間に着地できるでしょうか。登場人物は配達人1人、ルートは隙間2つとチェックポイント1つ、目的は印のある出口への到達に絞ります。範囲を狭くすれば、敵、収集物、追加レベルに埋もれず、タイミングルールをプロンプトで定義できます。

Beatglass Crossingはこの記事のために作成した、架空の2.5D横視点コースです。タイルマップ、拍、ゲートの周期、リセット動作はいずれも著者が設計した前提です。既存ゲームの観察結果でも、測定された移動システムでもありません。

カバー画像は判断前の状態を示します。現在のゲート状態と着地予測が異なります。スコア、別のHUDパネル、説明のないパワーアップがなくても、待つ理由をプレイヤーが見て理解できます。

拍と着地のルールを定める

名前付きの位置と操作時間を使います。この紙上モデルでは横方向のタイル1つを1単位とします。「拍」は設計用の離散時計で、自然なジャンプ物理の主張ではありません。1拍は公称60 Hzで固定ステップ6回、つまり0.1秒と定義します。ゲートは配達人がタイルに入る時だけ判定します。

操作仕様も同じくらい明確にします。「右へ走る」は1タイル移動して1拍進みます。「待つ」は安全タイルで位置を保ち、1拍進みます。「右へジャンプ」は空きタイル1つをまたいで正確に2タイル移動し、2拍かかります。この簡略操作は目的地で解決します。ゲート位相はbeat mod 4です。シャッターが閉じている時にx=7へ入ろうとするか、隙間へ走ると、移動をキャンセルし、遮断または落下の合図を出し、直近のチェックポイントに戻し、試行時計を拍0にリセットします。スコア、体力、収集物の状態はありません。

メカニズム画像は一般的なジャンプではなく、着地判定に焦点を当てています。シャッタータイル、空の隙間、着地した配達人、位相表示が、記述した同じ状態を示しています。

プロンプトを段階的に作る

プロンプト集は改訂しやすくするためのものです。最初にコースと目標を頼み、次に移動とタイミングを加え、その後でフィードバックと確認ケースを追加します。以下の3つはコピーして使えるひな形ですが、実行していません。将来のビルドで使う前に角括弧内を置き換え、要求する報告が見えるゲーム状態と結びつくようにします。

プロンプト1：プレイ可能な範囲を定義する

[仮タイトル]という架空の精密プラットフォーマーの一場面を作る。横視点カメラでx=0からx=9までのコンパクトなコースにする。プレイヤーは配達人1人を操作し、x=9に到達する。安全なスタート床をx=0～2、1タイルの隙間をx=3、チェックポイント床をx=4～5、1タイルの隙間をx=6、時間制限シャッターをx=7、安全な出口床をx=8～9に置く。x=4に着地した時にチェックポイントを有効化する。離散した拍時計を1つ使い、現在位置、拍、ゲート位相、チェックポイント、勝利状態を簡単なアイコンで見えるようにする。隙間、敵、収集物、スコア、移動能力を追加しない。アートを加える前にマップと初期状態を返す。

この初回の依頼ではレベルの広さを限定し、レビュー担当者が確認可能であるべき状態変数を示します。配置を変える場合は、移動ルールを変える前にタイルマップを更新します。

プロンプト2：移動と時間制限ゲートを指定する

承認済みのx=0～9のコースを保つ。紙上設計の入力だけを実装する。「右へ走る」は安全なタイルを1拍で1つ進む。「待つ」は安全なタイルに留まって1拍進む。「右へジャンプ」は空きタイル1つを越えて正確に2タイル移動し、2拍かかる。phase = beat mod 4とする。x=7のシャッターは位相0と1で開き、2と3で閉じる。プレイヤーがx=7へ入る時だけ判定し、ジャンプは2拍の終了時に解決する。閉じている時に進入するか、「走る」で隙間に入ると移動をキャンセルし、明確な遮断/落下合図を示し、直近のチェックポイントへ戻してbeatを0にする。連続的な慣性、可変ジャンプ高、空中制御、壁ジャンプ、別のゲート、2つ目の時間ルールを追加しない。各入力の状態表を返す。

この段階では「ギリギリのジャンプ」「ちょうどよいタイミングで開く」のような曖昧な語を取り除きます。タイミング判定とリセット状態を直接求めるため、表示状態を記述したルールと比べられます。

プロンプト3：フィードバックとレビュー計画を求める

承認済みのコースとルールを変更せず保つ。現在の拍位相は小さなランプ4つで示し、開いたシャッターは青緑、閉じたシャッターは赤で表示する。安全に着地した後だけ控えめな着地フラッシュを見せる。x=9で真鍮の出口ベルを点灯し勝利とする。閉じたゲートへの進入または隙間への落下では短いフィードバックを1回表示し、その後チェックポイントとbeat 0を復元する。以下を示す：(1)成功時の入力/状態追跡、(2)待たずに失敗する追跡、(3)チェックポイントからの回復追跡、(4)2つの隙間、開閉状態での進入、位相リセット、出口の受け入れケース。予測と観測を分ける。記録したビルドを実際に調べていないケースを合格と主張しない。

状態追跡と受け入れケースを同時に頼むと、2つ目のレベルを加える前に矛盾を見つけやすくなります。後のビルドで操作やタイミングが異なる場合は、実際のバージョンを記録して仕様を改訂し、期待表を黙って変えないようにします。

Beatglass Crossingを手計算で確認する

成功ルートは「走る、走る、ジャンプ、走る、待つ、ジャンプ、走る、走る」です。ジャンプは2拍を使うため、開始時の位相だけでなく終了時の位相も記録します。

x=5ですぐジャンプすると拍7、位相3で終わるため、進入を拒否されて試行がリセットされます。待つと時計が拍6に進み、次の2拍ジャンプで拍8、位相0にx=7へ着地します。ルートが記載どおり成立するのは、ジャンプの両方の拍を時計に含めるためです。

この結果のイラストは手計算で解決した架空の終了状態です。ゲームビルドのスクリーンショットではなく、ベルはテスト完了の証拠でなく視覚的な目標表示です。

チェックポイントのリセットを定義する

再試行には完全な再開状態が必要です。拍7に閉じたシャッターへ進入した場合、チェックポイントx=4に戻し時計を拍0にリセットします。そこからの回復ルートは「走る、待つ、ジャンプ、走る、走る」です。x=5/拍1に到着して拍2まで待ち、拍4/位相0でx=7にジャンプし、x=8を経て拍6でx=9へ走ります。チェックポイントの位置と時計のリセットは両方必要です。拍7を維持するとゲート位相が変わります。

隙間に落ちた場合も同じルールを使います。失敗した操作をキャンセルし、原因を表示し、最新のチェックポイントを復元し、試行時計を消去し、コース形状は変更しません。失敗は次に調整するルールを示し、名前の付いた状態から再試行できる有用なものになります。

将来プレイテストするときは、正確な入力列、開始チェックポイント、拍、シャッター位相、復帰位置を記録します。ここでは記載した表をもとにルートを再生しただけで、ゲームセッションは記録していません。

再生ルートを受け入れ確認にする

コンテンツを追加する前に、紙上モデルを観測可能な問いにします。これらは将来のビルド向けに提案する受け入れ確認で、取得済みの結果ではありません。

実際の結果が得られたら期待状態の横に記録し、ビルド版も残します。確認に失敗したら、たとえばゲート周期やジャンプ時間など一度に1つのルールを変更し、成功ルートと失敗ルートの両方を再生します。手作業の表をテスト結果と呼ばないでください。

ゲーム制作ワークフローに概要をつなぐ

プロンプトで最初の小さな操作と明確な目標を説明できたら、その概要をゲーム制作ワークフローに持ち込めます。現在の公式Free AI Game Makerページは、平易な英語でのゲーム入力、プレイ可能な2Dまたは3Dの初版、ブラウザーテスト、追加プロンプトによる調整を説明しています。無料Koinsを提供し、生成ごとのコストを確認するよう案内しています。これは一般的なワークフローの説明であり、Beatglass Crossingやそのタイミングルール、プロンプトが生成済みであるとは示していません。

将来の反復では、レビューしたビルドをプロンプトのマップ、操作仕様、位相表、リセット状態と比較します。各反復で修正点を1つに絞り、たとえば開いたシャッターを見分けやすくする、リセット後にチェックポイントを表示するといった内容にします。ルールが実装されたとみなす前に、実際の結果と挙動を調べます。

次のレビューも、記述したマップ、移動仕様、ゲート位相、リセット状態、勝利条件に沿って行います。後のビルドは紙上例と異なる可能性があります。どのルールを直すか決める前に、実際の挙動を記録します。

レビューできるルートを1つから始める

時間制限のある横断を1つ作り、状態追跡を求めて、結果を印刷した仕様と比較します。詳細が見えるようになったら、将来の反復で試す修正を1つ選びます。Beatglassの数値は手計算した架空教材モデルのままで、生成ゲームの証拠ではありません。

焦点を絞った案を一般的な制作ワークフローに持ち込みます：Free AIゲームメーカー

精密プラットフォーマーのプロンプト FAQ

精密プラットフォーマーのプロンプトは何を明確にすべきですか？

コースの位置、各操作の移動距離と時間、タイミングルール、判定の瞬間、失敗時のフィードバック、リセット状態、正確な勝利条件を明記します。「ジャンプを難しくして」ではビルドがどう動くべきか分かりません。短い追跡表でシステムを増やす前に期待値の整合性を確認できます。

ジャンプには固定時間を含めるべきですか？

最初の決定的な紙上モデルでは、はい。移動距離と拍、そのジャンプで越えられる隙間を指定します。将来のエンジンで連続的な動きを使うなら、別の仕様と記録された確認が必要です。ここでの2拍ジャンプは設計上の前提です。

時間制限ゲートはどう記述しますか？

周期、開く位相、閉じる位相、判定する正確なイベントを示します。Beatglassではx=7への進入時だけ確認し、ジャンプの途中ではルールが変化しません。すべての操作で時計を進めるか、リセット後にどの位相へ戻すかも記載します。

ゲート進入に失敗したらどうすべきですか？

移動をキャンセルし、遮断の合図を出し、最も近いチェックポイントへ戻し、試行時計を拍0に戻します。再試行を追跡できるよう位置とタイミング状態を明記します。この例では、追加でリセットするスコア、体力、収集物の状態はありません。

Beatglass Crossingは作成またはプレイテスト済みですか？

いいえ。コースは架空で、ルートは紙上で手計算しています。プロンプトひな形は送信しておらず、プレイ可能なビルド、ゲームテスト、観測結果も主張しません。生成画像はコンセプトイラストで、ゲーム画面ではありません。記載された値は架空ルールだけを表し、実装の観測結果ではありません。