同じ制作要件で四つの AI ゲーム制作ツールを比較する方法

ゲーム制作ツールは、スクリーンショットだけではなく、プレイできるゲーム、加えられる変更、手元に残せるプロジェクトを基準に選びましょう。公平な比較は、同じ小さな制作要件から始め、見た目を判断する前にプレイヤーから見える同じルールを確認します。手作業、プランの制限、実際の書き出し内容も記録します。この提案テストは、既存の比較で挙げられた SEELE AI、Rosebud AI、GDevelop、Buildbox の四つを対象とします。この草稿には、条件をそろえた実行結果や書き出しの検査結果がありません。そのため結果と推奨は保留中です。点数、観察された機能の差、勝者はいずれもありません。以下では、後の比較が選択の問いに誠実に答えられるよう、何を実行し保存するかを定義します。

共通の制作要件と統制条件

すべての実行でデスクトップブラウザ、固定の表示領域、同じ入力機器を使います。ツールを開く前に、許可するプラン、支出上限、介入の上限、停止条件を定めます。アカウントのプラン、日付、表示されるツールのバージョン、実際の費用を記録してください。一方のワークフローに視覚的な編集が必要な場合、プロンプト数が同じでも労力が同じとは限りません。

Lantern Delivery という、一画面の見下ろし型 2D ブラウザゲームを作ってください。オリジナルの配達人とシンプルなオリジナルの背景を使います。WASD または矢印キーで移動します。動く障害物を一つ避けながらランタンを五つ集めます。収集数と45秒のタイマーを表示します。障害物への接触または時間切れで試行終了です。五つすべて集めると勝利します。見える説明と再スタートを含めます。配達人とアートの方向性は全体を通して同じに保ってください。ライセンス付きのキャラクターやダウンロードした著作権保護対象のアートは使わないでください。

これは仕様であり、生成済みの結果ではありません。テストでは最初の移動でタイマーを開始し、どちらの終了後も入力を停止し、再スタートで全状態を復元します。インターフェースが要件を直接受け付けない場合は、そのツール本来のワークフローでどのように実装するかを記録してください。一つの候補だけに追加の準備を黙って与えたり、より完成度の高いテンプレートに置き換えたりしないでください。

記入が必要な四つの候補の記録

SEELE AI：プロンプト後の引き渡しを確認する

SEELE は自然言語によるゲームシーン、アセット、ゲームプレイのコードの作成を説明しています。この比較では、そのワークフローが指定された Lantern Delivery のゲームの流れを作り、同じプロジェクトで統制した変更を行えるかが重要です。利用可能な制作ワークフローに変更していない要件を入力し、元の依頼、応答履歴、最初にアクセスできたビルド、アカウント条件を保存します。

製品の説明からソースへのアクセス、エンジンの互換性、ローカル起動の成功を推測しないでください。実際の引き渡し物を調べて形式を記録します。追加の確認や修正が必要なら、シールドの変更に進む前に回数を数えて保存します。後に有用な推奨を行うには、観察したプレイ可能性、修正の手間、再現性を読者のニーズに結びつける必要があります。現在はそれらの観察結果がないため、この候補には点数も優位性も与えられません。

Rosebud AI：実際の作成と変更の過程を記録する

テストする Rosebud AI アカウントで利用可能なワークフローを使い、共通の要件を実行します。最初の入力形式、必要な準備、アクセス可能なビルドを得るためのすべての介入を記録してください。プラン条件については現在の公式ドキュメントを参照しますが、文書の主張と評価者が観察した事実は分けます。この草稿では、現在利用可能な機能や書き出し形式を確定していません。

基準版をプレイできたら、同一のシールド依頼を出す前に保存します。変更が既存プロジェクトに加えられたか、配達人、ルール、マップが維持されたかを記録してください。引き渡しについては、テストしたワークフローが実際に提供する成果物を調べます。ホストされたリンクを「ソースコード」と呼び替えてはいけません。あるアカウントでアクセスできないことは、そのプランに固有の観察であり、製品がその機能を一切提供しない証拠ではありません。この記事のために Rosebud の生成、変更、書き出しは行っていません。

GDevelop：エディターでの作業を見えるようにする

現在の GDevelop ワークフローを、対話型ジェネレーターのコピーと仮定せず、テスト担当者に実際に提示される形で評価します。要件を実装するために必要なシーン構築、イベント編集、アセット準備、テンプレート選択を記録してください。支援付きの制作が提供される場合は、その入力と出力を手動操作とともに保存します。この記事では、それらの現在の選択肢やプラン条件を検証していません。

編集可能なイベント構造は、ビジュアルエディターの利用者にとって適切な引き渡し物になり得ます。手書きスクリプトのディレクトリと異なるだけで退けるべきではありません。一方、エディターのプロジェクトだけでは、共有されたブラウザビルドが動くことを証明できません。基準版、統制したイベントまたはプロジェクトの変更、プレイの確認、実際の書き出し内容を別々に記録します。後の比較では、このワークフローの手間と結果を示し、「ノーコード」というラベルだけで不利にも有利にもしないでください。ここには GDevelop のテスト結果はありません。

Buildbox：プロジェクト編集と公開された成果物を区別する

テストする Buildbox アカウントの実際のワークフローを使って Lantern Delivery を実装し、必要な準備やテンプレート由来の挙動を記録します。公開や書き出しの選択肢を説明する前に、現在のドキュメントとアカウント条件を確認してください。他のツールのプロンプト画面、ファイル構成、ローカル実行手順がここでも使えると仮定してはいけません。手動の準備を含め、評価できる最初のプロジェクトリビジョンを保存します。

シールドの変更では、保護を実装する編集可能なロジックやプロジェクトの差分を、基準版のルールが保たれた証拠とともに記録します。実際に提供されたものに応じて、エディターのプロジェクト、ホストされたビルド、コンパイル済みの成果物、ソースファイルのいずれかを正確に特定してください。対象や書き出しにアクセスできない場合は、テストしたプランと観察した正確な制限を明記します。後の読者が自分のニーズに照らして判断できるためです。現時点では Buildbox のビルド、変更、引き渡しはいずれも検査されておらず、機能についての判断は正当化できません。

プレイ・編集・引き渡しを同じ方法で確認する

まず、説明、二つの移動方法、一度だけの収集、障害物への接触、ランタン五つでの勝利、時間切れ、各終了後の再スタートをテストします。新たに読み込んだ後も繰り返してください。各確認を合格、失敗、未テストのいずれかにし、ビルドのリビジョンを添えます。失敗を含む中断のない記録を残してください。ページが応答することや魅力的なシーンは、ゲームの流れ全体を確認したことにはなりません。

次に統制した変更を一つ加えます。障害物との接触を正確に一回だけ防ぎ、収集すると消えるシールドを追加します。保護が有効かどうかを表示してください。配達人のアート、マップ、操作、ランタン数、タイマー、再スタートを維持します。再スタート前に二つ目のシールドが現れないことを指定します。収集、最初の保護された接触、次の保護されていない接触、保護中の時間切れ、再スタート時の復元をテストします。基準版のすべての確認も再実行してください。コード、イベント、その他の検査可能なプロジェクト成果物など、ネイティブな形式でリビジョン差分を保存します。

最後に、プレイ可能なリンク、コンパイル済みビルド、編集可能なプロジェクト、人が読めるソースを区別します。提供された書き出しを保存して検査してください。クリーンなディレクトリで、文書化されたツールを使って開くか実行し、実際のコマンド、バージョン、欠落アセット、手動修正を記録します。ダウンロードの成功だけでは再現可能なプロジェクトを証明できません。現在のドキュメントは観察結果と一緒に保存しますが、テストの代わりにはしません。

同等のものを比較してください。最初にアクセスできた結果同士、修正済み結果同士を比べ、介入を明示します。初心者は理解しやすい反復と動くゲームの流れ、開発者は再現可能なソース、エディター利用者は検査可能なイベントを重視するかもしれません。こうしたトレードオフは成果物が存在してから報告します。時間とクレジットの数値には、結果を見た後の推測ではなく、記録した開始・終了のルールが必要です。一回の実行で支えられるのは限定的な事例比較であり、一般的な信頼性の主張ではありません。

証拠のチェックリスト：結果欄は一つも完成していない

• 各候補のアカウントプラン、テスト日、表示されたバージョン、ブラウザ、予算、実際の介入履歴。
• 元の要件、基準プロジェクトまたはビルド、承認確認の全記録。
• 正確なシールドの依頼、変更前後のリビジョン、検査可能な変更、回帰確認の観察結果。
• 実際の書き出しまたは引き渡し成果物、クリーン環境でのセットアップ記録、観察した起動結果。
• プランや形式に関する記述を裏付ける現在の公式ドキュメント。
• これらの確認後にのみ作成する、ツール別の結果と条件付きの推奨。

この記事では、四つの候補の実行はすべて未実施です。このチェックリストは収集計画であり、結果表ではありません。テスト済みの順位、最速のツール、最も安く完成したゲーム、検証済みの書き出しの勝者は報告できません。

まとめ：証拠がそろうまで推奨を待つ

役立つ比較は、どのツールが最も充実して聞こえるかではなく、どのテスト済みワークフローが継続したいプロジェクトに合うかを問うものです。共通の要件を保存し、受けた支援を明示し、プレイ可能な挙動と検査できる引き渡し物を分けます。この草稿では勝者を選べません。条件をそろえた四つの実行、変更、書き出しがまだ欠けているためです。アクセスと必要な予算が承認されたら、共通の Lantern Delivery 要件を SEELE で使い、他の候補でも変更せずに繰り返します。失敗や制限も記録に残してください。その後に初めて、想定上の順位ではなく、観察されたプレイ可能性、編集の手間、プロジェクトへのアクセスに基づいて選択肢を絞れます。

よくある質問

書き出しボタンがあれば編集可能なソースを受け取れますか？

いいえ。書き出しはコンパイル済みビルドや特定のエディター向けプロジェクトかもしれません。実際の成果物をダウンロードして調べ、文書化されたツールで開くか実行してください。アカウント単位の限定的な観察を製品全体の機能と取り違えないよう、テストしたプランと形式を記録します。

公式ドキュメントは実地比較の代わりになりますか？

いいえ。ドキュメントは現在の機能やプランに関する記述を裏付けられますが、この特定のゲームが正しく動いたことやシールドの変更後も機能したことは示せません。ドキュメントと観察結果は別々のメモに残します。実行していないシナリオは、宣伝例や機能一覧から確信を借りるのではなく、未テストと記してください。

各候補にまったく同じ数のプロンプトを与えるべきですか？

最初の要件と変更仕様は同じにし、追加の支援と手作業はすべて明示してください。インターフェースによって必要な操作が異なるため、プロンプト数だけでは労力を公平に測れません。介入と予算の上限を事前に定め、結果を見てからルールを変えるのではなく履歴を保存します。