GM モード
GM モードは、あなたのゲームをあなたの稼働中のサーバーに対してテストするための手段です。
サーバーが権威を持つようになると、オフラインで使っていた小技は通用しなくなります。セーブファイルを編集して レベル 40 のモンスターを自分に渡すことはできません。セーブファイルはもう真実が存在する場所ではなく、 サーバーがそうだからです。ローカルでレベルを設定しても、次のロースター同期で上書きされるか、 さらに悪いことにそうならず、あなたのマシンにしか存在しないバグを追って午後を丸ごと費やすことになります。
これがこの機能が存在する理由のすべてです。サーバーが権威を持つ間にローカルのセーブへ書き込むデバッグツールは、 ツールではありません。幻のバグの発生装置です。そのため、すべての GM の操作は、サーバーが解決し、 サーバーが永続化し、問い合わせたすべてのクライアントから見える、サーバーの RPC になっています。
GM モードは、サーバーを運用する人、つまり開発中のあなた、そしてリリース後にゲームを運営する人のためのものです。 プレイヤー向けの機能ではなく、有効にしたまま出荷するチートメニューでもありません。 ロックダウン を参照してください。
2 つの入り口
同じ 8 つの RPC に、2 か所からアクセスできます。2 つの異なる作業がそれを必要とするためです。
| ゲーム内パネル | Hub の GM タブ | |
|---|---|---|
| 場所 | 実行中のゲーム、F9 | Tools → MCE → OpenMon Hub → GM |
| 用途 | プレイしながらのテスト | ゲームを起動せずに運用する |
| 必要なもの | ログイン済みのオンラインセッション | 独自のメール／パスワードによるログイン |
ゲーム内パネル（F9）
ホットキーは自分自身をインストールします。シーンにドラッグするものは何もなく、それは 意図的です。運用者向けのツールはどのシーンでも動作しなければならず、エンジンを購入した後に作るシーンも含まれます。 手作業で配線したシーンは、次のシーンでは忘れられてしまうからです。
以前はそうではありませんでした。GmModeHotkey は参照がゼロのコンポーネントとして出荷されており、
どのプレハブ、シーン、アセットもその名前を挙げていなかったため、誰もインスタンス化せず、F9 はどのゲームでも
動作しませんでした。読むのではなく操作して見つかりました。稼働中のオンラインセッションで、本物のゲームマスターとして
サインインした状態で F9 を押しても、サーバーに gamemaster_status がまったく送られなかったのです。
これは、稼働中のオンラインワールドの上に、サーバーが認識するアカウントで F9 を押して開いたパネルです。
下の行 -- "10 verbos disponibles" -- は、クライアントが書いたラベルではなく、
gamemaster_status に対するサーバー自身の応答です。そのため、権限のないアカウントでは、
パネルは空のまま開くのではなく、開くのを拒否します。
F9 がデフォルトなのは、MCE がプレイに使う範囲の外にあるためです。移動キー、Z/X、
メニューのバインドにはどれも触れないので、ゲームに必要な入力をパネルが奪うことはありません。
バ インドは GmModeHotkey.cs にあり、単純な Key フィールドなので、移動できます。
パネルは、サーバーがゲームマスターと見なすアカウントにのみ表示されます。仮定せず、
尋ねます。開いたときに gamemaster_status を呼び、その答えは呼び出し元についてのものです。
「あのアカウントは GM か」と尋ねる方法はなく、そのため、この RPC を使って、
サーバーで誰が権限を持っているかを列挙することはできません。
Hub の GM タブ
Hub のタブは、プレイヤーとまったく同じようにメールとパスワードでサインインし、 本物のセッショントークンを受け取ります。これは意図的な選択であり、説明する価値があります。 Hub のほかの部分はこの方式では動作しないからです。
サーバーと通信するほかのすべての Hub パネル -- 特にシーディング -- は、Nakama ランタイムの http_key による
サーバー間通信を行います。このキーにはユーザーが紐づいていません。そして 7 つの操作用の動詞はすべて
ctx.userId を必要とします。どれも、誰がそれを行ったかを名指しする行を書き込むからです。
動詞の http_key 版を追加することもできました。私たちはそれを拒みました。理由は 1 文です 。
監査の行が*「http_key がやった」*と記すことになり、ログは主体を失います。管理者ログに
誰もが尋ねるのは、その主体だけだからです。
http_key はゲームマスターではないこれらは 2 つの異なる意味を持つ 2 つの資格情報です。シーディング用のキーを持っていれば、 サーバー間でストレージに書き込めます。それでゲームマスターになるわけではなく、 GM の動詞が付与されることも決してありません。混同しないでください。どちらも リポジトリに置かないでください。
タブは、4 つの状態を 1 つの失敗にまとめず、区別して示します。「サインインしていない」、 「サインインしたが GM ではない」、「GM だがこのサーバーでは緊急停止がオンになっている」、 「準備完了」は、それぞれ 4 つの異なる場所へあなたを導きます。1 つの「接続できませんでした」では、 実際に必要なのは付与なのに資格情報の確認へ向かわせたり、サーバーを運営している人に話すべきなのに すでに持っている権限をシードしようとさせたりします。
タブは、エディターのセッション間でパスワードを記憶しません。ホスト、ポート、 サーバーキー、メールは保持されますが、パスワードは保持されません。
8 つの動詞
1 つは質問をし、7 つは行動します。
| RPC | 動作 |
|---|---|
gamemaster_status | 自分はゲームマスターか？ここで GM モードは有効か？どの動詞があるか？ |
gamemaster_mint_monster | 指定した種のモンスターを、サーバー上で、サーバーが割り当てた ID で作成する |
gamemaster_set_level | モンスターのレベルを変更する |
gamemaster_set_hp | 現在の HP を設定する -- ひんしの経路に到達するために 0 まで含む |
gamemaster_heal_party | パーティを全回復する |
gamemaster_force_encounter | 次の野生エンカウントを強制す る |
gamemaster_set_dex | 種を見た／捕まえたとしてマークする |
gamemaster_set_variable | ゲーム変数を書き込む |
gamemaster_mint_monster には補足があります。モンスターをサーバー上で作成し、ID はサーバーが割り当てます。
クライアントの経路でモンスターを生成できるものはありません。アップリンクが更新できるのは、プレイヤーがプレイすることで
変わる 7 つのフィールドだけで、それが限界です。モンスターを存在させる必要があるなら、これが唯一の入り口です。
これがコンテンツの再プレイより優れている理由
gamemaster_set_level が存在するのは、進化アニメーションの確認がかつて 126 回のバトル
を必要としたからです。これが置き換えた機能は、テストを回避する近道ではなく、
実行されるテストと実行されないテストの違いそのものでした。
ロックダウン
動詞が実行される前に、3 つの独立した条件がすべて満たされなければなりません。そのうちどれか 1 つでも、 それを止めるのに十分です。
1. ゲームマスターのテーブル。 アカウントは、そのテーブルにある場合にのみ GM です。テーブルは 空で始まり、空とは誰もいないという意味です。「全員」でも「最初のアカウント」でも 「キーを持つ者」でもありません。新しいサーバーには、ゲームマスターがまったくいません。
2. 緊急停止。 環境変数 MCE_GM_MODE_DISABLED=true を設定すると、テーブルに触れずに
すべての動詞がオフになります。本番ノードで使ってください。付与はそのまま残り、何も
呼び出せなくなります。もう一度オフにすれば、もともとあったものが復元されるので、
インシデントの最中にテーブルを記憶から作り直す必要は決してありません。
3. 動詞ごとのゲート。 requireGameMasterVerb は、gamemaster_status を含むすべての呼び出しで実行されます。
拒否された呼び出しも記録されます。
2 つの監査記録（意図的に）
GM の操作はすべて2 つの記録を書き込み、それぞれ 2 種類の異なる読み手のために存在します。
gm_audit は運用者のログです。システム所有で、ゲームマスター、動詞、対象を記録し、
拒否された呼び出しも含め、すべての呼び出しで書き込まれます。拒否は、まさに
管理者ログが存在するための出来事です。
2 つ目 の記録は、対象プレイヤー自身のアカウントの下に置かれ、そのプレイヤーが読めます。 これは省略しやすい半分であり、倫理的に重要な半分です。権限を持つ誰かが自分のデータに触れたことを、 プレイヤーは常に知ることができます。*「触れられたが、何も知らされなかった」*という状態は、 このシステムが表現できないものです。プレイヤーに見える行は、効果そのものと同じストレージ書き込みで 運ばれるため、片方だけが反映される瞬間はありません。
セットアップ
- サーバーを起動します -- セットアップ を参照。
- 運用に使いたいアカウントを作成します（ゲームを一度プレイするか、登録します）。
game_mastersテーブルで、それにゲームマスターを付与します。クライアントにはこれはできません。サーバー間の呼び出しmce_gamemaster_seedが{ "grant": [userId, ...], "revoke": [userId, ...] }を受け取り、ほかのシーディング呼び出しと同様に Nakama ランタイムのhttp_keyが必要です。冪等であり、revokeに挙げられていないアカウントを取り消すことは決してありません。- Hub の GM タブを開き、サインインして、ステータス行に GM であると表示されることを確認します。
- ゲーム内で F9 を押します。
パネルが表示されない場合は、ステータスの呼び出しを読んでください。3 つのゲートのどれが あなたを止めたのかがわかります。
出荷前に
- プレイヤーが到達できるノードでは、本番でライブの GM ツールを意図的に使いたい場合を除き、
MCE_GM_MODE_DISABLED=trueを設定してください。 - ゲームマスターのテーブルは小さく保ち、監査してください。そこにあるすべてのアカウントが、 任意のプレイヤーのデータに書き込めます。
- インシデントの後は
gm_auditを読んでください。まさにその瞬間のために書かれています。