オンラインゲーム技術入門2013年5月15日中嶋　謙互

http://github.com/kengonakajima

• https://github.com/kengonakajima/profile

• 1996年ごろから

• 商用オンラインゲーム x 8以上

• オンラインゲームミドルウェア x N

• 書籍 x 2

• 最近: DQXサーバ / ホリキング(Flash mmo)

自己紹介

「オンラインゲームの開発は、あまり怖くないかも」

と思えるようになる、はず

今日の話の効果

今日の話

「狭義のオンラインゲーム」

狭義のオンラインゲームとは？

• リアルタイム

• リモート

• マルチプレイ

ジャンル

• RTS : StarCraftシリーズ、AoE

• ARPG : ディアブロシリーズ

• MOBA(RTS) : League of Legends, ヒーローズ of order & chaos

• TPS : FEZやコズミックブレイクなど

• FPS : unrealエンジンの実績のほとんど、CS, halo, Cod, minecraft, L4D, ...

• レーシング : マリオカートシリーズ、ほとんどのメジャーなレースゲーム

• 対戦格闘 : ストリートファイターシリーズ、スマブラ

• スポーツ : サッカーのオンラインゲーム化はよくされるが。。

• MMO : wow, ff11/14, など大手以外にもrunescapeなども

• スクロールアクション: テラリア,KAG, ラテールなど

• バーチャルワールド: ピグやhabboなど(テーブルゲームなど含む)

skipped: 20枚にわたって写真と動画でゲーム紹介

だいぶ異なる2つの技術体系

• HTTPが使える体系

• HTTPが使えない体系

※クラウドゲーミングは定着していないので入門からは省略

HTTPが使えない理由

• プッシュ

• 遅延 (LOL ping 64.7.194.1 / google.co.jp, 地球、光)

• 効率 (ネットワークで4~10倍/CPUで10~100倍)

HTTPを使うゲームとも共通する課題

• 描画/UI設計

• DB負荷

• サーバのI/O負荷(ファイル、ネットワーク)

• ログ解析

• サーバデプロイ/up/down

• クライアントアップデート

• バージョン管理

• クライアント/サーバでのコード共有

※省略

←最初のトラブルはほぼこれ

HTTPの体系にはない課題

1. 状態のあるサーバをどうスケールするか2. 通信が遅いとプレイ感が劇的に悪くなる3. サーバで、速いゲーム処理をどう書くか

ほぼ使えない: Ruby, Python, PHP, Perl軽め: JavaScript, Lua重め: C#, Java, C++, C (省略)

4. 他C10K、 JSON重すぎ、 UDP、 NATトラバーサル、 etc (省略)

1. 状態のあるサーバをどうスケールするか

状態のあるサーバとは

• オンメモリ

• シミュレータ

• 特定のクライアントとの接続を持ち続ける

• 数千～数万 Qps/core

• 非同期

• だいたい「ゲームサーバ」と呼んでいる

game 0 Net

game 1

game 2

・・

User A

User B

User C

User D

User E

User F

web 0

web 1

状態ありの「ゲームサーバ」こまかく制御されたロードバランスが必要

状態なしweb等サーバ

backend

• 起動

• prefork / on-demand fork

• ホモ？ヘテロ？

• コア(Thread)あたり何ゲームをホストするか

• ゲームタイプ(人数が違う、設定が違う)

• ゲームデータ(地形など)が大きくて全部は読めない

• 発見

• プレイ相手はどのサーバにいるのか

1. ゲームサーバのロードバランス

←運営開始時に必ずトラブルDBまわりの次に多い

←なかなか満足いく結果を出せない

2. 通信が遅いと、プレイ感が劇的に悪くなる

通信の遅れ = RTT × 2

gameserver

User

時間

操作

座標変更

操作を通知

Net

結果を通知

描画

時間

• 光速 = 30万km/秒

• 直線1000kmあたり 3.3msec

• 光ファイバの屈折率だと4~5msec

• 途中のルータや無線LAN, OSを経由して +2~3msec

• 意図がある場合の人間の反射速度 : 10~30msec

地球の大きさと光速

人間の操作よりネットが遅いgameserver

User

時間

操作 : 左へ行け

座標変更

Net

描画 : 左に進む

操作 : 左へ行け操作 : 左へ行け操作 : 右へ行け操作 : 右へ行け操作 : 右へ行け

描画 : 左に進む描画 : 左に進む描画 : 右に進む描画 : 右に進む描画 : 右に進む

プレイ感覚の悪化(デモ)

• 遅れ無し

• 一定の遅れ

• スパイクのある遅れ

http://kengonakajima.github.io/delay/game/index.html

http://goo.gl/7ZnWY

さまざまな工夫

• 自己操作の特別扱い (デモの自機)

• 操作そのものではなく欲しい結果の送信(デモの”goal”)

• 決定論的挙動 (デモの宝石)

• クライアント状態の条件付き採用 (デモの自動同期)

• 他にも様々な工夫が、ゲーム内容ごとに

• ホーミング(追いかけることでヒット)

• 可変アニメーション時間で調整

←やりすぎて、チートの温床に!!

• 見てみる

• 自己操作の特別扱い

• 決定論的挙動(矢)

• 自動同期(他PCのジャンプ開始位置)

• 考えられるチート

• 矢

• 自動同期

KAGでの実際https://www.youtube.com/watch?v=bB2167x9Uog

1. ジャンルを決める

2. 同じジャンルの参考にするゲームの、ゲームサーバスケールと遅延対策について多くプレイして当たりをつける

3. 最も単純な「対策なし」で実装する

• ゲームサーバは固定数プレフォーク

• 遅延対策はしない

4. 人数・内容を増やしてプレイを重ね、どうしても直さなければならないところに一つづつ対策を入れていく

オンラインゲーム開発の手順

オンラインゲームだからといって、高度なアルゴリズムや工夫を最初から入れようとがんばらないこと!!　時間が足りなくなります。

1. 狭義のオンラインゲームの開発では、

2. 独特の問題として、ゲームサーバのスケールと、

3. 遅延によるプレイ感覚の悪化という問題があるが、

4. それはあくまでも問題全体の一部なので、

5. 優先順位を上げ過ぎないように取り組みましょう。

まとめ

より詳しくは

「オンラインゲームを支える技術」 We+DB Press, 3024円

http://www.amazon.co.jp/dp/4774145807

(おまけ)「同時にプレイできない問題」

• 「マッチング」の問題と呼んでいる

• 一緒にプレイして楽しいかは相手による

• 楽しめる相手を、楽しめるタイミングでマッチさせる方法が未開拓

• ゲームなら、時間帯、性別、年齢、言語、所属するグループを超えたマッチングができるはず。新しいアイデアが待たれている。