コードのようにゲームデザインをホットリロードする

ほとんどのエンジンは不透明なバイナリを出荷する。RakuAIは差分・レビュー・ホットリロードが可能なテキストを出荷する——AIの神経系はそのファイルの中でまさにアドレス可能だ。その選択こそが、エージェントのチーム全体があなたと共に構築できる理由だ。

ファイルフォーマットの週末。このエンジンではAIはランタイム・プリミティブであり、隣に取り付けられた機能ではない。それは以前にも述べてきたアーキテクチャ上の主張だ。この投稿は、それを具体化するファイルフォーマットについてのものだ。

ほとんどのエンジンでゲームを作ると、出荷する成果物はバイナリ、プロジェクトバンドル、アセットデータベース、あるいはその三つの組み合わせのいずれかだ。あなたが作成するものは独自エディタの中に存在する。あなたが出荷するものは、あなたのチームがすでに使っているツールにとって不透明だ。体験の二つのバージョンを差分するには、同じエディタを二回起動し、変更ログが正直であることを願うしかない。

私たちは別の道を選んだ。RakuAIの体験は.rakuファイルだ。ファイルはJSONだ。どんなエディタでも開ける。どんなコードレビューツールでも二つのバージョンを差分できる。スキーマに対して検証できる。gitでバージョン管理できる。PRでレビューできる。ホットリロードできる。望むなら手書きで体験を書ける。

ファイルフォーマットは派手ではない。しかし荷重を支えている。

実際の.rakuファイルはどう見えるか

これは実際のゲーム定義だ。投稿用にトリムしてある。

{
  "schema_version": "1.0",
  "game": {
    "title": "My Space Shooter",
    "genre": "space_shooter",
    "template": "space_shooter",
    "mode": "prototype",
    "max_players": 1
  },
  "ai": {
    "dda_enabled": true,
    "target_flow_state": 0.7,
    "profiler_mode": "active",
    "emotional_tracking": true,
    "adaptive_music": true
  },
  "entities": [
    {
      "type": "player_ship",
      "health": 100,
      "shield": 80,
      "speed": 22.0,
      "fire_rate": 0.09
    },
    {
      "type": "enemy_wave",
      "count": 8,
      "health": 15,
      "ai_behavior": "strafe",
      "properties": { "enemy_id": "interceptor" }
    },
    {
      "type": "boss",
      "health": 500,
      "ai_behavior": "boss_pattern"
    }
  ]
}

それが体験のほとんどだ。スキーマバージョン管理されたヘッダー。表面のメタデータを持つgameブロック。ランタイムAI設定を持つaiブロック。世界に何があり、各エンティティがどう振る舞うかを記述するentities配列。

指摘する価値のあるいくつかの点がある。

aiブロックはランタイムの契約だ

この部分をもう一度見てほしい。

"ai": {
  "dda_enabled": true,
  "target_flow_state": 0.7,
  "profiler_mode": "active",
  "emotional_tracking": true,
  "adaptive_music": true
}

これは、ファイルが「AI神経系はオンだ」と言っている場所だ。「GPTにレベルを書かせてくれ」ではない。オンだ。ランタイムレイヤーで、プレイヤーがプレイしている間、毎フレームだ。

dda_enabledは動的難易度調整をオンにする。ランタイムはプレイヤーが何をしているかをプロファイルし、その場でエンカウントを再構成する。target_flow_state: 0.7は、ランタイムが目指す難易度帯だ。profiler_mode: "active"は、AIがプレイヤーの行動をサンプリングするだけでなく読み取っていることを示す。emotional_trackingとadaptive_musicは、同じ考えを他のサブシステムに適用したものだ。

ファクトリーパターンのエンジンには、これらのつまみをファイルレベルで持つことはできない。ファイルがアドレスすべきランタイムAIが存在しないからだ。私たちのエンジンでは、これらのつまみは、作者がどんな種類の体験になるべきかを神経系に伝える方法だ。

このブロックはPRでレビューできる。CIで二つの値をA/Bテストできる。エディタを見たことのないプロデューサーがこれを読み、ターゲットフロー状態が何を意味するかについてエンジニアリングと会話できる。ファイルフォーマットはデザイン判断を可視化する。

エンティティごとのAIビヘイビアは統合ではなく文字列だ

ファイル内の各エンティティはai_behaviorフィールドを持てる。

{
  "type": "enemy_wave",
  "count": 8,
  "ai_behavior": "strafe"
}

"strafe"はモデル呼び出しではない。神経系レイヤーが駆動する、ランタイムに登録されたビヘイビアだ。同じエンティティは"patrol"や"boss_pattern"や、ランタイムがやり方を知っている他の何にでもなれる。ファイルはモデルをインポートしない。能力をアドレスする。

これが、ファイルフォーマットを特定のモデルから切り離す方法だ。作者は意図を書く。ランタイムは、その意図を届けるためにどのモデル、どの重み、どの決定論的フォールバックを使うかを決める。来四半期にモデルを差し替えても、.rakuファイルは変わらない。

この分離は、聞こえる以上に重要だ。特定のLLMをエンジンに組み込んだ私が話をしたすべてのチームは、モデルベンダーが動いたときに統合をやり直さなければならなかった。私たちはそうする必要がない。

なぜJSONなのか

これは、ファイルフォーマットを見せると最もよく聞かれる質問だ。なぜ、数式のためのより良い構文やインラインスクリプティングやリアクティブバインディングを持つカスタムDSLではなくJSONなのか。

三つの理由がある。

一つ:すべてのツールがすでにJSONを話す。 コードレビュー。差分ツール。バージョン管理。リンター。スキーマバリデータ。CIパイプライン。静的解析。あらゆるプラットフォームのあらゆるエディタ。それらを一つも自分で構築する必要がなかった。無料で手に入れた。

二つ:人間はJSONを十分にうまく読める。 上記のファイルは美しくはないが、シニアデザイナーは訓練なしで読める。それを、誰かがPRをレビューできるようになるまで一週間かかるDSLと比較してほしい。

三つ:AIアシスタントはJSONを非常によく読める。 これは三年前よりも2026年の今のほうがずっと重要だ。デザイナーがAIアシスタントに「ボスをもっと怖く感じさせて」と頼むとき、アシスタントはファイルを読み、差分を提案でき、人間はその差分を受け入れるか拒否するかできる。カスタムDSLだと、すべてのアシスタントに新しい文法を教える必要が出てくる。

コストは本物だ。JSONは冗長だ。インラインの数式、コメント、省略記法を持たない。私たちはツールの普遍性と引き換えに表現力を犠牲にしている。これまでのところ、そのトレードオフは何倍にもなって元を取っている。

これが何を可能にするか

体験がテキストになると、いくつかのことが変わる。

ゲームデザインのPRレビュー。 デザイナーがtarget_flow_stateを0.7から0.5に変更する。その変更はプルリクエスト内で一行の差分として現れる。エンジニアリングとデザインは一緒にその変更をレビューする。PR内の会話は、なぜその体験がそのようにプレイされるかの記録になる。半年後、誰かが難易度カーブがなぜそう感じられるのか尋ねたとき、答えはコミットログにある。

体験のためのCI。 .rakuファイルがスキーマ検証に失敗する。変更が出荷される前にビルドが失敗する。ユニットテストを実行する同じCIが、体験定義を実行する。

ホットリロード。 ディスク上でファイルが変わる。ランタイムが気づく。再起動なしで世界が更新される。開発ループは秒単位に締まる。

ロールバック。 ある変更がボス戦を壊した。コミットを取り消す。体験は元に戻る。エディタも、アセットの再ビルドも、一週間かかる往復もない。

AIによるオーサリング。 チームメンバーが自然言語で欲しいものを説明する。AIアシスタントが.rakuの差分を書く。人間のレビュアーがそれを承認する。その差分は監査可能でバージョン管理可能であり、他のあらゆるコード変更と同じレビュー規律の下にある。

これらは奇抜な能力ではない。あらゆる現代的なソフトウェアチームが、コードベースの残りの部分について当然のこととしているものだ。私たちはそれをゲームデザインにまで拡張した。

何が難しいか

正直なコストを述べる。

JSONにはコメントがない。デザイン意図のためのサイドカー.mdファイルと説明的なフィールド名で補っているが、それでも本物の摩擦だ。

スキーマは慎重に進化させなければならない。世界生成が元の形を超えて成長したとき、schema_version: 1.0から2.0に一度上げた。現存するすべてのファイルには移行パスが必要だった。その作業は仕事の一部であり、無料ではない。

フィールドを追加し続けたい誘惑がある。聞こえる以上に強くそれに抵抗している。追加されたすべてのフィールドは、ランタイムが永続的に守らなければならない契約だ。バイアスは、ファイルを小さく保ち、複雑さをファイルではなくランタイムに置くことだ。

そして最後に:テキストベースの体験定義が重要になるのは、ランタイムが実際にそれらで何か興味深いことをする場合に限る。ファイルフォーマットは、その下にあるアーキテクチャ上の決定の下流にある。エンジンがAIをコンテンツファクトリーとして扱うなら、ファイルは単なるマニフェストだ。エンジンがAIをランタイム・プリミティブとして扱うなら、ファイルは楽譜だ。

このフォーマットを端から端まで読みたいなら、スキーマは公開ドキュメントにあり、サンプルファイルはリポジトリに出荷されている。一つ開いてみてほしい。コードとして読んでほしい。それがまさにそれなのだから。

ファイルフォーマット作業の二日間が終わった。来週末はエンジンに戻る。