2012年8月22日 にあった、ＣＥＤＥＣの講演についての記事です。


「コンシューマゲームでの挑戦！
ネットワークを活用したゲームの構築と運用「シェルノサージュ」の事例」


「シェルノサージュ」の具体的な運用例を中心にレポートしました。
ソースコードや遷移図を交えての話　ミドルウェアの紹介などもありましたが　
文章ではまとめきれないため割愛しました。

すみません。


-------------------------------------------------

●まず 「シェルノサージュ」とは




ネットワークを活用したコミュニケーションゲーム
大きく以下の３つのパートに分かれます。


・コミュニケーションパート



イオンちゃんと コミュニケーション
アイテム採取や、アイテム生成を行う

→　クラウド　（今回のテーマはコレ）



・シナリオパート

ゲーム本体には第一章のみが入っている。
シナリオは順次追加されていく。

→　追加コンテンツ
　　（第２章までは無料、第三章以降有料）



・交流パート



他のプレイヤーとメッセージ送り合ったり、共同でミッションをクリアしたり

→　コミュニケーション




●「シェルノサージュ」のクラウド

ＰＳＶＩＴＡ のデータ
（例：　「着ている服」「疲れ具合」「機嫌」「交流履歴」「所持アイテム」　）

→　ＰＳ３　、スマートフォン　、ＷＥＢアプリ　などの他の媒体で参照できる。



つまり

クラウド　≒　ネットワーク上のセーブデータ


こういう事もできるかも？？）　　（あくまで構想）

→　PSVITA でコミュニケーションゲームを遊び
→　スマートフォンで アイテム調合、ミニゲーム
→　PS3で、そのデータを使い RPG


クラウド機能は、様々な機種で同じ「世界」を創造できる。




●「シェルノサージュ」でクラウドにしているデータ

・ヒロイン情報
各種パラメータ、装備品　など

・アイテム情報
アイテム所持数、興味度、知識度　など

・イベント情報
ユーザーが発生させたイベント、選択肢情報



-------------------------------------------------

●クラウドの実装手法について

・クラウドと、通常のネットワーク通信の違い


通信手法　　　　　　　両方 ｈｔｔｐｓ

通信時アナウンス　　クラウド：　しない　（バックグラウンド）
　　　　　　　　　　　 　　通常：　　　ダイアログ表示　（通信中です）

通信サイズ　　　　　クラウド：　固定サイズ　（シェルノサージュの場合　5000byte）
　　　　　　　　　　 　　通常：　　　可変　（大体、100～30000byte くらい）

エラー時処理　　　　クラウド：　しない　（オートリトライ）
　　　　　　　　　　　　 通常：　　　ダイアログ表示　（停止）


クラウドでは、ユーザーに通信している事を ユーザーに意識させない



・シェルノサージュの実装

特定のメモリに、通信データ領域 （5000byte）を用意している。

ゲームプレイをしパラメータなどが更新された場合、通信データ領域のメモリに書き込む。

→　定期的に、通信データ領域のデータをチェックし
　データが更新されたのを発見した場合、自動的にクラウドサーバーにデータを送信する。



・こんな所に注意

常にオンラインではない状況に どう対応するか？

移動中などで 途中切断が起きたとき、どうするか？

→　PSVITA内のデータと、サーバー内のデータは　常に整合性を保たれているように設計する必要がある。



-------------------------------------------------

●サーバー運用について

・サーバー構成

load balancer　　（負荷分散装置）
　　↓
APIサーバー　× ２１　　　　　　　（状況によって 数を柔軟に変更）
　　↓
データベースサーバー　× ４　　（テーブルごとに 分けて格納）




●発売から いろいろなトラブルがありました。
大きな３つの原因について


１．データベースサーバーの処理超過

データベースの処理速度がおいつかない為、サーバーダウン

→　データベースサーバーが当初１つだけだったのを、４台に分割

→　テーブルを用途、負荷に応じて分割した。
　（関連テーブルは同一サーバーに
　処理が重いテーブルが入っているサーバーはテーブル数を減らす）



２．データベースから取得するレコード数が増大してサーバーダウン

例）　他のプレイヤーの妖精を検索
→　テスト時、数千で負荷テストをしても大丈夫だったけど
　発売後は、数万～数百万になり 全然状況が違った


→　取得数に必ず上限をつける。
　（プレイヤー １０００人分検索したら 検索終了　など）



３．スクリプトの不可増大によるサーバーダウン

→　永久ループを極力回避するスクリプトを組む




●技術的な注意点

・データベースに適切なインデックスを付ける
→　検索カラムにインデックスを付けるだけで、処理が格段に早くなる

・フレームワークは データベースアクセス回数を調べる

・１回のレコード取得数は極力減らす

・Apacheの同時接続数、コネクションタイムの調整をする

→　同時接続数を増やす　→　高速化　しかし、クラウド料金跳ね上がり

　　切断時間を減らす　→　検索にかかる時間が延びる　　（ユーザビリティが悪くなる）




●その他の注意点

・クラウド業者選択時は ２４時間電話サポートしている業者を

→　ゲームの場合、１時間でも停止すると大問題になる。
　深夜のトラブルでも 早急な復帰ができる業者を

→　それができない業者の場合、最悪 サーバーの復帰が翌朝になってしまう恐れがあったり・・・



・リリース時にサーバーリソースをケチらない

→　発売後の最初の１週間だけでも、サーバー台数は できるだけ最大数で
　その後、最適な数にまとめていく
　（クラウドサービスであれば、容易かつリーズナブルに変更できる）

[0回]