Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

年の瀬リアルタイム通信サーバ勉強会

13,932 views

Published on

こちらの勉強会のスライドとなります。
https://atnd.org/events/72568
以下、ATNDページからの引用です。
---
モノビット代表の本城です。
当社は2年半前から、ゲーム向けのリアルタイム通信エンジンを、いろいろな会社様に提供させて頂いてきました。今回の勉強会では、その経験から学んだ、リアルタイム通信のゲームサーバを設計、開発する際の注意点や落とし穴を、実例を交えてご紹介致します。

■勉強会概要

日時:2015/12/03 (木) 19:00 ~ 20:30(受付18:30から)
料金:無料
場所:BIZ新宿@1F多目的ホール
   最寄り駅:丸ノ内線「西新宿」駅徒歩5分、大江戸線「都庁前」駅徒歩8分
   アクセス:http://www.city.shinjuku.lg.jp/content/000147528.pdf
   会場詳細:https://www.city.shinjuku.lg.jp/jigyo/file04_03_00017.html

■勉強会アジェンダ

1,リアルタイム通信サーバ設計・開発の最新事情
 ・サーバ設計はどうすればいいの?
 ・ポート番号問題
 ・負荷テストってどうやってるの?
 ・負荷分散の実例
 ・Webサーバとの連携方法は?
 ・既存のタイトルに後から組み込める?
 ・どこのクラウドがおすすめ?

2,リアルタイム通信エンジンの最新事情
 ・Photonとモノビットエンジンの違いは?
  (性能、速度、安定性、サポート、etc…)
 ・Unity、UnrealEngineなどのゲームエンジンと通信エンジンの組み合わせ方
 ・自社でオリジナルの通信エンジンを作ってみる?
 ・通信エンジン界隈の今後の予想図

■講師
 本城 嘉太郎(株式会社モノビット代表)
 安田 京人(株式会社モノビット ミドルウェア事業部 部長)
 モノビットエンジンサポートチーム

Published in: Engineering
  • Be the first to comment

年の瀬リアルタイム通信サーバ勉強会

  1. 1. 年の瀬! リアルタイム通信ゲームサーバ 勉強会 代表取締役 本城 嘉太郎郎 ミドルウェア事業部部⻑⾧長 安⽥田 京⼈人 2015/12/03
  2. 2. 2 ■株式会社モノビット 2005年年よりネットワークゲームの開発と運営を⾏行行っているゲ ーム制作会社です。2013年年よりミドルウェア事業を開始。『 モノビットエンジン』のブランドで、リアルタイム通信エンジ ンの販売を⾏行行っています。 <本城 嘉太郎郎> 神⼾戸出⾝身。モノビット社代表取締役。元ゲームプログラマ&ネッ トワークエンジニア。CEDECで5年年連続でネットワークゲームの 運営企画やサーバ技術の講演を⾏行行っています。そのうち2講演はト ップクラスの評価を頂き、翌年年のCEDEC  AWARDの選考委員を務 めました。 <安⽥田 京⼈人(Kyoto Yasuda)> 株式会社モノビット ミドルウェア事業部部⻑⾧長。IT系企業でSE 兼PGとして2年年勤務後、6年年間⼤大⼿手デベロッパーでコンシューマ ーゲームプログラマーとしてアクションゲームを中⼼心に様々な ジャンルのゲーム開発に携わる。オンラインゲームの知識識を⾝身 に付けるため株式会社モノビットに⼊入社。現在はモノビットエ ンジンの開発指揮とエヴァンジェリストとしても活動。 ・登壇者紹介 ■本日の登壇者
  3. 3. ■本日の勉強会のアジェンダ 第一部:リアルタイム通信サーバ設計・開発の最新事情 <登壇者:安田 > リアルタイム通信サーバに関する最新トレンドや、 設計や負荷テストについてのtipsを実例を交えてお話します。 第二部:リアルタイム通信エンジンの最新事情 <登壇者:本城> リアルタイム通信エンジンについて、 各社製品の特徴の違いや、通信エンジンの選び方をお話しします。 3
  4. 4. 4 第一部:リアルタイム通信サーバ設計・開発の 最新事情
  5. 5. ■目次 1.リアルタイム通信サーバ設計・開発の最新事情 1.1.  リアルタイム通信サーバ設計の最新トレンド 1.2.  ポート番号問題 1.3.  負荷テストってどうやってるの? 1.4.  負荷分散の実例例 1.5. Webサーバとの連携⽅方法は? 1.6. どこのクラウドがおすすめなの? 5
  6. 6. ■リアルタイム通信サーバ設計の最新トレンド エリアサーバA エリアサーバB DB バックエンドサーバ (オークション、チャット) クライアント クライアント クライアント クライアント 1ワールド エリアサーバN… ■サーバ設計の過去 かつてPCオンラインゲームが全盛だった時代は、 全てをC++で実装したリアルタイム通信のサーバで設計する構成 (下図参照)が主流流だった。 6
  7. 7. ■リアルタイム通信サーバ設計の最新トレンド ■現在のトレンド モバイル案件ではソーシャル要素を⾮非同期で実装し、 バトル部分をリアルタイムサーバで実装する構成、 ハイブリッド型のサーバ設計が主流流。 →リアルタイム通信が必要ない部分を実装が容易易なWEB⾔言語で実装し、 処理理負荷の⾼高いバトル部分をC++⾔言語で実装することにより、 ⽣生産性と実⾏行行効率率率の両⽅方いいとこ取りしたサーバー構成が実現可能。 また、既にWebの資産がある場合再利利⽤用可能というメリットもある。 ■実例例 今回はこのハイブリッド型のサーバ構成で実際に運⽤用した、 とあるMO系モバイルタイトルのサーバ構成を⼆二種類ご紹介します。 (これから紹介するタイトルは架空の案件を複数組み合わせたものですが、 詳細には事実が含まれております。) 7
  8. 8. ■リアルタイム通信サーバ設計の最新トレンド ■タイトルA Webサーバでソーシャル要素を実装し、 バトルルームに複数⼈人が集まって敵と戦う⽩白猫のようなゲーム。 ■設計ポイント ある程度度のプレイヤーのリスティングをWebサーバで⾏行行い、 更更にレベルマッチング等マッチングの種類によるマッチング処理理を、 C++で実装されたリアルタイム通信のマッチングサーバで⾏行行う事で、 ⾮非常に⾼高速なマッチング処理理を⾏行行う事が可能になる設計。 そのためマッチングサーバの台数をやや多⽬目に⾒見見積もっている。 8
  9. 9. ■具体的なサーバ構成 クライアントアプリはマ ッチングサーバを介して バトルサーバの接続先を 取得する インスタンスバトルへの参加 のたびに、 いずれかのBattleサーバに直 接接続。バトルが終了了すると 切切断。 WEB SERVERS(EC2) Cashe Database Backend Game(Lobby)Servers Backend Game(Others)Servers Frontend Servers Frontend (Battle)Servers Private Section Global Section Battle Battle Ranking Chat ChatRanking Battle Battle Matching Lobby Lobby Lobby Lobby Sync Matching Matching Matching 9
  10. 10. ■リアルタイム通信サーバ設計の最新トレンド ■タイトルB Webサーバでソーシャル要素を実装し、 起動するとビジュアルロビーがあり、 そこからバトルフィールドに⼊入って敵と戦うログレスのようなゲーム。 ■設計ポイント グローバルIPアドレスを節約して欲しいというオーダーがあり、 フロントエンドに通信の⼊入り⼝口を⼀一つにまとめるサーバを設置し、 クライアントはフロントエンドサーバにコネクションを張る事で、 そこを介してバックエンドに設置したエリアサーバに通信を⾏行行う。 エリア間の移動は全てサーバ間通信で賄えるので、 対象エリアサーバに対してコネクションを張り直すといった事もしなくても良良い。 結果として通信料料の削減にも繋がった。 10
  11. 11. ■具体的なサーバ構成 クライアントアプリは1台 のRelayServerに 常時接続。エリアを移動し ても切切断・再接続は不不要。 WEB SERVERS(EC2) Cashe Database Backend (Game)Servers Frontend Servers Private Section Global Section Relay Relay Relay Relay Lobby Lobby Sync Area Game Area Game Area Game 11
  12. 12. ■ 1.2.ポート番号問題 初⼼心者向け ■ポート番号とは? コンピュータがデータ通信を⾏行行う際に通信先のプログラムを特定するための番号のこと。 TCP/UDPのプロトコルそれぞれに対し、0〜~65535の数値と決まっている。 プログラムでポートを⽤用いて通信するには、⼀一般にソケットと呼ばれる仕組みを⽤用います。 ■ソケットプログラミングとは? (※Wikipedia参照) 1.サーバ機でサービスを提供するプログラムは、ソケットを作成し、サービス固有のポート番号を ソケットに割り当て (bind)、待ち⾏行行列列を⽤用意し (listen)、クライアントからの接続を待ち受ける (accept)。 2.サービスを利利⽤用するクライアントプログラムは、ソケットを作成し、そのソケットの通信相⼿手と してサーバ機のIPアドレスとサービスのポート番号を指定し (connect)、接続を⾏行行う。 3.サーバは接続を受け付けると、新規にソケットを作成し、そのソケットとクライアントとの間に 通信を確⽴立立する。もとのソケットは再び待ち受けに戻る(これは、会社などで、受付係が来客を担 当者に引き合わせ、その後また受付に戻るようなものと考えることができる)。 4.通信が終わると、2.および3.で作成したソケットは破棄される。 12
  13. 13. ■ 1.2.ポート番号問題 リアルタイム通信のゲームサーバではクライアントからの通信を待ち受ける ポートを決める必要がある。 ⼀一般的に設定するポートについては、ウェルノウンポート(0-1023) を避けて設定する事。 ウェルノウンポートを避けて設定すれば基本的に⾃自由に決めて問題ない。 ■注意点 特定のポートだと通信が⾏行行えなくなる場合がある。 例例えば5桁の15000以上に設定し、 通信がうまく⾏行行えない場合そのポートは、 サーバサイドでも他サーバへの通信で使っている可能性がある。 つまり、サーバ側がクライアントとなり他サーバに通信をする場合、 システム側で割り当てられたポートとして使われているケースが多い。 (あくまで⼀一例例ですがHTTP通信等) ※Linuxでnetstatコマンドで確認すると⾒見見知らぬポートが⾒見見つかる的な 他にも、 ルータ側の問題で10000以上が繋がらなかったり…。 13
  14. 14. ■ 1.2.ポート番号問題 ■ポート番号指定の失敗例例 セキュリティの観点からHTTP通信で使⽤用する80ポートを設定した所、 結果、⼀一部のユーザーさんだけサーバに接続できない問題が発⽣生。 原因としてはAUのLTE回線で80ポートはHTTP通信しか許可しない設定になっ ていた。 参考URL: http://www.au.kddi.com/developer/android/kaihatsu/network/ ■解決策 8100ポートも空けておく事で80ポートでアクセスできない場合、 8100ポートにリダイレクトする処理理をインフラ側で対応した。 こういったキャリア側の問題も存在するため、 ウェルノウンポートは可能な限り使わない⽅方が良良い。 14
  15. 15. ■ 1.2.ポート番号問題 ■結論論 リアルタイム通信サーバのクライアントからの通信の待ち受けポートとし ては、1万以下が良良い。 実際にモノビットエンジンでは、 4000以上9000以下のポートを使⽤用した場合に今までトラブルが少なかっ たが、トラブルが発⽣生しない事を完全に保証する訳ではない。 ポート問題は奥が深い…。 →それでも設定したポートで通信出来なかったら、 下記ページが何かのヒントになるかも。 ・TCPやUDPにおけるポート番号の⼀一覧 https://ja.wikipedia.org/wiki/TCP%E3%82%84UDP%E3%81%AB%E3 %81%8A%E3%81%91%E3%82%8B%E3%83%9D%E3%83%BC%E3 %83%88%E7%95%AA%E5%8F%B7%E3%81%AE%E4%B8%80%E8 %A6%A7 15
  16. 16. ■テスト⽅方法について ・Web系の場合 →JMeter等を⽤用いてテストを⾏行行うのが⼀一般的。 ・リアルタイム通信ゲームサーバの場合 →JMeterでは独⾃自のプロトコルが使⽤用できないので、 ダミークライアントを⾃自前で作成し、それを⽤用いた負荷テストを⾏行行う。 ■ダミークライアントとは? クライアントの通信をエミュレーションしたプログラムの事。 ■ダミークライアントの処理理の実際 起動したらログインといったアウトゲームの処理理を模倣するのではなく、 マッチングサーバに直接接続し、バトルに移⾏行行しクライアント、 サーバ間で通信を送り合う処理理を作成する事が多い。 ■ 1.3.負荷テストってどうやってるの? 16
  17. 17. ■ 1.3.負荷テストってどうやってるの? ■ダミークライアントの作り⽅方 バトル中の処理理については、 インゲーム(バトル)の部分にログを仕込んで通常プレイを⾏行行い、 バトル中のログを取得する事で、 ユーザーのバトル中の⾏行行動がある程度度把握できるので、 そのログを元にダミークライアントにバトルの通信をエミュレートした 処理理を実装していく。 17
  18. 18. ■ 1.3.負荷テストってどうやってるの? ■テスト⽅方法について 2種類ある。 ⽅方法1:PCや端末を⼤大量量に⽤用意してテストクライアントを動かして テストを⾏行行う⽅方法。 ⽅方法2:クラウド上に負荷をかけるサーバと負荷をかけられるサーバを⽤用 意し、 Linux上で稼働するダミークライアントをインストールして テストを⾏行行う⽅方法。 ■実際は・・・ ⽅方法1を採⽤用する事もあるが、 数万接続をエミュレートする際に現実的には⽅方法2を選択する。 18
  19. 19. ■⽅方法2でAWSを使⽤用する際の注意点 インスタンスタイプを選択する際、 t2.microを選択しないようにする。 負荷検証等、CPU負荷をかけるような処理理の場合Steal (※)問題が発⽣生する。 最低でもt2.medium以上を使うべき。 ※Steal問題とは、 短時間であれば問題なく動作するが⾼高負荷状態が⼀一定時間続くと、 強制的に低速モードに切切り替わり、 CPU性能が約8〜~9割劣劣化し極端に処理理速度度が低下してしまう問題。 ■ダミークライアントをLinux上で使⽤用する上での注意点 ダミークライアントの作りにもよるが、 1つのダミークライアントで数ユーザー等少ない⼈人数をエミュレーションして、 1台のマシンで同時に500プロセス等、 ⼤大量量のダミークライアントプロセスを起動するような場合、 コンテキストスイッチの切切り替えが短い時間で発⽣生し、 1つのプロセスで⼗十分な処理理時間が確保できなくなり、 通信が正常に⾏行行われなくなる場合がある。 出来る限り1プロセス内に複数ユーザーを処理理ようなプログラムにし、 同時起動プロセス数を出来るだけ少なくするのが重要。 ■ 1.3.負荷テストってどうやってるの? 19
  20. 20. ■ 1.3.負荷テストってどうやってるの? ■モノビットエンジンのダミークライアント Linuxで動作するダミークライアントのスケルトンを提供しています。 パッケージ構成 dummy_client_base/    =>  ダミークライアントのベースプログラム dummy_client =>  ダミークライアント実⾏行行ファイル dummy_client_multi.sh  =>  dummy_client を複数プロセスで起動するためのシェル dummy_client_start.sh  =>  ダミークライアント起動シェル dummy_client_stop.sh    =>  ダミークライアント停⽌止シェル setup.sh                            =>  初回のみ実⾏行行するシェルスクリプト dummy_client.sh              =>  サーバーのビルドや起動/停⽌止を⾏行行うシェルスクリプト log/                                    =>  ダミークライアントがプロセス単位で出⼒力力するログファイルディレクトリ config/                              =>  ダミークライアント⽤用コンフィグファイルディレクトリ src/                                    =>  ダミークライアント⽤用ソースファイルディレクトリ libmln/                              =>  必要に応じて接続先のMLNサーバー側で使⽤用しているものと同じMLNライブラリを配置するディレクト リ dummy_client_echo_sample_lite/    =>  echo_sample_lite版ダミークライアントプログラム dummy_client =>  ダミークライアント実⾏行行ファイル dummy_client_multi.sh  =>  dummy_client を複数プロセスで起動するためのシェル dummy_client_start.sh  =>  ダミークライアント起動シェル dummy_client_stop.sh    =>  ダミークライアント停⽌止シェル setup.sh                            =>  初回のみ実⾏行行するシェルスクリプト dummy_client.sh              =>  サーバーのビルドや起動/停⽌止を⾏行行うシェルスクリプト log/                                    =>  ダミークライアントがプロセス単位で出⼒力力するログファイルディレクトリ config/                              =>  ダミークライアント⽤用コンフィグファイルディレクトリ src/                                    =>  ダミークライアント⽤用ソースファイルディレクトリ libmln/                              =>  必要に応じて接続先のMLNサーバー側で使⽤用しているものと同じMLNライブラリを配置するディレクト リ 20
  21. 21. ■ 1.3.負荷テストってどうやってるの? ■カスタマイズ⽅方法について ゲーム中の通信を定義して出⼒力力されたRPCコードを該当箇所にどんどん追加していくだけでOK。 21
  22. 22. ■ 1.3.負荷テストってどうやってるの? ■ダミークライアントの起動シェル ダミークライアントの起動シェル dummy_̲client_̲start.sh  には、以下の設定値が⽤用意されている。 SELF_NODE_ID                  :  ダミークライアントのノードID SELF_IP_ADDR                  :  ダミークライアントを実⾏行行しているマシンのIPアドレス SELF_PORT                        :  ダミークライアントのノード待ち受けポート番号(0なら、ランダム) SYNC_IP_ADDR                  :  Syncサーバーを実⾏行行しているマシンのIPアドレス SYNC_PORT                        :  Syncサーバーのノード待ち受けポート番号 デフォルトではローカル環境の設定になっているので、 SELF_IP_ADDR   と SYNC_IP_ADDR  を環境に合わせて修正する。 22
  23. 23. ■ 1.3.負荷テストってどうやってるの? ■ダミークライアントの起動シェルオプション ダミークライアントの起動シェル dummy_̲client_̲start.sh  には、以下のオプションが⽤用意されている。 -m  :  ダミークライアントで使⽤用する全体のキャラ数(接続数) -n  :  1プロセスで使⽤用する最⼩小キャラ数(接続数) -i :  ダミークライアントで使⽤用するキャラID(接続ID)の開始値 デフォルト(-‐‑‒m  1  -‐‑‒n  1  -‐‑‒i 1)では、キャラID  1  のキャラで 1  プロセスを起動する。 例例: -‐‑‒m  4  -‐‑‒n  4  -‐‑‒i 1  とした場合、キャラID  1,  2,  3,  4  のキャラで 1  プロセスを起動する。 また、 -‐‑‒m  8  -‐‑‒n  4  -‐‑‒i 10  とした場合、キャラID  10,  11,  12,  13  のキャラで 1  プロセス、 キャラID  14,  15,  16,  17  のキャラでもう 1  プロセスを起動する。 23
  24. 24. ■ログレスライクゲームの負荷テスト ・ゲーム内容 4⼈人のユーザーが集まってバトルを⾏行行うタイプのゲーム。 ・リアルタイム通信サーバの使⽤用箇所 マッチングサーバ、バトル、チャット ・テスト対象 どれがかけてもゲームが成⽴立立しないため、 マッチング、バトル、チャット、それぞれに対して負荷テストを⾏行行う。 今回はバトルサーバの負荷テストの実例例を紹介します。 ・負荷テストの⽬目標 同時接続10000⼈人でバトルサーバのMAXCPU使⽤用率率率30%程度度を⽬目標とする。 ・テストシナリオ プレイ時間から逆算を⾏行行う。 プレイ時間を1時間だと仮定し、 デッキ編成やガチャ等ソーシャル要素をプレイしている時間を考慮し、 10分に1回はバトルをしていると想定。 →ここのさじ加減は⾮非常に重要! ■ 1.3.負荷テストってどうやってるの? 24
  25. 25. ■ 1.3.負荷テストってどうやってるの? ■バトルサーバの負荷テストの実例例 負荷にもよるが、ログレスのようなターン制のアクションゲームの場合、 1バトルサーバに500〜~1000プレイヤーを収容するケースが多い。 バトル中の処理理が軽いものだと3000以上収容できる事も多い。 今回は余裕をもってバトルサーバは15台⽤用意した。 ・負荷テスト⼀一回⽬目 AWS上に負荷をかけるサーバを⽤用意しダミークライアントをインストールした。 クラウドサーバ内 Dummy Battle Battle Dummy Dummy 負荷テスト開始! 25
  26. 26. ■ 1.3.負荷テストってどうやってるの? ■負荷テスト中の状況の確認 CPUの使⽤用率率率を確認するには、バトルサーバへSSHでログインし、 負荷試験中にtopコマンドで確認を⾏行行う。 topコマンドを実⾏行行した所、 テスト早々にバトルサーバのCPU使⽤用率率率が100%になってしまった! 26
  27. 27. ■ 1.3.負荷テストってどうやってるの? ■対策 この時点で原因は完全に不不明。 どこの処理理でCPUコストを⾷食っているのか調べる必要があったので、 バトルサーバのコードに細かくログ出⼒力力を仕込み、 ロジック毎の処理理時間を計測した。 こういった泥泥臭い事が実は解決への⼀一番近道。 最初は粒粒度度が荒い所から始め、 徐々にコストが重い処理理を絞り込んでいくイメージ。 27
  28. 28. ■ 1.3.負荷テストってどうやってるの? ■原因 上述の⽅方法でコストが重い処理理を調査した結果、 あたり判定処理理に⾮非常にコストがかかってしまっていた事が判明。 ■改善策 プレイヤー含む全てのオブジェクトに対し当たり判定を⾏行行っていた。 ゲーム仕様的に同期が必要なオブジェクトのみ、あたり判定を⾏行行えば良良かったので、 当たり判定処理理の最適化を⾏行行った。 再度度負荷テストを⾏行行い、MAXCPU使⽤用率率率が25%程度度に落落ち着くようになった。 また、⽬目標の30%以内には収まってはいるが、本番サーバ構築時に余裕を持たせ バトルサーバマシンのスケールアップを⾏行行った。 ■結果 CPU負荷も軽減され負荷テストも滞りなく完⾛走。 これで負荷テストも終わり! 28
  29. 29. ■ 1.3.負荷テストってどうやってるの? 安⼼心してください。 終わってませんよ。 29
  30. 30. ■ 1.3.負荷テストってどうやってるの? ■何が起きていたのか。 同接10000⼈人時のネットワークトラフィックを監視していた所、 ネットワークのトラフィックが膨れ上がっていました。 当初1プレイヤー当たり2kbps程度度、同接10000⼈人で20mbps前後と⾒見見込んでいたが 35mbps程度度になってしまっていた。 →通信処理理の最適化を⾏行行う必要有 ■ネットワークトラフィックの監視について iftopコマンドにて確認。 ※インストール⽅方法については割愛 30
  31. 31. ■ 1.3.負荷テストってどうやってるの? ■原因 パケットの送信間隔や量量に問題があるとし、解析した所、 通信プログラムがどこから呼ばれてるのかをエクセルに記述し、 ソートしてみた所、 位置情報の更更新のためのRPCが毎フレーム呼び出されており、 送信間隔に問題がある事が判明。 ■対策 毎フレームポーリングするのはやめて、 オブジェクトが⼊入⼒力力による移動や攻撃等、 変化があった際に通信を⾏行行うイベントドリブン形式に変更更を⾏行行った。 その結果、再テストを⾏行行うと通信量量がほぼ22mbps程度度に削減が出来、 ほぼ想定通りのトラフィックになった。 ■余談 モノビットエンジンでは、 エクセル等を⽤用いずとも、 通信関数の呼び出し回数等を出⼒力力できるようにするデバッグ機能を開発中です! 31
  32. 32. ■ 1.4.負荷分散の実例 ■負荷分散の考え⽅方 例例えばクラウドのインスタンスが8コアのマシンだった場合に、 マシンパワーを使い切切るには、 リアルタイム通信サーバのプロセスが8プロセス起動といった形で、 ポートを複数⽤用意し、コア数分だけ⽴立立ち上げると良良い。 ここから更更にマシンの台数を増やす事で冗⻑⾧長化も⾏行行う。 バトルサーバの振り分けについては、マッチングサーバ側で、 ラウンドロビンを採⽤用し⾃自然分散に期待する。 ■1マシン1ポートしか使えない場合の対策 複数サーバプロセスを⽴立立ち上げたものの、 グローバルのポートが⼀一つしか開放できないような場合は、 フロントエンドにクライアントからの接続を待ち受ける専⽤用のサーバプ ロセスを作成し、 そのサーバプロセスを介してマッチングサーバプロセスに接続させる。 モノビットエンジンでは、Relayサーバというサーバプロセスを⽤用意して おり、そちらを介して通信する事が可能。 32
  33. 33. ケース1.バトル後のレベルアップ処理理や戦利利品取得したらDBに書き込みたい →KVS等を経由してデータを受け渡す。 リアルタイム通信のゲームサーバでユーザーデータを DBに書き込みを⾏行行った際、 既存処理理が⾮非同期通信で作成された処理理だった場合、 タイミングによってはユーザーデータの不不整合が起きてしまう。 それを防ぐおすすめの⽅方法としては、 C++でなくWebサーバ側でDBに書き込みを⾏行行う⽅方法。 昨今のトレンドではRedisが良良く⽤用いられる。 C++⽤用のRedisクライアントを導⼊入しバトル終了了時に Redisにデータを 書き込む。 Webサーバ側で書き込んでデータを参照する。 ・C++ Redis Client https://osdn.jp/projects/sfnet_̲cpp-‐‑‒redis/ バトルの終了了時に、KVSへのデータ書き込みが終了了したら リアルタイム通信サーバからWebサーバに通知する。 その場合、libcurl を⽤用いてHTTP通信でリクエストする。 導⼊入も⾮非常に容易易なのでおススメ。 ・libcurl http://curl.haxx.se/libcurl/ ■ 1.5. Webサーバとの連携方法は? 33
  34. 34. ■ 1.5. Webサーバとの連携方法は? ケース2.バトルルームの情報をWebサーバから取得したい →モノビットエンジンのプラグインを利利⽤用。 リアルタイム通信ゲームサーバから情報を取得するための PHPやRubyのプラグインを提供している。 PHPはエクステンション、Rubyの場合は拡張ライブラリの形式。 インストール後、Apacheを再起動するだけで使⽤用可能。 RPCベースでリアルタイムサーバから情報を取得する事が可能。 34
  35. 35. ■ 1.6.どこのクラウドがおすすめなの? ■クラウドの選び⽅方 基本的にどこのクラウドを選んでも問題ない。 リージョンの場所次第。 AmazonやNiftyクラウドの場合、 海外にもリージョンがあるので、海外展開を検討しやすいのでは。 ■注意点 パブリッククラウドでの運⽤用経験がある⽅方の場合、 Microsoft Azuleは少々⽑毛⾊色が違う。 Webオンリーの構成を取る場合はAzuleはむしろ簡単。 AzuleはグローバルのIPアドレスが基本的に⼀一つとなっており、 グローバルネットワーク的に使い勝⼿手が違うので⼾戸惑うかもしれない。 ただしこれは、 他のOpenStackやVMWareをベースとしたパブリッククラウドと少々違う程度度。 ■モノビットエンジンでは? 国内⼤大⼿手クラウド全てで稼働実績があります。 Nifty、Amazon、IDCF、Azule 35
  36. 36. 36 第二部:リアルタイム通信エンジンの最新事情
  37. 37. 37 ■第二部もくじ 2,リアルタイム通信エンジンの最新事情 リアルタイム通信エンジンについて、 各社製品の特徴の違いや選び方などをお話します。 <アジェンダ> 1,Photonとモノビットエンジンの違いについて 2,リアルタイム通信サーバ製品の選び方
  38. 38. 38 1,Photonとモノビットエンジンの違いについて
  39. 39. 39 モノビットエンジンにお問い合わせを頂くお客様から、 「Photonとモノビットエンジンって、どう違うの?」 といつも質問を頂きますので、 ここでまとめて比較をしてみたいと思います。 ■Photonとモノビットエンジンの違いについて
  40. 40. 40 質問1:Photonとモノビットエンジンって仲が悪いの? 回答1:とっても仲良しです (棒読み) ■Photonとモノビットエンジンの違いについて
  41. 41. 41 ■Photonとモノビットエンジンの違いについて →嘘です、本当に仲良しです! 実は現場では仲が良く、下北沢で一緒にお酒を飲んだりしています。 (証拠写真) GMOクラウドの丸山さんは、Photon事業の総責任者をされています。 ゆきえさんは、Photonのマニュアルを英語から日本語へ翻訳されています。 モノビット本城 モノビット高橋 GMOクラウド 丸山さん (目が座っています) GMOクラウド ゆきえさん
  42. 42. 42 というわけで、本日のPhotonとモノビットエンジンの比較は、 GMOクラウドさんにも 「どうぞ自由にやってください!」と許可を頂きました! 後で丸山さんに怒られないよう、なるべく中立の視点で比較を 行いたいと思います。 ■Photonとモノビットエンジンの違いについて
  43. 43. 43 まずはPhotonについての概要 <特徴> ・ドイツ生まれの通信エンジン ・GMOクラウドさんが販売代理を行っている ・海外でも数多くの実績がある ・もともとゴルフの対戦ゲームを作っていて、 その通信エンジンを抜き出して提供し始めたものが起源(らしい) ・主に、PhotonRealtimeと、PhotonServerという2種類の製品がある ・PhotonRealtimeはクラウドサービスとして利用できる ・PhotonServerはWindowsサーバで動作する 注)PhotonTurnbase、PhotonChatなどの製品もあるようですが、 今回はリアルタイム通信がテーマなので割愛します。 ■Photonとモノビットエンジンの違いについて
  44. 44. 44 次に、モノビットリアルタイム通信エンジンについて <特徴> ・日本生まれの通信エンジン ・国内の有名タイトルで実績がある ・もともと本格的なオンラインゲームを作る目的で、 10年前から研究開発していた社内通信ライブラリを製品化したもの。 ・クラウドサービスは行っていない(今のところ) ・主にLinuxサーバで動作 ■Photonとモノビットエンジンの違いについて
  45. 45. 45 ■比較の前提 Photonには主に2つのリアルタイム通信製品がある。 →『PhotonRealtime』と、『PhotonServer』 1,PhotonRealtimeについて ・主にクライアント同士の通信をリレーする製品 ・マッチング機能とルーム(通信リレー)機能がある ・クラウドサービスとして提供されているため、サーバ立ち上げが不要 ・従量課金で、安価に使える ・ただし、サーバにはコードを書くことはできない。 →簡単にマッチングとP2P通信だけができればいい、というニーズに 合った製品。クラウド提供されているので、自分でサーバを立ち上げ なくても簡単に使える。 →ただし、サーバにゲームロジックを書くことはできないので、 利用シーンはクライアントtoクライアントのみの通信で成立する ゲームに限定される ■Photonとモノビットエンジンの違いについて
  46. 46. 46 ■比較の前提 2,PhotonServerについて ・サーバにコードを書くことができるサーバ製品 ・マッチングやルーム以外に、様々な機能を自分で書くことが出来る。 ・クラウドサービスは提供されていない ・カスタマイズ可能 ・Windowsサーバのみで動作 →サーバでも処理を行う、本格的なオンラインゲームを作りたい時に使う製品。 クラウド提供はされておらず、自分でサーバを用意しなければならない。 →『PhotonRealtime』と、『PhotonServer』について、 それぞれの製品の特徴がまったく違うので、製品ごとに、 モノビットリアルタイム通信エンジンと比較を行います。 ■Photonとモノビットエンジンの違いについて
  47. 47. 47 ■比較の前提 ・モノビットリアルタイム通信エンジンについて モノビットリアルタイム通信エンジンは、PhotonRealtimeのようなクラウドサービ スを提供していません。(今のところ) そして、PhotonServerとほとんど同じ特徴を持っています。 1,モノビットリアルタイム通信エンジンの特徴 ・サーバでコードを書くことができるサーバ製品 ・マッチングやルーム以外に、様々な機能を自分で書くことが出来る。 ・クラウドサービスは提供されていない ・カスタマイズ可能 ・Linuxサーバで動作 ■Photonとモノビットエンジンの違いについて
  48. 48. 48 ■比較の前提 それでは、それぞれ細かく見ていきましょう! 1,『PhotonRealtime』 vs  『モノビットリアルタイム通信エンジン』 →まずはここから! 2,『PhotonServer』 vs  『モノビットリアルタイム通信エンジン』 ■Photonとモノビットエンジンの違いについて
  49. 49. 49 1,PhotonRealtime vs  モノビットリアルタイム通信エンジン 項目ごとに比較表を作ってみました!! それでは、比較内容についてそれぞれ見ていきましょう。 ■Photonとモノビットエンジンの違いについて PhotonRealtime モノビットエンジン 同時接続性能 ○ ○ 通信速度性能 ○ ○ クラウドサービス ○ × 導入のしやすさ ◎ △ 実績の数 ◎ ○ ライセンス料 ○ ○ 運用コスト ○ ○ カスタマイズ × ◎ サポート体制 ○ ○
  50. 50. 50 1,PhotonRealtime vs  モノビットリアルタイム通信エンジン <同時接続性能> PhotonRealtimeは、接続数によって従量制で料金があがっていき、オートスケ ールする仕組みになっています。よって、接続数による制限や性能劣化はあり ません(のはず!) モノビットリアルタイム通信エンジンは、クラウド提供されていませんので、自分 でサーバの台数を増やすことで、いくらでもスケールが可能です。 <通信速度性能> 両製品とも、RTTは十数ms〜数十ms以内と、ほとんど同じ性能です。 →上記2点においては、どちらを選んでもそれほど大きな差はありません。 ■Photonとモノビットエンジンの違いについて PhotonRealtime モノビットエンジン 同時接続性能 ○ ○ 通信速度性能 ○ ○
  51. 51. 51 1,PhotonRealtime vs  モノビットリアルタイム通信エンジン <クラウドサービス> PhotonRealtimeは、機能をリレーとマッチングに限定する代わりに、クラウドサ ービスとして提供しています。 モノビットエンジンは、サーバにコードが自由に書けるため、サーバ負荷が予想 できないため、クラウド提供を行っていません。(PhotonServerと同じ) <導入のしやすさ> PhotonRealtimeは、クラウド提供されているため、ID登録するだけで、簡単に通 信のテストが行え、そのまま本番サーバとしても利用できます。 モノビットエンジンは、自分でサーバを立ち上げる必要があります。 (PC上でテストするだけなら、VMWareのイメージを配布しているので、簡単にテ ストは可能です) ■Photonとモノビットエンジンの違いについて PhotonRealtime モノビットエンジン クラウドサービス ○ × 導入のしやすさ ◎ △
  52. 52. 52 1,PhotonRealtime vs  モノビットリアルタイム通信エンジン <実績の数> PhotonRealtime(およびPUN)の実績に ついて、海外も含め合計で39タイトルが PhotonのHPにて公表されています。 (PhotonのHPより→) モノビットリアルタイム通信エンジンの採用実績は、 現在6タイトルで、すべて国内タイトルです。 (モノビットエンジンHPより→) ■Photonとモノビットエンジンの違いについて PhotonRealtime モノビットエンジン 実績の数 ◎ ○
  53. 53. 53 1,PhotonRealtime vs  モノビットリアルタイム通信エンジン <ライセンス料> <運用コスト> PhotonRealtimeは、同時接続が1000人 までで、月額33,766円だそうで、それ 以上の同時接続については、 お問い合わせ下さいとのことです。 モノビットエンジンは、サーバ1台あたり月額3万円です(ライセンスのみ)。 ただし、同時接続数に制限はありません。1サーバあたり同時接続数3000は 捌けますので、同時接続が2000を超えるなら、サーバ代込みでも、こちらの方 が安くなる可能性はあります。 同接1000以下なら、PhotonRealtimeの方が安価です。 ■Photonとモノビットエンジンの違いについて PhotonRealtime モノビットエンジン ライセンス料 ○ ○ 運用コスト ○ ○
  54. 54. 54 1,PhotonRealtime vs  モノビットリアルタイム通信エンジン <カスタマイズ> PhotonRealtimeは、 ・ルーム(※ゲームのこと)作成 ・ルーム検索(マッチング) ・ルーム内でのクライアント同士のリアルタイム通信 の3つの機能が提供されているのみで、これ以外のことは出来ません。 しかし、サーバロジックを利用しない、P2P型のゲームでは、上記3つの機能で 必要十分というケースも多くあり、必ずしも悪いという訳ではありません。 モノビットエンジンの場合は、マッチングサーバやルームサーバのサンプルが ソースコードごと提供されているため、自由に処理をカスタマイズすることがで きます(サーバにゲームロジックを書くことができます)。 ■Photonとモノビットエンジンの違いについて PhotonRealtime モノビットエンジン カスタマイズ × ◎
  55. 55. 55 1,PhotonRealtime vs  モノビットリアルタイム通信エンジン <補足> サーバにロジックを書けなくて困るシーンとは? コンシューマゲームによくある対戦機能のように、ワンボタンで簡単にマッチン グして、対戦が終わったらオフラインモードに戻ってくる、というゲームであれば 、PhotonRealtimeで提供されている機能で十分です。 しかし、たとえばファンタシーアースZEROのマップ画面 のような、対戦中の戦局や、各ルームに入っている人数 をリアルタイムに表示する画面を作りたい場合は、 PhotonRealtimeでは対応できず、モノビットリアルタイム 通信エンジンか、PhotonServerを利用して、独自の サーバロジックを記述する必要があります。 これ以外でも、複数ルームをまとめて管理したい場合や、サーバ側でルームの 戦局や戦績を管理する必要がある場合も、PhotonRealtimeでは対応できませ ん。 ■Photonとモノビットエンジンの違いについて
  56. 56. 56 1,PhotonRealtime vs  モノビットリアルタイム通信エンジン <サポート体制> PhotonRealtimeは機能も限定されており、 ドキュメントも日本語化されているため、 困ることはあまりなさそうです。 もし困っても、GMOクラウドのサポートスタッフが すぐに対応してくれる(はずです!) モノビットリアルタイム通信エンジンの場合は、 サポートスタッフだけでなく、エンジン開発技術者も日本にいるため、 質問に対しての1営業日以内の返答保証を行っています。 (ただし利用申し込みか、サポート契約をされている方のみとなります) ■Photonとモノビットエンジンの違いについて PhotonRealtime モノビットエンジン サポート体制 ○ ○
  57. 57. 57 1,PhotonRealtime vs  モノビットリアルタイム通信エンジン <まとめ> 1,PhotonRealtimeは、 導入の敷居の低さや、 クラウド提供の利便性が 最大の利点 2,提供されている機能のみ でゲームが作れるなら、 PhotonRealtimeを そのまま使うのが 一番早い。 3,ただし、サーバ側の カスタマイズができないので、 実現できない仕様があった場合は、 モノビットエンジンかPhotonServerを検討する必要がある。 ■Photonとモノビットエンジンの違いについて PhotonRealtime モノビットエンジン 同時接続性能 ○ ○ 通信速度性能 ○ ○ クラウドサービス ○ × 導入のしやすさ ◎ △ 実績の数 ◎ ○ ライセンス料 ○ ○ 運用コスト ○ ○ カスタマイズ × ◎ サポート体制 ○ ○
  58. 58. 58 1,『PhotonRealtime』 vs  『モノビットリアルタイム通信エンジン』 2,『PhotonServer』 vs  『モノビットリアルタイム通信エンジン』 →次はこちら!PhotonServerと比較してみます。 ■Photonとモノビットエンジンの違いについて
  59. 59. 59 1,PhotonServer vs  モノビットリアルタイム通信エンジン またまた項目ごとに比較表を作ってみました!! それでは、比較内容についてそれぞれ見ていきましょう。 ■Photonとモノビットエンジンの違いについて PhotonServer モノビットエンジン 同時接続性能 ○ ○ 通信速度性能 ○ ○ クラウドサービス × × 導入のしやすさ △ △ ライセンス料 ○ ◎ 実績の数 ◎ ○ 開発環境 VisualStudio gcc 使いやすさ ◎ △ カスタマイズ ○ ○ 運用コスト △ ◎ サポート体制 ○ ◎ 開発依頼 ー 可能
  60. 60. 60 1,PhotonServer vs  モノビットリアルタイム通信エンジン <同時接続性能> <通信速度性能> 1プロセスにおける同時接続性能は最大3000〜4000くらい (サーバ性能に依存)、 RTTは十数ms〜数十ms以内と、ほとんど変わりません。 <クラウドサービス> <導入のしやすさ> どちらもクラウドサービス(SaaS)は行っておらず、オンプレミス環境(もしくはお 客様が用意したクラウド上のサーバ)にインストールする前提の製品となります。 ■Photonとモノビットエンジンの違いについて PhotonServer モノビットエンジン 同時接続性能 ○ ○ 通信速度性能 ○ ○ クラウドサービス × × 導入のしやすさ △ △
  61. 61. 61 1,PhotonServer vs  モノビットリアルタイム通信エンジン <ライセンス料> PhotonServer、 モノビットエンジンともに、 ほとんど同じ料金体系です。 月額と、買い切りの2種類の ライセンスがあります。 PhotonServerは右図の通り。 (PhotonServerのHPより料金表を抜粋→) <要点> ・1サーバ月額約3万円 ・1サーバ買い切り約60万円 ・使い放題約33万円/月 ■Photonとモノビットエンジンの違いについて PhotonServer モノビットエンジン ライセンス料 ○ ◎
  62. 62. 62 1,PhotonServer vs  モノビットリアルタイム通信エンジン <ライセンス料> モノビットリアルタイム通信 エンジンは右図の通り。 (モノビットエンジンのHPより料金表を抜粋→) <要点> ・1サーバ月額約3万円 ・1サーバ買い切り約60万円 ・使い放題約26万円/月 使い放題の場合、モノビットリアルタイム通信エンジンの方が約7万円/月ほど お安くなっています。Photonさんと同じ値段にしたはずなんですが...円安で値上 がった?勘違いかも知れませんが、結果的にモノビットエンジンの方が 約25%も安くなってしまいました… また、ほとんどのお客様が「大規模向けライセンス」を選択されています。 ■Photonとモノビットエンジンの違いについて PhotonServer モノビットエンジン ライセンス料 ○ ◎
  63. 63. 63 1,PhotonServer vs  モノビットリアルタイム通信エンジン <実績の数> PhotonServerのHPには、国内外合わせて21タイトルの実績が掲載されていま す。 (PhotonServerのHPより→) モノビットリアルタイム通信エンジンの実績は現在6タイトルで、すべて国内タイ トルです。 (モノビットエンジンのHPより→) ■Photonとモノビットエンジンの違いについて PhotonServer モノビットエンジン 実績の数 ◎ ○
  64. 64. 64 ■Photonとモノビットエンジンの違いについて 1,PhotonServer vs  モノビットリアルタイム通信エンジン 最近の『PhotonServer』採用タイトル 最近の『モノビットリアルタイム通信エンジン』採用タイトル 両エンジンとも、続々と最新タイトルに採用されています。
  65. 65. 65 1,PhotonServer vs  モノビットリアルタイム通信エンジン <開発環境> PhotonServerはWindowsサーバで動作するため、開発環境はVisualStudioを利 用します。(使用言語は主にC#) モノビットエンジンはLinuxサーバで動作するため、gccやemacs、eclipseなどの OSS系の開発環境を利用します。(使用言語は主にC++で、C#も利用可能) ■Photonとモノビットエンジンの違いについて PhotonServer モノビットエンジン 開発環境 VisualStudio gcc
  66. 66. 66 1,PhotonServer vs  モノビットリアルタイム通信エンジン <使いやすさ> PhotonServerは、Windowsサーバ上の.Net Frameworkで動作するため、C#を自 在に利用することができます。 また、TCPとUDPをシームレスに利用することが出来ます。 モノビットエンジンは、LinuxサーバでC++言語でTCP通信を利用する前提で開発 されました。その後、C#対応とUDP対応を後付けで行ったため、C#を使ったり、 UDP通信を使う場合に、サーバ設計が若干いびつになってしまう欠点があります 。(しかし、何か実現できない機能がある、という訳ではありません) こちらは来年前半中にPhotonと同じくらい使いやすく改善する予定です。 ■Photonとモノビットエンジンの違いについて PhotonServer モノビットエンジン 使いやすさ ◎ △
  67. 67. 67 1,PhotonServer vs  モノビットリアルタイム通信エンジン <カスタマイズ> PhotonServer、モノビットエンジンともに、本格的なオンラインゲームを開発する ためのロビーやルーム、マッチング、ロードバランシングのサンプルなどが、ソースコ ードごと提供されており、サーバのゲームロジックを自由に記述することが出来ま す。 モノビットエンジンの場合は、VertialNetwork機能や、リレーサーバなども提供され ます。PhotonServerでも同様の機能が提供されている可能性がありますが、両エ ンジンとも、本格的なオンラインゲームの実績があるため、機能的に大きな差は ないと思われます。 このあたりは今度Photonさんと一緒に掘り下げてみたいところです。 ■Photonとモノビットエンジンの違いについて PhotonServer モノビットエンジン カスタマイズ ○ ○
  68. 68. 68 1,PhotonServer vs  モノビットリアルタイム通信エンジン <運用コスト> PhotonServerはWindowsサーバを利用する必要があるため、OSのライセンス費用がかかってきます。 モノビットエンジンはLinuxサーバで動作するため、OSのライセンス費用がかかりません。 1,AmazonEC2 東京リージョンのオンデマンドインスタンス価格で比較すると... c4.large(2コア)の場合、Linuxは$0.14  /1  時間、Windowsは$0.24  /1  時間となり、インフラコストは1.7倍。 2,AmazonEC2 バージニア北部リージョンのオンデマンドインスタンス価格で比較すると... m4.4xlarge(16コア)の場合、Linuxは$1.008  /1  時間、Windowsは$2.016  /1  時間となり、インフラコストは2倍。 AWSの場合、LinuxとWindowsのコスト差は、最小1.3倍から最大2倍になりました。 Azureでも、1コアの場合は同価格になるものの、8コア以上だとやはり約1.5倍ほどの差になります。 Linuxサーバの方が、インフラコスト的には圧倒的な優位性があります。 ■Photonとモノビットエンジンの違いについて PhotonServer モノビットエンジン 運用コスト △ ◎
  69. 69. 69 1,PhotonServer vs  モノビットリアルタイム通信エンジン <サポート体制> PhotonServerの場合、GMOクラウドの方が大変頑張って サポートしてくれます! 技術的な質問も、開発元のドイツ本国に問い合わせてくれるようです。 モノビットエンジンは、エンジン本体も日本で開発を行っているため、 日本人のサポートスタッフが1営業日以内の返答を保証しています。 (ただし、利用申し込みをされた方か、サポート契約をされている方のみ) ※無料利用中の方は、facebookのモノビットエンジン助け合い助でサポートしています。 また、緊急の問題が発生した際に、エンジンの開発エンジニアが お客様のオフィスに伺ってサポートを行うこともやっています。 ■Photonとモノビットエンジンの違いについて PhotonServer モノビットエンジン サポート体制 ○ ◎
  70. 70. 70 1,PhotonServer vs  モノビットリアルタイム通信エンジン <モノビットエンジンのオンサイトサポートの実例> (お客様) リリース後、リアルタイム通信を行っているサーバの負荷が どうしても下がらないので、なんとか見てくれないか? →緊急対応が必要な依頼だったため、モノビット社のエンジニアが 2週間にわたって先方オフィスへ常駐し、ゲームアプリ側の プログラムも含めてデバッグと負荷対策を実施。 バグを取り除きつつ、 エンジン本体内にもチューニングを施して、 高負荷問題を解決。 ■Photonとモノビットエンジンの違いについて PhotonServer モノビットエンジン サポート体制 ○ ◎
  71. 71. 71 1,PhotonServer vs  モノビットリアルタイム通信エンジン <開発依頼> エンジンの機能とは関係ありませんが、モノビットには、ミドルウェア部門以外にも、ゲーム制作部門が あり、数十名のエンジニアが在籍し、実際に自分たちでもリアルタイム通信を用いたゲームを開発して います。 そのため、ただ単にエンジンを提供するだけでなく、 ・リアルタイム通信エンジンに、こんな機能を追加してほしい ・リアルタイム通信サーバの設計開発の一部を手伝って欲しい。 などのニーズにも答えることが出来ます。 例1)チャットサーバに監視機能を追加して欲しい。 →開発案件として、チャットサーバ用GMツールを開発、納品しました。 例2)Webサーバとリアルタイム通信の連携プラグインを開発してほしい →開発案件として、プラグインを開発、納品しました。 例3)リアルタイム通信サーバの詳細設計をすべて依頼したい →開発案件として、通信サーバの詳細設計を行い、納品しました。 ■Photonとモノビットエンジンの違いについて PhotonServer モノビットエンジン 開発依頼 ー 可能
  72. 72. PhotonServer モノビットエンジン 同時接続性能 ○ ○ 通信速度性能 ○ ○ クラウドサービス × × 導入のしやすさ △ △ ライセンス料 ○ ◎ 実績の数 ◎ ○ 開発環境 VisualStudio gcc 使いやすさ ◎ △ カスタマイズ ○ ○ 運用コスト △ ◎ サポート体制 ○ ◎ 開発依頼 ー 可能 72 1,PhotonServer vs  モノビットリアルタイム通信エンジン <まとめ> ■モノビットエンジンを選ぶ理由 1,Linuxサーバを使いたい 2,ライセンス料やインフラコストを抑えたい 3,日本人開発者による即日&オンサイトの サポートを受けられる安心感 4,サーバの設計や開発を発注したい ■PhotonServerを選ぶ理由 1,Windowsサーバを使いたい 2,VisualStudioでサーバを開発したい 3,実績が多いソリューションを使いたい そのほか、実際に使ってみたり、担当者の話を聞いてみて、 気に入った方を選択されるのが良いかと思います。 ■Photonとモノビットエンジンの違いについて
  73. 73. 73 ■次回について 実は、今回のPhotonとモノビットエンジンの比較について、 GMOクラウドさんに「一緒にやりましょう!」とお声がけしたのですが、 「たまたま翌週にコロプラさんと勉強会やる予定なので、準備がちょっと...」 という理由で、残念ながら断られてしまいました。 ただ、「来年の春頃にはぜひ!」と話をしています。次回はPhotonさんと合同で もう一歩踏み込んだ「リアルタイムサーバ勉強会」を開催したいと思っていますの で、どうぞ楽しみにしていてください! Photonさんも、来週コロプラさんと一緒に サーバ勉強会を開催されるそうなので、 興味のある方は是非!→ (しかし既に満席のようです…) ■Photonとモノビットエンジンの違いについて
  74. 74. 74 <おわび(T-T)> ATNDで下記のアジェンダを告知していましたが、 Photonとモノビットエンジンの比較だけで大ボリュームになってしまっ たのと、下記アジェンダだけでも1時間くらい語れるボリュームになっ てしまったので、今回は割愛して、後日それぞれ勉強会を開催させ ていただきます。 ・Unity、UnrealEngineなどのゲームエンジンと通信エンジンの組み 合わせ方 ・自社でオリジナルの通信エンジンを作ってみる? ・通信エンジン界隈の今後の予想図 期待されていた方、大変申し訳ございませんでした…  osz ■ 最後に
  75. 75. 75 <アンケートのお願い> よろしければ、次回の勉強会をより良くするため、 アンケートに答えて頂けると嬉しいです! また、モノビットエンジンの話を個人的に詳しく聞きたい方は、 お名刺を席に置いていって頂くか、アンケートに連絡先を ご記入ください。 後日、こちらよりご連絡させて頂きます。 本日はどうもありがとうございました!! ■ 最後に(その2)

×