Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例

4,420 views

Published on

2014.7.19 に開催された第二回ゲームサーバ勉強会で使用したスライド
http://peatix.com/event/42642

Published in: Engineering
  • Be the first to comment

MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例

  1. 1. MMOのサーバについて 剣と魔法のログレス ~いにしえの女神~ での実装例 山藤 智之
  2. 2. Aiming • 代表:椎葉 忠志 • オンラインゲームの会社 • 企画・開発・運営 全部やってます!! • 東京、大阪 • HP:http://aiming-inc.com/
  3. 3. 自己紹介 • 山藤 智之 • 最初はWEB系(R&D) • 2007年からオンラインゲーム開発 – 開発タイトル • BladeChronicle • 剣と魔法のログレス(PCブラウザ) • 剣と魔法のログレス ~いにしえの女神~ • 株式会社Aiming 大阪スタジオ所属
  4. 4. ログレス • PC – 剣と魔法のログレス – 2011年10月サービス開始 – http://mmo-logres.com/ • スマートフォン – 剣と魔法のログレス ~いにしえの女神~ – 2013年12月サービス開始 – http://sp.mmo-logres.com/ – 2014年5月 200万DL達成
  5. 5. 目次 • ログレスのサーバ – フロントエンド – バックエンド • 実装例 – 移動 – チャット • 実際に起こった問題と対応
  6. 6. • ログレスのサーバ – フロントエンド – バックエンド • 実装例 – 移動 – チャット • 実際に起こった問題と対応
  7. 7. ログレスのサーバ • 階層を分けて冗長化しています • 縦に繋ぐ、同階層での横の繋がりは無し WAN WAN
  8. 8. フロントエンド • ユーザークライアントが接続する • 2種類の通信を使い分け – Socket / HTTP ずっと接続してる ゲーム入出力 必要に応じて接続 ゲーム出力
  9. 9. バックエンド • ユーザークライアントは接続しない • ゲームサーバとのSocket通信のみ • DBも含まれる ずっと接続している ゲームサーバ間の情報共有
  10. 10. SocketとHTTPの使い分け • Socket – サーバからのプッシュが必要な箇所 – レスポンス速度を要求される処理に向いている – 常時接続 – 差分更新 • HTTP – サーバからのプッシュが不要な箇所 – レスポンス速度を要求しない物に向いている – 必要都度、接続/切断 – 一括更新
  11. 11. Socket(常時接続・差分更新) • 利点 – オペレーション毎の接続コストが発生しない – 一回の送受信量を少なくできる • 欠点 – バッテリー消費が多くなる – 回線切れに弱い • ソフトウェア側で対応しないといけない内容が増える – スケールアウトが難しくなりがち
  12. 12. 通信経路別の内容 場所 セッション 用途・内容 クライアント ゲームサーバ Socket 常時接続 ゲームへの入力 ゲームからの出力 通信内容:差分更新型 クライアント WEBサーバ HTTP 都度接続 ゲームからの出力 通信内容:描画に必要な完全な内容 ゲームサーバ バックエンドサーバ Socket 常時接続 ゲームサーバ間の情報共有 ゲームサーバ全体への命令 通信内容:差分更新型 ゲーム/バックエンドサーバ データベース(マスター) 常時接続 主に更新系クエリ INSERT, DELETE, UPDATE, たまに SELECT WEBサーバ データベース(スレーブ) 常時接続 ほとんどが抽出クエリ SELECT
  13. 13. • ログレスのサーバ – フロントエンド – バックエンド • 実装例 – 移動 – チャット • 実際に起こった問題と対応
  14. 14. 移動 • ログレスでの移動処理 • キャラクターの座標はサーバでも管理 – 歩けない場所を歩かせないため • MMOの世界で移動すると… – 動くとどうなる? • 見えなかった物が見える様になる • 見えなかったユーザーも見える様になる – 見えるとどうなる? • 自分が取った行動を、見えてる人に送らないといけな くなる • 見えてる人達が取った行動を受信しないといけなくな る
  15. 15. こういうこと
  16. 16. 通信範囲 • そこで必要になるのが通信範囲という考 え方 通信範囲 この人とはデータ のやり取りをする この人達とはデータの やり取りをしない
  17. 17. 移動 • 移動はこの通信範囲の更新を繰り返す 移動した事で、この人達とデータをやり取りする様になる この人達とデータをやり取りする必要がなくなった
  18. 18. 移動のデータフロー クライアントで移動開始 ・移動情報の妥当性を検証 ・移動前後の座標周辺に居 るキャラクターの検索 周辺に居るキャラクター に移動した情報を通知 クライアントで移動開始 移動開始・到達点を送信 クライアントで移動開始
  19. 19. どうしてこんな作りなの? • 移動の都度、サーバを介していると、移 動開始までの反応が遅くなる – 他の人から見た移動は、ある程度遅れてもあ まり気にならない • クライアントだけで移動させてしまうと、 通信範囲の計算ができない • クライアントだけで移動させると、マッ プの当たり判定を完全に無視できてしま う
  20. 20. チャット • 文字ベースのコミュニケーション こんな感じで、発言したキャラク ターから吹き出しが出る この部分にチャットログが残る この間はSocket通信 こっちはHTTP通信
  21. 21. チャットのデータフロー 発言 DBに書く 発言 吹き出し表示 ログ取得 ログ読み込み 吹き出し表示 ログ表示 吹き出し表示
  22. 22. どうしてこんな作りなの? • チャットの吹き出しは見える人だけ見え ればOK • 吹き出しは発言後なるべく速く画面に表 示したい • チャットログは、自分がオフラインの間 に受信した物も見れて欲しい – コミュニケーションが途切れるの良くない
  23. 23. • ログレスのサーバ – フロントエンド – バックエンド • 実装例 – 移動 – チャット • 実際に起こった問題と対応
  24. 24. • 1台のサーバにログインできるプレーヤー数 が限られる – サーバのリソースには限りがある • CPU • メモリ • ハードディスク • ネットワークカード • クライアントは裏で、サーバ間の接続を切り 替えながら動いている • この切り替え時にサーバへの負荷が大きかっ た 実際に起こった問題と対応
  25. 25. サーバ間の移動
  26. 26. サーバ間の移動シーケンス 1:移動開始の通知 2:受信用の器を用意 3:準備OK 4:接続しろ 4:データ転送 6:受信完了 6:切断 5:接続 7:完了 8:入場 8:移動前のキャラを消す
  27. 27. ビフォー ここの負荷がとにかく大きい
  28. 28. アフター ラウンドロビンで切り替えて使う
  29. 29. どうやって直したの? 他の部分には影響無し 直したのはこの部分
  30. 30. 宣伝!! • 剣と魔法のログレス ~いにしえの女神~ • iOS / Android 絶賛サービス中です! – 2013/10/11 Android先行体験開始 – 2013/12/17 Android正式サービス開始 – 2014/2/09 60万DL達成 – 2014/3/21 100万DL達成 – 2014/4/22 150万DL達成 – 2014/5/22 200万DL達成
  31. 31. 仲間募集!! • Aimingでは一緒に魅力的なタイトルを作 れるエンジニアの皆様を募集中です! • 会社見学(@東京、大阪)もやってます のでお気軽にどうぞ! • http://aiming-inc.com/
  32. 32. • 以上

×