Research
通信リサーチ
オンラインゲームの通信とクライアント実装を調べ、権威の置き方（どこが正とされるか）を整理する。対象タイトルの調査記録と、作品をまたいで見える設計パターンのメモ。
01 / Method
調査の進め方
パケットの羅列ではなく、「この値は誰が正か」を追う。再現可能な仮説だけを隔離環境で検証する。
手順
- –キャプチャ → 操作との相関 → 状態遷移図の作成
- –ローカル表示値と通信で確定した値の差分を記録
- –権威の所在を分類（クライアント / サーバー / 予測＋訂正）
- –最小の再現環境で仮説を試し、パターンとして整理する
倫理・環境
- –隔離環境のみ。実サービスへの干渉・妨害はしない
- –調査対象の詳細・生データは公開しない
- –再現は検証用途に限定し、攻撃手順は公開しない
- –攻撃手順の公開ではなく、設計パターンの学習が目的
02 / Protocol
通信解析
認証から戦闘・報酬まで、メッセージの順序依存と「送ってよい情報」の粒度を読み解く。
見ているもの
- –セッションの寿命 — ログイン、入場、再接続でトークンがどう変わるか
- –メッセージの意味 — 意図（対象 ID）か結果（ダメージ値）か
- –順序依存 — 先に消費すべきリソース、単発で失効する入場権
- –冪等性 — 再送・二重送信で状態が壊れるか
- –ローカルキャッシュとサーバー確定値の同期タイミング
よく見るパターン
- –意図だけ送る — 攻撃は対象 ID のみ、ダメージはサーバー算出
- –結果を送る — クライアント計算値をそのまま受理（検証次第で危うい）
- –予測＋訂正 — 移動は先に反映、サーバーが後から位置を戻す
- –イベント駆動 — 報酬・ドロップはサーバー通知が正、UI は追従
03 / Trust Boundary
クライアント側の権威
ローカルで何が計算され、改ざんや不整合がゲーム結果に届くか。表示用の値と確定値の境界を切り分ける。
ローカルに残りやすいもの
- –UI 用のステータス・クールタイム表示
- –移動・攻撃の予測再生（サーバー訂正前）
- –セーブデータ上の所持数・装備（同期遅延のキャッシュ）
- –演出・アニメーション用の一時状態
危うくなりやすい条件
- –ローカル判定だけで結果が確定する処理
- –サーバー検証前にインベントリへ反映する UI
- –クライアント送信値をそのまま信じる API
- –再接続時にローカル状態を優先する復元
差分分析で分かること
- –操作前後のセーブとメモリ — 何が即時変わり、何が通信後に変わるか
- –表示と実値のズレ — チートツールの有無より、設計上の隙間の指標になる
- –ローカルだけ変わる値 — サーバー再計算の候補としてマークする
04 / Patterns
設計パターンの整理
複数作品を通して繰り返し見える構成。個別タイトルの実装詳細ではなく、一般化したメモ。
サーバー構成
- –認証・マッチング層とフィールド層の分離（Gateway / World 型）
- –入場トークンは短命・単発消費が多い
- –ソーシャル調整とシーン進行は別チャンネルに載ることがある
権威の置き方
- –クライアントは意図のみ送り、結果はサーバーが確定
- –コンテナ同期 — 入場時にまとめて、以降は差分
- –Attr リスト — キャラごとに同じ形で状態を表す
クライアント実装
- –C#（エンジン）と Lua（UI・ソーシャル）の二層構成が大規模 MMO で多い
- –RPC は method ごとに C# / Lua に振り分けられる
- –スクリプト層はホットアップデートとコンテンツ量の多さに向く
調査の生データ・対象タイトルの特定情報は公開しない。ここに書いているのは、複数作品を通して見えた設計パターンの一般化のみ。