AI が生成したゲームを継続して開発できますか？

ブラウザで開けるゲームが、継続して開発できるプロジェクトとは限りません。次に確かめたいのは、誰かがそれを再現し、ルールを説明し、元のラウンドを壊さずに機能を一つ追加できるかどうかです。スクリーンショットやコードを編集できるという説明ではなく、保存した基準版と範囲を絞って指定した拡張によって検証します。この記事では、小さな星集めゲームを対象に、再現可能な継続開発テストを定義します。これは実践を終えた報告ではありません。この草稿には元のプロジェクト、基準版の実行結果、拡張のパッチがいずれもありません。実際の結果を示すための要件は未充足です。この手順で不足する証拠を集めてください。受け入れ基準を、SEELE や生成されたプロジェクトについての検証結果と受け取らないでください。

1. プロジェクトと元のルールを定める

対象を限定したテスト条件を一つ用意します。デスクトップのブラウザゲームで、矢印キーで移動し、集められる星は五つ、ラウンドは30秒、五つすべてを集めると勝利、時間切れで敗北、きれいに再スタートできるものです。これは予定するテスト条件であり、既存のビルドではありません。実際に編集可能なプロジェクト、そのアセット、依存関係の定義、起動手順を入手します。表示される場合はジェネレーターやツールのバージョンを記録し、プロジェクトのリビジョン、実行環境、ブラウザ、OS も記録します。

ソースファイルと、ホストされたプレビューやコンパイル済みの成果物を区別してください。アセットの欠落、文書化されていない依存関係、ソースを受け取れない状況は、黙って補うのではなく記録すべき発見事項です。提供されたプロジェクトが想定条件と異なる場合は、同程度に範囲を限定した拡張を選ぶ前に、そのプロジェクトの既存ルールを記録します。後の変更で元の証拠が失われないよう、変更しないコピーと別の作業用コピーを保存してください。

2. 修正する前に基準版を再現する

空のディレクトリで、提供されたセットアップ手順に従います。実際のコマンド、インストール出力、起動ログ、ブラウザコンソールを保存してください。見慣れたフレームワークに似ているという理由でコマンドを作り出してはいけません。セットアップに失敗したらエラーを残し、行った対処は別途記録します。評価者が修正した基準版は、修正済みの基準版です。提供されたプロジェクトが無条件に成功したことにはなりません。

四つのシナリオを実行します。星を一つ集めてその場にとどまる、五つすべてを集める、時間切れまで待つ、それぞれの終了後に再スタートする、というものです。星が一つにつき一回だけカウントされること、終了後に移動が止まること、ラウンドのすべての状態が復元されることを確認します。各シナリオについて、操作、期待結果、観察結果、リビジョンを書き留めてください。成功と同じように失敗も丁寧に保存します。

3. 変更するルールを追跡する

移動、接触判定、収集状態、表示されるカウント、勝利判定を結びつける実際のコードまたは編集可能なロジックを探します。メモには実際のファイル名やイベント識別子を使ってください。タイマーをどの要素が管理し、どのリセット操作で復元されるかを説明します。AI のもっともらしい説明だけでは不十分です。プロジェクトと照らし合わせて確認してください。

重複したカウンターや、無関係な複数のシステムに分散したリセットロジックを探します。これらは確認すべき論点であり、設計が悪いことの自動的な証明ではありません。実際の目的は、ボーナスアイテムをどこに組み込み、既存のどの動作を変えずに保つかを明らかにすることです。パッチを依頼する前に不明点を記録してください。

4. 同じプロジェクトに青いボーナススターを一つ追加する

基準版のリビジョンを保存してから、この一つの変更を依頼します。以下の例では、タイマーへの新しい効果と既存の収集カウントを意図的に分けています。

この既存のゲームに青いボーナススターを一つ追加してください。進行中のラウンドで初めて接触したときに星を取り除き、残り時間を3秒増やします。通常の星のカウンターを増やしたり、星五つという勝利条件を変更したりしてはいけません。再スタート時にボーナススターを復元します。終了したラウンドは再開できません。移動、通常の星、時間切れ、元のすべての終了ルールを維持してください。最小限のパッチを提案する前に、実際に影響を受けるプロジェクトのファイルまたはイベントを特定してください。ゲームや無関係なアセットを置き換えないでください。

提案された変更は実行前に確認します。変更されたファイルやイベント、追加された依存関係、構造変更を記録してください。無関係なサブシステムが変わった場合は、その理由を尋ねます。青い物体を持つ新しい独立したゲームは、プレビューが似ていても、基準版を継続開発した証拠にはなりません。別のレビュー担当者が同じリビジョンを調べられるよう、パッチと説明を一緒に保存します。

5. 既存の動作、新しい境界条件、ロールバックを再確認する

基準版のすべてのシナリオを繰り返します。次にボーナススターを一度集め、その元の位置にとどまります。時間が増えるのは一度だけで、通常のカウントは変わらないはずです。再スタートして再び集め、リセットを確認します。時間切れ直前と終了後の接触も確認してください。新しいアイテムによって終了済みのラウンドが再開してはいけません。同時イベントが結果に影響する場合は、フレームの処理順序に関する前提を記録します。

確認が失敗したら、別の修正を依頼する前に、失敗したリビジョンと短い再現手順を保存します。保存した基準版にロールバックし、基準シナリオを一つ再実行してください。この確認の後に初めて、ロールバックを再現できたと報告できます。ここでは、成功したパッチ、回帰のない結果、修正時間、ロールバックの結果はいずれも確認されていません。

SEELE が提供できることと確認が必要なこと

SEELE は、シーン、アセット、ゲームプレイのコードを扱う自然言語でのゲーム制作ワークフローを説明しています。そのため、小さな生成ゲームはこのテストの適切な出発点になります。まず簡潔なゲームの要件を入力し、現在のワークフローが実際に何を引き渡すのかを確認してください。プレイ可能な結果、編集可能なプロジェクト、ソースファイル、その他の成果物は互いに同じものではありません。

継続開発の段階では、既存プロジェクトの背景とボーナススター一つの要件を伝えます。自然言語による変更が状態を正しく保つと決めつけず、生成された変更を調べてください。プロジェクトへのアクセス、エンジンとの互換性、エクスポートの詳細は、実際のアカウントと出力で確認する必要があります。製品説明はワークフローを試す根拠にはなりますが、このプロジェクトの再現性、アーキテクチャ、保守性を証明するものではありません。

実際の結論に必要な証拠

• 元のソースまたは編集可能なプロジェクトのアーカイブ、必要なアセット、安定した基準版のリビジョン。
• 実際のセットアップ手順、環境の詳細、コマンド出力、起動時のエラーや修正。
• 基準シナリオの記録と、勝利・敗北・再スタートを示す中断のない実行証拠。
• 実際のコードやイベントに結びついた説明、正確な拡張依頼、検査可能なパッチ。
• 変更前後のリビジョン、回帰と境界条件の確認結果、再現されたロールバック。
• 未解決の失敗を含み、このプロジェクトとこの拡張に限定した結論。

結果を裏付けるこれらの成果物はすべて現在欠けています。ボーナススターの変更に成功すれば、限定的な継続開発の主張は支えられますが、ネットワーク機能、セーブデータの移行、本番規模の開発を保証するものではありません。不完全な引き渡しは「AI のコードは編集できる」という一般論に置き換えず、報告書に明記すべきです。

まとめ：まず次の変更に関する証拠を集める

レビューと回帰確認に耐える変更によって、継続開発を評価してください。再現可能なプロジェクト資料から始め、元のルールを保ち、予想外の編集に気づける程度に拡張を小さくします。この草稿が提供するのは方法であり、欠けている結果ではありません。プロジェクト、パッチ、実行時の証拠がそろうまで、実践に基づく保守性の判断はできません。次の一歩として、SEELE で小さな星集めゲームの要件を使い、ボーナススターを依頼する前に実際の引き渡し物を保存してください。ソースがない場合やセットアップに失敗した場合はそこで止まり、障害を記録し、完成度の高いプレビューを開発継続の証拠と見なさないでください。

よくある質問

ホストされたプレビューでゲームの保守性を証明できますか？

いいえ。ホストされたプレビューでは観察可能なゲームプレイを示せますが、ソースの完全性、再現可能なセットアップ、コード変更の影響は証明できません。記録の一部として使ってください。継続開発に関する主張には、編集可能な資料、保存した基準版、検査可能な変更、想定する実行環境での回帰確認も必要です。

このテストにはプログラマーが必要ですか？

プレイヤーから見えるシナリオはプログラマーでなくても記録できますが、ソースと依存関係を信頼できる形で確認するには、プロジェクトの言語やエディターに詳しい人が必要です。これらの役割を分けてください。自信に満ちた AI の説明や動く開始画面をアーキテクチャレビューと見なさず、適任者に実際の変更を検証してもらいます。

拡張は動作するのに、セットアップが文書化されていない場合はどうしますか？

完全な引き渡しではなく、部分的な成功として報告します。すでに構成された環境で拡張が動いても、新しい開発者が再現できない場合があります。成功したリビジョンを保存し、実際に使ったセットアップ手順を書き留め、提供された資料からその手順を繰り返してから、独立して再現可能なプロジェクトと表現してください。