【Unite Tokyo 2019】「禍つヴァールハイト」最大100人同時プレイ！モバイルオンラインゲームの実装テクニック
•
1 gefällt mir•3,371 views
2019/9/25-6に開催されたUnite Tokyo 2019の講演スライドです。 平井 佑樹（KLab株式会社） 稲田 真吾（KLab株式会社） 西那 康志（KLab株式会社） こんな人におすすめ ・スマホの常時接続型のゲームを開発に関わるプログラマー ・頻繁に通信のやり取りを行うゲームの開発に関わるプログラマー ・アセットのダウンロード時間を短縮したいと思っているプログラマー 受講者が得られる知見 ・常時接続型スマホゲームのクライアント設計の理解 ・常時接続を利用したクライアント最適化技術 ・通信型のモバイルゲームの開発技法 Unityのイベント資料はこちらから： https://www.slideshare.net/UnityTechnologiesJapan/clipboards
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie 【Unite Tokyo 2019】「禍つヴァールハイト」最大100人同時プレイ！モバイルオンラインゲームの実装テクニック
Ähnlich wie 【Unite Tokyo 2019】「禍つヴァールハイト」最大100人同時プレイ！モバイルオンラインゲームの実装テクニック (20)
Mehr von UnityTechnologiesJapan002
Mehr von UnityTechnologiesJapan002 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (8)
【Unite Tokyo 2019】「禍つヴァールハイト」最大100人同時プレイ！モバイルオンラインゲームの実装テクニック
- 3. 西那 康志 クライアントエンジニア クライアント基盤/チュー ニング/CI担当 稲田 真吾 エンジニアリングマネージャ 通信基盤開発/ダウンローダ 開発/運用ツール開発 平井 佑樹 クライアントエンジニア バトル/チューニング担当 自己紹介 3
- 4. 禍つヴァールハイトとは 4 — モバイル向けMMORPG — 最大100人同時プレイ可能 — リアルタイムバトル — 通称：まがつ
- 5. アジェンダ 5 — 通信基盤の紹介 — リアルタイムバトル実装 — アセットロードの負荷軽減 — アセットダウンロードの高速化 — 開発ツールの紹介
- 7. まがつの通信基盤 — CL/SV型 – クライアント: UnityC# – サーバ: Go — 通信ライブラリ fmof を内製 – TCP RPC通信 – MessagePack Client / UnityC# GameServer / Go TCP RPC fmof fmof
- 8. なぜ内製？ — サーバを Go⾔言語 で開発したかった — チューニングを⾃自分達でできるようにしたかった — 技術的チャレンジ! というか開発当初はサードパーティ通信基盤なくて⾃自作⼀一択という状況だった !8
- 9. このセクションで話すこと — RPCクライアントの紹介 — RPCとは? — どう実現しているのか — 受信処理理のチューニング — サーバその他の話はしません !9
- 10. RPCとは？ Remote Procedure Call - プログラムから別のアドレス空間（通常、共有ネットワーク上の別のコンピュータ 上）にあるサブルーチンや⼿手続きを実⾏行行することを可能にする技術。- wikipedia 今回は [クライアント] C# のメソッド実⾏行行 Go の関数実⾏行行 [サーバ] を実現する技術を指す。 !10
- 11. Fmof.RPCClient のお仕事 — ゲームサーバとの通信を担うクラス — ゲーム実装から関数呼び出し → サーバへ送信 — サーバから受信 → ゲーム実装の関数呼び出し — 通信データ圧縮・難読化 ゲーム 実装 RPCClient GameServer Internet(⾃自動⽣生成コード)
- 13. 送信処理理の例例 ゲーム実装 RPCClient Rpc.Battle.Attack(enemyId=2, skillId=14) Func=Attack Enemy=2 Skill=14 Socket Serialize 送信Buff
- 14. 送信処理理の例例 ゲーム実装 RPCClient Rpc.Battle.Attack(enemyId=2, skillId=14) Func=Attack Enemy=2 Skill=14 Socket Serialize 送信Buff Write
- 16. 受信処理理の例例 Socket ゲーム実装 RPCClient Read 受信Buff Func=Attack Player=2 Enemy=2 Skill=14
- 17. 受信処理理の例例 Socket ゲーム実装 RPCClient Rpc.Battle.OnAttack( playerId=2, enemyId=2, skillId=14) Read 受信Buff Func=Attack Player=2 Enemy=2 Skill=14 Deserialize / Callback
- 18. シリアライザ:MessagePack — MessagePack for C# https://github.com/neuecc/MessagePack-CSharp — Unityに向けてチューニング済 — LZ4圧縮拡張 — MessagePackはGoでも扱いやすい
- 19. シリアライズの詳細 !19 固定⻑⾧長ヘッダ(20Bytes) 引数: Array[2, 14] Rpc.Battle.Attack(enemyId=2, skillId=14) RpcPacket Serialize
- 20. シリアライズの詳細 !20 固定⻑⾧長ヘッダ(20Bytes) 引数: Array[2, 14] Rpc.Battle.Attack(enemyId=2, skillId=14) RpcPacket Serialize メッセージ⻑⾧長 関数タイプ 関数ID ユーザID シーケンス番号 ここは MessagePack トップレベルは引数の配列列 各種オブジェクトも配列列 圧縮や難読化をかける
- 21. RPCの実現 — サーバ側も似たように実装 — RpcPacket をクライアント-サーバ間で送り合う — RPC通信を実現 !21 Client / UnityC# GameServer / Go TCP RpcPacket RpcPacket
- 22. 受信処理理のチューニング — オンラインゲームの通信の⼤大半は受信 — 受信処理理は何度も実⾏行行される — GC Alloc 発⽣生を極⼒力力抑えたい
- 24. 受信処理理: データ受信 ゲーム実装 RPCClient ヘッダ データ1 データ2受信Buff Read Socket
- 25. 受信処理理: デシリアライズ Socket ゲーム実装 RPCClient ヘッダ データ1 データ2 データ1 データ2new 受信Buff Read
- 26. 受信処理理: ゲーム実装に渡す ゲーム実装 RPCClient ヘッダ データ1 データ2 Handler(data1, data2) データ1 データ2new 受信Buff Read Socket !26
- 27. 受信処理理: データの所有権がゲーム実装に渡る ゲーム実装 RPCClient ヘッダ データ1 データ2 Handler(data1, data2) データ1 データ2 受信Buff Read Socket データ1 データ2new !27
- 28. 受信処理理: 新鮮なデータが次々⼊入荷 ゲーム実装 RPCClient ヘッダ データ1 データ2 Handler(data1, data2) データ1 データ2 受信Buff Read Socket データ1 データ2new データ1 データ2 データ1 データ2 データ1 データ2 !28
- 29. 受信処理理: 新鮮なデータが次々⼊入荷 ゲーム実装 RPCClient ヘッダ データ1 データ2 Handler(data1, data2) データ1 データ2 受信Buff Read Socket データ1 データ2new ここで毎回 new したくない データ1 データ2 データ1 データ2 データ1 データ2 !29
- 30. うまく再利利⽤用したい ゲーム実装 RPCClient ヘッダ データ1 データ2 Handler(???, ???) データ1 データ2 受信Buff Read Socket 確保済のオブジェクトを再利利⽤用したい 引数どうしよう？ !30
- 32. 上書きデシリアライズ !32 // bytes を デシリアライズして返却 (毎回 Alloc 発⽣生) var myObj = MessagePackSerializer.Deserialize<MyClass>(bytes); // bytes を myObj に上書きデシリアライズ（これをうまく使いたい） MessagePackSerializer.DeserializeTo<MyClass>(ref myObj, bytes);
- 33. 遅延デシリアライズ 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
- 34. 遅延&上書きデシリアライズ 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
- 35. うまく再利利⽤用したい (再掲) ゲーム実装 RPCClient ヘッダ データ1 データ2 Handler(???, ???) データ1 データ2 受信Buff Read Socket 確保済のオブジェクトを再利利⽤用したい 引数どうしよう？ !35
- 36. うまく再利利⽤用できた! ゲーム実装 RPCClient ヘッダ データ1 データ2 Handler(serialized_data1, serialized_data2) データ1 データ2 受信Buff Read Socket new or 上書きデシリアライズ Serialized<T>でデシリアライズを遅延 !36
- 37. まがつの通信基盤 — 通信ライブラリを内製 — CL/SV型でRPCによる通信 受信処理理のチューニング — 遅延&上書きデシリアライズでオブジェクトを再利利⽤用する設計 通信基盤の紹介まとめ !37
- 39. リアルタイム協力バトル 39
- 40. バトルの要素 40 攻撃判定
- 41. バトルの要素 41 攻撃判定
- 44. 同期ズレ発生 44 — パーティで同じバトルに参加しているのに画面が異なる — 低スペック端末のバトルのレスポンスが悪い — パーティプレイが成立しない
- 48. 原因 48 — 通知処理に１フレーム以上の時間がかかり処理が重なる – エフェクト、UI演出が重い — 端末の性能でFPSが異なる – 高スペック端末 – 30~28FPS – 低スペック端末 – 20~10FPS – 当時の開発段階では
- 50. 改善目標 50 — 演出で処理負荷が増えても画面同期できるようにする — 低スペック端末でも処理負荷を気にせずプレイできる — サーバから送られてくる通知を処理する前に確認する — 不要となる通知は削除する
- 67. 結果 67 — リリース前の高負荷バトル — iPhone7 — iPhone6s — Pixel2 — Xperia X SOV33
- 68. リアルタイムバトル実装まとめ 68 — サーバから送られてくる通知は上書き更新で統一 — 重複した通知は最後の通知のみ適用 — 処理負荷が高くても復帰できる仕組み作り
- 69. A69 アセットロードの負荷軽減
- 70. キャラクターのロード A70
- 72. 対策1: Priorityによるロード順の制御 A72 — フィールドには最大100人のプレイヤー・NPC・モンスターが存在 — 端末スペックが低いと全てロードし終わるまでに時間かかる — Priorityが高いものからロード – クエストの進行に関わるNPCやモンスターが最優先 – 100人のプレイヤーはカメラから距離が近いプレイヤーを優先
- 75. 対策2: 操作中のロード負荷の軽減 A75 操作中は状況によって負荷が変わる ロード処理 1. ファイルロード 2. Instantiate
- 77. 端末ごとの並列数に差 A77 — iPhone6S 14 並列 — Pixel3a 8 並列 — Xperia Z4 2 並列 [高スペック端末] FPSを維持したままロードが早くなる [低スペック端末] FPSが安定するがロードが遅くなる Priorityの制御でプレイに支障はでない
- 78. 対策3: Instantiateの高速化 A78 — よく使うアセットは事前にロード・Instantiateして 非アクティブにした状態でキャッシュしておく — 2回目以降のInstantiateはClone処理となるため高速化 初回のInstantiate Time: 0.52ms 2回目のInstantiate Time: 0.29ms 武器のPrefabのInstantiateの比較
- 79. アセットロードの負荷軽減のまとめ A79 — ロード順の制御 — 端末スペック、負荷状況に最適化した並列ロード数 — Instantiateの高速化
- 81. アセット総容量量 1.9 GB ファイル数 38987 これをめっちゃ速くダウンロードしたい — 進⾏行行に応じて都度ダウンロード・・ができない！ — ゲームの世界に⼊入る前に全アセットを準備しておく必要あり まがつのアセット事情 81
- 82. — Unity標準API — WWW — UnityWebRequest HTTPで必要なファイルを1つずつダウンロード これが遅い… HTTPによるアセットダウンロード 82
- 83. — 1 TCPコネクション 1 リクエスト — 1 リクエスト毎に往復復待ち — メインスレッド待ち →ファイル数に⽐比例例してDL時間増加 遅い理理由 83 GET GET GET
- 84. 合計 50MB のDL時間⽐比較 on モバイル4G回線 ファイル数に⽐比例例 84 50 1024 4096 ファイル数 250秒100秒 200秒50秒 150秒
- 85. RTT 50ms の回線を仮定 1ファイルあたり1往復復するとして往復復待ち時間は.. — 50ms × 1000 ファイル = 50秒 ちょっと⾒見見積もってみよう 85
- 86. RTT 50ms の回線を仮定 1ファイルあたり1往復復するとして往復復待ち時間は.. — 50ms × 1000 ファイル = 50秒 — 50ms × 10000 ファイル = 8.3分 ちょっと⾒見見積もってみよう 86
- 87. RTT 50ms の回線を仮定 1ファイルあたり1往復復するとして往復復待ち時間は.. — 50ms × 1000 ファイル = 50秒 — 50ms × 10000 ファイル = 8.3分 — 50ms × 38987 ファイル = 32.5分 !? ちょっと⾒見見積もってみよう 87
- 88. 待ちを減らせば 速くなる？ 88
- 89. — メインスレッドを使わない – コネクション数増やす — まとめてDLして受信後に展開 速くする⽅方法 89
- 90. — WWW / UnityWebRequest はメインスレッド待ちが必要 — 平均待ち時間は 30fps で 16ms — 16ms × 38987ファイル = 10.4分 — 全然無視できない →メインスレッド⾮非依存のHTTPライブラリを使⽤用 — iOS: NSURLSession — Android: OkHttp メインスレッド待ちの回避 (採⽤用) 90
- 91. — 並列列数を増やして往復復待ち時間を分散 — 並列列数だけサブスレッドでダウンロード処理理 — コネクションそこまで増やしたくない — スレッド数もそんなに増やせない → 6並列列を採⽤用 コネクション数を増やす (採⽤用) 91
- 92. 合計 50MB のDL時間⽐比較 on モバイル4G回線 →かなり改善 でもまだファイル数に⽐比例例 並列列化の効果 92 直列列 6並列列 50 1024 4096 ファイル数 250秒100秒 200秒50秒 150秒
- 93. まとめてDLして受信後に展開 (採⽤用) アイデア：まとめてRangeリクエスト 1. アセットを連結したファイルを⽤用意 2. 欲しいファイルをまとめてRangeリクエスト 3. レスポンスを適当に分割保存 → 往復復待ちが減って⾼高速化! GET Range GET Range 93
- 94. ファイルの⼀一部分を取得するHTTPの機能 リクエスト Range: bytes=xxx,yyy レスポンス 206 Partial Content xxx バイトから yyy バイトの内容が返る ※200とファイル全体を返しても良い事になっている点に注意 Range Requests (rfc7233) 94
- 95. 合計50MBのDL時間⽐比較 on モバイル4G回線 ファイル数に⽐比例例しなくなる 95 6並列列 Rangeリクエスト 50 1024 4096 ファイル数 20秒 40秒10秒 30秒 50秒
- 96. 下準備 1. アセットをtarで連結して配置 2. tarから情報を抽出して配置 (アセットリスト) – tar名、アセット名、開始位置、サイズ、ハッシュ値 ダウンロード時 1. アセットリストをダウンロード 2. 未所持のアセットを列列挙 3. リクエスト範囲を決定 4. レスポンスの分割保存 実装 96 GET Range GET Range
- 97. — 更更新ファイルだけのtarを配置 — アセットリストを差分更更新 更更新の無いファイル → 古いtar 更更新のあったファイル → 新しいtar いい感じに別Rangeでダウンロードされる パッケージ管理理が簡単！ アセット更更新時の対応 97
- 98. 満たしたい要件 — 無駄にダウンロードしたくない — 1Rangeをあまり⼤大きくしたくない – 途中から再開を実装したくないので… ⼀一度⼤大きなRangeにまとめた後、以下を満たすまで分割 — 欲しい２つのファイルの間の不不要なバイト数 < 1MB — 1Rangeのサイズ < 6MB リクエスト範囲の決定⽅方法 98
- 99. — アセット総容量量 1.9 GB — ファイル数 38987 — 30Mbps 10分 — 1Gbps 1 分 環境によってはファイル操作がボトルネックになる 結果 99 ↓ 1分12秒 iPhoneXs Wifi 下り: 491.1Mbps
- 100. 待ちを減らせば 速くなる！ 100
- 101. A101 開発ツールの紹介
- 103. ツールの構成 A103 — アプリとゲームサーバーが通信したデータを 都度UnityEditorに転送 — 通信内容をリアルタイム監視 UnityEditor アプリ ゲームサーバー ① ②
- 104. 通信データ監視ツール A104
- 106. USB接続について A106 Androidはadbコマンド、 iOSはiproxyコマンドを使用して ローカルポートをUSBトンネリングして接続 adb -s [Android serial_number] forward tcp:[local port] tcp:[server port] iproxy [local port] [server port] [ios UDID]
- 108. Luaの使用 A108 — アプリにLuaエンジンを組み込み — LuaスクリプトをUnityEditorからアプリに送信＆実行 — sluaを利用 – LuaからUnityAPIを簡単に呼び出すようにできるライブラリ – github.com/pangweiwei/slua
- 109. 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
- 110. 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
- 111. 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
- 117. File Explorer A117
- 118. File Explorer A118
- 119. File Explorer A119
- 121. アセットバンドル転送ツール A121
- 122. アセットの実機確認に時間がかかる A122 — アセットバンドルビルドに20〜30分以上かかる – Jenkinsで全アセットを対象にビルド — サーバーから実機にダウンロード
- 123. アセットバンドル転送ツール A123 アセットバンドルビルド＆ファイル送信が10〜30秒 1. UnityEditorでアセットを右クリックで実行 2. ローカルマシンでアセットバンドルビルド 3. USB経由で実機にファイル送信 4. アプリ側のアセット依存情報等をLuaで更新
- 125. 全体のまとめ 125 — 通信基盤の紹介 — リアルタイムバトル実装 — アセットロードの負荷軽減 — アセットダウンロードの高速化 — 開発ツールの紹介
- 126. 禍つヴァールハイト 126 App Store, Google Playで「まがつ」で検索 ご興味があるかたは是非プレイしてみて下さい。
- 127. ご清聴ありがとうございました 127