game-systems-design

ゲームシステム設計

機能の一覧を作るだけでなく、時間の経過に伴うゲームの振る舞いを設計します。意図するプレイヤー体験を、明示的な状態、ルール、フィードバック、根拠と結び付けます。

エンジンに依存しない形で進めます。ユーザーが実装環境を指定しない限り、状態表、方程式、図、遷移ルール、擬似コードで振る舞いを表現します。

基本原則

• システム境界は、特定の問いと時間軸に応じて選択する設計上の判断として扱います。
• 各要素をその状態と振る舞いでモデル化し、次に、それらの要素が互いを変化させる関係をモデル化します。
• 変化を増幅する強化フィードバックと、逸脱に対抗する均衡フィードバックを区別します。どちらも本質的に良い、または悪いものではありません。
• コアループは、プレイヤーの直近の注意を引き付ける、意図・行動・状態変化・フィードバックの反復サイクルとして定義します。
• メタループは、今後のコアループの試行、セッション、またはチャプターの条件を変化させる、より遅いサイクルとして定義します。
• ゲーム内の真実、プレイヤーが確認できる根拠、プレイヤーがしそうな解釈を分けます。プレイヤーが推測できないルールは、計画を立てるうえで確実に役立つものにはなりません。
• 例外を増やすより、意味のある相互作用を持つ、再利用可能な少数のルールを優先します。
• システムを洗練したり拡張したりする前に、最もリスクの高い前提をプロトタイプで検証します。
• プレイテストのコメントは、体験や問題を示す根拠として扱い、正しい解決策そのものだと決めつけません。
• 意図、モデル、プロトタイプ、実装、現時点の根拠を、相互に追跡できる状態に保ちます。

事前確認

置き換え案を提示する前に、既存の設計メモ、データ、図、ビルド、テスト、制約を確認します。タスクに必要な範囲で、以下をできるだけ明確にします。

• プレイヤーへの約束：役割、望まれる判断、感情、習熟。
• 対象者と状況：想定される知識、セッションの長さ、プレイヤー数、対戦または協力プレイの設定。
• 設計上の問い：解決しようとしている不確実性や失敗。
• 範囲：1回の遭遇、1セッション、継続的な進行、またはゲーム全体。
• 現在のシステム：要素、ルール、リソース、インターフェース、既知の依存関係。
• 制約：制作予算、コンテンツ予算、アクセシビリティ、プラットフォーム、ネットワーク、永続化、ビジネスルール。
• 根拠：観察、プレイテストのメモ、テレメトリー、シミュレーション、または前提のみ。
• 必要な成果物と対象者。

情報が得られないからといって、作業を止めないでください。重要な前提を明示し、不明点を示し、それを解消するために必要な根拠を特定します。

ワークフロー

1. 意図する体験を明確にする

システムを図示する前に、目標を簡潔に記述します。

The player repeatedly [decision/action] to pursue [goal].
The interesting tension is [tradeoff or uncertainty].
The player should learn [model] and eventually master [skill].
Success looks like [observable behavior or result].
The design must avoid [failure experience].

曖昧な性質を、具体的な振る舞いに置き換えます。「奥深いクラフト」を、たとえば「プレイヤーは状況に応じて役立つレシピを少なくとも2つから選び、それぞれが異なるニーズに合う理由を説明できる」といった主張に置き換えます。

2. 境界と時間スケールを定める

境界の内側、外側、境界をまたぐものを明示します。最小の意味ある時間ステップと、問いに関係する最長の時間軸を指定します。

境界を定めるワークシート、要素の一覧、関係マップ、フィードバック分析、作業例には、システムモデリングを使用します。

異なるスケールを暗黙に混在させないでください。1秒間の戦闘反応、10分間の遭遇、10セッションにわたるアップグレードサイクルは、相互に作用することがありますが、それぞれに固有の状態と進行周期が必要です。

3. 要素と関係を一覧にする

関連する各要素について、以下を記録します。

• 状態：変化する値、単位、初期値、範囲。
• 振る舞い：何を感知、決定、生成、消費、変換、伝達できるか。
• 所有者：どのルールがその状態を変更できるか。
• 可視性：プレイヤーが何を、いつ確認できるか。
• 関係：何が、どの条件で、どの程度の遅延を経て、別の要素に渡るか。

問いに関与しない装飾的な名詞は取り除きます。時間、注意、容量、脅威、評判、ターン順など、物理的でない要素でも、振る舞いを実質的に変えるものは追加します。

4. フィードバックを追跡し、分類する

重要な出力をすべて追跡し、それが境界の外へ出るか、以前の状態に影響を及ぼす形で戻るまで確認します。

閉じた経路ごとに、次の項目を確認します。

1. プレイヤーにとっての目的を示します。
2. 各関係が同方向か逆方向かを記します。
3. ループが強化ループか均衡ループかを分類します。
4. 遅延、しきい値、上限、非線形領域を記します。
5. 誰がループに変化を加えられるか、またその結果がどのフィードバックで明らかになるかを特定します。
6. 値が低いとき、通常のとき、高いとき、敵対的なときに何が起こるかを予測します。

強化ループでは、優位性の暴走、希少性の累積、回復不能な衰退を確認します。均衡ループでは、反応の遅さ、振動、隠れた補償、獲得した優位性の喪失を確認します。

5. コアループとメタループをつなぐ

コアループを機能名ではなく、動詞で説明します。

read situation -> choose -> act -> resolve -> perceive result -> choose again

よりゆっくり進む各ループを、それぞれ分けて説明します。

complete attempt -> earn or lose persistent resources -> invest -> alter future options -> begin next attempt

次に、それらの間の各つながりを特定します。つながりでは、次の点を説明します。

• コアループから何が出ていくのか。
• メタループがそれをどのように変換、または蓄積するのか。
• 後のコアループに何が戻るのか。
• 選択肢を広げるのか、単に数値を上げるだけなのか、それとも以前の学習を無効にするのか。

コアループは楽しいのに、メタループが必須の事務作業になっている場合は、メタループを簡素化します。メタループによって次のコアループへの挑戦が自動的なものになる場合は、その力に上限を設けるか、別の用途に振り向けます。

6. プレイヤーのメンタルモデルを設計する

意思決定に重要なルールごとに、次の流れを完成させます。

game state -> perceivable cue -> player interpretation -> prediction -> action -> confirming or correcting feedback

新しいプレイヤーが手がかりに気づき、正しい原因と結びつけ、有用な結果を予測し、誤ったメンタルモデルから立て直せるかを確認します。不確実な状況での推論がプレイの一部である場合に限り、不確実性を残します。

説明を加えるだけで、コミュニケーション上の問題を解決しようとしてはいけません。まず、ルールの一貫性、状態の見えやすさ、原因と結果のタイミング、フィードバックの優先順位を改善します。

7. コンテンツを追加する前にシステムを診断する

代表的なプレイの流れを用いて、モデルを紙上でテストします。

• 初回プレイの流れ：事前知識やアップグレードがない状態。
• 標準的なプレイの流れ：想定されるスキルとリソースを持つ状態。
• 熟練者のプレイの流れ：最適化された選択と高い実行精度。
• 立て直しの流れ：プレイヤーが不利な状況から始める、または大きなミスをする状態。
• 飽和時の流れ：上限、エンドゲームの蓄積資源、成熟した戦略。
• 敵対的なプレイの流れ：ため込み、停滞、結託、破綻したループ、または繰り返される悪用。

問題が見つかったときは、数値を変える前に関係性をさかのぼってたどります。目に見える問題の原因は、数段階離れたところにあるかもしれません。

8. 不確実性を一つだけプロトタイプで検証する

検証するやり取りを保てる、最も手軽な媒体を選びます。紙、カード、スプレッドシート、進行役が台本に沿って行うテスト、小規模なシミュレーション、インタラクティブなデジタルビルドなどが候補です。

Prototyping and Playtestingを使って、仮説カード、テストスクリプト、観察シート、メンタルモデルの確認項目、反復記録を作成します。

ゲームプレイのプロトタイプでは、プレイヤーが意図を立て、行動し、状態に応じた結果を受け取り、再び選択できるようにする必要があります。インタラクティブでないモデルで内部の動態は検証できますが、プレイ体験は検証できません。

9. プレイテストを行い、理解を再構成する

早い段階で短時間のテストを実施します。説明する前に観察します。次の内容は分けて記録します。

• 何が起きたか。
• プレイヤーが何を信じているように見えたか。
• プレイヤーが後で何を話したか。
• システムに何が記録されたか。
• チームがどのような解釈をしたか。

好みだけでなく、予測や説明を尋ねます。たとえば、「その選択で何が変わると思いますか？」、「次に違う結果を得るには、どうすればよいと思いますか？」と聞きます。

初めてプレイする人と、再びプレイする人を比較します。初めてプレイする人からは習得しやすさがわかり、再びプレイする人からは奥深さ、適応、以前の知識が引き続き役立つかどうかがわかります。

10. 適切なレベルで改訂する

診断した原因に対処する、最小限の変更を選びます。

• パーツレベル：値、上限、状態、または局所的な振る舞い。
• 関係性レベル：割合、条件、遅延、方向、または可視性。
• ループレベル：欠けているブレーキ、弱い報酬、デッドロック、またはつながっていない橋渡し。
• 体験全体レベル：システムが一貫した結果を生み出すものの、意図したゲームとは一致しない。

一度に変更する因果のまとまりは一つにします。仮説、期待する結果、観察した結果、判断を記録します。構造を変更するたびに、以前のエッジトレースを再実行します。

11. 現在のデザインを伝える

1ページの概要、システム仕様、決定ログ、図の表記法、引き継ぎ時の確認事項には、Design Communicationを使用します。

成果物を段階的にまとめます。

1. 認識合わせのための、意図とループをまとめた1ページの概要。
2. デザインレビュー用のシステムマップと状態ルール。
3. 実装用のデータ定義と受け入れ確認項目。
4. 意思決定者向けのテスト結果と未解決のリスク。

ドキュメントは常に最新の状態に保ちます。提案、テスト済みの挙動、リリース済みの挙動を明確に区別します。

診断シグナル

• 機能の一覧にとどまり、システムになっていない： 名詞は列挙されているものの、状態を変化させる関係性がループを形成していません。挙動を追加し、時間経過に伴う変化を追跡します。
• 境界が不明確： 質問が出るたびにモデルが膨らみます。判断と時間軸を改めて定め、外部の詳細は明示的な入力または出力に置き換えます。
• 先行者の暴走： 成功によって、対抗策が発達するより速く、さらなる成功を確保する能力が高まります。コスト、露出、飽和、別ルート、または状況に応じて作用するバランス調整ループを追加します。
• 失敗の連鎖： 敗北によって立ち直る手段が失われます。最低限の行動予算を確保する、リスクのある回復ルートを設ける、または主体性を奪わずに挫折によって戦略が変わるようにします。
• 振動： 修正が目標を繰り返し行き過ぎます。ゲインを下げる、遅延を短縮または可視化する、許容範囲を広げる、または応答を減衰させます。
• 支配的な経路： どの状況でも1つの選択肢が最善です。実質的なトレードオフを設けるか、状況ごとの差を明確にします。複雑さに隠れて優位性が見えなくなるようにはしません。
• コアとメタの断絶： 報酬が後の判断を変えない、または永続的な強化がコア部分を形骸化させます。通貨を増やすのではなく、橋渡し部分を再設計します。
• メンタルモデルの破綻： 似た行動から、説明のつかない異なる結果が生じます。例外をなくす、条件を明示する、またはフィードバックの因果関係を明確にします。
• プレイのないシミュレーション： 内部の動態は健全に見えるものの、プレイヤーに意味のある介入手段がありません。判断の機会と、観察可能な結果を追加します。
• 形だけのプレイテスト： プロトタイプは洗練されているものの、結果によって変わる判断がありません。テスト前に、反証可能な問いを明確にします。
• 古い仕様書： 実装とドキュメントの内容が一致していません。内容を照合し、次の反復に進む前に、どちらを正とするかを明確にします。

必須の成果物

ユーザーがより限定的な成果物を求めていない限り、以下を作成します。

• 体験の目標と明示的な前提。
• 境界、時間尺度、依存関係の一覧。
• パーツ、状態、挙動の一覧。
• 関係性とフィードバックループのマップ。
• コアループ、メタループ、橋渡しの説明。
• プレイヤーのメンタルモデルとフィードバックの計画。
• 1つの不確実性に焦点を当てたプロトタイプまたはプレイテストの計画。
• 診断、失敗リスク、エッジトレース。
• 検証基準と現在の根拠。
• 決定ログまたは次に推奨する実験。

検証

デザインを完成したものとして提示する前に、以下を確認します。

• 重要な状態すべてに、所有者、単位またはカテゴリ、初期条件、上限または下限が定められています。
• 状態変化ごとに、ルール、トリガー、遷移先が定められています。
• 重要なループはすべて、完結するか、境界を意図的に抜けています。
• 強化ループには既知の限界があり、調整ループには目標と許容可能な応答時間があります。
• コアループとメタループは、意図した判断を無効にすることなく、状態を明示的にやり取りします。
• 意思決定に重要な状態について、適時に識別可能なフィードバックが得られます。
• プレイヤーは、限られた体験の後に有用な予測を述べることができます。
• 典型的なケース、エッジケース、復旧ケース、悪用ケースのトレースを少なくとも1つずつ検証しています。
• プロトタイプは、適切な忠実度で、明示された不確実性を検証しています。
• 証拠と推論は区別され、不明点にはその旨が明記されています。
• コミュニケーション用の成果物は、対象者が次の判断を下す、または実装するのに十分な精度を備えています。