『GAME CREATORS CONFERENCE '18』の下記セッションにて「話題のPUBGをモノビットエンジンを使って効率よく開発する手法」として、解説に使用したスライドです。 【タイトル】 超高速ゲームサーバを用いたマルチプレイゲーム開発実例と、MOアクションゲーム実践開発ノウハウ集公開 【内容】 サーバ１CPUあたり2万同時接続可能、秒間54万パケット達成、さらに業界初Linuxサーバ上にC#言語で書かれたゲームロジックを動かすことが出来るモノビットエンジン。Toylogic社がリリースしたスマホおでかけRPG『八百万（やおよろず）クエスト』を実例に、モノビットエンジン＋Unityを用いたマルチプレイサーバ＆クライアントの実装事例や、サーバサイドのカスタマイズ実例をご紹介致します。またセッション後半では、あらゆるオンラインゲームを開発し、「オンラインゲームを支える技術」の著者でもあるCTO中嶋兼互より、話題のPUBGをモノビットエンジンを使って効率よく開発する手法を大公開致します！ 【講演者】 取締役CTO　中嶋　謙互 ミドルウェア事業部　部長　安田　京人

1. PUBGライクなゲームを
Unityだけで早く確実に作る方法
〜ひとつのUnity上でダミークライアントを100個同時に動かす〜
(株)モノビット
取締役CTO 中嶋謙互
2018年3月

2. ゲーム開発の大原則
いつでもプレイできる状態を保って
開発を続けるべし。

3. 「プレイできる状態」とは？
• 100人用ゲームだけど、最初は1人用で作ります。
(だから、マルチプレイはできません)
• 最初からマルチプレイできる状態で作るけど、Unityを何個も立ち上げたり
するのがめんどくさいので、だいたい1人でプレイしてるだけ。
(気付いてない未実装部分がじわじわたまっていく)
• NPCを100体出して、1人プレイでも襲撃されるようにしました。
(でも、ネットワークは一切使ってない。。正直いって後がこわい)

4. 「プレイできる状態」とは？
• 開発の最初から、ゲームサーバーに100クライアントが接続して、対戦し
ている状態を作って実装を続けれるのが理想
• 本番用コードと構造がまったく同じ状態
今日は、実際にこの手順で作る方法を解説し、
それがどれぐらいめんどくさ(くな)いのかを紹介します。

5. 実際に作って説明します
「爆弾バトルロイヤルゲーム」

6. 爆弾バトル サーバー接続前
この立派なカプセルがあなた自身なのです!

7. 爆弾バトル サーバー接続後

8. 爆弾バトル 俯瞰視点

9. 爆弾バトル 複数起動PvP

10. ゲーム内容 : 爆弾をなげるだけ
クリックして爆弾を投げて、敵を吹き飛ばすだけ！
ダメージ判定はあるけど勝敗判定とかはありません
爆弾
爆風

11. ゲーム内容 : 自分以外はすべて敵
自分の爆風:オレンジで表示
自分以外の爆風:青で表示
自分は白カプセル
自分以外は赤カプセル

12. 1 動作確認手順
1.ゲームサーバー(mrs_room)を起動する
2.Unityを起動する
3. 1人目はStart Room Client Ownerボタンを押す
(2人目以降は Join a Room ボタンを押す)
4.Add 1 Dummy Playerボタンを押す
(Add 100 Dummy Playerボタンで100人を一気に追加する)

13. デモ
• 出力した実行形式を使用

14. ネットワーク構成
LocalPlayer
mrs_room
サーバー
Unity (ダミークライアントあり)
RemotePlayer
RemotePlayer
DummyPlayer
・・・
SampleBattleClient
MrsConnection
DummyPlayer
MrsConnection
MrsConnection
・・・
更新
TCP
LocalPlayer
Unity (ダミークライアントなし)
SampleBattleClient
MrsConnection
更新
更新
RemotePlayer
RemotePlayer
・・・
更新
Input
Input
これが
ダミープレイヤー

15. 本番用のコード構成とまったく同じ
LocalPlayer
mrs_room
サーバー
Unity (ダミークライアントあり)
RemotePlayer
RemotePlayer
DummyPlayer
・・・
SampleBattleClient
MrsConnection
DummyPlayer
MrsConnection
MrsConnection
・・・
更新
TCP
LocalPlayer
Unity (ダミークライアントなし)
SampleBattleClient
MrsConnection
更新
更新
RemotePlayer
RemotePlayer
・・・
更新
Input
Input
これが
ダミープレイヤー

16. mrs_roomサーバーの基本コマンド
• CREATE : データリレーの単位となる「部屋」を新規作成
• JOIN : 部屋に参加する
• LEAVE : 部屋から離脱する(ゲーム終了)
• SET_OWNER : 部屋の所有者であることを宣言
• BROADCAST : 部屋にいる全員に送信
• OWNERCAST : 部屋の所有者のみに送信
• MULTICAST : 部屋にいる複数人に送信
• NEARCAST : 部屋にいる「近い人」だけに送信
• UNICAST : 部屋にいる一人のみに送信
UNICASTが重要なのであとでくわしく解説

17. 爆弾バトルゲームの独自コマンド
• PING : 通信の遅延時間を測定
• PING(UInt32 t) tは、Time.timeを1000倍した値
• SYNC_POS : キャラクターの位置を同期する
• SYNC_POS(Int32 x, Int32 z) x,zは位置の座標を1000倍した値
• SHOOT : 爆弾を投げる
• SHOOT(Int32 vx, Int32 vy, Int32 vz ) vx,vy,vzは爆弾の速度を1000倍した値

18. ダミープレイヤーなしの時の動作
• mrs_roomにTCP接続
• CREATE(player_id), SET_OWNER(player_id)を発行
• 1秒に5回、SYNC_POSをNEARCAST
• 爆弾を投げるときは SHOOTをNEARCAST
TCP サーバアドレス サーバポート プレイヤーID
CREATE
JOIN

19. NEARCASTの範囲
範囲外に出たら同期しなくなり、
10秒間同期しなかったら消える

20. DummyPlayerの動作
1.Start()で mrs_roomサーバーにTCP接続
2.座標を-300~300でランダムに初期化
3.プレイヤーID17番のキャラを特別扱いし、17番からのSYNC_POSが来たらそ
の位置を記憶する。
4.17番キャラを追いかけるものと、ランダムにうろうろするものが半数づつ
5.数秒に1回爆弾を投げる
6.NEARCAST(SYNC_POS), NEARCAST(SHOOT)は通常プレイヤーと同じように送る

21. 同期用座標の反映方法
• 移動目標地点を更新するだけ。
• ただし20より離れてたらワープする

22. 100プレイヤー状態で、通信量と遅延を常時測定
バイト数/秒受信レコード数/秒 PING値
NEARCASTを使う場合、
毎秒143レコードで
4214バイト=33Kbps
BROADCASTを使う場合、
毎秒504レコードで
15048バイト=120Kbps
送信モード切り替え
良好
採算性がかなり悪い

23. ゲームサーバーの採算性
• AWSなどでは、CPUは安く、通信費用は高い。
• 1プレイヤー(CCU)あたり、だいたい100Kbpsを越えないよ
うにできると採算性の問題が起きにくい。
• ダミークライアントを使えば、常に100人が接続している
状態で通信量と遅延の程度を見ながら、画面の動きを同
時に確認できる。

24. BROADCASTとNEARCASTの使い分け
• mrs_roomが自動的にBROADCASTするもの
• 部屋の状態変化(退出や途中参加)
• BROADCAST送信が向いているもの
• 高速移動するキャラや、乗り物に乗っているキャラの同期
• 射程が長い武器の動き
• 地形や建造物の破壊や変更、天候変化など
• フィールドに落ちているアイテムの状態変化
• モブの発生や削除
• 時刻の同期
• NEARCAST が向いているもの
• キャラクターやモブの位置変化
• キャラクターやモブの頻繁に発生するタイプのアクション(ジャンプとか)
• エフェクトやサウンド通知

25. CCU=100でのMRSサーバー負荷
• CCU=100 時点でのサーバCPU消費量は計測できない範囲におさまる
。(0.5~1%)
• NEARCASTでもBROADCASTでもCPU負荷に大きな違いはない
• MRSサーバーの性能は マシンあたり2〜3GBps以上、50万パケット以
上 (ネットワークスイッチがまずボトルネックになる)

26. ゲーム内容の作り込み
• たとえば、爆弾バトルに「伏せる」という動きを追加したい場合
• まずLocalPlayerに動きを追加して、操作ができるようにする
• LIE_DOWNというコマンドを追加、動作時にNEARCASTする
• DummyPlayerが数秒に1回LIE_DOWNを送信するようにする
• LIE_DOWNを受信したらRemotePlayerが伏せる反応を追加する
サーバーコードをいじる必要はない。
Unityのみで作業は完結。

27. ダミークライアントの作り込み
• もっと賢くすることはできる
• 影に隠れたり
• ダミクラ同士で襲撃したり
• 経路探索を行う
• etc..
• ただしCPU負荷は増えていく

28. 100人以上について
• モノビットエンジンの性能上は200〜300人でも問題はな
かった。
• Unityの描画・ダミークライアントのロジック負荷がだん
だん上がっていくので、限界はある

29. 結論
• MRSを用いれば、
• PUBGライクな100人バトルロイヤルゲームにおいて
• Unity内部に100個の実際に通信するダミークライアントを
追加して実際に活動させることで
• 本番コードと完全に同じ構成における通信負荷と遅延を
常時監視しながら、開発作業を進行できる。

30. モノビットのミドルウェア製品
• MRS “Monobit Revolution Server”
• UDP/RUDP/TCP/WebSocketに対応した全プラットフォーム向け通信ミドルウェア
• http://www.monobitengine.com/mrs/
• MUN “Monobit Unity Network”
• Unity向けの導入が非常に簡単なMRSベースのミドルウェア
• http://www.monobitengine.com/mun/
• MRSクラスタ
• MRSサーバー群のクラウド・オンプレにおける運用を支援する製品
爆弾バトルはこれを使っています