忍者ブログ
ゲームを作ったり、ゲームを遊びまくったりしている せっき~の生き様。   まずは目次をご覧ください
×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

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


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



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

すみません。



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

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


シェルノサージュ

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


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

シェルノサージュシェルノサージュ

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

→ クラウド (今回のテーマはコレ)



・シナリオパート

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

→ 追加コンテンツ
  (第2章までは無料、第三章以降有料)



・交流パート

シェルノサージュ

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

→ コミュニケーション




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

PSVITA のデータ
(例: 「着ている服」「疲れ具合」「機嫌」「交流履歴」「所持アイテム」 )

→ PS3 、スマートフォン 、WEBアプリ などの他の媒体で参照できる。



つまり

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


こういう事もできるかも??)  (あくまで構想)

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



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




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

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

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

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



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

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

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


通信手法       両方 https

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

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

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


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



シェルノサージュの実装

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

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

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



・こんな所に注意

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

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

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



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

●サーバー運用について

・サーバー構成

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




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



1.データベースサーバーの処理超過

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

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

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




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

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



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



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

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




技術的な注意点

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

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

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

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

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

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




●その他の注意点

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

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

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



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

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



拍手[0回]

PR
この記事にコメントする
お名前
タイトル
文字色
メールアドレス
URL
コメント
パスワード   Vodafone絵文字 i-mode絵文字 Ezweb絵文字
プロフィール
HN:
せっき~
性別:
男性
職業:
ゲームプログラマ
自己紹介:
古いパソゲー、ボードゲーム、カードゲームを熱狂的に遊んでいます。


ついったー
http://twitter.com/seki_seki_seki

連絡先は
sekisekiseki(あっと)gmail.com
最新コメント
[08/18 モンクレール ブランソン コピー]
[08/17 located here]
[08/17 resource]
[08/17 シュプリーム 激安]
[08/16 Ana Clara]
カウンター
ついったー

Copyright © [ せっき~のゲーム屋さん ] All rights reserved.
Special Template : 忍者ブログ de テンプレート and ブログアクセスアップ
Special Thanks : 忍者ブログ
Commercial message : [PR]