【Unite Tokyo 2019】「禍つヴァールハイト」最大100人同時プレイ！モバイルオンラインゲームの実装テクニック

「禍つヴァールハイト」 最大100人同時プレイ！ モバイルオンラインゲームの実装テクニック KLab株式会社 平井 佑樹 稲田 真吾 西那 康志

自己紹介 平井 佑樹 稲田 真吾 西那 康志 クライアントエンジニア エンジニアリングマネージャ クライアントエンジニア バトル/チューニング担当 通信基盤開発/ダウンローダ クライアント基盤/チュー 開発/運用ツール開発 3 ニング/CI担当

禍つヴァールハイトとは — モバイル向けMMORPG — 最大100人同時プレイ可能 — リアルタイムバトル — 通称：まがつ 4

アジェンダ — 通信基盤の紹介 — リアルタイムバトル実装 — アセットロードの負荷軽減 — アセットダウンロードの高速化 — 開発ツールの紹介 5

通信基盤の紹介 ~100⼈人乗っても⼤大丈夫！~ 6

まがつの通信基盤 — CL/SV型 – クライアント: UnityC# – サーバ: Go — 通信ライブラリ fmof を内製 – TCP RPC通信 – MessagePack TCP RPC Client / UnityC# fmof fmof GameServer / Go

なぜ内製？ — サーバを Go⾔言語 で開発したかった — チューニングを⾃自分達でできるようにしたかった — 技術的チャレンジ! というか開発当初はサードパーティ通信基盤なくて⾃自作⼀一択という状況だった !8

このセクションで話すこと — RPCクライアントの紹介 — RPCとは? — どう実現しているのか — 受信処理理のチューニング — サーバその他の話はしません !9

RPCとは？ Remote Procedure Call - プログラムから別のアドレス空間（通常、共有ネットワーク上の別のコンピュータ 上）にあるサブルーチンや⼿手続きを実⾏行行することを可能にする技術。- wikipedia 今回は [クライアント] C# のメソッド実⾏行行 Go の関数実⾏行行 [サーバ] を実現する技術を指す。 !10

Fmof.RPCClient のお仕事 — ゲームサーバとの通信を担うクラス — ゲーム実装から関数呼び出し → サーバへ送信 — サーバから受信 → ゲーム実装の関数呼び出し — 通信データ圧縮・難読化 ゲーム 実装 Internet (⾃自動⽣生成コード) RPCClient GameServer

送信処理理の例例 ゲーム実装 Rpc.Battle.Attack(enemyId=2, skillId=14) RPCClient 送信Buff Socket

送信処理理の例例 ゲーム実装 Rpc.Battle.Attack(enemyId=2, skillId=14) Serialize RPCClient 送信Buff Func=Attack Enemy=2 Skill=14 Socket

送信処理理の例例 ゲーム実装 Rpc.Battle.Attack(enemyId=2, skillId=14) Serialize RPCClient Write 送信Buff Func=Attack Enemy=2 Skill=14 Socket

受信処理理の例例 ゲーム実装 RPCClient 受信Buff Socket

受信処理理の例例 ゲーム実装 RPCClient Read 受信Buff Func=Attack Player=2 Enemy=2 Skill=14 Socket

受信処理理の例例 ゲーム実装 Rpc.Battle.OnAttack( playerId=2, enemyId=2, skillId=14) Deserialize / Callback RPCClient Read 受信Buff Func=Attack Player=2 Enemy=2 Skill=14 Socket

シリアライザ:MessagePack — MessagePack for C# https://github.com/neuecc/MessagePack-CSharp — Unityに向けてチューニング済 — LZ4圧縮拡張 — MessagePackはGoでも扱いやすい

• https://github.com/neuecc/MessagePack-CSharp

シリアライズの詳細 Rpc.Battle.Attack(enemyId=2, skillId=14) Serialize RpcPacket 固定⻑⾧長ヘッダ(20Bytes) 引数: Array[2, 14] !19

シリアライズの詳細 Rpc.Battle.Attack(enemyId=2, skillId=14) Serialize RpcPacket 固定⻑⾧長ヘッダ(20Bytes) メッセージ⻑⾧長 関数タイプ 関数ID ユーザID シーケンス番号 引数: Array[2, 14] ここは MessagePack トップレベルは引数の配列列 各種オブジェクトも配列列 圧縮や難読化をかける !20

RPCの実現 — サーバ側も似たように実装 — RpcPacket をクライアント-サーバ間で送り合う — RPC通信を実現 TCP RpcPacket Client / UnityC# GameServer / Go RpcPacket !21

受信処理理のチューニング — オンラインゲームの通信の⼤大半は受信 — 受信処理理は何度も実⾏行行される — GC Alloc 発⽣生を極⼒力力抑えたい

受信処理理 ゲーム実装 RPCClient 受信Buff Socket

受信処理理: データ受信 ゲーム実装 RPCClient Read 受信Buff ヘッダ データ1 データ2 Socket

受信処理理: デシリアライズ ゲーム実装 RPCClient 受信Buff new データ1 ヘッダ データ1 データ2 データ2 Read Socket

受信処理理: ゲーム実装に渡す ゲーム実装 Handler(data1, data2) RPCClient 受信Buff new データ1 ヘッダ データ1 データ2 データ2 Read Socket !26

受信処理理: データの所有権がゲーム実装に渡る ゲーム実装 データ1 データ2 Handler(data1, data2) RPCClient 受信Buff new データ1 ヘッダ データ1 データ2 データ2 Read Socket !27

受信処理理: 新鮮なデータが次々⼊入荷 ゲーム実装 データ1 データ1 データ2 データ1 データ2 データ1 データ2 データ2 Handler(data1, data2) RPCClient 受信Buff new データ1 ヘッダ データ1 データ2 データ2 Read Socket !28

受信処理理: 新鮮なデータが次々⼊入荷 ゲーム実装 データ1 データ1 データ2 データ1 データ2 データ1 データ2 データ2 ここで毎回 new したくない Handler(data1, data2) RPCClient 受信Buff new データ1 ヘッダ データ1 データ2 データ2 Read Socket !29

うまく再利利⽤用したい ゲーム実装 確保済のオブジェクトを再利利⽤用したい データ1 データ2 Handler(???, ???) 引数どうしよう？ RPCClient Read 受信Buff ヘッダ データ1 データ2 Socket !30

遅延&上書きデシリアライズ !31

上書きデシリアライズ // bytes を デシリアライズして返却 (毎回 Alloc 発⽣生) var myObj = MessagePackSerializer.Deserialize<MyClass>(bytes); // bytes を myObj に上書きデシリアライズ（これをうまく使いたい） MessagePackSerializer.DeserializeTo<MyClass>(ref myObj, bytes); !32

遅延デシリアライズ
public struct Serialized<T>
{
// Buff は受信バッファの⼀一部を指す
public ArraySegment<byte> Buff;
// Buff の内容を Deserialize で取得
public T Get()
{
return MessagePackSerializer.Deserialize<T>(Buff);
}
// Buff の内容を DeserializeTo で取得
public void Get(ref T dest)
{
MessagePackSerializer.DeserializeTo<T>(ref dest, Buff);
}
}

!33

遅延&上書きデシリアライズ
ゲーム実装

public void Handler(Serialized<MyClass> myData) {
var myObj = myData.Get(); // new してデシリアライズ
myData.Get(ref myObj);

// 上書きデシリアライズ

}

RPCClient

// 受信バッファをSerializedでラップしてゲーム実装に渡す
var myData = new Serialized<MyClass>{Buff = partOfRecvBuff};
Handler(myData);

!34

うまく再利利⽤用したい (再掲) ゲーム実装 確保済のオブジェクトを再利利⽤用したい データ1 データ2 Handler(???, ???) 引数どうしよう？ RPCClient Read 受信Buff ヘッダ データ1 データ2 Socket !35

うまく再利利⽤用できた! ゲーム実装 new or 上書きデシリアライズ データ1 データ2 Serialized<T>でデシリアライズを遅延 Handler(serialized_data1, serialized_data2) RPCClient Read 受信Buff ヘッダ データ1 データ2 Socket !36

通信基盤の紹介まとめ まがつの通信基盤 — 通信ライブラリを内製 — CL/SV型でRPCによる通信 受信処理理のチューニング — 遅延&上書きデシリアライズでオブジェクトを再利利⽤用する設計 !37

リアルタイムバトル実装 〜低スペック端末でもリアルタイム同期〜

リアルタイム協力バトル 39

バトルの要素 攻撃判定 40

バトルの要素 攻撃判定 41

バトルの要素 攻撃判定 ダメージ 42

同期ズレ発生 — パーティで同じバトルに参加しているのに画面が異なる — 低スペック端末のバトルのレスポンスが悪い 43

同期ズレ発生 — パーティで同じバトルに参加しているのに画面が異なる — 低スペック端末のバトルのレスポンスが悪い — パーティプレイが成立しない 44

同期ズレ原因 Queue Attack Attack Attack Attack Attack 低スペック Attack サーバ Queue Attack Attack 45 高スペック

同期ズレ原因 Queue Attack Attack Attack Attack Attack 低スペック Attack サーバ Queue Attack Attack 46 高スペック

原因 — 通知処理に１フレーム以上の時間がかかり処理が重なる – エフェクト、UI演出が重い 47

原因 — 通知処理に１フレーム以上の時間がかかり処理が重なる – エフェクト、UI演出が重い — 端末の性能でFPSが異なる – 高スペック端末 – 30~28FPS – 低スペック端末 – 20~10FPS – 当時の開発段階では 48

改善目標 — 演出で処理負荷が増えても画面同期できるようにする — 低スペック端末でも処理負荷を気にせずプレイできる 49

改善目標 — 演出で処理負荷が増えても画面同期できるようにする — 低スペック端末でも処理負荷を気にせずプレイできる — サーバから送られてくる通知を処理する前に確認する — 不要となる通知は削除する 50

今までのフロー Queue Execution Attack Attack Attack Attack Attack 51

今までのフロー Queue Execution Attack Attack Attack Attack 52 Attack

今までのフロー Queue Execution 53 Attack Attack Attack Attack Attack

やりたいこと Queue Execution Attack Attack Attack Attack 54 Attack

やりたいこと 不不要なものは無視 Queue Execution Attack Attack Attack Attack Attack 必要処理理だけ実⾏行行 55

通知の概要 Notice/~ Time (UnixTime) Value (Struct) 56

通知の概要 通知種類類 Notice/~ Time (UnixTime) Value (Struct) 57

通知の概要 通知種類類 Notice/~ Time (UnixTime) Value (Struct) 58 実⾏行行時刻

通知の概要 通知種類類 Notice/~ Time (UnixTime) 実⾏行行時刻 更更新値 Value (Struct) 59

やりたいこと 不不要なものは無視 Queue Execution Attack Attack Attack Attack Attack 必要処理理だけ実⾏行行 60

やりたいこと 不不要なものは無視 Queue Execution Attack Attack Attack Attack Attack 必要処理理だけ実⾏行行 61

対策 Execution Notice/~ Time (UnixTime) Value (Struct) 62

対策 無視できる？ Execution Notice/~ Time (UnixTime) Value (Struct) 63

対策 Execution 過去？ Notice/~ Time (UnixTime) Value (Struct) 64

対策 Execution Notice/~ Time (UnixTime) Value (Struct) 更更新する？ 65

対策結果 Execution Attack Attack Attack Attack Attack 66

結果 — リリース前の高負荷バトル — iPhone7 — iPhone6s — Pixel2 — Xperia X SOV33 67

リアルタイムバトル実装まとめ — サーバから送られてくる通知は上書き更新で統一 — 重複した通知は最後の通知のみ適用 — 処理負荷が高くても復帰できる仕組み作り 68

アセットロードの負荷軽減 A69

キャラクターのロード A70

課題 — プリロードできない — 操作中のロード負荷 A71

対策1: Priorityによるロード順の制御 — フィールドには最大100人のプレイヤー・NPC・モンスターが存在 — 端末スペックが低いと全てロードし終わるまでに時間かかる — Priorityが高いものからロード – クエストの進行に関わるNPCやモンスターが最優先 – 100人のプレイヤーはカメラから距離が近いプレイヤーを優先 A72

レイヤーによるPriorityの制御 — UIのレイヤーが上に行くほどPriorityが高くなる High A73 Low

割り込みロード キャラクターのロード中の 割り込みロード A74

対策2: 操作中のロード負荷の軽減 操作中は状況によって負荷が変わる ロード処理 1. ファイルロード 2. Instantiate A75

動的に並列ロード数を変更 並列ロード数を4に固定 ↓ FPSに応じて並列ロード数を動的に変更 A76

端末ごとの並列数に差 — iPhone6S 14 並列 — Pixel3a 8 並列 — Xperia Z4 2 並列 [高スペック端末] FPSを維持したままロードが早くなる [低スペック端末] FPSが安定するがロードが遅くなる Priorityの制御でプレイに支障はでない A77

対策3: Instantiateの高速化 — よく使うアセットは事前にロード・Instantiateして 非アクティブにした状態でキャッシュしておく — 2回目以降のInstantiateはClone処理となるため高速化 武器のPrefabのInstantiateの比較 初回のInstantiate Time: 0.52ms 2回目のInstantiate Time: 0.29ms A78

アセットロードの負荷軽減のまとめ — ロード順の制御 — 端末スペック、負荷状況に最適化した並列ロード数 — Instantiateの高速化 A79

アセットダウンロードの⾼高速化 ~ 待ちを減らせば速くなる ~ 80

まがつのアセット事情 アセット総容量量 1.9 GB ファイル数 38987 これをめっちゃ速くダウンロードしたい — 進⾏行行に応じて都度ダウンロード・・ができない！ — ゲームの世界に⼊入る前に全アセットを準備しておく必要あり 81

HTTPによるアセットダウンロード — Unity標準API — WWW — UnityWebRequest HTTPで必要なファイルを1つずつダウンロード これが遅い… 82

遅い理理由 GET — 1 TCPコネクション 1 リクエスト — 1 リクエスト毎に往復復待ち — メインスレッド待ち GET →ファイル数に⽐比例例してDL時間増加 83 GET

ファイル数に⽐比例例 合計 50MB のDL時間⽐比較 on モバイル4G回線 ファイル数 50 1024 4096 50秒 100秒 150秒 200秒 84 250秒

ちょっと⾒見見積もってみよう RTT 50ms の回線を仮定 1ファイルあたり1往復復するとして往復復待ち時間は.. — 50ms × 1000 ファイル = 50秒 85

ちょっと⾒見見積もってみよう RTT 50ms の回線を仮定 1ファイルあたり1往復復するとして往復復待ち時間は.. — 50ms × 1000 ファイル = 50秒 — 50ms × 10000 ファイル = 8.3分 86

ちょっと⾒見見積もってみよう RTT 50ms の回線を仮定 1ファイルあたり1往復復するとして往復復待ち時間は.. — 50ms × 1000 ファイル = 50秒 — 50ms × 10000 ファイル = 8.3分 — 50ms × 38987 ファイル = 32.5分 !? 87

待ちを減らせば 速くなる？ 88

速くする⽅方法 — メインスレッドを使わない – コネクション数増やす — まとめてDLして受信後に展開 89

メインスレッド待ちの回避 (採⽤用) — WWW / UnityWebRequest はメインスレッド待ちが必要 — 平均待ち時間は 30fps で 16ms — 16ms × 38987ファイル = 10.4分 — 全然無視できない →メインスレッド⾮非依存のHTTPライブラリを使⽤用 — iOS: NSURLSession — Android: OkHttp 90

コネクション数を増やす (採⽤用) — 並列列数を増やして往復復待ち時間を分散 — 並列列数だけサブスレッドでダウンロード処理理 — コネクションそこまで増やしたくない — スレッド数もそんなに増やせない → 6並列列を採⽤用 91

並列列化の効果 合計 50MB のDL時間⽐比較 on モバイル4G回線 ファイル数 直列列 50 6並列列 1024 4096 50秒 100秒 150秒 →かなり改善 でもまだファイル数に⽐比例例 200秒 92 250秒

まとめてDLして受信後に展開 (採⽤用) GET Range アイデア：まとめてRangeリクエスト 1. アセットを連結したファイルを⽤用意 2. 欲しいファイルをまとめてRangeリクエスト 3. レスポンスを適当に分割保存 GET Range → 往復復待ちが減って⾼高速化! 93

Range Requests (rfc7233) ファイルの⼀一部分を取得するHTTPの機能 リクエスト Range: bytes=xxx,yyy レスポンス 206 Partial Content xxx バイトから yyy バイトの内容が返る ※200とファイル全体を返しても良い事になっている点に注意 94

ファイル数に⽐比例例しなくなる 合計50MBのDL時間⽐比較 on モバイル4G回線 ファイル数 6並列列 50 Rangeリクエスト 1024 4096 10秒 20秒 30秒 40秒 95 50秒

実装 下準備 GET Range 1. アセットをtarで連結して配置 2. tarから情報を抽出して配置 (アセットリスト) – tar名、アセット名、開始位置、サイズ、ハッシュ値 ダウンロード時 GET Range 1. アセットリストをダウンロード 2. 未所持のアセットを列列挙 3. リクエスト範囲を決定 4. レスポンスの分割保存 96

アセット更更新時の対応 — 更更新ファイルだけのtarを配置 — アセットリストを差分更更新 更更新の無いファイル → 古いtar 更更新のあったファイル → 新しいtar いい感じに別Rangeでダウンロードされる パッケージ管理理が簡単！ 97

リクエスト範囲の決定⽅方法 満たしたい要件 — 無駄にダウンロードしたくない — 1Rangeをあまり⼤大きくしたくない – 途中から再開を実装したくないので… ⼀一度⼤大きなRangeにまとめた後、以下を満たすまで分割 — 欲しい２つのファイルの間の不不要なバイト数 < 1MB — 1Rangeのサイズ < 6MB 98

結果 — アセット総容量量 1.9 GB ↓ 1分12秒 iPhoneXs Wifi 下り: 491.1Mbps — ファイル数 38987 — 30Mbps 10分 — 1Gbps 1分 環境によってはファイル操作がボトルネックになる 99

待ちを減らせば 速くなる！ 100

開発ツールの紹介 A101

通信データを監視したい — 秒間10以上のデータを送受信 — デバッグログでの監視は辛い UnityEditorでリアルタイムに監視できるツール A102

ツールの構成 — アプリとゲームサーバーが通信したデータを 都度UnityEditorに転送 ゲームサーバー — 通信内容をリアルタイム監視 UnityEditor アプリ ② A103 ①

通信データ監視ツール A104

ツールの基盤部分の説明 UnityEditorと実機アプリをUSBを介してTCP接続し相互通信 TCPクライアント TCPサーバー 高速・安定 A105

USB接続について Androidはadbコマンド、 iOSはiproxyコマンドを使用して ローカルポートをUSBトンネリングして接続 adb -s [Android serial_number] forward tcp:[local port] tcp:[server port] iproxy [local port] [server port] [ios UDID] A106

Unity標準APIでUSB接続 Unityの標準APIでも実機とUnityEditorの通信ができる — UnityEngine.Networking.PlayerConnection.PlayerConnection — UnityEditor.Networking.PlayerConnection.EditorConnection A107

Luaの使用 — アプリにLuaエンジンを組み込み — LuaスクリプトをUnityEditorからアプリに送信＆実行 — sluaを利用 – LuaからUnityAPIを簡単に呼び出すようにできるライブラリ – github.com/pangweiwei/slua A108

UnityEditorからLuaソースコードの送信処理
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

if (GUILayout.Button("非アクティブにする"))
{
// Luaスクリプト
var luaScript = @"
function main()
-- 特定のGameObjectを非アクティブにする
local obj = UnityEngine.GameObject.Find('Player')
obj:SetActive(false)
end";
// UnityEditorから実機にLuaスクリプトを送信
Client.SendLuaScript(
luaScript,
result => {}
);

A109

}

UnityEditorからLuaソースコードの送信処理
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

if (GUILayout.Button("非アクティブにする"))
{
// Luaスクリプト
var luaScript = @"
function main()
-- 特定のGameObjectを非アクティブにする
local obj = UnityEngine.GameObject.Find('Player')
obj:SetActive(false)
end";
// UnityEditorから実機にLuaスクリプトを送信
Client.SendLuaScript(
luaScript,
result => {}
);

A110

}

UnityEditorからLuaソースコードの送信処理
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

if (GUILayout.Button("非アクティブにする"))
{
// Luaスクリプト
var luaScript = @"
function main()
-- 特定のGameObjectを非アクティブにする
local obj = UnityEngine.GameObject.Find('Player')
obj:SetActive(false)
end";
// UnityEditorから実機にLuaスクリプトを送信
Client.SendLuaScript(
luaScript,
result => {}
);

A111

}

応用編 — UnityEditorと実機の相互通信 — Luaを使ったアプリの動的更新 A112

Unityのモバイル開発を 快適にするツール A113

実機で使えるHierarchy・Inspector A114

Hierarchy Hierarchy情報送信 A115

Inspector Luaで更新 A116

File Explorer A117

File Explorer A118

File Explorer A119

Inspectorでファイルの詳細情報を表示 A120

アセットバンドル転送ツール A121

アセットの実機確認に時間がかかる — アセットバンドルビルドに20〜30分以上かかる – Jenkinsで全アセットを対象にビルド — サーバーから実機にダウンロード A122

アセットバンドル転送ツール アセットバンドルビルド＆ファイル送信が10〜30秒 1. UnityEditorでアセットを右クリックで実行 2. ローカルマシンでアセットバンドルビルド 3. USB経由で実機にファイル送信 4. アプリ側のアセット依存情報等をLuaで更新 A123

開発ツールのまとめ — UnityEditorと実機の相互通信 — Luaを使ったアプリの動的更新 この2つがあれば、よりモバイル開発を快適にする事ができる A124

全体のまとめ — 通信基盤の紹介 — リアルタイムバトル実装 — アセットロードの負荷軽減 — アセットダウンロードの高速化 — 開発ツールの紹介 125

禍つヴァールハイト App Store, Google Playで「まがつ」で検索 ご興味があるかたは是非プレイしてみて下さい。 126

ご清聴ありがとうございました 127