オンラインゲームの仕組みをしってみよう

0f75d76df768c585ccb6fc9ada7f5ca2?s=47 Takuma Kajikawa
August 01, 2018
640

 オンラインゲームの仕組みをしってみよう

0f75d76df768c585ccb6fc9ada7f5ca2?s=128

Takuma Kajikawa

August 01, 2018
Tweet

Transcript

  1. オンラインゲームの しくみをしってみよう Takuma Kajikawa 2018/08/01 サポーターズ CoLab

  2. 唟䊛꼛 5BLVNB,BKJLBXB ⼼ا٦ءٍٕ؜٦يꟚ涪⠓爡 ؟٦غ٦ؒٝآص،䎃湡 㺡㿊⳿魦

  3. サポーターズでの発表 - MySQLの基礎 - DBテーブル設計入門

  4. Agenda - オンラインゲームとオフラインゲームの違い - プレイヤー間のデータの同期方法いろいろ - データの流れを考えてみよう - サーバーで処理する?クライアントで処理する? -

    TCPとUDPを使い分けよう
  5. オンラインゲームと オフラインゲームの違い

  6. ネットワークの遅延やエラーが発生する 前提でゲームデザインするかどうか

  7. オンラインゲームの定義  طحزٙ٦ؙ׾➜׃ג㼔欽ך؟٦غה䱸竲 - ゲームの進行状態をリアルタイムに他のプレイヤーと同期

  8. ネットワークの種類 - ルーターを介してインターネット接続 - モバイルネットワーク - アーケードゲームの専用回線 - LAN、赤外線、bluetooth

  9. ネットワークの種類 - ルーターを介してインターネット接続 - モバイルネットワーク - アーケードゲームの専用回線 - LAN、赤外線、bluetooth

  10. ゲームの進行状態を同期 - 状態: 名前、ランク、ステータス - 操作情報: キー入力、コマンド入力 - 外部要因: アイテムドロップ、ダメージ

  11. オンラインゲームの定義  طحزٙ٦ؙ׾➜׃ג㼔欽ך؟٦غה䱸竲 - ゲームの進行状態をリアルタイムに他のプレイヤーと同期

  12. リアルタイム? - インターネットは様々な機器を介してデータをやり取り - 通信機器はいろいろな処理を行っている - 通信の帯域によっても左右される - 物理的な距離、光速は超えられない

  13. ルーターの処理 - ゲーブルの信号を読み取ってバッファに積む - パケットを解析して送り先IPアドレスを調べる - 送信バッファに出力 - ケーブルに送信 -

    パケットの断片化 - 暗号化 - アタック防止 - ファイアウォール - NATの変換 - 統計データの取得…
  14. データの消失 - 処理しきれなくなったデータは失われる - その結果データの再送信が発生し、さらに遅延を生む

  15. 越えられない物理法則 - 光速 30万km/秒 (光ファイバ20万km/秒) - 東京 ⇔ 大阪 500km

    往復 5ミリ秒 - 日本 ⇔ アメリカ西海岸 往復 90ミリ秒
  16. 0.1秒の遅延 - 60FPSのゲームが0.1秒遅れると… - 1000 (ms) / 60 (F) =

    16.666 (ms/F) - 100(ms)/ 16.666 (ms/F) ≒6 F
  17. ネットワークの遅延が起きたときは - データが届くまでゲームの進行は止める? - 遅延を許容しても良いデータ?

  18. - データが届かなかったときは再送信をする? - ゲーム中に通信が切れたらどうする? - 再送信の待ち時間は? - ゲーム画面はどうなっている? 回線の切断、データの消失

  19. プレイヤー間のデータの 同期方法いろいろ

  20. プレイ人数と遅延の許容度で 決める

  21. いろいろな同期方式 - 格闘ゲーム: 完全同期型/キー入力同期方式 - RTS: 完全同期型/コマンド入力同期方式 - FPS:非同期型/サーバー集中処理型 -

    MMO:非同期型/クライアント分散処理型
  22. 完全同期型 - お互いの端末のゲームの進行を一致させる - 一致するまでゲームの進行を止める必要がある - 一人でも遅延すると全員が待たされるため大人数のゲー ムには向いていない - 同期の単位はフレームやターン

    - ほぼ2人対戦用?
  23. 完全同期型/キー入力同期方式 - キーの入力を同期 - コントローラーのボタンや方向キーのフラグ - フレーム単位で同期 - キーの入力タイミングが結果を大きく左右するゲーム -

    格闘ゲームなど
  24. 完全同期型/コマンド同期方式 - コマンドを同期 - まとまった入力の単位、選択したものなど - フレーム単位またはターンで同期 - そこまで入力がシビアではないゲーム -

    RTSやターン制のゲーム
  25. 非同期型 - 必要最低限のものを同期 - ゲームの描画は他の端末を待たなくても良い - 遅延が発生するとゲームの描画と進行がズレる = ラグ -

    大人数向け
  26. 非同期型/サーバー集中処理型 - ゲームの進行はサーバー(の役割を兼ねた端末)に任せる - 端末はコマンドの送信と描画のみ - コマンドの結果は遅れて反映されることがある - 端末間でズレてはいけない処理 -

    当たり判定、アイテムの取得調停など
  27. 非同期型/クライアント分散処理型 - 各クライアントでゲームを進行させる - キャラの位置やダメージなどを同期 - 端末同士のゲームの状態はズレてしまう - ゲームの仕様で許容する必要がある -

    サーバーを待つ必要がない
  28. データの流れを考えてみよう

  29. リアルタイム性と正確さのトレードオフ

  30. リアルタイム性と正確さのトレードオフ - リアルタイム性をもとめる場合 - 一つの端末のデータをとにかく速く他の端末に届け たい - 正確さを求める場合 - 判定ロジックを一箇所で行い、端末間の差異をな

    くしたい
  31. ネットワークトポロジー - 端末間の通信の接続形態 - よく使うのはスター型とフルメッシュ型 - 使い分けても良い IUUQTFOXJLJQFEJBPSHXJLJ/FUXPSL@UPQPMPHZ

  32. スター型 (サーバー経由型) メリット - 情報が集中するため整合性を取りや すい - 各端末とサーバー間の通信量は少ない デメリット -

    サーバーを経由して他の端末と通信す るため遅延が大きい IUUQTFOXJLJQFEJBPSHXJLJ/FUXPSL@UPQPMPHZ
  33. スター型 (サーバー経由型) - 整合性が取れないとゲームバランスが おかしくなる通信に向いている - 例) ユーザー同士でアイテム取得が競 合する場合の調停 IUUQTFOXJLJQFEJBPSHXJLJ/FUXPSL@UPQPMPHZ

  34. フルメッシュ型 (クライアント分散型) メリット - どの端末からどの端末へも直接たど り着けるので高速 デメリット - 全ての端末に送信するので通信量は 増える

    IUUQTFOXJLJQFEJBPSHXJLJ/FUXPSL@UPQPMPHZ
  35. フルメッシュ型 (クライアント分散型) - 即座に反映させる必要があるデータ - 多少の誤差は許せるデータ - 例) キャラクターやモンスターの位置情 報

    IUUQTFOXJLJQFEJBPSHXJLJ/FUXPSL@UPQPMPHZ
  36. サーバーで処理する? クライアントで処理する?

  37. C/SとP2P - 以下の2種類をネットワークトポロジーに当てはめて接続 - Client/Server モデル (C/S) - Peer To

    Peer (P2P) - 使い分けても良い
  38. C/SとP2P IUUQTCMPHQFFSDPNUIFQQXJUDIIVOU

  39. Client/Server モデル IUUQTCMPHQFFSDPNUIFQQXJUDIIVOU - スター型 - ゲーム運営者がサーバーを用意 - 端末間の通信は必ずサーバーを経由

  40. Client/Server モデル IUUQTCMPHQFFSDPNUIFQQXJUDIIVOU - webサーバー - 不正が無いかデータをチェックする - データを保持する -

    リレーサーバー:単なる通信の中継
  41. Peer To Peer (P2P) IUUQTCMPHQFFSDPNUIFQQXJUDIIVOU - スター型とフルメッシュ型 - スター型では一台の端末がサーバーと しての役割を兼ねる

    - サーバー負荷が小さい
  42. P2Pの問題点、NAT越え - NAT(Network Address Translation) - IPアドレス枯渇のため、NATによってIPアドレスとポー トを変換している - NATがインターネットからのパケットをブロック

    - P2Pの実現には、NAT越えが必要 - 環境によっては遊べなくなってしまう
  43. NAT越えの手順 結局はサーバーが必要 1. NATが無いときは普通にP2P接続 2. UPnP 環境依存 3. STUN 要サーバー 4. TURN 要サーバー

    (もはや P2Pとは言えない?)
  44. C/SとP2Pどちらを選ぶ? - チート対策はサーバー側でやった方が確実 - アイテム課金/月額課金制ならC/S方式 - P2PでNAT越え対応 - 最初からC/S方式でリレーサーバーやったほうが楽

  45. TCP/UDPを使い分けよう

  46. インターネットの仕組み - データはバケツリレー方式で様々な機器を介して届けら れる - インターネットのプロトコルにのっとることでバケツリレーに 参加できる

  47. プロトコルの階層 04*ࢀরϞσϧ 5$1*1 ࣮ࡍͷϓϩτίϧ ΦϯϥΠϯήʔϜͷϨΠ Ϡ  ،فٔ؛٦ءّٝ㾴 ،فٔ؛٦ءّٝ㾴 )551

    ؜٦ي鸐⥋ךفٗز؝ٕ  فٖئٝذ٦ءّٝ㾴 ؜٦يךر٦ة׾ ءٔ،ٓ؎ؤ  إحءّٝ㾴 鸐⥋ָⴖ׸׋׵ ⱄ䱸竲  زٓٝأه٦ز㾴 زٓٝأه٦ز㾴 5$1 6%1  طحزٙ٦ؙ㾴 ؎ٝة٦طحز㾴 *1  ر٦ةؙٔٝ㾴 طحزٙ٦ؙ ؎ٝة٦ؿؑ٦أ㾴 搀简-"/  暟椚㾴 ع٦سؐؑ،㾴 ،ٝذشծ؛٦ـٕ
  48. TCPとUDP - 代表的なプロトコル - 安心と信頼のTCP - 速さのUDP

  49. 安心と信頼のTCP - HTTPで使われる - データのロスや順序を保証してくれる - データがちゃんと届くまで何度も再送信

  50. TCPの通信 IUUQXXXBUNBSLJUDPKQBJUBSUJDMFTOFXT@IUNM

  51. TCPの再送制御 IUUQXXXBUNBSLJUDPKQBJUBSUJDMFTOFXT@IUNM

  52. 速さのUDP - コネクションを確立せずに、データを送りつけるだけ - データは届かないかも - 届いたとしても順番が変わっているかも

  53. UDP IUUQXXXBUNBSLJUDPKQBJUBSUJDMFTOFXT@IUNM

  54. TCPの使い所 - デッキ編成やユニット強化等のアウトゲーム部分はHTTP 通信 - 速度的に許容出来るのであれば使っても良い - TCPで到達保証してくれるので、開発難易度は低

  55. UDPの使い所 - アクション性が求められる対戦のゲームだとほぼ一択 - データのロスは実装でカバー - 実装量が増えるので、開発難易度は上がる

  56. まとめ

  57. まとめ - インターネットを使用する以上、遅延や切断は避けて は通れない - 遅延や切断を考慮したゲームデザインにする - ゲームの規模やジャンルによってデータの同期方法は変わ る

  58. 次の機会があれば… - 実装上の工夫 - サーバーのアプリケーションやDBのアーキテクチャ - 運用やデプロイの工夫

  59. ご清聴ありがとうございました!

  60. おすすめの本 - オンラインゲームのしくみ Unityで覚えるネットワークプロ グラミング - オンラインゲームを支える技術(WEB+DB PRESS plus)