ケース
InterDead の「Why」を再現可能なカノン契約へ変えた方法
カノンの「Why」を InterDead の運用可能な SSOT 契約へ変換したケーススタディ。
ゲームデザインにおける大きく恐ろしい「Why」について。
背景
InterDead は、物語アーキテクチャとメカニクス実装の交点で動き、実体、プロトコル、ローカライゼーションが継続的に増えます。各要素が多くの要素と相互作用し、累積的な複雑さを生みます。
問題
共有された因果関係を持たない局所判断、意味の重複、用語解釈の差、カノン拡大と共に増える矛盾が発生しました。多言語対応も整合性を難しくしました。維持に必要な規律より速くプロジェクトが拡大していました。
仮説
カノンを公開 Wiki へ移し、各実体に明示的な「Why」を与えれば、構造を管理できます。更新を波として導入し、因果関係を検証し、チーム同期を速め、ローカライゼーションを派生版として管理できます。
解決策
「Why」を哲学的な概念から運用ツール、つまりカノン契約へ変えました。各実体には次の要素が必要です。
- 定義された目的
- 文書化された因果関係
- 明確な適用範囲
- 説明可能な結果
Wiki は形式化の環境であると同時に、規律を支える制約システムです。
効果指標
効果はアーキテクチャ上のものです。拡大時の予測可能性、内部矛盾の減少、ローカライゼーション間の意味差の縮小、意思決定の高速化が得られました。最も重要な成果は、因果関係を統制できることです。
副次効果として編集工程の高速化と観客エンゲージメントの改善があり、後者は別ケース『How We Offset Development Costs』で扱います。
制約
このモデルは参入の難易度を上げ、用語の規律を要求し、自発的な反復を遅くします。長期カノンを持たない短期プロトタイプには過剰な場合があります。
中核要因としての自己規律
すべての決定が「Why」に答え、拡大前にカノンを固定し、公開 Wiki が表現精度への圧力として働く場合にモデルは機能します。創造性は構造を得ます。
モデルのアーキテクチャ
SSOT：唯一の信頼できる情報源
カノンの一次版は英語です。他のローカライゼーションは派生版であり、どの版が「正しいか」という対立を避けます。
Change-list プロセス
変更は次の順序で進みます。
- 「Why」を定義する
- 影響を受ける全ページを特定する
- 中核資料を更新する
- 依存する変更を波として伝播する
- ローカライゼーションを検証する
三つの公開モード
手動公開、半自動ビルド、Action API + CI による完全 API 同期を区別します。手動は柔軟ですが誤りやすく、半自動はコピー作業を減らし、API は高い同期性と拡張性を提供します。自動化後も、意味変更に対する編集責任は残ります。
次の段階
次の複雑性は文化的なカノン適応です。文化的文脈を変えながら「Why」を保存する方法を別ケースで扱います。
結論
公開された内部システムにより、「Why」は契約、編集フィルター、アーキテクチャ安定装置、同期機構になりました。