セミナー

【CEDEC 2018】セガゲームス『コトダマン』の800万DL達成を陰で支える「Monobit Unity Networking2.0」　モノビットエンジン採用実例を公開

株式会社セガ

セガ

2018.08.25 11:16

セガゲームスは、8月22日～24日にかけてパシフィコ横浜で開催中の「CEDEC 2018」において、「800万ダウンロードを達成した共闘ことばRPG『コトダマン』でのモノビットエンジン採用実例と最新情報」と題したセッションを開催初日（22日）に実施した。

セガゲームスがパブリッシングを担当し、わずか3か月で800万ダウンロードを達成した『共闘ことば RPG コトダマン(以下コトダマン)』を題材にした同セッション。本作のマルチプレイでは、モノビットエンジン製品群の一つ「Monobit Unity Networking2.0」を採用している。この日は、同サービスのような大規模な接続環境でのマルチプレイのリアルタイム通信を実現する上での開発から運用について、事例をベースに紹介された。

登壇したのは、モノビットエンジン代表取締役社長の安田京人氏と、セガゲームスの日合亨氏（ゲーム＆デジタルサービス統括本部開発統括部ソフト開発部第２ソフト開発セクションセクションマネージャー／シニアプログラマ兼サーバー開発支援課課長）。まずは安田氏が、モノビットエンジンVer2.0シリーズについて紹介していった。

▲モノビットエンジン代表取締役社長の安田京人氏（左）。

同シリーズは、スマホ/家庭用ゲームやVRコンテンツで、マルチプレイを簡単に実現できるリアルタイム通信ミドルウェアで、MMORPGや多人数MOアクションゲームにも対応できる処理速度とレスポンスを追求した高速ゲームサーバ"Monobit Revolution Server（MRS）"、Unityに特化した通信ミドルウェア"Monobit Unity Networking 2.0（MUN2.0）"、Unityで簡単にボイスチャットを実現することができるUnityプラグイン"VR Voice Chat 2.0"という主に3つの製品ラインナップで展開している。

▲同社のエンジン採用実績について紹介。

その中のMUN2.0が、今回のメインテーマであり『コトダマン』でも使われている、クライアントのみでも実装できるUnity特化型の通信エンジンとのこと。多彩な機能を多様なプラットフォームで利用可能でき、MUNで実装できる機能の一部として、サーバー接続、切断、オンラインorオフラインを判定するモード、ルームに入っているプレイヤー情報の取得、シーン内オブジェクトの位置、姿勢、アニメーション等を同期できる機能など、安田氏から一部機能などに関する説明が行われた。

モノビットエンジンに関する紹介が終わると、続いてセガゲームスの日合氏が登壇。『コトダマン』におけるモノビットエンジンの採用実例について語られていった。

▲セガゲームスの日合氏。

まず、なぜモノビットエンジンを採用したのか？　『コトダマン』は開発当初、内製の通信ライブラリを開発していたそうだ。「そのほうが我々の中で色々カスタマイズでき、利点がある」と日合氏は思っていたそうだが、"それぞれ異なる用件への対応が難しい"、"通信というプログラムそのものが難易度が高い（エラー処理、デバック対応など）"という2つの問題が発生。「開発が難航し、これらを解決するよりゲーム本編の開発に注力したほうが良い」と日合氏は考えという。

そこで有償のライブラリを使ったほうが良いと判断し、いくつかの製品を検証した。その中で、モノビットエンジンの採用に至った選定理由として、日合氏は以下を要因に挙げた。

⇒高速で安定したミドルウェアに仕上がっている
⇒C/C++とC#のサポートとLinux環境での実行が可能
⇒日本語でのサポート
⇒（当時は）オフィスが近くパワーサポートにも期待できる
⇒年額でサポート込みと考えると安い

次に日合氏は、『コトダマン』のサーバー構成について、いくつかのAPIサーバーとアクションサーバー群（ここにモノビットエンジンを搭載）、そしてバッチサーバーがあるとし、その中からアクションサーバー群について話を展開した。

アクションサーバーのそれぞれ1つ1つの構成は、1つのインスタンスの中にモノビットエンジン（MUN）を構成するすべてのプロセスを配置。以下4つあるプロセスを配置したセットを複数を配置しているそうだ。

mun_master
mun_proxy
mun_resolver
mun_room

実際にスケールさせるとしたらは、roomさえスケールできていれば基本的にマルチプレイとしては「問題ないはず」（日合）。しかし、「私たちは運用、プレイしやすさのほうに重きを置いている」と日合氏。例えばroomが1台死んだ場合、そのroomルームをどうやって復帰させるか？　どうやってmasterやproxyといった他のサーバーで動いているプロセスに統一するのか？　という問題に直面するが、日合氏は「それを考えるくらいなら、どこか1ヵ所のプロセスが死んだ場合、そのインスタンスの中の全てのプロセスを再起動して生き返らせる」という構成になっていると明かした。

masterが複数あるというところで、クライアントがどこに繋げば良いかわからなくなると思うが、実際にクライアントからマルチプレイで遊びたいと思った場合、クライアントはまずAPIサーバー側に自分がどこに接続すれば良いのか問い合わせをする。そのAPIサーバーは、複数あるアクションサーバー中でどこが生きているかというリストを持ち、空き状況を把握しており、一番空いているサーバーに繋ぎなさいという情報を出す。その後クライアント側から指定されたサーバーに接続するという流れになっているとのこと。

また、4人マルチプレイにおける通信については、前提として「『コトダマン』のマルチプレイはリアルタイムではなくターン制になっている」（日合）とし、4人の内1人は必ずプレイしており、その1人が文字を出したら次の人がプレイするという流れ。つまり残りの3人は1人のプレイを必ず待っている状態にあるという。そして、マルチプレイにおけるユーザー間でやり取りする通信に関しては、自分が持っている文字を場に出したことをほかのユーザーに通知する通信と、他のユーザーにこの文字を置いてほしい、この文字を置きたいと伝える通信の2種類あると日合氏は説明した。

続いて、モノビットエンジンのサーバー監視について。元々ほかのタイトルも含めてMackerelを利用していたそうだが、『コトダマン』を実運用するにあたって、監視関連の機能追加の際、Mackerelのサービスになるべく親和性が高くなる実装、特にルーム数、接続ユーザー数について事細かに依頼したという。結果として、監視対象のメトリクスを取得するMONITORというプロセスを追加することになった。

そして日合氏は、モノビットエンジン内部の情報を監視できるようになったことで、「リソース使用量の比較からサーバーサイジング計画がしやすいこと、接続ユーザー数とDAUの相関関係を正確に把握できるようになり、イベントや施策の効果を適切に判断でき、次のイベント施策に利用できるようになった」ことを利点として挙げた。

最後に日合氏は、モノビットエンジン採用について、以下のようにまとめた。

・リリースから4ヵ月強になるが実運用上でモノビットエンジン起因で不具合は発生しておらず非常に安定したミドルウェア
・要望やバグ修正に対しては迅速に対応してくれて、サポート体制や速度に満足
・単純な通信であればUnityのアセットを導入するだけで完了。C/C++やC#でサーバーサイドにゲームロジックを実装できる

■『共闘ことばRPG コトダマン』

©SEGA