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

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)