Comments
Description
Transcript
株式会社セガ 技術開発センター ネットワークセクション 阿形 佳美
オンラインゲームの 基礎知識 株式会社セガ 技術開発センター ネットワークセクション 阿形 佳美 1 はじめに • オンラインゲームの特徴をわかりやす くするため、ゲーム専用機に特化して 説明します。 • ゲーム機の仕組み、スタンドアローン のゲーム開発手法を説明します。 • オンライン化することでどういった問 題が発生してくるか説明します。 2 ゲーム専用機 コンシューマー アーケード Dreamcast NAOMI, NAOMI 2 PS2 System246 GAME CUBE TriForce Xbox Chihiro 3 ゲーム機の思想 コストダウン 比較的貧弱なCPU 少ないメモリ容量 ハードディスク無し ハードウェア性能を 最大限に使う OS無し、あるいは最低限の機能のみ 画面表示重視 強力なグラフィック性能と、 それを最大限に活かす実装 4 「貧弱なCPU性能、 メモリ容量」への対策 • OS無し or 最低限の機能のみ • • • OSのオーバーヘッドの解消 OS分のメモリ容量を節約 CPU、メモリ(キャッシュ等も含む)を最大限使え るようにアプリケーションでスケジューリングし 最適化 5 最適化の代償 割り込みが使いにくい！ 割り込みが入ると、折角最適化したのが無駄になる タイマー割り込みも使 いにくい 入力処理どうする？ Unixなんかだと割り込みで実現し てるみたいだけど… TCP、DHCP、PPP、DNSなど 沢山あるタイマーをどうする？ プロトコル実装するの面倒すぎ！ 6 割り込み対策 • しかたないので… • • 入力はバッファにためておく • タイマーはV blankの回数を数える アプリケーション側から受信要求し、バッファか らコピー 7 「ハードディスクがない」 • 最近は付くようになりましたが • 基本はCD-ROMなどの光ディスクメ ディア • 一度プレスしたら、変更するには再度プレスして 交換するしかないので、非常にコストがかかる • あると便利なんだけど… 8 プロトコルスタックの修正 プロトコルスタックはアプリケーションに 組み込んでいるので… アプリケーションの修正 ROMの再プレス、配布 再プレスと配布費用がかさむから、やーめた！ 9 修正しなくてすむように • 実環境でのテストを十分に行う • それでも問題が出るときは出る • 新しいプロトコルにはどっちにしろ対 応できない 10 画面表示問題 • ゲーム機において、なぜそんなに画面 が重要なのかを説明します。 • そのためにとっている開発手法と、そ れによってオンラインゲームでどのよ うな問題が発生してくるか説明しま す。 11 まず画面ありき • ほとんどのゲームは画面 中のプレイヤーキャラク タを動かすことで成立 • プレイヤーキャラクタが 画面に出なくても、何ら かの情報が画面に表示さ れ、それをもとにゲーム を進める • よって、画面がちゃんと 出ないと話にならない 12 ちゃんとした画面の定義 • ユーザーの操作に遅れることなく確実 に反応が画面に反映されること • コマ落ちなくスムーズに動くこと • 家庭用TVで綺麗に見えること 13 家庭用TV • NTSCフォーマットの場合 • • 約30fps インタレースで約60fps ゲーム機の場合、これに同期して画面を更新する 14 画面の更新 • なぜ同期しなければなら ないか？ • 同期せずに更新する と、書き換え途中の状 態が表示されてしまう 書き換え途中の画面 15 同期するために 16.6ms (1/60s) V blank 割込処理 アプリ メイン アイドル 時間 16 • V blank割り込みをベー スにタスクを組み立てる • １V blank 周期の間に プレイヤーの操作情報を 処理して、次の画面を用 意 オンラインゲームの場合 これは一体何ms? • これまで通り、V blank を基準にすると • 遅延 • • 非常に短い時間(少 なくとも16ms以下) で届く必要がある ここで届いても… パケットロスや到着順 序の入れ替わり • あってはならない 操作 入力 17 送信 受信 時間 現実には不可能なので… • なんらかの対策が必要 • せめて数百msぐらいまで許容できな いと、現実的でない • どうにかして「ごまかす」しかない • • ゲームのルール自体で工夫 データのやりとりで工夫 18 ゲームのルールで工夫 • 遅延が大きくても問題の無いルール作 り • • • 相手行動を待つタイプにする(ターン制) ローカルの情報をバッファして、あとで判定 プレイヤー同士のかかわり合いを減らす 19 データのやり取りで工夫 • データを分類し、内容に応じた処理方 法を選択する • • • プロトコル トポロジー etc… 20 トポロジー スター型 ハイブリッド型 メッシュ (P2P)型 全てサーバー経由で 通信する。 スター型、メッシュ 型の混合 端末同士で直接通信 する。 情報の整合性を チェックできる。 スター型、メッシュ 型それぞれの長所を 活かせる。 遅延について、 スター型より有利。 通信形態 メリット 21 遅延耐性と更新頻度による 分類 小 大 遅延 移動、動作情報 キャラクターの移動 キャラクターの動作情報 ステータス更新 フィールドのステータス変化 キャラクターのステータス変化 アイテムのステータス変化 初期情報 フィールドの地形とステータス キャラクターの位置とステータス アイテムの位置とステータス 多 少 更新 22 情報の種類と トポロジー、プロトコル TCP 高 UDP スター型 確実に届く必要性 初期情報 ステータス 更新 移動・動作情報 メッシュ型 低 低 高 リアルタイム性 23 実際のトポロジーと プロトコル • スター型＋TCP（クライアント側から 接続）という選択をせざるを得ない面 が多い • • NAT対策 遅延にシビアなゲームは、可能であれば、P2P やUDPにしたいけど… 24 まとめ(?) • Internetのプロトコルはゲーム機に優 しくない • 遅延耐性はゲームのルールにより大き く変わる • ルールや実装を工夫してなんとか遅延 をごまかしている • しかし、実装の工夫も環境による制限(NATなど) をかなり受けている 25 おしまい ご清聴ありがとうございました。 26