八百万クエストにおける
MUN採用事例
MUN使用環境における課題と対策
株式会社モノビット
ミドルウェア事業部部長 ／ 安田京人
1

自己紹介
安田 京人
株式会社モノビット
1980年横浜生まれ。
システムエンジニアを経て、コンシューマゲーム開発に6年間従
事。メインプログラマとして、携帯ゲーム機から据え置き機まで
様々なタイトル開発に関わる。その後、ネットワークゲーム時代
の到来を予見し、その分野で展開を試みる株式会社モノビットへ
入社。現在はミドルウェア事業部長として、リアルタイム通信の
研究開発に従事し統合サーバパッケージ「モノビットエンジン」
の開発ディレクションとエヴァンジェリストとしても活動。
2

モノビットエンジンVer2.0シリーズ
3
スマホ/家庭用ゲームやVRコンテンツで、マルチプレイを簡単に実現できる、リアルタイム通信ミドルウェアです。
主に３つの製品ラインナップで展開しています。2017年にVer2.0に進化しました！
１，Monobit Revolution Server （略称：MRS）
MMORPGや、多人数MOアクションゲームにも対応出来
る処理速度とレスポンスを追求した、高速ゲームサーバ
です。シンプルなAPIで超高速通信かつ大規模同時接
続を実現します。
２，Monobit Unity Networking 2.0 (略称：MUN)
Unityに特化した通信ミドルウェアです。マッチング、ルー
ム、通信リレーの機能が標準で用意されており、ネット
ワークの知識がなくてもマルチプレイを実装可能。RMSと
連携して、サーバにもC++/C#でコードが書けるように進
化しました。
３，VR Voice Chat
VRコンテンツに「ボイスチャット機能」を手軽に実装できる
Unity専用の無料アセットです。MUNを搭載し、正確な物
理同期・音声同期の実現が可能です。xRデバイスへの
搭載実績もあり、様々な業態にて利用されています。

エンジン採用実績
4

MUNとは？
5

MUN (Monobit Unity Networking)
• Unityに特化した通信ミドルウェア
• マッチング、ルーム、リレー機能が標準で用意されており
• マルチプレイを簡単に実装できる
• サーバサイドにC++やC#でコードを書くことも可能
• クライアント同時接続100人まで可能なパッケージが無料
6

八百万クエストについて
7

八百万クエストとは？
• 開発は株式会社 トイロジック様
• 純和風ファンタジーRGP
• 歩いて遊ぶ、いわゆる位置ゲーで、地図上
の「道」を判別して、自動的にゲームを展
開することで、地域格差をなくし、日本全
国どこでもプレイが可能。
• ２～４人で協力してプレイする「マルチプ
レイモード」では、協力して宝箱を空けた
り、多数決クイズを行うなど、今までの
ゲームには無いリアル連動性を持つRPG。
8

MUN採用箇所
9

みんなで冒険
• マップ上の様々なスポットを同期
• リアルタイムに、他のプレイヤー
がいる位置がわかる
• 宝箱を開ける等、他のプレイヤー
がアクションすると、リアルタイ
ムに全ユーザに反映される
• 多数決クイズや協力して開ける宝
箱等も
10

バトル
•ターン制のシンプルなバトル
•他のプレイヤーと協力して、
様々なスキルや奥義を駆使し
てバトル
11

発生した問題と解決例
12

[みんなで冒険] 実行アクションの排他制御
同時に一人しか実行できないような
「アクション」を行う場合(宝箱を開ける)等に
複数プレイヤーが同時にアクセスできてしまう。
13
画面上に表示されている宝箱(アクションポイント)を
いずれかのユーザが取得した場合、他のユーザに対して
宝箱を取得したことを通信するまでに、若干間が生じる。
その通信が行われる間に、他のユーザが「同じ」宝箱を取
得すれば２人のユーザが同時に「同じ」宝箱を取得できて
しまう。
これ

[みんなで冒険] 実行アクションの排他制御
• ホストが全プレイヤーのまとめ役となり、排他制御などの状態を保持
ホストから許可が下りたときに初めて実行できるようにする。
14
ホストにRPCでアクションIDを送信し
ロックの可否を取得
ホスト クライアント
アクションの実行可否を
クライアントにRPC送信このアクションを実行中(ロック中)の
他のプレイヤーがいないか
アクションIDから検索
アクション実行
ホストのみが持っている
アクションIDと
ロック状態のリスト

RPCとは？
• 「Remote Procedure Call（リモートプロシージャコール）」
の略で、同じルームに所属するユーザに対して
様々なパラメータを設定して通信を行うことができます。
(当たり判定の通知、チャットのメッセージの送信等)
• 送信可能なデータは、様々なデータ型に対応しています。
15
・bool（Boolean） ・int（Int32） ・double（Double） ・byte（Byte） ・unsigned int（UInt32）
・string（String） ・char（SByte） ・long（Int64） ・object（Object） ・short（Int16）
・unsigned long（UInt64） ・Vector2, Vector3, Vector4 ・unsingned short（UInt16） ・float（Single）
・上述のデータ型に基づく、任意の長さを持つ配列情報
・上述のデータ型に基づく Hashtable
・上述のデータ型に基づく Dictionary

RPCの例
16
送信対象 送信データ
RPC名
Monobit.Targets
以降のデータが
引数として結果が渡されます
RPC送信処理
RPC受信処理

ルームについて
• ルームに入ることで、同じルームに入っている他のユーザの
オブジェクトとリアルタイムに同期を行うことができます。
また、同じルームに入っているユーザに対して
RPCを送ることができます。
• ルームの中で誰か一人が「ホスト」としてルームの代表となり
敵キャラのオブジェクト等、シーンオブジェクトの所有や
スコアや勝敗などの、ゲームルールの決定権を受け持ちます
(通常は、ルームに一番最初に接続したクライアントになります。)
• また、同じルームに所属するユーザ全員が参照できる
ルームカスタムパラメータを持つことも可能です。
17

[みんなで冒険] 実行アクションの排他制御
18
宝箱開放アクションRPC実行
ホスト クライアント１
他に実行している人がいないので
実行可能な旨をRPCで送信
宝箱を開ける
宝箱開放成功
ホスト
アクションの実行可能な旨を
クライアント２にRPCで送信
宝箱開放成功
宝箱を開ける
クライアント１ クライアント２
宝箱開放アクションRPC実行
宝箱を開ける
失敗
すでにクライアント２が
アクション実行済み
宝箱開放アクションRPC実行
宝箱開放成功 宝箱開放失敗
• アクションの排他制御の例

任意のプレイヤーがサーバーと通信を行った際にその結果を
他のメンバーに通知する前に、アプリが落ちてしまった等の場合に
状況が共有されない
[みんなで冒険] タイミングによって通信結果が共有されない
19
クライアントA
クライアントB
クライアントC
ロック処理の例 ①MonobitTargets.Hostに
ロック通知RPCを送信
• 同期が必要な通信は全てホストが
代わりに通信を行い、その結果を
他メンバーに通知するように変更
ホスト
②MonobitTargets.Others(ホスト以外)に
クライアントAがロック下旨をRPCで通知

RPCの送信対象について
RPCは下の図のように対象を選択して
データを送信することができます。
20
MonobitTarget.All 送信者自身には即座に受信し、送信者自身以外の
ルーム内プレイヤーに対し、サーバを介して送信
します。
MonobitTarget.Other 送信者自身以外のルーム内プレイヤーに対し、
サーバを介して送信します。
MonobitTarget.Host ホストにのみ、サーバを介して送信します。
MonobitTarget.AllViaServer 送信者自身も含むルーム内プレイヤー全員に対し、
サーバを介して送信します。

• 通信中にホストが落ちたときのために
通信の際は常にホストの変更を監視
ホストがもし、通信途中で落ちた場合
新しく切り替わったホストに対して
再度通信を行う。
21
ホスト クライアント１→ホスト クライアント２
宝箱を開ける
ホストが
落ちる
ホストに
切り替わる
③「①」で保存したホストのIDと
現在のMonobitNetwork.host.ID
を比較して、ホストが切り替わりを検知
再度宝箱開放アクションRPC実行
ホストから
レスポンスが
来るまで待機
[みんなで冒険] タイミングによって通信結果が共有されない
①宝箱開放アクションRPC実行
MonobitNetwork.host.ID
(ホストのプレイヤーID)を保存
②ホストの切り替えが
通知される

[みんなで冒険] ユーザの途中退出時の問題
途中退室したユーザーが復帰した場合に
そのユーザーが初期化中にRPCを受信すると予期せぬ挙動を引き起こす
SafeRpcという関数を独自に定義し
任意のRpcに対して初期化処理が
終わるまでRPC受信側で待ち
改めて実行する事で回避した。
22
他のクライアント 復帰したクライアント
RPC送信 クライアント
初期化中
RPC受信
処理実行RPCを受信したクライアント側で
マップ情報や他のプレイヤー情報が
同期されるまで、コルーチンで待つ

[バトル] データ同期中のプレイヤーの退室
バトルにおいて(自身の攻撃の後の)同期待ち時に
退室したプレイヤーがいると延々と待ち続けてしまう
• 現在のバトルの参加者のメンバーの接続状
況を常に全クライアントが把握する為に
他のクライアント全員にRPCでバトルの情
報の送信と受信を行い、全クライアント分
のデータが揃ったら処理を実行する
(切断状況を常に把握する)
クライアント１ クライアント３クライアント２
切断
MUNサーバ
プレイヤーの
切断検知と
他プレイヤーへ
の通知
バトルデータ
をRPCで同期
ターン開始
バトルデータ
をRPCで同期
バトルデータ
をRPCで同期
バトルデータ
をRPCで同期
バトルデータ
をRPCで同期
MUNサーバが切断検知
クライアント３の
切断通知を送信
バトル実行

サーバ側のカスタマイズ
24

サーバサイドをカスタムするには？
25
MUNのサーバ側のソースコードをHPからダウンロードして
C#/C++で改造してカスタマイズできます
１．MUN公式サイトから、サーバプログラムをダウンロードします。
http://www.monobitengine.com/mun/
２．ダウンロードしたZIPファイルを展開し、VisualStudioのSLNファイルを開いて準備を整えます。
※設定の詳しいことはドキュメントの「オンプレミス版 MUN サーバの動作要件」を御覧ください。
http://www.monobitengine.com/doc/mun/
３．「オンプレミス版 MUN サーバの導入について」に基づいて、必要なモジュールをインストール
４．「サーバサイド・チュートリアル」を元に、サーバサイドのカスタムを行います。
VisualStudioでWindows環境でサーバ側と
クライアントを両方開発できます！

サーバサイドカスタマイズの例(クライアント側)
26
RPC送信処理
カスタムパラメータに
パスワードを設定
ルーム入室時に
クライアントからパスワードを送る

カスタムパラメータとは？
• ルームごとにパラメータを保持することができます。
この値はクライアントからでも
サーバでも参照でき、サーバ側で
チェック処理などを実装することが可能です。
27

サーバサイドカスタマイズの例(サーバ側)
28
クライアントの入室処理にチェックを追加
パスワード不一致ならログインさせない

[みんなで冒険] サーバサイドのカスタマイズ実例
・緯度経度の情報をMUNサーバのルームパラメータに保存し
新たに入ってきたクライアントが、ホストから一定距離以上離れていた場合
同じルームに入室できないようにする
29
ホスト
ルーム参加
可能範囲
範囲外のため
入出できない
mun_room
新規接続
クライアント
カスタムルームパラメータ
JoinRoom(ルーム入出)時に
サーバ側で緯度・経度を比較
新規接続
クライアント
経度x4 緯度y4
ホスト：経度x1 緯度y1
クライアント：経度x2 緯度y2
クライアント：経度x3 緯度y3
入室時に追加
ホストの位置と比較
MUNサーバ
JoinRoom

まとめ
30

まとめ
•MUNを実際に使用するときは
同期が必要なデータについては
ホストが一元管理するか、全クライアントで
双方向の同期を行う必要がある
•ルーム入出時にチェックしたい項目については
ルームパラメータに設定すると良い
31

MUNの今後のロードマップ
32
対応
プラット
フォーム
通信方式
クライアント
プログラム
現行リリース 2018年4月 2018年5月 2018年秋以降
Windows
MacOSX
Android
iOS
Client/Server
通信方式
TCP/UDP/RUDP
プロトコル
ブラウザ対応
Switch
2018年夏
WebSocket
サーバプログ
ラム
Linux C++
Windows C++,C#
MacOSX
.NET Core C#
.Net Core 2.1対応
Unity C#
コア処理のリファクタリングにより、
高頻度送受信時の性能向上
（GC抑止等）
PS4

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