CEDEC 2015 IoT向け汎用protocol MQTTのリアルタイムゲーム通信利用と実装、そして未来へ…

CEDEC 2015 IoT向け汎用protocol MQTTのリアルタイムゲーム通信利用と実装、そして未来へ…

1. 1. Copyright Drecom Co., Ltd. All Rights Reserved. 1 IoT向け汎用protocol MQTTの リアルタイムゲーム通信利用と実装、 そして未来へ… 株式会社ドリコム 川上知成 市川毅明
2. 2. Copyright Drecom Co., Ltd. All Rights Reserved. 2 講演者紹介 テクノロジー本部 研究開発部長 • 川上 知成 – 技術調査 – PM ・TD レビュー 同部 • 市川 毅明 – アーキテクト – ゲーム・汎用基盤開発
3. 3. Copyright Drecom Co., Ltd. All Rights Reserved. 3 本セッションの概要 • 弊社 崖っぷちバスターズ®でリアルタイム 通信4人協力バトルの実現に、MQTT protocolを採用 • インターネット時代における通信技術の トレンドとともに採用に至った選定過程、 クライアント／サーバー実装やインフラ 構成などを紹介 受講者が得られるであろう知見： • 技術採用プロセス事例 • リアルタイム通信 ゲームクライアント・サーバー開発技術・手法 • OSS技術の活用方法
4. 4. Copyright Drecom Co., Ltd. All Rights Reserved. 4 目次 1. ネットワークゲームの近年の流れについて 2. インターネットモバイルリアルタイム ゲームを実現する課題 3. 弊社事例：崖っぷちバスターズ® 1. 通信技術選定 2. MQTTとは 3. 実装について 1. 全体概略 2. サーバー実装概略 3. アプリケーション実装 4. 考察 5. そして未来へ…
5. 5. Copyright Drecom Co., Ltd. All Rights Reserved. 5 IoTとは？
6. 6. Copyright Drecom Co., Ltd. All Rights Reserved. 6 IoT ＝Internet of Things IoT 背景 デバイスの進化 ネットワーク技術の進化 ゲーム スマートフォン クラウド上での運営
7. 7. Copyright Drecom Co., Ltd. All Rights Reserved. 7 ネットワークゲーム 近年の流れについて
8. 8. Copyright Drecom Co., Ltd. All Rights Reserved. 8 ネットワークゲーム • 2000年前後 – アーケード：店舗間専用線 – パソコン通信、インターネット – MO/MMORPGの誕生 • 2010年頃以降 – 高速インターネット環境 Gbps – MO/MMORPGの普及と多様化 – eSports 誕生 – モバイルゲームの一般化
9. 9. Copyright Drecom Co., Ltd. All Rights Reserved. 9 モバイルの潮流 • 通信環境： – 従量課金 – パケット定額 – ブロードバンド普及 wifi通信の利用促進 – 3G/4Gの誕生 →常時接続通信が可能に • 携帯モバイルゲーム – カジュアル・ミニゲーム – webソーシャルゲーム – Nativeソーシャルゲーム →携帯モバイルゲームの一般化 常時通信×携帯モバイルゲームが進化 →リアルタイム体感へ
10. 10. Copyright Drecom Co., Ltd. All Rights Reserved. 10 インターネットモバイル リアルタイムゲームを 実現する課題
11. 11. Copyright Drecom Co., Ltd. All Rights Reserved. 11 課題 • 通信環境 • 実装手法 • インフラ環境
12. 12. Copyright Drecom Co., Ltd. All Rights Reserved. 12 通信環境 • 回線速度 業務用∼家庭用∼移動通信（3G/4GLTE） 例:10Gbps超∼数G - 100MB∼70- 20 MB – 理論値と実測値 – 不安定 • 帯域保証 • 物理的な干渉・回折 • 移動体通信網とWifiの混在 →転送頻度/データ量の考慮
13. 13. Copyright Drecom Co., Ltd. All Rights Reserved. 13 実装手法 • protocol： リアルタイム通信の特殊性 – UDP / TCPなど通信protocol の選択/設計 – Data Format / Payload 設計 • 実装効率： ゲームという専門性ó汎用性 – 設計はゲームロジックによるアプリ毎様々
14. 14. Copyright Drecom Co., Ltd. All Rights Reserved. 14 インフラ環境 • インフラ環境の変化： – 専用線＋オンプレミス – インターネット＋オンプレミス – インターネット＋IaaS／Paasクラウド • 技術課題 – Load Balancing – NAT超え – 爆発的なユーザ増加に合わせた受け入れ →可用性・冗長性
15. 15. Copyright Drecom Co., Ltd. All Rights Reserved. 15 弊社事例： 崖っぷちバスターズ ®
16. 16. Copyright Drecom Co., Ltd. All Rights Reserved. 16 崖っぷちバスターズ® ご紹介 崖っぷちバスターズ®は、壁を壊して、敵を崖から突き落す、新感覚のぶっ 放し協力バトルゲームです。GPS連動したエリアバトルでスコアランキング を競い、エリアNo.1になることで、そのエリアを制圧しながら拡大していくこ とができます。また、最大4人で遊べるマルチプレイ機能を搭載!仲間と連 携して必殺技を繰り出せば、敵に大ダメージを与えることができます。手に 汗握るバトルが繰り広げられる、「みんなで遊べるゲーム」の決定版です。
17. 17. Copyright Drecom Co., Ltd. All Rights Reserved. 17 ゲームの特徴 <通信> • シングルプレイ – Web API通信を中心に構成 – バトルはスタンドアローン • マルチプレイ – バトルはリアルタイム通信を行い、 最大4名の複数プレイヤーが１つの バトルセッションで協力プレイ
18. 18. Copyright Drecom Co., Ltd. All Rights Reserved. 18 開発基盤Bisque Bisqueにて開発 Copyright Drecom Co., Ltd. All Rights Reserved. 28 Bisque! Bisque ! JNIObjecGve'C++!
19. 19. Copyright Drecom Co., Ltd. All Rights Reserved. 19 通信技術選定
20. 20. Copyright Drecom Co., Ltd. All Rights Reserved. 20 通信技術選定の背景 弊社観点 • 強み – WebAPIを中心のサーバー/クライアント資産 – クラウド利用実績 • 弱み – リアルタイムサーバー・クライアント構築 – リアルタイム通信ゲーム制作
21. 21. Copyright Drecom Co., Ltd. All Rights Reserved. 21 リアルタイム通信 実現に向けて ⃝方針 – 実現スピード重視 既存技術を活用し、工期短縮 – ゲーム仕様実現に焦点 ⃝ゲーム仕様 – 1Room 4名のターン制 ⃝技術要件 – リアルタイム性→同期通信 – 同期性の担保 レイテンシー：最大1秒目標 クライアントにHostを立て、 サーバはメッセージの同期のみ クライアント側ではメッセージを元に再現 プロトを経て
22. 22. Copyright Drecom Co., Ltd. All Rights Reserved. 22 技術検討
23. 23. Copyright Drecom Co., Ltd. All Rights Reserved. 23 技術検討の一部 • http polling • websocket • Socket.io • MQTT • Platform機能 • 商用エンジン • 選定観点 – Protocol – Server実装 – Client実装 – ライセンス 総合的に評価 MQTT案ベースに詳細検討
24. 24. Copyright Drecom Co., Ltd. All Rights Reserved. 24 Client 検証フェーズ 検証 仮実装 本実装 結合 β ■MQTT案 Game イ ン フ ラ ミドルウェア選定 単体負荷試験 クラウド選定 構成設計 ブラッシュアップ 実データ負荷テスト 組み込みテスト α→機能洗い出し 仕様検証 基本ライブラリ選定 ライブラリ実装 チューニング 単体検証 仕様ブラッシュアップ 組み込み実装
25. 25. Copyright Drecom Co., Ltd. All Rights Reserved. 25 MQTTとは?
26. 26. Copyright Drecom Co., Ltd. All Rights Reserved. 26 MQTTとは MQTT(MQ Telemetry Transport) • MQTTとは、publish/subscribeモデルに基づ くメッセージプロトコル • 低速・不安定なネットワークで動作するための 機能や非力なデバイスで動くための軽量化、同 期通信な点などが特徴 • 事例： Facebook Messenger など各種Chat
27. 27. Copyright Drecom Co., Ltd. All Rights Reserved. 27 歴史 1999年よりIBMが主導で商用製品提供も 2011年 Eclipse Foundationへコード寄贈 2013年 OASIS 国際標準化団体で標準化へ ・・・ 発展途中 ・・・ Ø 近年ではサービス提供事業者も Ø Protocol仕様はロイヤリティフリー Ø サーバー/クライアント実装複数
28. 28. Copyright Drecom Co., Ltd. All Rights Reserved. 28 特徴 • 軽量：固定ヘッダーは2byte, Payload: Max256MB • Topic：送受信先. 階層構造 • QoS: • Will • Retain • CleanSession ※TCP Connection NAT配下でも問題なく動作。 0:At  most  once 1:At  least  once 2:  Exactly  once
29. 29. Copyright Drecom Co., Ltd. All Rights Reserved. 29 概要：Pub/Subモデル MQTT Broker publisher Subscriber Topic例： /cedec/2015/room315/iot /cedec/2015/room315/gameengine /cedec/2015/room315/# /cedec/2015/+/iot A B C D A B A B C A D
30. 30. Copyright Drecom Co., Ltd. All Rights Reserved. 30 実装について
31. 31. Copyright Drecom Co., Ltd. All Rights Reserved. 31 実装について マルチプレイバトルにおける • 全体概略 • サーバー実装概略 • アプリケーション実装
32. 32. Copyright Drecom Co., Ltd. All Rights Reserved. 32 全体概略
33. 33. Copyright Drecom Co., Ltd. All Rights Reserved. 33 MQTT  Cluster BackEnd全体構成 Draft internet Client    pub  /  sub  /  http(rest) LB  (MQTT) LB(web)LB  (HTTP) Web/ AP Web/ AP Web/ APWeb/ AP KVS DBDBKVS Reverse-­‐Proxy MQTT  Broker REST Worker MQTT  BrokerMQTT  BrokerMQTT  Broker direct  routing ※検討当時資料
34. 34. Copyright Drecom Co., Ltd. All Rights Reserved. 34 BackEnd構成概略 internet Client    pub  /  sub  /  http(rest) LB(web) Web/ AP Web/ AP Web/ APWeb/ AP KVS DB MQTT  BrokerMQTT  BrokerMQTT  BrokerMQTT  Broker direct  routing ※検討当時資料
35. 35. Copyright Drecom Co., Ltd. All Rights Reserved. 35 利用方法概略 • MQTT Broker Serverを BattleInstanceServerの位置づけで利用。 • Broker Serverの利用： – Topic Room – Room管理はAPIServer制御 – Broker ServerよりMessageを配信 – QoS 再現性/信頼性コントロール
36. 36. Copyright Drecom Co., Ltd. All Rights Reserved. 36 サーバー実装概略
37. 37. Copyright Drecom Co., Ltd. All Rights Reserved. 37 Room MQTT Broker Web AP MQTT Broker MQTT Broker … 同期接続(mqtt) 非同期接続(http) Room Matching Game Client マルチプレイバトルの接続イメージ
38. 38. Copyright Drecom Co., Ltd. All Rights Reserved. 38 MQTT Broker Game Host Client １ 同期接続(mqtt) 非同期接続(http) Room Guest Client ２ Guest Client ３ Guest Client ４ バトルターンのイメージ SessionMasterとして 同期委譲管理 Web/AP
39. 39. Copyright Drecom Co., Ltd. All Rights Reserved. 39 WebAPIサーバー • マッチング処理： – ロビーにてマッチング処理(非同期) – ルーム管理: 作成,メンバーJOIN/CANCEL,中断/再開,終了,破棄
40. 40. Copyright Drecom Co., Ltd. All Rights Reserved. 40 WebAPIサーバー • Clientが接続する Broker Serverを選定しBalancing • ノード死活監視、cacheリスト化 • リストから Least connections で接続
41. 41. Copyright Drecom Co., Ltd. All Rights Reserved. 41 BrokerServer選定 • 検証観点 – １台あたりの性能・コストパフォーマンス最 大化を重視 – 高負荷時の安定性 • 最終候補 – Mosquitto →シングルスレッド、クラスタ無し(要自作) – RabbitMQ with MQTT Plugin →マルチスレッド、クラスタ有り(要検証)
42. 42. Copyright Drecom Co., Ltd. All Rights Reserved. 42 BrokerServer開発 • RabbitMQ with MQTT Plugin利用 – MQTT自体仕様のみで実装はプロダクト依存 – 不足機能の実装例 • topicの制限や禁止 • Payload Size制限 • Client操作の制限(Server設定値) • Queues expire化 • MQTT向けのlogging 言語: erlang
43. 43. Copyright Drecom Co., Ltd. All Rights Reserved. 43 BrokerServer構成について • 構成案 – Broker Standalone Parallel – Broker Clustering ※一部課題あり：Performance劣化等 • 仕様の割り切り – Cloudの性質上可用性には限界あり – FailOverの検知復旧時間と体感待ち時間とのト レードオフ →Standaloneで利用
44. 44. Copyright Drecom Co., Ltd. All Rights Reserved. 44 BrokerServer ScaleOut • Standaloneのためインスタンス増設で ScaleOut • AWSを利用しAutoScalingを実現 – CPU使用率監視 • 研究としてスポットインスタンス利用すること でコスト圧縮も可能 – 手法詳細はslideshareにて。 http://www.slideshare.net/GedowFather/gedow-­‐style-­‐aws-­‐spot-­‐instance
45. 45. Copyright Drecom Co., Ltd. All Rights Reserved. 45 アプリケーション編
46. 46. Copyright Drecom Co., Ltd. All Rights Reserved. 46 MQTTクライアント選定
47. 47. Copyright Drecom Co., Ltd. All Rights Reserved. 47 MQTTクライアント選定 • フルスクラッチから書く • Paho Embedded • Mosquitto 調査の結果この3点が候補に挙がりました
48. 48. Copyright Drecom Co., Ltd. All Rights Reserved. 48 フルスクラッチから書く • 全部自分で作る • 全部自分で作るので比類無き自由度 • 全部自分で作るので工数爆発 • (実は30%位作った)
49. 49. Copyright Drecom Co., Ltd. All Rights Reserved. 49 paho • Eclipse Foundation謹製 • ANSI Cで書かれ、データ処理だけを提供する ので移植性と実装の自由度が高い • 通信部分は自力で実装する必要あり
50. 50. Copyright Drecom Co., Ltd. All Rights Reserved. 50 Mosquitto • 古くからあるMQTTブローカー • コア部分がlibmosquittoとして分離されており、 単体のMQTTクライアント/サーバーライブラ リとして利用可能 • リッチな高レベルAPIが揃っている
51. 51. Copyright Drecom Co., Ltd. All Rights Reserved. 51 MQTTクライアント選定 検証の結果、Mosquittoを選定 • Cで書かれておりコンパクト • コードが綺麗で読みやすい(もしもの時に重要) • 外部ライブラリ依存が皆無 • BSDソケットさえあれば何処でも動く
52. 52. Copyright Drecom Co., Ltd. All Rights Reserved. 52 Mosquittoの難点 • BSDソケットを使っているが、iOSで動作が怪 しいヶ所が多数 • pthreadを使っているがiOS/Androidで未実装 の関数(排他周り)を多数使用 • 他にも色々と･･･(主にシステムコール周り)
53. 53. Copyright Drecom Co., Ltd. All Rights Reserved. 53 内製ライブラリ”Bisque” Thread/Socket周りを クロスプラットフォーム基盤として開発している ”Bisque”を利用した置き換え実装を行いました
54. 54. Copyright Drecom Co., Ltd. All Rights Reserved. 54 内製ライブラリでの解決 • Socket/pthreadの弊社ライブラリBisqueで置き換え を実施 • ただし、Mosquittoのソースには手を加えない -> includeオーバーライド + Redefineリューション! // ライブラリビルド時に定義 #define pthread_create BQ_compat_pthread_create #define pthread_join BQ_compat_pthread_join #define pthread_cancel BQ_compat_pthread_cancel
55. 55. Copyright Drecom Co., Ltd. All Rights Reserved. 55 Bisqueの紹介
56. 56. Copyright Drecom Co., Ltd. All Rights Reserved. 56 内製ライブラリ”Bisque” • ソースコードレベルでクロスプラットフォームを実現 する為のライブラリ群 • スマホからサーバーまで、対応可能なプラットフォー ムのAPIを抽象化 • ゲームエンジンや他処理系への組み込みを意識し、 可能な限りプリミティブに設計
57. 57. Copyright Drecom Co., Ltd. All Rights Reserved. 57 内製ライブラリ”Bisque” 同一ソース群から3エディションが存在します Bisque  Workstation  Edition(PC版) Bisque Bisque  Datacenter  Edition(サーバー版)
58. 58. Copyright Drecom Co., Ltd. All Rights Reserved. 58 サウンド用I/F OpenAL OpenSL /dev/audioXaudio2 下回りの実装は最適 なAPIを選択 アプリ開発者にはプラッ トフォームを意識させな い
59. 59. Copyright Drecom Co., Ltd. All Rights Reserved. 59 One  and  Half  設計
60. 60. Copyright Drecom Co., Ltd. All Rights Reserved. 60 柔軟な上部 (ゲームエンジンやアプリ) 強靭なでシンプル設計 の根元 (抽象化レイヤー)
61. 61. Copyright Drecom Co., Ltd. All Rights Reserved. 61 サーバー(Ruby) クライアント Bisque  アーカイブモジュール Bisque  アーカイブモジュール 全く同じコードから生成されるので 完全互換のデータ持ち回りを実現
62. 62. Copyright Drecom Co., Ltd. All Rights Reserved. 62 ・Windows  Phone  8 ・Windows  10  Mobile ・iOS ・Android ・Tizen 対応プラットフォーム(2015/08  現在) スマートフォン PC系 ・Windows  Vista以降(i386/amd64/ARM) ・Solaris  8以降 ・Linux  (kernel  2.6.32以降) ・MacOS 10.5以降(PPCもOK!) ・OpenVMS  (Alpha) ・*BSD
63. 63. Copyright Drecom Co., Ltd. All Rights Reserved. 63 崖っぷちバスターズ®での事例紹介
64. 64. Copyright Drecom Co., Ltd. All Rights Reserved. 64 Topicの構造 ROOM/ Common System Private Host “部屋”に対して4つのTopicがぶら下がる構造 この構造がセッション毎に作られる
65. 65. Copyright Drecom Co., Ltd. All Rights Reserved. 65 Topicの構造 System Private Host Topicを分ける事でメッセージフィルターを実現 メッセージの振り分けをシステムに任せる ROOM/ Common
66. 66. Copyright Drecom Co., Ltd. All Rights Reserved. 66 Topicの構造 Common ホストからのゲストへのメッセージ配信用 ゲストプレイヤーがSubscribe System システムメッセージ用 全員がSubscribe Private ゲストへの個別メッセージ用 各員がPrivate/<プレイヤーID>にSubscribe Host ホストプレイヤーへのメッセージ用 ホストがSubscribe
67. 67. Copyright Drecom Co., Ltd. All Rights Reserved. 67 Topicの構造 Commonホスト ゲスト ゲスト 例：ホストプレイヤーからのメッセージ配信 ホストはpubだけ(subしない) ゲストはCommonにSub
68. 68. Copyright Drecom Co., Ltd. All Rights Reserved. 68 Topicの構造 System ホスト ゲスト ゲスト 例：全体への配信 全員がSubscribe
69. 69. Copyright Drecom Co., Ltd. All Rights Reserved. 69 Topicの構造 Host ホスト ゲスト ゲスト 例：相互死活判定(ライブパケット) ゲストはHostにPub
70. 70. Copyright Drecom Co., Ltd. All Rights Reserved. 70 Topicの構造 Private/ゲストIDホスト ゲスト 例：相互死活判定(ライブパケット) ホストは送信元のゲストに返信Pub
71. 71. Copyright Drecom Co., Ltd. All Rights Reserved. 71 Pub/sub ・Topicを分ける、Subscribeする物を選ぶ事で必要なメッセー ジだけを受信する事が出来る ・SubscribeしたTopicのメッセージは全て飛んでくるので自分 でPublishした物も受信してしまう ・Pub専用、Sub専用、Pub/Sub両用を使い分ける事により細 かいメッセージ制御が可能
72. 72. Copyright Drecom Co., Ltd. All Rights Reserved. 72 QoS ・崖っぷちバスターズ®ではQoS0とQoS1を使用 ・欠損しても影響の無いデータはQoS0 ・欠損が許されないデータはQoS1
73. 73. Copyright Drecom Co., Ltd. All Rights Reserved. 73 QoS 矢印のモーション等 アバウトに扱って問題の無い データはQoS0で送信
74. 74. Copyright Drecom Co., Ltd. All Rights Reserved. 74 QoS 必殺技発動 衝突等 進行に絡むデータはQoS1
75. 75. Copyright Drecom Co., Ltd. All Rights Reserved. 75 タップ〜ヒットまでのpub タップ 移動・スワイプ ヒット QoS1のメッセージさえ届けばゲームが成立するように設計 QoS1 QoS0
76. 76. Copyright Drecom Co., Ltd. All Rights Reserved. 76 その他 ・pubの量を減らす為、メッセージにプライオリティーを 付け即時送信する必要の無いデータはバッファリン グしてから塊で送信 ・QoS1でクリティカルな物には返信要求ビットを立て、再送さ せるメカニズムを作成 ・これにより1ゲーム2000アクションで100pub、総通信量を 100KB程度に抑える事に成功
77. 77. Copyright Drecom Co., Ltd. All Rights Reserved. 77 セキュリティー
78. 78. Copyright Drecom Co., Ltd. All Rights Reserved. 78 セキュリティー MQTT  over  SSLという便利なソリューションがあります
79. 79. Copyright Drecom Co., Ltd. All Rights Reserved. 79 Mosquittoで構築したサーバーにSSL有無で1000回pub (とあるAndroid  スマートフォン) セキュリティー pubだけでSSL無しの約10倍 該当端末ではゲームに支障を来す可能性も 星の数程あるAndroid端末では同じ現象が起きる端末の存在を否 定できない SSL無し SSL 一部 Android端末でSSLが遅い！
80. 80. Copyright Drecom Co., Ltd. All Rights Reserved. 80 “Bisque”難読化ライブラリ採用 • 通信の難読化には弊社タイトルで実績のある内製難読化 ライブラリを採用 • 改竄防止が主な目的なので本格的な暗号は必要ない • ゲームで3タイトル、その他アプリでも利用されています(本 当にクリティカルなデータはSSLを使用) • アルゴリズムは複数ありますが、今回は128bitブロックの 物を採用(送信データはほぼ1ブロックに収まる)
81. 81. Copyright Drecom Co., Ltd. All Rights Reserved. 81 難読化ライブラリのチューニング 1024バイトの文字列を1000回難読->復号を繰り返した結果 チューニン グ前 チューニン グ後 高速性には定評があるが、リアルタイム通信での使用 に耐える為、対応アーキテクチャー全てでベクタライズ を中心とした徹底的ハンドオプティマイズを実施
82. 82. Copyright Drecom Co., Ltd. All Rights Reserved. 82 その結果・・・ • AES128(弊社はUnityで利用)より250倍速く • 前バージョン比8000%高速化 • (コード行数50倍) AES128 チューニン グ前 チューニン グ後
83. 83. Copyright Drecom Co., Ltd. All Rights Reserved. 83 データ構造 • 高速でコンパクト • Protocol BuffersよりもプリミティブなAPI • サーバー側(スクリプト言語)との相互運用に優れる 通信内容はmsgpackを採用
84. 84. Copyright Drecom Co., Ltd. All Rights Reserved. 84 データ構造 MQTTではプリミティブなデータが飛び交うので 通信内容のコンテナ化を実施しました ヘッダー 実際のデータ(msgpack) 付帯 データ ※何かに似てますが、“それ”とは違います
85. 85. Copyright Drecom Co., Ltd. All Rights Reserved. 85 データ構造 複数のデータを固めて飛ばす可能性を考え チェーン構造を取れるように設計 ヘッダー データ 付帯 データ ヘッダー データ 付帯 データ
86. 86. Copyright Drecom Co., Ltd. All Rights Reserved. 86 データ構造 難読化 このデータを難読化して送受信します ※1000レコード連結した実際のデータをビットマップにしています
87. 87. Copyright Drecom Co., Ltd. All Rights Reserved. 87 データ構造 シンプルに汎用性を高く設計したため、セーブ データやHTTP通信のデータコンテナとしても採 用されました
88. 88. Copyright Drecom Co., Ltd. All Rights Reserved. 88 テスト • 地下鉄(接続が頻繁に切り替わる) • 社内スマホ用Wi-Fi(昼休みに不安定) • ヴィンテージWi-Fiルーター(パケット損失多発) • 激しい帯域制限を掛けたVPN • 居酒屋 • 野外 実際にプレイされる環境を想定した検証を実施
89. 89. Copyright Drecom Co., Ltd. All Rights Reserved. 89 崖っぷちバスターズ®の目玉要素、陣取りの為に 特殊なテストも実施しました
90. 90. Copyright Drecom Co., Ltd. All Rights Reserved. 90 野外テストの模様
91. 91. Copyright Drecom Co., Ltd. All Rights Reserved. 91 こんな場所です
92. 92. Copyright Drecom Co., Ltd. All Rights Reserved. 92 悪条件野外テスト(洋上)
93. 93. Copyright Drecom Co., Ltd. All Rights Reserved. 93 ゲストプレイヤーが船酔いに・・・
94. 94. Copyright Drecom Co., Ltd. All Rights Reserved. 94 悪条件野外テスト(高速助手席)
95. 95. Copyright Drecom Co., Ltd. All Rights Reserved. 95 わかった事 • LTE〜3G〜圏外を繰り返す洋上でも再接続するとBrokerが保持している限りQoS1のメッセー ジが飛んでくるのでゲームが成立する • Willは、通信速度が極端に不安定になる悪天候の川沿いでpingに答えられないケースが多数 (これに関してはサーバー依存の可能性も有り) • 利根川の高圧線の下では切断多発でゲームにならないのでやめてください(iOS) • クライアント側で実装しなくてもメカニズムでカバーしてくれるMQTTの洋上での可用性は救世 主クラス！ • 特殊な環境でのプレイテストは机上や疑似環境では起こらないナチュラルなトラブルが発生 するので、是非やりましょう
96. 96. Copyright Drecom Co., Ltd. All Rights Reserved. 96 今後について BisqueのTCP周りはIPv6に対応済みなので今 後も踏まえてPaho Embeddedに移行予定です
97. 97. Copyright Drecom Co., Ltd. All Rights Reserved. 97 考察
98. 98. Copyright Drecom Co., Ltd. All Rights Reserved. 98 考察 • MQTT BrokerServerを選択し、リアリ タイム通信ならびにターン制ゲーム実装 はゲーム仕様マッチのため可能。 • MQTT protocolやBrokerServerにも課 題はあり、要継続改善。
99. 99. Copyright Drecom Co., Ltd. All Rights Reserved. 99 そして未来へ…
100. 100. Copyright Drecom Co., Ltd. All Rights Reserved. 100 選定技術の今後について • RabbitMQ with MQTT利用 – erlangによる実装知見 – 今後の発展型： ターンベース→MO/MMO/MOBAの可能性 • Rubyを中心にしたWeb技術 – MQTT protocol ライブラリ – Elixirの採用とBEAM親和性
101. 101. Copyright Drecom Co., Ltd. All Rights Reserved. 101 リアルタイム技術トレンド – OSSその他protocol例 • HTTP1.1 • CoAP • (SPDY) • HTTP2 • Reliable UDP • MessagePack • ProtocolBuffers – 独自・汎用実装 • OSS • ネットワークエンジン • IoT PaaSの登場 • 自社・自前開発 – 市場の変化 • 例: IPv6への対応
102. 102. Copyright Drecom Co., Ltd. All Rights Reserved. 102 IoTの今後 • IoTとしての決定版は？ – Protocol – インフラ基盤の構築（内製、クラウド） – デバイス疎／密連携 – 継承・委譲関係 • マクロ、ミクロのアクション・オペレーション • ゲームでの利用 – 特定環境（アミューズメント施設、販売店舗） – コンシューマ環境（ホーム、モバイル）
103. 103. Copyright Drecom Co., Ltd. All Rights Reserved. 103 まとめ • リアルタイム通信にMQTT選定 • 弊社事例を元に、MQTTの リアルタイム通信ゲーム実装の紹介 • 今後のIoT技術への期待
104. 104. Copyright Drecom Co., Ltd. All Rights Reserved. 104 ご清聴ありがとうございました。