ForgeAX は、AIネイティブのパーソナルゲームスタジオ。私たちは、ゲーム制作の障壁が AI によって再定義されつつあると信じています。
私たちのビジョンは次のとおりです。これまでは大規模なチームが必要だったゲームを、AI を使って小規模なチームで作成できるようになります。クリエイターを置き換えるのではなく、「アイデア」と「プレイ可能なゲーム」の間の重要なエンジニアリングと制作を AI に任せます。
私たちがいる場所
現在の段階は、AI でアイデアをプレイ可能なゲームに変える: PBR レンダリング、物理学、骨格アニメーションをカバーするエンジンを使用して、スタジオでプレイ可能な FPS、ARPG、サバイバル、シューティングのデモをすでに作成できます。出荷可能な品質に向けて、この段階を磨き続けます。
オープンソース
ForgeAX ツール レイヤーは、以下に基づいてライセンス供与されています。Apache ライセンス 2.0— 誰でも自由にフォーク、使用、商用ビルド、再配布できます。私たちは、コミュニティが一緒に構築できるオープンなプロジェクトにしたいと考えています。を参照してください。ライセンスページ。
小さなチームがより大きなゲームを作れるようにしましょう。
スタジオでは、チャットを通じて、ビジュアル エディターで直接作業し、（後で）画像やビデオなどの入力を使用して、Forge と呼ばれる AI リードに必要なゲームについて説明します。計画を立て、必要に応じて専門のサブエージェントを導入します (ゲームプレイ、デザイン、アートなど)。エンジンコード自体を書きます、結果をライブブラウザプレビューにホットリロードします。
その下には 2 つの社内基盤があります。AIの観点から再設計されたエンジン(AI が読み書きし、エラーを理解できるようにするため)、およびAI を正しく検証可能な結果に導く開発ループ(要件は入力、再生可能な出力は出力、すべてのステップは観察可能で追跡可能)。
7 ステップのループ
エンジン内では、すべての機能が同じパイプラインを通過します。つまり、要件が入力され、実行結果が出力され、各ステップで読み取り可能なレコードが生成されます。
- 要件 — 何を構築するかを受け入れ基準とともに記述します。
- 調査 — 調査履歴、制約、およびオプション。
- 計画 — 戦略を設定し、それをタスクに分割します。
- 実装 — コードとテストを作成します。
- 検証 — 独立したチェック。赤の場合はマージがブロックされます。
- 判断 — 最終的な判断は人間が行います。
- ファイナライズ — 合格したらマージします。
オーケストレーターとサブエージェント
「オーケストレーター」はステート マシンを駆動し、各ステップでどのサブエージェントをディスパッチするかを決定し、その出力をチェックします。サブエージェントは、独自のコンテキストを持つ役割に特化したものです。人間が判断を下すのは、要件の表明と結果のレビューという 2 つの時点だけです。
「見た目は大丈夫」がすり抜けることはありません
検証には 2 つの AI ゲートがあります。1 つは AI ユーザーの観点からドキュメントと API を静的にスキャンし、「約束されているが実装されていない」ものを検出します。もう 1 つは、隔離されたサンドボックスで実際にデモを実行し、スクリーンショットをキャプチャして再チェックします。これにより、「テストは緑、画面は黒」にならないようにします。
時間が経つにつれて安定していきます
各機能の後、途中で発生した摩擦がフィードバックとしてキャプチャされ、パイプライン自体がアップグレードされます。次の機能では、改良されたバージョンが自動的に使用されます。パイプラインは独自の出力をフィードし、よりスマートになります。
結果: AI は「デモグレード」のコードではなく、人間が引き継ぐことができる検証済みの再現可能な機能を生成します。
ほとんどのゲーム エンジン API は人間向けに作成されています。 AI がコードを書くようになると、エンジンは違ったものになるはずです。
ForgeAX の核となるアイデアはシンプルです。ユーザーがゲームを説明し、AI がエンジン コードを作成します。これは「作者が違うだけ」のように聞こえますが、実際には既存のエンジンは AI に適していません。人間と同じようにドキュメントを読み、推測し、コンテキストを埋める読者を想定しています。
私たちのスタンスは率直です: AI はエンジンの最初のユーザーです。 「AI に優しい」と「人間に優しい」が矛盾する場合、AI が勝ちます。 具体的な結果をいくつか示します。
1 · 真実の情報源は 1 つで、残りは導き出される
ファクトは正確に 1 か所で定義されます。他のすべてはそこから派生します。たとえば、コンポーネント フィールドはスキーマ内にインラインで存在します。インスペクター、デバッガー、ツールは、ソースを grep して推測する代わりにスキーマを読み取ります。 AI は、どこにでも点在する規則を「記憶」する必要がありません。見るべき場所は 1 つだけだからです。
2 · AI が理解して回復できるエラー
エラーは、単に人間が「投げる」文章ではありません。私たちはエラー コードの閉じたセットを使用しており、それぞれに構造化された「何を/なぜ/どのように回復するか」情報が含まれています。 AI はエラーに遭遇したとき、例外テキストを神秘主義として扱うのではなく、次に何を変更すべきかを認識します。
3 · 「画面を見る」のではなく構造化データ
レンダリングのバグで最も難しいのは、「画面上で間違って見える」ことです。人間はモニターを見つめることができます。 AIにはできません。そのため、エンジンはレンダー呼び出しのフレーム (描画呼び出し、バインディング、レンダー ターゲット、パイプライン状態) をキャプチャして、オフラインで読み取り、再生し、N 回目の描画で完全な状態を検査できます。視覚的な問題は、AI が「読み取る」ことができるデータになります。
4 · 相互にチェックする 2 つの実装
レンダー層には、単一のインターフェイスの背後に 2 つのバックエンド実装 (WebGPU と wasm 実装) があります。これらは並列してレンダリングされます。AI がエンジン API を悪用した瞬間に、もう一方のバックエンドが即座に分岐し、問題が表面化します。人間のレビューを待つよりもはるかに速くなります。
これらの設計には 1 つの基準があります。読者 (人間または AI) が頭の中に保持しなければならない概念が少ないほど、優れています。 API の自己一貫性が高く、ローカルでインデックス付け可能であるほど、AI が正しく理解できる頻度が高くなります。また、人間が引き継ぎやすくなります。
「AI ネイティブ」はスローガンではありません。それは、「AI の観点からやり直す」という長い一連の決定です。ドキュメントと将来の投稿でさらに詳しく説明します。