最近メールをチェックしていたら、スタレ（崩壊：スターレイル）の新キャラクター「花火」がちょっと面白そうだったから、またスタレの旅を始めてみた（そう、花火のこと。この記事を書き終えたあとに投稿するのを忘れてたことに気づいたんだ。まあ、相変わらず数日遊んでアンインストールしちゃったんだけどね）。

でも、久しぶりだったせいか、今回のプレイは明らかにいつもと違う感覚があった。遊んでいるというより、開発の設計アーキテクチャを理解しようとしている自分に気づいたんだ。

全体アーキテクチャ

全体的に見ると、スタレの設計思想（ボトムロジック）は「高内聚・低結合（高コヒーレンス・疎結合）」の原則を徹底しているように思える。

ゲームの各世界、各メインシティ、さらには各大型バージョンにいたるまで、すべて独立した小さなモジュールに分割されている。この設計のおかげで、ゲームの並行開発が可能になっているんだ。

別々のチームが異なるアイデアを持って同時に作業を進め、完成度が高いものや、先に出来上がったモジュールからメインストーリーに繋げていく。メインプログラムは統一された実行環境を提供するだけで、あとはこれらの「積み木」を組み立てるだけ、というわけだ。

キャラクター設計

シナリオとキャラクターのコントロール（スケジューリング）において、ここでは2つの全く異なる戦略が取られているように見える。

• メインストーリーのキャラクター（一貫する存在）：システムにおけるコアな「シングルトン（Singleton）」のようなもので、専門のメインシナリオチームが担当している。これによって、世界観設定の一貫性とロジックの自己整合性が保たれているんだ。
• サブクエスト／ガチャキャラクター（独立モジュール）：多くのキャラクターは実際には独立した一つのエピソードを担っているだけで、いわば特定の「標準インターフェース（Interface）」を実装したようなもの。開発が終わったら、そのインターフェースをどうにかしてメインストーリーに接続すればいい。
• キャラクターの呼び出し（コール）について：サブキャラクターはメインキャラクターのように常に状態の一貫性を保つ必要がない。そのため、システムが後のシナリオで彼らを再び呼び出す（登場させる）ときは、設定されたいくつかの「コアタグ（ステレオタイプ）」を抽出してシナリオを書けば事足りるようになっている。

ゲームシステム設計

ゲームシステム（遊び方）の次元から見ると、この「ミドルウェア化」されたフレームワーク感がさらに顕著になる。

「模擬宇宙」や「虚構叙事」といったコアコンテンツ、そして各バージョンの大型イベントは、ゲームシステムの根本ロジックやゲーム内通貨システムにいたるまで、メインストーリーから完全に独立している。これは、ゲーム本体をまるごと一つの巨大な「Spring Cloud サービスレジストリ（登録センター）」と見なしているようなものだ。

各開発チームが自由にアイデアを形にし、それぞれのコンテンツを独立した「マイクロサービス（Microservices）」としてパッケージ化する。そしてテストが終わったら、そのままゲームのフレームワークに組み込む。この設計は、バグの隔離（例えば模擬宇宙で問題が起きてもメインストーリーの進行には影響しない）だけでなく、ゲームの定期アップデートを確実に実現するための担保にもなっている。アップデートの時期が来たら、開発ブランチから最も完成度の高いサービスを引っ張ってきて統合するだけでいいからね。

トレードオフと考察

もちろん、タダで手に入るものはない。この究極の疎結合（デカップリング）であるマイクロサービスアーキテクチャにも、明らかな欠点はある。

プレイヤーとして一番直感的に感じるのは、「浮いている」感覚や「ぽっと出」感だ。高度に独立したイベントモジュールやキャラクターが無理やりメインストーリーの世界に組み込まれると、深い文脈（コンテキスト）の結合がないため、どうしても乖離感やチグハグさが生まれてしまう。

だけど、数百人から数千人規模の超巨大ゲーム開発チームが協業する中では、こうした妥協は避けられないのかもしれない。「技術的負債」に立ち向かうため、アーキテクトはインターフェース指向プログラミングを選択するしかないんだ。つまり、最高水準の共通プロトコルを定義し、すべてのチームに冷徹にそれを実行させる。

おそらく、これこそが現代の工業化されたコンテンツ制作の究極の形なのだろう。究極の理性的なフレームワークを用いて、感性的なデジタルの夢を支えるのだ。