【ITニュース解説】Modeling Game Worlds with Shapezo: A Typed Content Pipeline for Levels, Biomes, and Set Pieces

ゲーム開発において、ゲームの世界を構築する際のドキュメント作成は非常に重要な作業である。しかし、これまでのやり方では多くの課題を抱えていた。例えば、ゲームのレベル（ステージ）は、ゾーン、ルート、視界、インタラクティブな小道具、光の合図、敵との遭遇トリガー、データの読み込み境界、ゲームの進行ペースなど、多くの要素が複雑に絡み合った「グラフ」のような構造を持っている。このグラフとは、複数の異なる要素が互いに関連しあっている状態を、図として表現したものをイメージすると良い。しかし、このような構造的な情報を、従来のWikiページのような単なる文章（非構造的な文章）として保存すると、その要素間の関連性（グラフ）が失われてしまう。その結果、開発者はスプリント（短期間の開発サイクル）ごとに、必要な情報を手作業で探し出し、毎回一からその構造を理解し直すという非効率な作業を強いられていた。

このような問題を解決するために登場したのが「Shapezo」というアプローチだ。Shapezoは、「モデル先行、文章後出し」という考え方に基づいている。これは、まずゲームのロケーション（場所や環境）をシステム的に「モデル化」し、そのモデル（設計図のようなもの）から自動的に文章ドキュメントを生成するという手法である。従来のやり方が文章を先に書くのに対し、Shapezoはデータの構造を先に定義することに重点を置く。Shapezoでは、ゲームコンテンツを「型付きオブジェクト」として扱う。型付きオブジェクトとは、特定の「スキーマ」（データの構造や形式を定義する設計図）に基づいて作られたデータ構造を持つデータのことである。これにより、ゲームのデザインに関する概要（ブリーフ）そのものが、システムで生成・管理される「ビルド成果物」となる。つまり、人間が読むための文章であると同時に、プログラムが理解できるデータとしても扱われるのだ。

Shapezoのレベルスキーマは、意図的に非常にシンプルに設計されている。ほとんどすべてのゲーム環境を表現するために、わずか四つの主要な「エンティティ」（実体、つまりデータのかたまり）で構成される。このスキーマの中で特に注目すべきは、「narrative.shape」と「anchor_details」という二つのフィールドだ。narrative.shapeは、そのレベルの物語的な構造を固定された選択肢の中から選ぶもので、例えば「目的地がある廊下」や「放射状に広がる約束のあるハブ」といった形で定義される。一方、anchor_detailsは、レベルの物理的な詳細のうち、文章で深く掘り下げて説明することを許可する特定の箇所を一つか二つ指定する。それ以外の情報については、概要レベルに留めるというルールが設けられている。このシンプルな制約があるからこそ、生成されるブリーフは常に読みやすく、必要な情報に集中できる内容となるのだ。

モデルから文章を生成する際には、レンダラーと呼ばれる仕組みが使われる。このレンダラーは、先ほど選んだnarrative.shapeの種類ごとに専用の「テンプレート」を持っている。各テンプレートは、複数のセクション（章立て）で構成され、それぞれのセクションには、スキーマの特定のデータパスに紐付けられた「スロット」（穴埋め部分）が用意されている。ここで重要なのは、自由記述が一切許されていない点だ。もしスロットにデータが入力されていなければ、そのセクションは黙って消えてしまうのではなく、目に見える形で「TODO」というマーカーを表示する。これにより、必要な情報が不足している箇所が、ゲームが完成してリリースされる前に、デザインレビューの段階で明確に表面化し、早期に修正できる。また、一度スキーマが定義されれば、そこから生成される出力（文章）は常に同じ内容になる「決定的（deterministic）」な性質を持つため、生成された文章間の「差分（diff）」（変更箇所）が非常に意味のある情報となる。スキーマに変更が加えられると、コードレビューの際に、生成されたブリーフの変更点が明確な差分として表示される。これは、レベルデザインに関する知識の変更が、最も適切なタイミングと場所でレビューされるべきだというShapezoの思想を反映している。

さらにShapezoは、ゲームで使われる画像などの「アセット」（素材）の管理にも革新をもたらす。「アセットパイプライン」と呼ばれる一連の処理工程では、画像は単なる飾りとしてではなく、特定の「契約」（ルール）を持つビルド入力として扱われる。各レベルには、「establishing」（状況設定）、「working_layer」（作業層）、そして「consequence」（結果）という三つの画像スロットが宣言される。そして、画像がシステムに取り込まれる際（インジェスト時）に、パイプラインが自動的にその画像が持つべきジオメトリ（縦横比や解像度）やウェイト（ファイルサイズ）を強制的にチェックし、基準を満たさない場合は処理を停止させる。例えば、「16:9の比率にクロップし、720pの解像度、ファイルサイズは200KB程度のJPEG形式にする」といった具体的なルールが適用される。このファイルサイズの目標は、想像以上に重要だ。デザインブリーフは、開発者のラップトップ、テストプレイを行う部屋のモニター、ビルドマシン、あるいは出張先のホテルのWi-Fi環境など、様々な場所で閲覧される可能性がある。各画像のファイルサイズを200KBに抑えることで、三つのシーンすべてを含むブリーフ全体でも1MB未満に収まり、どこでも快適に閲覧できる状態を保つことができる。

この三つの画像スロットの中でも、特に「working_layer」はShapezoのパイプラインの価値を最もよく表すものだ。このスロットには、簡略化されたレンダリングパス（stylized render pass）で生成された画像が使われるのが最適とされている。ルート（移動経路）、カバー（遮蔽物）、クライムアフォーダンス（登れる場所）、ライトキュー（光の合図）といった要素は、開発スプリントごとに頻繁に変わる可能性がある。そこで、これらの要素を低詳細で模式的に表現したフレームをworking_layerとして使うことで、機能的なベースライン（基準線）として機能させる。この画像をスキーマの一部として管理することで、変更があった場合でも、特定の視点から撮影された画像の「git diff」（バージョン管理システムにおける変更履歴の差分）を比較するだけで、過去の状態を簡単に確認できる。これにより、手作業で過去の情報を探し回るという「考古学プロジェクト」のような手間を省き、効率的な開発が可能になる。

Shapezoのアプローチである「モデル先行、文章後出し」を採用することで、ゲーム開発のドキュメント作成に三つの大きな変化がもたらされる。第一に、ドキュメントが「レビュー可能」になる。スキーマの変更がブリーフの差分として明確に表示されるため、開発チーム内で変更内容を容易に確認し、議論できる。第二に、ドキュメントが「完全」になる。必須のスロットが空の場合、エラーとして明確に表示されるため、情報の抜け漏れを防ぎ、常に最新かつ正確な情報が保証される。第三に、ドキュメントの更新が「安価」になる。レベルの情報を更新する際、長い文章を書き直す必要はなく、わずか数ブロックのYAML（人間が読み書きしやすいデータ記述形式）を編集するだけで済むため、開発コストと手間が大幅に削減される。

Shapezoは、コンテンツ管理システム（CMS）でも、静的サイトジェネレーターでもない。これは、文章を書き始める前に、コンテンツがどのような「形」（構造）を持つべきかを厳密に決定するという「規律」であり、その決定を強制するための最小限のツール群である。特に、ゲームの世界のように、その基盤となるアセット（素材）が元々明確に定義された「グラフ」（要素間の関連性）である場合、この規律は開発者にとって非常に強力な武器となる。システムエンジニアを目指す者にとって、データ構造を設計し、その一貫性を保ち、自動化によって効率を高めるというShapezoの考え方は、ソフトウェア開発における普遍的な原則を学ぶ良い教材となるだろう。