Nexusの仕組み
フラットな複雑さ
従来のゲーム開発は、硬直したシステムの周りに構築される - メカニクスごとに個別のコード、メカニクス間の接続ごとにまた別のコード。サンドボックスでさえ個別システムの集合体だ。多様性は増しても、アーキテクチャは変わらず、開発の複雑さはそれに伴って増大する。
Nexusは異なる構造を持つ。ゲームの基本要素はアトム(原子)であり、そこからすべてが組み上がる。新しいメカニクスを追加しても、アーキテクチャの複雑さは増えない。
数百万の要素があっても、アーキテクチャは複雑にならない。システムはスケールする - どんな複雑さのメカニクス、ルール、世界にも対応できる。
セマンティックネットワーク
Nexusはデータをトリプレット(事実)として保存する -「主語 → 述語 → 目的語」という形式のシンプルな命題だ。世界についての事実もメカニクスのルールも、同じ形式で記述される:
- りんご → である → 食べられる(世界の事実)
- 鹿 → である → 草食動物(世界の事実)
- 打撃 → ダメージを与える → 6(メカニクスのルール)
- 毒 → 防御を無視する → はい(ルールの修正)
- 草 → 育つ → 一定以上の湿度で(世界の事実)
- シンジケート → 支配する → 都市の一区画(世界の事実)
データとルールは同じ形式で、同じグラフに記録される。トリプレットであらゆるものが記述できる - オブジェクト、属性、状態、関係、行動、技術、魔法。これがデータとロジックが別々に存在する従来のアプローチとの決定的な違いだ。
世界は膨大な数の事実の上に成り立っている - 動物、技術、道具、建造物、歴史的出来事。一般的な原理から具体的な詳細まで。
インタプリタ
インタプリタはトリプレットを処理し、事実から推論を導き出す:
- りんご → である → 果物
- 人間 → 食べられる → 果物
- 推論: 人間はりんごを食べられる
推論は事実の照合によって構築される。連鎖は長くなることもある。もう少し複雑な例:
- ゴブリン → である → 生物
- 生物 → 持つ → 体力
- 推論: ゴブリンには体力がある
- 打撃 → 与える → ダメージ
- ダメージ → 減少させる → 体力
- 推論: 打撃はゴブリンに害を与えられる
ダメージの述語を持つ毒を追加すれば、体力を持つすべての存在に対して自動的に効果を発揮する。
インタプリタは形式化されたクエリで動作し、自然言語ではない。
ナレッジグラフ
世界のオブジェクトと属性は、ハードコードなしで柔軟に記述する必要がある。
基盤にあるのはエンティティ - キャラクター、アイテム、動物、組織、船、植物。各エンティティに述語を通じて事実が紐づけられる。
各述語はひとつの関係またはひとつの属性を表す:
- 「である」(分類: ゴブリン → 生物)
- 「持つ」(所有: 生物は体力を持つ)
- 「ダメージ」(効果: 打撃は6を与える)
- 「コスト」(消費: 打撃はマナ3を消費する)
- 「吸収」(防御: 盾は5をブロックする)
- 「関係」(つながり: ゴブリンは人間を憎む)
打撃はダメージ = 6の述語を持つ。盾は吸収 = 5の述語を持つ。エンジンが導出する: 6 - 5 = 1が体力を通過する。剣でも毒でも炎でも呪文でも、あらゆるダメージ源とあらゆる防御に対してひとつのメカニクスで対応する。
属性はネットワークを形成し、各ノードがひとつの事実だ。ルールとインタラクションはコードに埋め込まれるのではなく、データとして存在する。
パフォーマンスのためにキャッシング、インデックス、適応的ディテール(LOD)が使用される。
パターンとしてのルール
データとロジックだけではゲームにならない。ゲームプレイにはルールのレイヤーが必要だ。従来の開発ではルールはコードだ - すべてのメカニクスをプログラマーが書く。Nexusでは、ルールもデータと同じトリプレットで記述される。
基盤にあるのは、あらゆるジャンルに共通する汎用パターンだ。効果: 剣は体力にダメージを与え、錆は耐久度に、インフレは購買力に。消費: 打撃にはマナが必要で、建設には木材が、旅には燃料が必要。吸収: 盾はダメージをブロックし、反論は告発を、保険は損失を軽減する。
デザイナーは「どう起きるか」ではなく「何が起きるか」を記述する。「打撃は6ダメージを与える」- ひとつのトリプレット。エンジンが自動的に判定する - ダメージは吸収を通過し、残りが体力に適用される。計算式をアクションごとに書く必要はない - パターンから導かれる。
パターンは自由に組み合わせられる。カードゲームは効果と吸収を使う。ストラテジーは消費と蓄積を使う。RPGはすべてを組み合わせる。
新しいゲームとは、新しいエンティティとパターンの新しい組み合わせだ。
エージェント
エンティティはエージェントとして記述できる - 独自の状態と行動ルールを持つ。これはオプションの属性だ。カードゲームの敵は自分で行動を選ぶ。ストラテジーの蛮族は条件が揃えば攻撃する。RPGの商人は都市間を移動する。エージェントは:
- 自身の知識の範囲で世界を認識する
- 利用可能な行動を評価する
- 目標と世界のルールに基づいて判断する
エージェントも他のすべてと同じトリプレットで記述される。鍛冶屋は鍛造を知っている(事実)、鉱石が必要(事実)、鉱石は鉱山にある(事実)。これらの事実からインタプリタが行動を導出する - 鉱山に行き、鉱石を採掘する。鉱山が水没した場合、鍛冶屋は鉱石を採れない - 商人を探す - 購入する。行動は事実の連鎖から生まれる。
ロジックを失わないスケーリング
深いシミュレーションでは、世界は膨大なプロセスを含み得る - 動物の移動や都市の成長から恒星系のダイナミクスまで。すべてを計算するのは不可能であり、その必要もない - プレイヤーは常に世界を主観的かつ限定的に認識する。
世界はヘックスのマップとして組織される。各ヘックスはそのスケールに応じた属性を保持する - 惑星レベルでは気候と資源、地域レベルでは都市と道路。ヘックスをクリックすると次のレベルが展開され、より詳細な属性を持つ新しいマップが現れる。恒星系から個別の建物まで、すべてのレベルで同じアルゴリズムが動く。
時間と空間
長期間については、ステップごとの計算ではなく統計モデルを使用できる。すべての瞬間をシミュレートせずに時間を移動できる。例えば千年の間に、森が育ったり消えたり、川が流れを変えたり、集落が拡大したり放棄されたりする。傾向と関係性は保持される。
空間のスケーリングがエンティティとプロセスのレベルを決定する。広域スケールでは気候、移住、政治。ローカルスケールでは個々のエンティティとその属性。因果関係のロジックはすべてのレベルで共通だ。
抽象化により、あらゆるスケールの世界を収容できる - 村、惑星、銀河。詳細は意味を持つときに現れる。残りは簡略化された形で記述されるが、関係性は保持される。
プレイヤーは世界の構造を掘り下げ、エンティティを調べてその属性をたどっていくことができる - リファレンスシステムのナビゲーションのように。
世界のマテリアライゼーション
世界は探索に応じて構築される。プレイヤーが訪れていないロケーションは、データとルールとして存在する。オブジェクトはあらかじめ保存されるのではなく、インタラクションの瞬間に出現する。
観察範囲外のイベントは、完全なシミュレーションではなく確率によって決定される。詳細はオンデマンドで生成されるが、世界は一貫して見える。
ロケーションとのインタラクション後、その状態は保存され、再計算されない。
長い時間スケールでは統計的な傾向が機能する。開始から千年後、どの種が生き残るか、気候がどう変わるか、どこに集落が現れるかをシステムが確率的に決定する。
ネットワークプレイ
ネットワークプレイも同じ原理で動作する。サーバーがデータ、ルール、プレイヤーがすでに発見したものを保持する。
複数のプレイヤーが同じエリアにいれば、サーバーが共有状態を集約し、プレイヤー間で同期する。
プレイエリア外では世界は潜在的なまま - ルールと傾向のみで、詳細はない。
基本的なネットワークアーキテクチャはすでに稼働している。各プレイヤーが隔離されたセッションを受け取り、他のプレイヤーがコードで参加できる。アクションはリアルタイムで同期される。
言語としてのアーキテクチャ
データ、ルール、インターフェース、エージェントの行動 - すべて同じ形式。エンティティは互いを知らず、共通の述語を通じて自動的に接続が生まれる。
実際にどう機能するか? 森はエンティティであり、事実を持つ - 木材がある、隠れ場所である、可燃性である。斧は述語「伐採」を持つ。伐採は木材に作用する。火は可燃物に作用する。干ばつは可燃性を高める。各事実は一行。森は斧のことを知らず、斧は森のことを知らない。接続は共通の述語を通じて自動的に生まれる。伐採の述語を持つレーザーカッターを追加すれば、森に対して機能する。火の述語を持つ惑星爆撃を追加すれば、森は燃える。
ゲームの状況を言葉で記述できるなら、Nexusで動く。