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