Empfohlen
Weitere ähnliche Inhalte
Empfohlen
Empfohlen (20)
Onlinegame entrylevel 201305
- 2. • https://github.com/kengonakajima/profile • 1996年ごろから • 商用オンラインゲーム x 8以上 • オンラインゲームミドルウェア x N • 書籍 x 2 • 最近: DQXサーバ / ホリキング(Flash mmo) 自己紹介
- 5. 狭義のオンラインゲームとは？ • リアルタイム • リモート • マルチプレイ
- 6. ジャンル • 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など(テーブルゲームなど含む)
- 9. HTTPが使えない理由 • プッシュ • 遅延 (LOL ping 64.7.194.1 / google.co.jp, 地球、光) • 効率 (ネットワークで4~10倍/CPUで10~100倍)
- 10. HTTPを使うゲームとも 共通する課題 • 描画/UI設計 • DB負荷 • サーバのI/O負荷(ファイル、ネットワーク) • ログ解析 • サーバデプロイ/up/down • クライアントアップデート • バージョン管理 • クライアント/サーバでのコード共有 ※省略 ←最初のトラブルはほぼこれ
- 11. HTTPの体系にはない課題 1. 状態のあるサーバをどうスケールするか 2. 通信が遅いとプレイ感が劇的に悪くなる 3. サーバで、速いゲーム処理をどう書くか ほぼ使えない: Ruby, Python, PHP, Perl 軽め: JavaScript, Lua 重め: C#, Java, C++, C (省略) 4. 他 C10K、 JSON重すぎ、 UDP、 NATトラバーサル、 etc (省略)
- 13. 状態のあるサーバとは • オンメモリ • シミュレータ • 特定のクライアントとの接続を持ち続ける • 数千∼数万 Qps/core • 非同期 • だいたい「ゲームサーバ」と呼んでいる
- 14. 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
- 15. • 起動 • prefork / on-demand fork • ホモ？ヘテロ？ • コア(Thread)あたり何ゲームをホストするか • ゲームタイプ(人数が違う、設定が違う) • ゲームデータ(地形など)が大きくて全部は読めない • 発見 • プレイ相手はどのサーバにいるのか 1. ゲームサーバのロードバランス ←運営開始時に必ずトラブル DBまわりの次に多い ←なかなか満足いく結果を出 せない
- 17. 通信の遅れ = RTT × 2 game server User 時間 操作 座標変更 操作を通知 Net 結果を通知 描画 時間
- 18. • 光速 = 30万km/秒 • 直線1000kmあたり 3.3msec • 光ファイバの屈折率だと4~5msec • 途中のルータや無線LAN, OSを経由して +2~3msec • 意図がある場合の人間の反射速度 : 10~30msec 地球の大きさと光速
- 19. 人間の操作よりネットが遅い game server User 時間 操作 : 左へ行け 座標変更 Net 描画 : 左に進む 操作 : 左へ行け 操作 : 左へ行け 操作 : 右へ行け 操作 : 右へ行け 操作 : 右へ行け 描画 : 左に進む 描画 : 左に進む 描画 : 右に進む 描画 : 右に進む 描画 : 右に進む
- 20. プレイ感覚の悪化(デモ) • 遅れ無し • 一定の遅れ • スパイクのある遅れ http://kengonakajima.github.io/delay/game/index.html http://goo.gl/7ZnWY
- 21. さまざまな工夫 • 自己操作の特別扱い (デモの自機) • 操作そのものではなく欲しい結果の送信(デモの”goal”) • 決定論的挙動 (デモの宝石) • クライアント状態の条件付き採用 (デモの自動同期) • 他にも様々な工夫が、ゲーム内容ごとに • ホーミング(追いかけることでヒット) • 可変アニメーション時間で調整 ←やりすぎて、 チートの温床に!!
- 22. • 見てみる • 自己操作の特別扱い • 決定論的挙動(矢) • 自動同期(他PCのジャンプ開始位置) • 考えられるチート • 矢 • 自動同期 KAGでの実際 https://www.youtube.com/watch?v=bB2167x9Uog
- 23. 1. ジャンルを決める 2. 同じジャンルの参考にするゲームの、ゲームサーバスケールと遅延対 策について多くプレイして当たりをつける 3. 最も単純な「対策なし」で実装する • ゲームサーバは固定数プレフォーク • 遅延対策はしない 4. 人数・内容を増やしてプレイを重ね、どうしても直さなければならな いところに一つづつ対策を入れていく オンラインゲーム開発の手順 オンラインゲームだからといって、 高度なアルゴリズムや工夫を最初から入れようと がんばらないこと!! 時間が足りなくなります。
- 24. 1. 狭義のオンラインゲームの開発では、 2. 独特の問題として、ゲームサーバのスケールと、 3. 遅延によるプレイ感覚の悪化という問題があるが、 4. それはあくまでも問題全体の一部なので、 5. 優先順位を上げ過ぎないように取り組みましょう。 まとめ
- 25. より詳しくは 「オンラインゲームを支える技術」 We+DB Press, 3024円 http://www.amazon.co.jp/dp/4774145807
- 26. (おまけ)「同時にプレイできない問題」 • 「マッチング」の問題と呼んでいる • 一緒にプレイして楽しいかは相手による • 楽しめる相手を、楽しめるタイミングでマッチさせる方法が未開拓 • ゲームなら、時間帯、性別、年齢、言語、所属するグループを超えたマ ッチングができるはず。新しいアイデアが待たれている。