シンラ・テクノロジー第2回クラウドゲーム開発者会議

クラウド専用ゲームの
設計と実装
第2回クラウドゲーム開発者会議2014@東京
中嶋謙互
github.com/kengonakajima
twitter.com/ringo
Ⓒ2014 Shinra Technologies, Inc. All Rights Reserved.

自己紹介
• 1996 MMORPG Lifestormシリーズ合計3作
• 2000 コミュニティーエンジン㈱, VCE
• 2004 MMOサンドボックスgumonji
• 2010 書籍「オンラインゲームを支える技術」
• 2014 PS VITA® AIRSHIPQ®（未発売）
• 2014 シンラ・テクノロジー・チームに参画

シンラ・テクノロジーでの担当
• Shinra Community SDKの開発、サポート、普及

今日の内容
1.クラウドゲームの用語整理
2.スペース・スゥイーパーの設計
3.スペース・スゥイーパーの同期に関する詳しい話
4.Shinra Community SDK(仮称)の予定について

1. クラウドゲーム

クラウドゲーム?
• ストリーミングゲーム
• クラウド専用ゲーム
1.クラウドゲーム

クラウド専用ゲームとは
• サーバ上で動作させる前提で作られ、
• 一般ユーザにそのものを配布することができないゲーム

クラウドゲームのメリット
• タイトルごとにインストールする必要がない
• タイトルごとのアップデートがない
• 起動が早い
• 海賊行為がやりにくい
• 高性能な端末が不要
• 開発、移植、運営、更新のコスト低減
• これまでにない内容のゲームが作れるかも
• これまでにない方法で商売ができるかも
ストリーミングゲームにも
クラウド専用ゲームにもある特性
ストリーミングゲームにはないが
クラウド専用ゲームにはある特性

クラウドゲームの課題
• 帯域: 高速回線が常に必須
• 遅延: 光速“1000kmの円”
• コスト: サーバ側のCPU/GPU, 回線

1000km/2000kmの円
Amazon EC2® リージョンがあるところ

実測例(往復時間)
• 富山<-> 大阪IX <-> 東京IIJ <-> yahoo.co.jp 30ms
• 富山<-> 東京kddi <->東京Linode 9ms
• 東京(Linode) <-> 北大ntp.hokudai.ac.jp 18ms
• 東京(Linode) <-> 九大ns.nc.kyushu-u.ac.jp 19ms
• 東京(Linode) <-> 阪大11ms (光速の3分の1)
* シンラ・テクノロジーでは外部の協力を得てもっと詳しい調査をしています

モバイル
2020年、10Gbps/1ms？
http://www.itmedia.co.jp/mobile/articles/1310/04/news082.html から写真を引用

シンラ・テクノロジーの特徴
• 技術インフラ
• リモートレンダリング
• 探求の方向性
• クラウドでしか作れないゲーム内容とは、
どのようなものか？実際にコンテンツを作って検証する
。

シンラ・テクノロジーの探求
• これまでにない内容のゲームが作れるはず
• 巨大メモリ・膨大なCPU/GPU時間を共有するゲーム
• 高速なプロセス間通信を使うゲーム
• 逆に極めて短時間・高頻度・小さい画面を使うゲーム
• 開発や移植のコスト低減
• 少人数マルチプレイではネットコードがまるごと不要になる
• セキュリティコード不要: リバースエンジニアリングされない
• エラー処理、非同期処理不要: プロセス間の通信は安定高速
• プラットフォーム移植不要、移植層も不要: ゲームの長寿命化？
• アップデートの工夫不要
• プログラム終了、電源プチ、回線断はバグ扱いにできる
• などなど
• 経験や工夫をどこまで一般化・共有化できるか？

2. スペース・スゥイーパーの設計

シンラ・システムで推奨する基本3パターン
1:1 (Stand-alone model) 1:N (MC model)
インターネット
game
Viewer
Viewer
Viewer
Viewer
Viewer
game
game
game
game
game
Viewer
Viewer
Viewer
Viewer
Viewer
backend
game
game
game
game
game
Viewer
Viewer
Viewer
Viewer
Viewer
game
game
Viewer
Viewer
Viewer
Viewer
Viewer
backend
N:N (Virtual MMO model)
ゲームプレイ空間
M:N (参考)

1:N とN:N
game
Viewer
Viewer
Viewer
Viewer
Viewer
game
game
game
game
game
Viewer
Viewer
Viewer
Viewer
Viewer
backend
1:N (MC model) N:N (Virtual MMO model)
•ゲームプロセスは1個
•複数のレンダリングターゲットに描画
•ネットコード一切無し
•少人数向けならこれが鉄板
•これが多人数向けにも使えたら。。(誰か!)
•ゲームプロセスは多数
•ネットコードは必要
•多人数向けにはまだ必要
•もっと簡単にできないか？ (誰か!)

スペース・スゥイーパーの構成
game.exe
game.exe
game.exe
game.exe
game.exe
Viewer
Viewer
Viewer
Viewer
Viewer
realtime_sv
Redis database_sv
Plain files
映像ストリーム
N:N (Virtual MMO model)

比較: 従来型MMOの構成
game.exe
game.exe
game.exe
game.exe
game.exe
Redis game_sv
Plain files

比較: 従来型MOの構成
game.exe
game.exe
game.exe
game.exe
game.exe
realtime_sv
Redis database_sv
Plain files
host
guest
guest
guest
guest

本日のデモの構成
VAIO 1
ゲームのサーバVAIO 2
ゲームのクライアントと
launcher
game.exe
realtime_sv
Redis database_sv
Plain files
MSI
game.exe
game.exe
game.exe
renderer0
レンダラ
シンラ・システム無し
GbE
HUB
VAIO 3
30FPS
Viewer
VAIO 4
60FPS
Viewer
VAIO 5
30FPS+100ms
Viewer

シンラ・システム無し
VAIO 1
launcher
game.exe
realtime_sv
Redis database_sv
Plain files
MSI
game.exe
game.exe
game.exe
renderer0
レンダラ
Shinra無し
GbE
HUB
VAIO 3
30FPS
Viewer
VAIO 4
60FPS
Viewer
VAIO 5
30FPS+100ms
Viewer

シンラ・システムあり
VAIO 1
launcher
game.exe
realtime_sv
Redis database_sv
Plain files
MSI
game.exe
renderer0
レンダラ
Shinra無し
GbE
HUB
VAIO 3
30FPS
Viewer
VAIO 4
60FPS
Viewer
VAIO 5
30FPS+100ms
Viewer
プレイヤー操作
映像

シンラ・システム+ 10ms(送受信)
VAIO 1
launcher
game.exe
realtime_sv
Redis database_sv
Plain files
MSI
game.exe
renderer0
レンダラ
GbE
HUB
VAIO 3
30FPS
Viewer
VAIO 4
60FPS
Viewer
VAIO 5
30FPS+100ms
Viewer
プレイヤー操作
映像
10ms

ストリーミング負荷
• 送信は一貫して100KB/sec以下
• 60FPS
• カメラ引き: 4.3MB/sec
• カメラ接近: 3.7MB/sec
• タイトル画面: 2.7MB/sec
• 30FPS
• 送受信ともにちょうど2分の1
• 差分圧縮が入って数分の1になる予定
• 解像度: 1280 x 720

Fake DLL

トータルコストの削減
* 通信のオーバーヘッドを含めても大幅にトータルコストを削減できることが確認された。(DeusEx3で2倍)

バックエンドとの通信(VCE)
ssproto.txt
ssproto_sv.cpp/h
gen.rb
ssproto_cli.cpp/h
変換
realtime_sv
database_sv
game.exe
link
link

バックエンドの設計
• game.exe間は直接通信せず、サーバ経由でのみ通信
• 1ゲーム同時100~200接続と多いため
• バグの追いやすさ
• channel/near/broadcast の3種類
• ストレージアクセスと同期用のリアルタイム通信を分離
• 静的ファイルやDBMSにアクセスする時の遅れを心配
• ストレージ用とリアルタイム用を独立にスケールできるように
• ストレージは同時接続1000あたり1プロセス。Disk I/Oが律速
• リアルタイム用は同時接続100~200あたり1プロセス。Netが律速
* すべてシンラ・システムの規定ではなくSpaceSweeperの判断

2つのバックエンド
game.exe
game.exe
game.exe
game.exe
game.exe
realtime_sv
Redis database_sv
Plain files

database server (保存用)
• Redisアクセスと静的ファイルのアクセスの順序制御/Atomic化
のために1プロセスを挟んでいる。
• Redisのコマンド文字列をgame.exeで作ってそのまま実行する。
game.exeが信頼できるため安全性、異常性検証などを省略。
• ファイルput/getもそのまま安全性検証せず、ファイルパスまでgame.exe
で作ってそのまま送受信
game.exe
game.exe
game.exe
game.exe
game.exe
* シンラ・システムでは1プロセスを挟むことは規定していない。
* Redisも規定していない。必要に応じてlibmysqlclientを直接game.exeに組み込んだりもOK
realtime_sv
Redis database_sv
Plain files

ストレージの実装パターン
game.exe
game.exe
game.exe
game.exe
game.exe
game.exe
game.exe
game.exe
game.exe
game.exe
Redis database_sv
Plain files
game.exe
game.exe
game.exe
game.exe
game.exe
WebAPI
realtime_sv
MySQL
スペース・スゥイーパーこんなのもOK
Samba
シンラ・システムの
デフォルト
* シンラ・システムではストレージのあり方を規定していない。

ストレージの速度
• 1MB送信確認までが3ms以下なので、非同期処理は
必要ありません。

realtime server (同期用)
• channelcast : publish/subscribe プロジェクトごと
• nearcast : XY座標で範囲指定、範囲判定はサーバで行う
• broadcast : デバッグ用以外では使っていない
• オンメモリの単純なカウンタベースのLock
• Grid Lock(後述)
• ユーザのPresence (コンタクト自体はdatabaseで保存)
• プロジェクトのPresence
game.exe
game.exe
game.exe
game.exe
game.exe
realtime_sv
Redis database_sv
Plain files

channelcast / nearcast
game.exe
game.exe
game.exe
game.exe
1Mbps
realtime_sv
channelcast
ch1
1Mbps
1Mbps
1Mbps
nearcast
game.exe
game.exe
game.exe
game.exe
ch1
realtime_sv
1Mbps
1Mbps
0Mbps
0Mbps
30m
200m
250m

同期用realtime serverは必要か？
• 少人数ゲーム: 1:Nモデルで実装可能なので不要
• 多人数ゲーム:
• フルメッシュ接続: あまり選択されてこなかった。しかし今
後はありかも。(TCP/IPヘッダの無駄)
• 同期用サーバ接続: サーバプロセスは無いほうがいい
• LANなのでUDPブロードキャスト・マルチキャストも利用可
能。誰かやってみて。。

3. 同期の詳細
*ストレージについては、問題がなさすぎて特に詳しく説明する必要がなかった
3. 同期の詳細

作業の進み方
1. game.exe通信量や内容を気にせず送る
2. 気づいたら30Mbpsになっていた。
ネットワーク用にCPUを使いすぎていた。
3. 敵の数を減らしたくないので、同期頻度下げ圧縮も使
う。簡単な調整で3~4Mbps程度に削減。
3. 同期の詳細

ゲームデータの概要
Player Project
Project
Project
Field
Milestone
Research
Fortress
PowerGrid
ResourceNetwork
Friend
Friend
3. 同期の詳細

同期送信の比率
• 敵の移動50%
• 地形セルの変化40%
• PCの移動5%
• 音、エフェクト4%
• メッセージとかこまごま1%
3. 同期の詳細

チャンク
チャンクサイズ: 16x16セル
サイズ: 16KB, 圧縮1.5KB
3. 同期の詳細

全体サイズ: 2048x2048セル
チャンク数: 65536
サイズ: 128MB
見えてる範囲: 15x10チャンク
Player 1
Player 2
3. 同期の詳細

変化する速さ(PCの操作による)
3. 同期の詳細
(映像は削除)

変化する速さ(自動的な変化)
「タイミングをあわせて攻撃
」を実現したい。
単体では遅いが、数が多い
3. 同期の詳細
(映像は削除)

フィールド状態の同期
• PC操作による地形変化
• 即、1セル単位
• 自動的な地形変化
• 即、チャンク単位、1フレームあたり2チャンクま
で(4KB*2)送信
3. 同期の詳細

チャンク単位のLock
3 3
2 2 2 2 4 4 4 4
2 2 2 2 4 4 4 4 4
2 2 4 4 4 4 4
1 2 4 2 4 4 4 4 4
1 1 1 4 2 4
1 1 1 1 2 2
1 1 1 1 1
1 1 1 1
PC4が見ている範囲
3. 同期の詳細

Project単位のLockもある
PC1 PC2
1秒の異常終了を確実に検知
3. 同期の詳細

敵キャラの同期
• 決定論的運動するもの: 出現時のみnearcast
• 動的なもの: 0.5~2秒に1回、位置、速度、目的位置
をnearcast (48bytes)
• Kill : channelcast
3. 同期の詳細

今後、試してみたいこと
• 1:Nモデルの人数を上げていく
• RPCより軽い実装も面倒でない同期の方法
3. 同期の詳細

4. Shinra Community SDK (仮)

Shinra Community SDKの目的
• シンラ・システムを極限までチューンしないような
ゲームを、高速にプロトタイプ、テスト、パブリッ
シングできるようにすること。
4. Shinra Community SDK

1. 普通にgame.exe を作る
2. ZIPに箱詰めする3. Shinraクライアントにドロップ
ShinraPack.exe
入力映像と音声
開発用マシン
シンラ・テクノロジーサーバマシン
Launcher server
VM
4. ランチャーに送られる
5. VM起動,インストール
6.game.exeやバックエンドサーバを
必要に応じて起動
User database
VisualStudioなどを利用

できること(予定)
1. ローカルでゲームを作成し、
2. ストリームテストし、
3. Packし、
4. 本番サーバに上げてテスト〜パブリッシングまで

内容物(予定)
• ローカルレンダリング版fake DLLセット
• ストリームViewer
• スペース・スゥイーパーのgame.exe, サーバのソー
ス全体
• その他サンプルプログラム
• Shinra Packer

技術サポート体制(検討中)
• モントリオールと日本のエンジニアがチームで対応し
ます。
• 日本のチームには私も含まれます。
• 詳しい窓口などについては現在調整中です
• 個別の相談が可能です

スケジュール(検討中)
• 2015Q2までにN:Nの制作と実機テストが可能に
• 1:1→1:N→N:N の順番で開発を進行
• 可能なタイミングでプレビュー版(を出したい)

シンラ・テクノロジー第2回クラウドゲーム開発者会議

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to シンラ・テクノロジー第2回クラウドゲーム開発者会議

Similar to シンラ・テクノロジー第2回クラウドゲーム開発者会議 (20)

Recently uploaded

Recently uploaded (10)

シンラ・テクノロジー第2回クラウドゲーム開発者会議