つぶやく
 |
7月23日に行われた特別招待講演「紅の砂漠（Crimson Desert）：大規模オープンワールドゲーム開発のためのプロセス確立」で語られたのは，後者――物量を投じる前に，回る仕組みを先に作るという選択だった。
登壇したのは，Pearl Abyssで「紅の砂漠」のゲームデザインを担当した2名だ。ドゥ・スンビン氏はプレイヤーアクションと戦闘システムの設計を，キム・ヒョンギョム氏はレベルデザインとクエストデザインを主に受け持った。講演は英語で行われ，日本語の同時通訳が付いた。
 |
冒頭で両氏は，これから話すのは完璧な解でも完成した手法でもなく，あくまで振り返りだと断った。ぶつかった問題と，そこから学んだこと，そして問題解決に対する自分たちの考え方――それを共有したい，と。
開発期間が約7年と長期化した理由は明快だ。プロジェクトの最初から，これを1本のゲームとしてではなく，スタジオの今後のプロジェクトを支える土台として位置づけていたからである。だからこそ意識的に開発を急がず，ツール，ワークフロー，制作プロセス全体の改善に時間を使った。その経験を次のプロジェクトに引き継ぐことが目的だった。
そのうえで両氏が「コアチャレンジ」と呼んだのが，野心と手持ちのリソースとのギャップである。目標は，AAA品質で，やることが詰まった大きな生きた世界を作ること。大規模な白兵戦，実在感のあるNPC，パズル，探索コンテンツ，そして実際に干渉できる世界。ジャンルを意味のある形で前へ進めたいという狙いがあった。
一方で制約は現実的だった。チームはおよそ200人。同等規模のオープンワールドを手掛ける他社チームと比べるとかなり小さい。しかも長らくMMOを中心に作ってきたスタジオにとって，これが初のシングルプレイタイトルだった。
 |
早い段階で両氏は重要なことに気づいたという。人を増やす，あるいは全員がもっと頑張る，というやり方では足りない。必要なのは，規模に応じてスケールするプロセスだ。生産性の向上はあれば望ましいという程度のものではなく，プロジェクトを完走するための唯一の道だった。
そこで軸に据えたのが3つの概念である。1つめは「高速なイテレーション」，すなわちフィードバックループの短縮。プロトタイピング初期だけでなく，磨き込みのフェーズでも効いてくる。チーム間の協業から，パラメータをいじって結果をその場で確認するといった細かい作業まで，あらゆる場所に現れる。
2つめは「保守性」，コンテンツを柔軟に，変更しやすい状態に保つことだ。どれだけ綿密に計画しても，プロジェクトは変更を免れない。コンテンツの変更が難しかったり，1つの変更に時間と調整が掛かりすぎたりすると，人は改善したいと思わなくなる。「紅の砂漠」の規模では，要件の変化に合わせて膨大な量のコンテンツを作り替える必要があった。
3つめは「並列ワークフロー」，チーム間の依存関係を減らすことである。部署をまたいで作業が固く連鎖していると，人は作るより待つことに時間を使うようになり，ボトルネックが生産全体を遅らせる。
 |
クエストから世界を作るのをやめた――「ワールドファースト」への転換
最初にして最大の課題が，オープンワールドをどう埋めるかだった。大きなマップを作ること自体は，1つの作業にすぎない。その空間を意味あるもの，探索する価値のあるものにしなければならず，しかもそれを大規模にやる必要がある。
両氏のアプローチは，世界を層（レイヤー）として積み上げることだった。1層めが環境レイヤーだ。地形，植生，野生動物，ランドマークが入る。2層めがコンテンツレイヤーで，アイテム，宝箱，NPCスケジュール，砦，盗賊のキャンプ，パズルエリアなど。3層めがメタゲームレイヤーで，交易拠点や勢力ノードといった，世界に大きな戦略構造を与えるシステム群だ。
 |
各レイヤーは独立して作れるうえ，単体で見ればどれも単純だ。しかし複数のレイヤーが1つのエリアで重なると，はるかに厚みのある体験ができあがる。小さな谷を思い浮かべてほしい，と両氏は言う。採取できる植物があり，野生動物がうろつき，近くに盗賊のキャンプがあり，宝箱の入った隠し洞窟がある。個々は単純でも，まとまればプレイヤーが立ち寄り，探索し，戦い，発見する理由になる。
この層構造は制作側にも効いた。すべてのエリアをゼロから手作りするのではなく，チームごとに異なる種類のコンテンツを別々に作り，それらを自然に組み合わせる。ありうる組み合わせを1つ1つ手で計画しなくても，バリエーションと密度が得られたわけだ。
この考え方の狙いは，クエストを追っていないときでも世界が遊べる状態を保つことにあった。それは，世界とクエスト構造の一般的な関係を組み替えることを意味する。多くのゲームではクエストがゲームプレイを駆動し，世界は物語の背景として存在する。両氏はそれを反転させ，オープンワールドそのものをゲームプレイの主たる供給源にしようとした。物語とクエストは依然として重要だが，あるエリアを訪れる唯一の理由ではなく，すでにそれ自体で魅力のある世界を案内するガイドとして扱われる。
 |
この構造の採用には，2つの理由があった。1つは思想的なものだ。オープンワールドゲームでは，メインクエストをどこまで進めていようと，プレイヤーが方向を決めて歩き出せば意味のある何かに出会えるべきだと両氏は考えていた。物語を完全に脇に置いたとしても，世界は発見できる場所，戦う敵，集める資源，見つかる報酬を与えてくれなければならない。探索そのものが，時間つぶしではなく本物のゲームプレイとして感じられる必要があった。
もう1つは生産性だ。開発初期，チームは「クエストファースト」で進めていた。工程はほぼ直列である。まずクエストを設計し，そのための環境を構築し，周囲に補助的なコンテンツを足す。世界は，各クエストが必要とするものを中心に組み上げられていた。
小規模ならそれでも回る。だが「紅の砂漠」の規模になると，実際の問題が噴き出した。制作サイクルは長くなり，チーム間の依存関係は積み上がり，クエストの目的が変われば環境やコンテンツまで作り直すことがしばしばあった。
 |
そこで「ワールドファースト」に切り替えた。クエストが各エリアを定義するのを待つのではなく，先に世界の遊べる土台を作る。土台さえできていれば，環境作業，コンテンツ配置，クエスト開発を大きく重ねながら同時に進められる。
もちろんチーム間の対話がなくなったわけではない。ストーリーとクエストのチームは環境やコンテンツのチームと密に連携し，物語がどうしても必要とする場合はエリアを調整した。
決定的に違うのは，クエストがそのエリアの唯一の出発点ではなくなったことだ。地形，ランドマーク，コンテンツレイヤーが，すべてのチームが乗れる共有の土台になった。これで強い依存関係が劇的に減った。ストーリーの変更がエリア全体の作り直しを意味しなくなり，多くの場合はクエストレイヤーを調整したり，目的を見直したり，すでに完全に遊べる空間に要素をいくつか足したりするだけで済むようになったのである。
このワールドファーストのパイプラインを実務で支えたのが，配置戦略だった。オープンワールドを効率的に埋めるため，自動配置と手作業のスポット配置を組み合わせるハイブリッドが採用されている。大規模なレイアウト，とくに川や道といった世界全体の構造を決める要素はHoudiniに大きく依存した。プロシージャルなツールを使えば，手作業よりはるかに速く構築と修正が回せる。
自動化はコンテンツの広域分布にも使われた。地域と地形のデータに基づいて，森に小動物を，水中に魚を配置し，地形タイプに応じて植生を撒き，道沿いにNPCを置く。しかも具体的な選択は地域ごとに変わる。これで，人の手がまったく入っていないエリアでも，世界全体に一定の密度が担保された。空っぽではなく，すでに人が住んでいる状態から始められるわけだ。
地域と地形の分類にはビットマップとトリガーを用い，このデータからキャラクターやワールドオブジェクトを適切な場所に自動スポーンさせる。道のスプラインからパスデータを抽出し，徘徊するNPCや野生動物のスポーンにも利用した。
 |
より強い意図や記憶に残る瞬間が必要な場所には，スポット配置が使われた。NPCの日常生活の小さな場面，スケジュールされた活動，特徴的なイベント的瞬間，クエストの受注者のような重要キャラクターなどだ。両氏いわく，これらが組み合わさると，プレイヤーは自動生成された背景の生活と意図的にデザインされた瞬間をほとんど区別しない。仕込まれた場面でさえ，世界の自然な一部として感じられるようになる。
講演では戦場のシーンが例として示された。逃げ惑うNPCはトリガーイベント。道に立つNPCは，プレイヤーが近づくとカットシーンを起動する仕込まれたイベント。一方で互いに戦っているNPCは，完全に演出されたシーケンスではない。敵対する勢力を戦場に置くだけで，NPCは自身のAIに従って敵を見つけ戦闘を演じる。これにより，最小限の労力で広大な戦場を埋められたという。
ただし両氏は，このアプローチが完璧だったとは言わなかった。ワールドファーストのパイプラインは，広大な遊べる世界，チーム間の依存の削減，職種をまたいだ高速なイテレーションという実利をもたらしたが，代償もあった。世界とそのコンテンツレイヤーが先に確定するため，物語のほうが，探索や戦闘やシステム的なゲームプレイを軸に形作られた空間に合わせざるをえない場面が出てきたのである。
 |
結果として一部のプレイヤーからは，ストーリーの進行が本来ありえたほど強くない，まとまりに欠ける，という声が上がった。両氏はその批判を聞いており，率直に，自分たちの開発アプローチがそこに影響していると考えていると述べた。
生産性を保ちながら，メインストーリーに体験全体を通じたより強い存在感を持たせるにはどうすればよいか。きれいな答えはまだ出ておらず，議論とテストと改善を続けている，という言い方だった。
「ギミック」と「フェーズスイッチング」――世界を動かすための2つの仕掛け
世界を埋めた次の課題は，世界をインタラクティブにすることだった。世界が信じられるものになるには，プレイヤーが眺めたり通り抜けたりするだけの存在ではなく，反応を返す必要がある。
両氏はインタラクションを2つの軸で整理した。プレイヤーが何をするか，そして世界のどの部分が応えるか，である。プレイヤー側は単純な移動から直接的なアクション，さらに長期的な進行まで。世界側の反応は，1本の草が揺れるといった小さなものから，レベルの一区画がまるごと変わるものまで，スケールが異なる。
 |
最初のレイヤーは植生である。多くのオープンワールドゲームで草や木は基本的に装飾だが，「紅の砂漠」では管理できる範囲で植生をインタラクティブな世界の一部にしようとした。移動するだけで，立っている地面に応じた土埃や小さな破片といったフィードバックが発生する。草や木々はプレイヤーが通ると反応する。アクションのレベルでは，武器を振って草や葉を刈り，木を切り倒し，さらには木をしならせてその反動で自分を前方に射出することまでできる。
 |
次がオブジェクトだ。世界が静的な小道具の集まりに見えないよう，可能な限りオブジェクトに何らかのゲームプレイ上の反応を持たせる方針が採られた。指針はごく単純で，できるだけ多くのオブジェクトを，インタラクト可能か，破壊可能か，何らかの形でリアクティブにする，というものである。
社内では，明確に定義された状態と挙動を持つスクリプト化済みのゲームプレイオブジェクトを「ギミック」と呼んでいる。目標は，ただのシーンオブジェクトに頼るのではなく，世界に占めるギミックの割合を増やし続けることだった。ギミックはプレイヤーが近づくと発動する罠や持ち上げられる箱のように単純なものもあれば，複数の可動部が1つの機構として働くクレーンのように複雑なものもある。重要なのは，これらがゲームプレイ要素として作られている点だ。
 |
これをスケールさせるため，独自のXMLスクリプティングシステムが構築された。デザイナーは1件ずつコードを書かずにギミックの挙動を定義できる。加えて，オブジェクトの自動差し替えもサポートされた。アーティストは通常のオブジェクトで世界を作り続け，デザイナーは並行してインタラクティブ版を用意し，準備ができたら一括で入れ替えられる。環境配置とギミック制作を並列で走らせるための仕掛けだ。
完全なギミックではない通常のオブジェクトにも，意味がある範囲で簡易な反応が足された。物理に反応するもの，強い衝撃で壊れるものなどだ。特定の機能がないオブジェクトでも，持ち上げて武器として投げたり，アイテム化して店で売ったり，自宅に飾ったりできるようにしている。
さらに，機能がありそうに見えるものは実際に機能させる方針が採られた。井戸，エレベーター，クレーン，城門を静的な装飾で終わらせず，インタラクティブにして機械的な機能を与えることで，プレイヤーの好奇心に報いようとしたのだという。
 |
インタラクションの最後のレイヤーは，レベル単位のスケールである。プレイヤーの進行に応じて世界の状態そのものを変えたい，という要求だ。敵の砦を思い浮かべてほしい。最初は敵に占拠されているが，プレイヤーが掃討すると同じ場所が味方の前哨基地になる。
素直に実装するなら，まったく別バージョンのマップを作り，状態変化時にロードすればよい。だがオープンワールドではそれが成立しない。地形は巨大で，多くのシステムが同じワールドデータを共有しており，1つのエリアについて複数の完全版を維持するのは大きなオーバーヘッドになる。
そこでマップ全体を差し替えるのではなく，「フェーズスイッチング」と呼ぶ手法が使われた。固定されるものと変化しうるものを分離する考え方だ。固定データは「ベースレベル」に置く。地形のように基本的に変化しない大規模で永続的な要素である。可変データは別の「ゲームプレイレベル」に入れる。建物，NPC，障害物，敵の配置，パズルのギミックといった，フェーズに依存するものだ。プレイヤーの進行がフェーズ変更を引き起こすと，ベースレベルはロードされたまま，ゲームプレイレベルだけが差し替わる。同じ場所がマップ全体を複製することなく，まったく異なる世界の状態を表現できる。
 |
このフェーズのロジックもXMLでデータ駆動化されており，デザイナーが各フェーズの条件，切り替えのタイミング，その状態でアクティブにすべきゲームプレイレベルを定義できる。
例として挙げられたのが，ゲーム中でもっともなじみ深い場所の1つ，グレイメイン族の拠点だ。この拠点はプレイヤーの旅を通じて変化していく必要があったため，共有のベースレベルの上にモジュール化したゲームプレイレベルを重ねる形で作られた。デザイナーはベースレベルを触らずに自由にイテレーションでき，結果としてプレイヤーは拠点が時間とともに自然に成長していく様子を見られるようになった。
 |
XMLという共通言語が，職種の壁を溶かした
講演の後半は，ここまでの仕組みを下支えするツールとデータシステムに充てられた。Pearl Abyssではコンテンツ関連のデータとスクリプトすべてに，共通の構文としてXMLを使っている。
コンテンツの種類ごとに異なるチャート形式が定義されている。キャラクターのアクションは，移動や攻撃などの挙動を定義する「アクションチャート」。NPCの挙動ロジックは「AIチャート」。インタラクティブなオブジェクトの状態と変化は「ギミックチャート」。ステージのイベントと進行は「ステージチャート」だ。
アクションチャートを例に取ると，キャラクターのアクションはステートマシンとして働く。1つのアクションが1つのステートであり，XMLの各ノードがそのステートに対応する。ノードの中の子ノードが，そのアクション中に何が起きるかを記述する。アニメーションノードは再生するアニメーションを指定し，フレームイベントノードは特定のフレームでエフェクトや攻撃判定，サウンドを発生させる。ブランチノードは他のステートへの遷移を定義する。XMLの構造がアクションのステートマシンそのものに直接対応しているわけだ。狙いは，コンテンツスクリプトを読みやすく，学びやすく，管理しやすく保つことにある。
 |
簡易化されたコンテンツスクリプトを制作に使うことで，デザイナーの技術的な障壁が下がり，小さな変更のたびにエンジンのコードを書かずに済む。データを通じて直接コンテンツを作り，調整し，テストできるためプロトタイピングとイテレーションが大幅に速くなる。プログラマは，デザイナーがスクリプトで組み合わせられるアクション，イベント，条件，ランタイムシステムといった再利用可能なエンジン機能のツールボックス作りに集中できる。
興味深いのは，そのうえで数ある選択肢からXMLを選んだ理由だ。両氏によれば，XMLは他のスクリプト言語とビジュアルエディタの中間にある現実的な落としどころだった。PythonやLuaのようなものと比べれば，非プログラマにとってXMLははるかに読みやすく学びやすい。ノードの階層が関係性を明示してくれるし，すべてのコンテンツ領域でXMLを使っているので基本構文がどこでも一貫する。
Blueprintのようなビジュアルエディタと比べると，XMLは構築と保守のコストがはるかに安い。コンテンツの種類ごとに専用のエディタUIを開発・保守する必要がなく，UXまわりの問題も発生しない。検索，一括編集，正規表現，アンドゥ履歴，プロジェクト内の移動といった標準的なテキストエディタとIDEの機能をそのまま活用できる。テキストベースなのでバージョン管理とも相性がよく，差分は確認しやすく，マージも扱いやすく，複数人が同時に同じコンテンツを編集できる。
 |
そしてもう1つ，比較的最近の利点として両氏が挙げたのが，テキスト形式であることによるAI支援ツールとの相性の良さだった。Claudeのようなツールとも非常にうまく機能するのだという。具体的な製品名まで挙がったこともあって，会場でもひときわ現実味のある話として響いた。
XMLは静的なゲームデータにも使われている。多くのチームと同じく，Pearl Abyssも当初はExcelのスプレッドシートを使っていた。慣れ親しんでいて編集しやすく，業界標準として広く受け入れられていたからだ。しかしプロジェクトが大きくなるにつれ，多くの開発者が経験しているのと同じ限界にぶつかった。
1つは複雑さである。列の数は増え続け，データ同士の関係は追いづらくなり，読むのも，レビューするのも，安全に編集するのも難しいシートが出てきた。もう1つはバージョン管理だ。スプレッドシートは差分とマージに向いておらず，複数人が同時に編集する場面ではとくに厳しい。実際には，誰かの作業が終わるのを別の誰かが待ってからでないと安全に変更できなかった。
そこでスプレッドシートのワークフローを拡大し続けるのをやめ，静的ゲームデータを独自のXML形式に置き換えた。Excelの列だった項目は属性か子ノードとして定義される。共通する属性はマクロとして定義でき，繰り返しを減らせる。それ以外の主要データを子ノードにすることで，1キャラクターに関する情報のほとんどが1画面に収まるようになった。
 |
スプレッドシートからの脱却は同社にとってかなり大きな変更だったが，見返りもあった。データ構造が読みやすく取っつきやすくなり，データにアクセスして直接編集できる人が増えた。新しいデータの追加や既存データの修正のために専任のゲームデータ担当者を通す必要がなくなり，必要な人は誰でも自分でできるようになったのである。
ここからが本題だ，というように両氏が力を込めたのは，個々の作業が速くなった以上の効果である。スクリプトとデータがここまでアクセスしやすくなると，それらはチーム全体の共通言語に変わった。プログラマも，デザイナーも，アーティストも，同じデータを見て，何がどう実装されているかを理解し，具体的な細部について一緒に話せる。
全員が同じ仕事をするようになるとか，専門性がなくなるという話ではない。各職種はそれぞれの専門性を保ったまま，職種間の境界が意味のある形で重なり始める。アーティストは新しいリソースをゲームに反映してもらうのを待たず，自分で変更を適用できる。デザイナーは小さな変更のたびにプログラマを経由せず，ゲーム内で直接プロトタイプを作れる。同時にプログラマは，自分の作ったシステムがコンテンツ制作者に実際どう使われているかを，はるかによく把握できるようになる。
 |
具体例として示されたのが，パズルのプロトタイピングだ。当初のワークフローは直列だった。デザイナーがパズルの設計書を書き，レベルアートチームが環境と必要なアセットを作り，その上にゲームプレイのロジックを実装する。だがこれは修正の繰り返しを招きがちだった。設計意図と環境の実際の制約が，かならずしも一致しなかったからだ。
XMLベースのパズルスクリプトが扱いやすくなると，この工程は一気に協業的になった。デザイナー側は，実際の環境に実寸で置いたプロキシメッシュを使ってパズルのインタラクションを直接プロトタイプできる。意図をはるかに明確に伝えられるうえ，アイデアを実際の環境に対して検証できる。レベルアート側も最終的な出力への統制を得た。タイミング，ペース，反応性，映像的な質感を直接調整できるし，スクリプト側の挙動を見越して，扉のピボットを回しやすい位置に設定しておく，破壊用にモデルのパーツを分けておく，といったアセット準備が可能になる。
最後に両氏が挙げたのが，ゲームデザイナーという職種そのものの汎用性が増したことだ。デザイナーは戦闘アクション，AIパターン，ステージロジック，ギミックといった複数のコンテンツ領域を横断して作業できる。すべてが統一されたXMLベースの構文を共有しているため，領域ごとにまったく異なるワークフローを覚え直す必要がない。基本構造さえ理解すれば，同じアプローチをあらゆるコンテンツに適用できる。
たとえばボス戦を作るとき，1人のデザイナーがステージロジックを定義し，戦闘アクションを組み，AIパターンを設定し，ギミックや罠を配置するところまで，同じステージの中で完結できる。頻繁な引き継ぎが要らなくなるぶん，デザイナーは複数の専門にまたがるタスクを独立して扱えるようになり，体験全体を直接イテレーションできる。コミュニケーションのオーバーヘッドも減る。チームマネジメントの観点でも，プロジェクトがそのとき必要としているものに応じて，デザイナーをコンテンツ領域間で動かせる自由度が生まれた。個人の生産性が上がるだけでなく，制作チーム全体が適応的で機敏になるということだ。
冒頭で両氏が断ったとおり，この講演は完璧な解の提示ではなかった。ワールドファーストのパイプラインは物語の弱さという代償を残し，配置の干渉は今も人の目で確認されている。それでも，クエストを起点にする作り方を捨て，スプレッドシートを捨て，手作業による広域配置を捨てて，そのぶんをレイヤー構造とフェーズスイッチングとXMLという仕組みに置き換えた7年間の記録は，同じ規模の壁に向き合う開発者にとって十分に生々しいものだったはずだ。
