Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
オンラインゲームの仕組みをしってみよう
Search
Takuma Kajikawa
August 01, 2018
4
3k
オンラインゲームの仕組みをしってみよう
Takuma Kajikawa
August 01, 2018
Tweet
Share
More Decks by Takuma Kajikawa
See All by Takuma Kajikawa
責務を分離するための例外設計 - PHPカンファレンス 2024
kajitack
2
670
Figmaで進化するデザイナーとエンジニアの連携 FoF Tokyo 2024
kajitack
0
13
コードの責務を例外で表現しよう PHPerKaigi2024
kajitack
2
250
スマホゲームサーバーのしくみをしってみよう
kajitack
1
14k
DBテーブル設計入門
kajitack
0
600
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
Adopting Sorbet at Scale
ufuk
73
9.1k
How GitHub (no longer) Works
holman
311
140k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
How to Think Like a Performance Engineer
csswizardry
22
1.2k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
It's Worth the Effort
3n
183
28k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Six Lessons from altMBA
skipperchong
27
3.5k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
17
2.3k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.3k
Transcript
オンラインゲームの しくみをしってみよう Takuma Kajikawa 2018/08/01 サポーターズ CoLab
唟䊛꼛 5BLVNB,BKJLBXB ⼼ا٦ءٍٕ٦ي涪⠓爡 ؟٦غ٦ؒٝآص،䎃湡 㺡㿊⳿魦
サポーターズでの発表 - MySQLの基礎 - DBテーブル設計入門
Agenda - オンラインゲームとオフラインゲームの違い - プレイヤー間のデータの同期方法いろいろ - データの流れを考えてみよう - サーバーで処理する?クライアントで処理する? -
TCPとUDPを使い分けよう
オンラインゲームと オフラインゲームの違い
ネットワークの遅延やエラーが発生する 前提でゲームデザインするかどうか
オンラインゲームの定義 طحزٙ٦ؙ➜׃ג㼔欽ך؟٦غה䱸竲 - ゲームの進行状態をリアルタイムに他のプレイヤーと同期
ネットワークの種類 - ルーターを介してインターネット接続 - モバイルネットワーク - アーケードゲームの専用回線 - LAN、赤外線、bluetooth
ネットワークの種類 - ルーターを介してインターネット接続 - モバイルネットワーク - アーケードゲームの専用回線 - LAN、赤外線、bluetooth
ゲームの進行状態を同期 - 状態: 名前、ランク、ステータス - 操作情報: キー入力、コマンド入力 - 外部要因: アイテムドロップ、ダメージ
オンラインゲームの定義 طحزٙ٦ؙ➜׃ג㼔欽ך؟٦غה䱸竲 - ゲームの進行状態をリアルタイムに他のプレイヤーと同期
リアルタイム? - インターネットは様々な機器を介してデータをやり取り - 通信機器はいろいろな処理を行っている - 通信の帯域によっても左右される - 物理的な距離、光速は超えられない
ルーターの処理 - ゲーブルの信号を読み取ってバッファに積む - パケットを解析して送り先IPアドレスを調べる - 送信バッファに出力 - ケーブルに送信 -
パケットの断片化 - 暗号化 - アタック防止 - ファイアウォール - NATの変換 - 統計データの取得…
データの消失 - 処理しきれなくなったデータは失われる - その結果データの再送信が発生し、さらに遅延を生む
越えられない物理法則 - 光速 30万km/秒 (光ファイバ20万km/秒) - 東京 ⇔ 大阪 500km
往復 5ミリ秒 - 日本 ⇔ アメリカ西海岸 往復 90ミリ秒
0.1秒の遅延 - 60FPSのゲームが0.1秒遅れると… - 1000 (ms) / 60 (F) =
16.666 (ms/F) - 100(ms)/ 16.666 (ms/F) ≒6 F
ネットワークの遅延が起きたときは - データが届くまでゲームの進行は止める? - 遅延を許容しても良いデータ?
- データが届かなかったときは再送信をする? - ゲーム中に通信が切れたらどうする? - 再送信の待ち時間は? - ゲーム画面はどうなっている? 回線の切断、データの消失
プレイヤー間のデータの 同期方法いろいろ
プレイ人数と遅延の許容度で 決める
いろいろな同期方式 - 格闘ゲーム: 完全同期型/キー入力同期方式 - RTS: 完全同期型/コマンド入力同期方式 - FPS:非同期型/サーバー集中処理型 -
MMO:非同期型/クライアント分散処理型
完全同期型 - お互いの端末のゲームの進行を一致させる - 一致するまでゲームの進行を止める必要がある - 一人でも遅延すると全員が待たされるため大人数のゲー ムには向いていない - 同期の単位はフレームやターン
- ほぼ2人対戦用?
完全同期型/キー入力同期方式 - キーの入力を同期 - コントローラーのボタンや方向キーのフラグ - フレーム単位で同期 - キーの入力タイミングが結果を大きく左右するゲーム -
格闘ゲームなど
完全同期型/コマンド同期方式 - コマンドを同期 - まとまった入力の単位、選択したものなど - フレーム単位またはターンで同期 - そこまで入力がシビアではないゲーム -
RTSやターン制のゲーム
非同期型 - 必要最低限のものを同期 - ゲームの描画は他の端末を待たなくても良い - 遅延が発生するとゲームの描画と進行がズレる = ラグ -
大人数向け
非同期型/サーバー集中処理型 - ゲームの進行はサーバー(の役割を兼ねた端末)に任せる - 端末はコマンドの送信と描画のみ - コマンドの結果は遅れて反映されることがある - 端末間でズレてはいけない処理 -
当たり判定、アイテムの取得調停など
非同期型/クライアント分散処理型 - 各クライアントでゲームを進行させる - キャラの位置やダメージなどを同期 - 端末同士のゲームの状態はズレてしまう - ゲームの仕様で許容する必要がある -
サーバーを待つ必要がない
データの流れを考えてみよう
リアルタイム性と正確さのトレードオフ
リアルタイム性と正確さのトレードオフ - リアルタイム性をもとめる場合 - 一つの端末のデータをとにかく速く他の端末に届け たい - 正確さを求める場合 - 判定ロジックを一箇所で行い、端末間の差異をな
くしたい
ネットワークトポロジー - 端末間の通信の接続形態 - よく使うのはスター型とフルメッシュ型 - 使い分けても良い IUUQTFOXJLJQFEJBPSHXJLJ/FUXPSL@UPQPMPHZ
スター型 (サーバー経由型) メリット - 情報が集中するため整合性を取りや すい - 各端末とサーバー間の通信量は少ない デメリット -
サーバーを経由して他の端末と通信す るため遅延が大きい IUUQTFOXJLJQFEJBPSHXJLJ/FUXPSL@UPQPMPHZ
スター型 (サーバー経由型) - 整合性が取れないとゲームバランスが おかしくなる通信に向いている - 例) ユーザー同士でアイテム取得が競 合する場合の調停 IUUQTFOXJLJQFEJBPSHXJLJ/FUXPSL@UPQPMPHZ
フルメッシュ型 (クライアント分散型) メリット - どの端末からどの端末へも直接たど り着けるので高速 デメリット - 全ての端末に送信するので通信量は 増える
IUUQTFOXJLJQFEJBPSHXJLJ/FUXPSL@UPQPMPHZ
フルメッシュ型 (クライアント分散型) - 即座に反映させる必要があるデータ - 多少の誤差は許せるデータ - 例) キャラクターやモンスターの位置情 報
IUUQTFOXJLJQFEJBPSHXJLJ/FUXPSL@UPQPMPHZ
サーバーで処理する? クライアントで処理する?
C/SとP2P - 以下の2種類をネットワークトポロジーに当てはめて接続 - Client/Server モデル (C/S) - Peer To
Peer (P2P) - 使い分けても良い
C/SとP2P IUUQTCMPHQFFSDPNUIFQQXJUDIIVOU
Client/Server モデル IUUQTCMPHQFFSDPNUIFQQXJUDIIVOU - スター型 - ゲーム運営者がサーバーを用意 - 端末間の通信は必ずサーバーを経由
Client/Server モデル IUUQTCMPHQFFSDPNUIFQQXJUDIIVOU - webサーバー - 不正が無いかデータをチェックする - データを保持する -
リレーサーバー:単なる通信の中継
Peer To Peer (P2P) IUUQTCMPHQFFSDPNUIFQQXJUDIIVOU - スター型とフルメッシュ型 - スター型では一台の端末がサーバーと しての役割を兼ねる
- サーバー負荷が小さい
P2Pの問題点、NAT越え - NAT(Network Address Translation) - IPアドレス枯渇のため、NATによってIPアドレスとポー トを変換している - NATがインターネットからのパケットをブロック
- P2Pの実現には、NAT越えが必要 - 環境によっては遊べなくなってしまう
NAT越えの手順 結局はサーバーが必要 1. NATが無いときは普通にP2P接続 2. UPnP 環境依存 3. STUN 要サーバー 4. TURN 要サーバー
(もはや P2Pとは言えない?)
C/SとP2Pどちらを選ぶ? - チート対策はサーバー側でやった方が確実 - アイテム課金/月額課金制ならC/S方式 - P2PでNAT越え対応 - 最初からC/S方式でリレーサーバーやったほうが楽
TCP/UDPを使い分けよう
インターネットの仕組み - データはバケツリレー方式で様々な機器を介して届けら れる - インターネットのプロトコルにのっとることでバケツリレーに 参加できる
プロトコルの階層 04*ࢀরϞσϧ 5$1*1 ࣮ࡍͷϓϩτίϧ ΦϯϥΠϯήʔϜͷϨΠ Ϡ ،فٔ؛٦ءّٝ㾴 ،فٔ؛٦ءّٝ㾴 )551
٦ي鸐⥋ךفٗز؝ٕ فٖئٝذ٦ءّٝ㾴 ٦يךر٦ة ءٔ،ٓ؎ؤ إحءّٝ㾴 鸐⥋ָⴖ ⱄ䱸竲 زٓٝأه٦ز㾴 زٓٝأه٦ز㾴 5$1 6%1 طحزٙ٦ؙ㾴 ؎ٝة٦طحز㾴 *1 ر٦ةؙٔٝ㾴 طحزٙ٦ؙ ؎ٝة٦ؿؑ٦أ㾴 搀简-"/ 暟椚㾴 ع٦سؐؑ،㾴 ،ٝذشծ؛٦ـٕ
TCPとUDP - 代表的なプロトコル - 安心と信頼のTCP - 速さのUDP
安心と信頼のTCP - HTTPで使われる - データのロスや順序を保証してくれる - データがちゃんと届くまで何度も再送信
TCPの通信 IUUQXXXBUNBSLJUDPKQBJUBSUJDMFTOFXT@IUNM
TCPの再送制御 IUUQXXXBUNBSLJUDPKQBJUBSUJDMFTOFXT@IUNM
速さのUDP - コネクションを確立せずに、データを送りつけるだけ - データは届かないかも - 届いたとしても順番が変わっているかも
UDP IUUQXXXBUNBSLJUDPKQBJUBSUJDMFTOFXT@IUNM
TCPの使い所 - デッキ編成やユニット強化等のアウトゲーム部分はHTTP 通信 - 速度的に許容出来るのであれば使っても良い - TCPで到達保証してくれるので、開発難易度は低
UDPの使い所 - アクション性が求められる対戦のゲームだとほぼ一択 - データのロスは実装でカバー - 実装量が増えるので、開発難易度は上がる
まとめ
まとめ - インターネットを使用する以上、遅延や切断は避けて は通れない - 遅延や切断を考慮したゲームデザインにする - ゲームの規模やジャンルによってデータの同期方法は変わ る
次の機会があれば… - 実装上の工夫 - サーバーのアプリケーションやDBのアーキテクチャ - 運用やデプロイの工夫
ご清聴ありがとうございました!
おすすめの本 - オンラインゲームのしくみ Unityで覚えるネットワークプロ グラミング - オンラインゲームを支える技術(WEB+DB PRESS plus)