ブループロトコル：スターレゾナンス

パーティとマップ入場の経路

• パーティ操作は Gateway 側のキャラクター用サービス（Lua）で処理される
• パーティ状態は CharSerialize の team_info として World から同期される
• 初回入場 — Gateway が接続先を通知 → World で入場確定
• フィールド内の移動 — World が NotifySwitchScene でシーン切替を指示
• ダンジョン入場 — パーティ投票（活動開始・参加返答）のあと World でシーン切替

なぜ分けるか

• ソーシャル調整とフィールド処理を別サーバーに分けられる
• World の接続先を変えても、Gateway との関係は保てる
• フィールド側はゲーム進行に集中できる

C# と Lua は、クライアント内で役割分担している

Lua が「何をするか」を決め、重い処理やサーバー通信の受け口は C# が担う。UI やソーシャルは差し替えやすく、エンジンは安定したまま更新できる。

Lua を使うメリット

• ホットアップデート — UI やクエストのロジックをアプリ全体の再ビルドなしで差し替えやすい
• 開発速度 — 画面遷移や条件分岐を C# より素早く書ける。コンテンツ量の多い MMO 向き
• 役割分担 — C# はエンジン（描画・同期）、Lua はゲーム体験（UI・ソーシャル）に集中できる
• 変更に強い — パーティやイベントなど頻繁に触る機能をスクリプト側に寄せられる
• 業界でよくある構成 — 大規模オンラインゲームのクライアントで採用例が多い

RPC の振り分け（ForCs / ForLua）

• 各 Proxy は method ID ごとに C# か Lua かを分ける
• 移動・戦闘・シーン切替の多くは C#（WorldProxy）
• パーティ・ログイン周りは Lua（Gateway の Char サービス）
• Lua 側の受け口を ZLuaProxy と呼ぶ（調査上の呼び名）

パーティ作成の流れ（Lua 視点）

• ① プレイヤーがパーティ画面で「作成」を押す（Lua UI）
• ② Lua が Gateway の Char サービスへ ReqCreateTeam を送る
• ③ サーバーが CharTeam を生成し、Return で成功／失敗を返す
• ④ World から CharSerialize（team_info）が同期される
• ⑤ ContainerDataChanged で Lua UI が更新、AttrTeamId でフィールド表示も変わる

イメージ

• 自分・他プレイヤー・敵 — それぞれが別々の Attr リストを持つ
• リストの形（行の種類）は共通。中身の値だけキャラごとに違う
• 1 行が「何の情報か」と「値」のペアになっている

1 つのステータスも、リストの中の複数行で表す

例：攻撃力（同じ並びが HP などにも使われる）

ざっくり言うと

• もとになる値（ベース）がある
• 装備やバフで「足す」「割合で増やす」が別々に記録される
• それらを合わせた最終値が画面に出る
• HP も攻撃力も会心も、同じ考え方でそろえてある

サーバーは、キャラごとのリストを更新する

入場時はリストまるごと。プレイ中は変わった行だけ。