※『みんゴル』は株式会社フォワードワークスより配信・提供
8月30日(水)から9月1日(金)までの3日間、横浜のパシフィコ横浜にて、日本最大のゲーム開発者向けカンファレンスである CEDEC 2017 が開催され、1日目の8月30日(水)に弊社エンジニアである福市と桂田が、2日目の8月31日(木)に同じく弊社エンジニアである西村がそれぞれ登壇しました。
(参考：CEDEC2017に3名のエンジニアが登壇します #CEDEC2017)
本記事では、1日目に福市と桂田が登壇しました『バンドリ！ガールズバンドパーティ！』『みんゴル』でのPhoton採用実例と最新情報の講義内容について、福市からは「『みんゴル』でのPhoton使用方法紹介」、桂田からは「実例：『みんゴル』物理とのシンプルで相性の良い連携」についてのまとめと補足を掲載しますので、ぜひご覧ください。
(2日目に登壇した西村についての記事はこちら：『ダビマス』の操作テンポと開発スピードを上げたUIフレームワークの作り方とその補足 #CEDEC2017)
『みんゴル』でのPhoton使用方法紹介(Author：福市)
はじめに
ゲームデベロップメント統括部福市です。
『みんゴル』のエンジニアリーダーをやっています。
ドリコムに来る前は、汎用機のオペレーターから始まり、
ドリームキャストの人面魚ゲーム開発や、大規模MMORPGの開発、
業務システム、金融システム、Webシステム等の開発もしていました。
今回は先日CEDEC2017で登壇して話した記事の補足として、
『みんゴル』で採用した通信ミドルウェアPhotonをどのように
『みんゴル』で使っているかを簡単に紹介したいと思います。
Photonとは
Photonとは、Photon Engineの事で、ドイツのExit Gamesという会社が開発した
リアルタイム通信に特化した通信ミドルウェアです。
GMOクラウドさんで、代理店とクラウドサービスを提供されています。
日本でもGMOクラウドさんが代理店を始めてから使用しているプロダクトも
非常に増えているように思います。
『みんゴル』でPhotonを採用した理由
『みんゴル』でPhotonを採用した理由を以下に説明します。
- 複数のプロダクトで既に多数の実績がある
世界的に有名なタイトルや、日本でも複数の有名タイトルが既にPhotonを採用しサービスを行っており、非常に多くの実績が既にあります。安定的サービスを提供するには、既に安定稼働している
サービスが多い実績は非常に心強いものです。 - ドリコム社内での検証の結果
ドリコム社内で、複数のリアルタイム通信エンジンの検証を行った結果、知見集約の為に、
特に理由がなければPhotonで統一しようと決定していました。
この為、『みんゴル』開発開始時にもPhotonを採用する流れとなりました。
検証時にPhotonに決定した理由としては以下になります。
- Unityと相性がよく同じC#で開発可能
Unityへ組み込むアセットライブラリが良く整備されていて、Unityに簡単に組み込めます。
また、Photon Serverでサーバーをカスタムしたいとなった場合でも、
Photon ServerはC#でカスタムできるので、C#さえできれば、
クライアントもサーバーも書けるという状態にできます。 - メジャーなクライアントOS（Windows）でデバッグ可能
Photon Serverは普通にVisual Studioでビルドできるので、Visual Studioというスーパー強力な統合開発環境下で開発できます。
当時いくつか触ったリアルタイム通信用のミドルウェアはLinux上だけでしか動かないものや、Javaで書かれてる等、開発環境を快適に整えるのにも若干のハードルの高さがあるものが多く、Visual Studioでプロジェクトを読みこんで実行するだけで動いてしまう
Photon Serverの導入コストの低さは魅力的でした。 - 開発環境を整える事がすぐでき、無料
先の説明でも少し書いてますが、クライアント側もサーバー側もSDKをサイトから落として、さっくり動く状態にできましたし、開発している間は接続数が絞られるだけで無料で使えました。 - サーバーをカスタムしなければ自前でサーバーをたてず、クラウドサービスが利用可能
リアルタイムでデータ配信するだけの機能であれば、
これも無料でさっくりクラウドサービスが利用できます。
自前でサーバーを用意してセットアップするのはなんだかんだで時間のかかる作業ですし、時間コストが削減できます。 - サポート窓口が日本語で可能
日本語でサポートを受けることができる、これは大事です。サポートに問い合わせても海外のサポートだと勤務時間が違ったり祝日が違ったりでレスポンスが遅れたり、そもそも英語等で問い合わせる必要があります。
英文で適切にこちらのニュアンスを表現するのはなかなか大変です。
ゲーム機能上のPhoton採用箇所
- 「みんなでゴルフ」
『みんゴル』では色々なゲームモードがありますが、その中でも「みんなでゴルフ」という機能で、プレイヤー8人で同時にリアルタイム対戦ができるゲームモードがあります。
この機能でPhotonを使ってリアルタイム対戦を実現しています。
「みんなでゴルフ」機能のリアルタイム通信の要件
「みんなでゴルフ」機能のリアルタイム通信の要件は簡単に書くと以下のようになります。
- 企画要件：「みんなでゴルフ」機能を実際に同時にみんなで遊んでいるライブ感
ここから機能要件に落とすと
- 機能要件：「みんなでゴルフ」機能でボールとスコアをリアルタイムに同期する
機能要件を満たしつつ、技術的要件としては
- 技術要件：機能要件を満たしつつ兎に角シンプルに
技術要件について、もう少し深く掘り下げます
機能要件をみたしつつ兎に角シンプルに
なぜ、シンプルにする必要があるかについては大きく以下の２点の理由があります。
- 通信パラメーターの増大や頻繁な通信は、通信パフォーマンスに大きく影響する
通信パフォーマンスといってもいくつかありますが特にこの２点「帯域」と「レイテンシ」が問題で、帯域を沢山使ってしまうと、ユーザーの月々使用できる通信帯域を大きく使用してしまい、あっという間にユーザーが帯域制限をされてしまったりしてユーザーに迷惑をかけてしまいます。
また、レイテンシが悪いと、同時にリアルタイムに遊んでいるというライブ感が特に
隣同士で遊んでいる場合等に削がれてしまいます。 - 同期タイミングのデータ整合性、エラーチェックが増大し、バグの発生率、実装コストが高くなる
沢山の同期タイミングがあったり、通信メッセージの種類が増えたりすると、
その分、同期タイミングでのデータの整合性や、排他処理、
エラー処理をその分記述する箇所が増える為、当たり前ですが、
それだけバグの発生率、実装コスト、テストコストが通信順番までも考え始めると、
指数残的に増えていきます。
シンプルに実装する上でやった事
- リアルタイム通信をしなくても、「みんなでゴルフ」機能は動作
- Photon Viewを使用せず、通信メッセージはEventで送信する
- 同期データと通信タイミングは最低限にする
これらについて、もう少し詳しく以下に説明していきます。
リアルタイム通信をしなくても、「みんなでゴルフ」機能は動作
「みんなでゴルフ」機能を以下のように実装しました。
- ラウンド途中のボール、プレイ情報のみをリアルタイム同期
- マッチング機能、ルームでの待ち合わせ機能等はAPIサーバーで実装
- １ホール完了時、全員のプレイを待っている時は、APIサーバーからポーリングで状況取得
- 万が一リアルタイムサーバーが落ちたり、問題がでた場合は、リアルタイムにボール、スコア情報が更新されないだけで、ゲームとしては成立する。
その結果、以下の利点が生まれました。
- 常時接続中の回線切断が起きても、リアルタイムに情報が更新されないだけで、プレイが止まらず続行でき、自身のプレイを阻害されない
- 回線が切れてもゲームが続行できている為、再接続での複雑な復旧処理が不要。 切断時は、ボールとスコア情報がリアルタイムに更新されず、 再接続すれば更新処理が再開されるというシンプルな構成
- 万が一リアルタイム通信ができなくなった場合でも、「みんなでゴルフ」機能は続行可能
- 開発途中、リアルタイム通信が無くとも、「みんなでゴルフ」機能自体は出来た為、ゲームサイクルが先行して確認できた
- リアルタイム機能は後付でリアルタイムサーバーはAPIサーバーとも連携しない為、好きなタイミングでリアルタイム機能を追加できた
Photon Viewを使用せず、通信メッセージをRaiseEventで送信
PhotonViewとRaiseEventの簡単な特徴は以下の通りです。
- PhotonView
PhotonViewはUnityのInspectorでGameObjectにくっつけて使う通信機能で、
オブジェクト同士の同期を自動で行ってくれる機能です。
導入は簡単ですが、そのかわりに、メッセージの送信タイミングがコントロールできず、
帯域のコントロールが出来ません。 - RaiseEvent
通信メッセージを自分で設計し、実装者の任意のタイミングでEventとしてメッセージを送信する機能です。
通信メッセージを自分で設計し、自分で送信タイミングを決める必要がありますが、
その分、通信タイミングと帯域コントロールが自由にできます。
同期データと通信メッセージを最低限にするには、通信メッセージの設計及び、
送信タイミングをコントロールする必要があります。
この為、RaiseEventを使用して、実装を行っています。
同期データと通信タイミングは最低限にする
「みんゴル」で開発していた物理エンジンはスキップ・リプレイ・ランク戦のゴーストを実現するため、入力が同じならば同じ結果を出力できるという特徴がありました。
このため、受信したパラメーターの入力から他のユーザーの動向を正確に再現できます。
これが前提にあった上で、通信タイミングはアドレス開始時と、ショット時の２回のみです。
最初はショット時のみだったのですが、スタート時に他プレイヤーのボールが無かったり、
スコアと打数の更新タイミングがなさすぎてライブ感が弱くなる等があった為、
アドレス時も送信タイミングとして追加しました。
各々の通信時に送信しているパラメーターは以下の通りです。
- アドレス開始時
・スコア情報
・ショットポイント
・打数 - ショット時
・スコア情報
・ショットポイント
・打数
・ボール位置
・物理槐人で軌道を再現するのに必要なパラメーター
通信メッセージの計測
これまで説明したシンプルな通信実装を行った結果、
通信メッセージの実測は以下の通りになりました。
- 最大メッセージ数/秒/ルーム
通常時２、最大でも３ - 帯域
１ユーザー当たり秒間100Byte
なかなかどうして、相当に通信数も帯域も抑える事ができました。
シンプルにした結果
シンプルにした結果、以下のように良いことばかりで、
リアルタイム通信部分で何か困ったという事もありませんでした。
- 実装はテスト含め２週間程度
リアルタイム通信機能を２週間で実装したゲームは他に聞いた事が無いです。 - リリース前から考えても、実装後リアルタイム通信まわりの不具合はほぼ無し
覚えている不具合では１件だけありました。
回線切断時に行う、オブジェクトの開放処理に問題があり、
ある特定のタイミングで、他ユーザーが切断されると進行不能になる不具合がありましたが、それくらいでした。（再現率も相当低かったですが）
リアルタイム通信を疑ったバグも追ってみたら全然別のバグだったという事ばかりでした。 - 通信パフォーマンスの心配はなく、接続数の注意だけすればよくなった
正直実績あるクラウドサービスなのもあり、極小の通信数と帯域でしたので
動かないわけがない。また、リアルタイム通信がなくても動くという仕組みにしていたので、負荷テストも行っていませんが、何もトラブル無く動いています。
最後に
リアルタイム通信は、色々できる事も多く、夢いっぱいで希望を詰め込み過ぎそうになりますが、そこはぐっと我慢して極力単純、シンプルに実装する事がリアルタイム通信実装の秘訣だと思います。
実例：『みんゴル』物理とのシンプルで相性の良い連携(Author：桂田)
はじめに
はじめまして。
ゲームデベロップメント統括部所属の桂田卓也です。
2016年9月入社にドリコムへ入社し、掲題となる『みんゴル』の開発ではクライアントエンジニアとして、描画処理や独自の物理エンジンの設計及び開発など、特にゲーム基盤となる部分を担当させていただいております。今回は、CEDEC2017で弊社福市と共に登壇させていただいた内容『バンドリ！ガールズバンドパーティ！』『みんゴル』でのPhoton採用実例と最新情報の増補版を記載させて頂ければと思います。
『みんゴル』独自物理エンジン
弊社広報ブログにも開発経緯が書かれておりますが、
『みんゴル』では「みんなのGOLF」シリーズがもつ独自の表現をスマートフォン上でも実装していく目的のため、独自の物理エンジンを実装しております。この物理エンジンは予測可能なゲーム状態を保持できることを特徴としたもので、マルチプレイ対戦の実装で重宝したことはもちろんですが、『みんゴル』の各種機能を実装する上でも基盤機能としてゲームの土台を支えております。
ゲームイベントの流れ
マルチプレイ対戦機能の紹介の前に、『みんゴル』のインゲームの基本サイクルを紹介したいと思います。
ゲーム処理的にはコース紹介後、AddressからEvaluateを繰り返し、ホール終了時にEmoteと呼ばれるポーズ演出、終了処理を繰り返す流れとなります。ご存知の通り、この中では実際にショット操作をする部分が最も重要で、ここで決定されるショット入力時のデータと決定された風速や風向等のラウンド環境を元に予測可能な物理軌道を生成しており、すべてのゲーム機能の根幹となっております。
ここで生成されるショットデータとその結果が「ひとりでゴルフ」の成績となり、同じラウンド環境からラウンド中の全ショットデータを物理エンジンに渡すことでVTR機能が実現され、相手のショットデータと対戦することで「ランクマッチ」が実現しております。
なので、『みんゴル』攻略の近道は、練習をしっかり重ねて安定したショットを打てることです。事実、狙い通りのショットパラメーターが作成され、ボール移動を実現する物理軌道が思い通りに進めば、狙い通りの結果を生む可能性が高くなるはずです。
『みんゴル』物理の技術要件
『みんゴル』では確定された入力が存在する場合、予測可能な結果が出せることが技術要件となっておりました。
これを実際の『みんゴル』の各機能ごとに見ていくと、
- 「ひとりでゴルフ」では、自分で入力したショットデータが、実際のボール軌道を作り出します。
- 「VTR」では、保存当時に自分が入力したショットデータが、VTRでのショット入力となり、ボール軌道とプレイ履歴が再現されます。
- 「ランクマッチ」では、サーバーに保存された自分以外のプレイヤーのショット履歴をショット入力として、対戦プレイを実現しています。
このように、実際の入力や保存されたデータなどを物理エンジンに登録すれば、ゴルフのボール軌道が実現可能であるため、
内製のオフラインツールの作成にも一役買っており、細かな物理調整やパラメーター調整等に関してイテレーションしやすい環境を整備しています。
ここで掲題のマルチプレイ対戦に立ち戻ると、リアルタイムでショットデータを送受信することが出来れば、自分のボール軌道を相手の環境で再現することができ、また相手のボール軌道が自分の手元で再現されるというマルチプレイ対戦の仕組みが見えてくると思います。
マルチプレイ対戦の紹介
上記にて弊社福市からも説明がありましたが、リアルタイム通信に関しましては極限まで通信回数を減らすことで実績あるPhotonの基盤の安定性を生かすという判断となりました。そのため、1人のプレイヤーがゲームイベントで発行する通信回数は1打につき2回という少なさとなりましたが、
この判断が可能になったのも、明確なゲームイベントからマルチプレイ対戦に必要な要素を判断することができ、物理エンジンに与えるべき入力をどうすれば良いかという点に注視できたことが大きいです。
先ほど紹介したゲームイベントの中で、物理エンジンに登録され解除される部分がショット処理から結果確定の部分までと記載しましたが、相手のボール軌道を再現するためには登録の元になるデータだけ存在すれば良いため、通信はAddressとShotの２つのイベントになります。
AddressMessageは、相手のスコア状態などからわかる順位などを更新するために送ります。
講演でもお話しさせていただきましたが、『みんゴル』では相手のボールを障害物として扱わない仕様であるため、相手の位置座標が厳密である必要性がありません。このため、アドレス時に現在座標を送信することで緩やかな同期処理を行うようにしています。
ShotMessageは、まさに物理エンジンに渡すための入力値を送るための部分となります。上記にて、弊社福市の方からリアルタイム基盤に問題が発生していても処理が可能と言っていたのは、APIサーバーの方に保存してあるショットデータとリアルタイム基盤で送受信するショットデータが等価であるため、相手のショットデータを取得することが出来れば再現は可能ということになります。
受信時の挙動は各モードで説明した内容に非常に似たものとなります。
先ほどショットデータをリアルタイムに送受信することが出来ればと書かせていただきましたが、この受信時がまさにそれにあたり、相手から送信されてきたショットデータを物理エンジンに与えることで、ゲーム上で他のプレイヤーのボールが入力値と同じように動くというわけです。
このように『みんゴル』は、とにかく自分のショットデータを安定させることが大事なゲームとなっており、練習すればするだけ上手くなります。
ギアを選ぶ際にも特性に振り回されず、自分自身のプレイに対して安定したギアを選ぶようにすることをおすすめします。
まとめ
以上でCEDEC2017の講演内容の簡単なまとめとなります。
ちなみに、この独自の物理エンジンは今回説明した内容のみならず、カメラ撮影なども土台として使用しております。
たまに気を向けてみると新しい発見があるかもしれません。
