[Unite2019] 『SINoALICE -シノアリス- 』〜 それは最速のゲーム起動 〜
動画・スライド:なし
中原 雄一 株式会社ポケラボ
学んだ知見
- ゲーム開始時のロードが重い(データ量が多い、数が多い)場合は、
必要な場面で随時ダウンロードするようにするとよい- 起動の高速化
- 開発のサイクル高速化
- API通信料金の削減
- UXを工夫することで体感時間を削減できる効果が見込める
講演概要
開発環境
- Unity 2018.4.2f1
- middle ware
- Spine(2D animation)
- SPARK gear(3D effect)
- CRIWARE
対策前、対策後の紹介
起動時間:2分→5秒に短縮
ゲーム起動シーケンス紹介
- ログイン処理
- ユーザーデータのDL
- マスターのDL
- AssetBundleのチェック&DL
- アイコン、キャラSpine、敵Spine、バトルエフェクト、バトル背景、バナー、その他
- ResourceFileのチェック&DL
- AssetBundle化していないバイナリ(CRIWARE系のファイル)
- 動画、BGM、SE、キャラボイス、シナリオボイス
余談
アプリサイズは150MB以下を指標としている
ボトルネック紹介
- マスタDL
- 種類が多すぎる(80種類)
- 一部マスタのサイズが大きい
- カード(4MB) パラメータ
- クエスト(10MB) 敵、報酬
- シナリオ(5MB) ストーリー
- AssetBundle DL
- アイコン(4500種類) → ゲーム起動時
- Spineなど → 随時
- ボトルネックはアイコン
- ResourceFile DL
- ゲーム起動時にDL
- ボトルネック
- シナリオボイスの数
- ファイルチェック回数
- 動画の容量
対策内容紹介
マスタDL
そのそもの管理の仕方
- 各マスタはバージョン管理マスタで管理
更新方法
- エクセルからSQL作成
- 管理画面で入力
- 事前に解析
- 差分表示
- 適用
- バージョン管理マスタも同時に更新
ロードの処理フロー
- バージョンチェック
- リクエスト
- ローカルに保存しているマスタID配列
- バージョン配列
- レスポンス
- 差分があるマスタID配列
- リクエスト
- 必要なマスタ取得
- ローカルに保存
- マスタの種類
- ゲーム起動時にまるごと取得するのをやめる
- 必要なときに必要な分だけDL
- 既存APIのレスポンス内にマスタを含める
- サイズが大きい
- 使用していないマスタをフィルタリングして返す
- マスタ上の有効期限(startTime, endTime)で管理
- アプリで参照してないデータをフィルタリング
- サーバーで除外して返却
- 使用していないマスタをフィルタリングして返す
AssetBundle DL
アイコン
起動時にDL → 随時DLに変更
- アイコン表示部分をすべて対応
- 図鑑などアイコンが複数並ぶ画面は表示を行いながら非同期でDL
- キャッシュクリアなどを行うとアイコンが徐々に表示される挙動になるがそれは許容する
ResourceFile DL
- シナリオボイス
- 随時DLに変更
- ファイルチェック回数
- 更新があったときのみチェック&DL
- ResourceFile管理マスタで管理する
- id, file_name, size, md5_key
- マスタ生成は自動化
- git pullしたタイミングでjenkinsで実行
- ResourceFile管理マスタで管理する
- 更新があったときのみチェック&DL
- 動画
- 再生する場所で随時DL
- 過去イベントの動画はDLしない
- DLに時間がかかるためプログレスバーの表示
- 動画管理マスタで管理
- id, play_scene, place, start_time, end_time
プログレスバーの表現の工夫
- 1本のプログレスバー(0~100%)をスムーズに動かす
以下のように変更
DL完了したファイル数 / DLするファイル数
→ DLした容量 / DLする容量
(System.Net.WebClient.DownloadProgressChanged
を併用)
表現の工夫
- キャラ紹介画像削除
- タイトルタップしたらマイページへ遷移
- 新規キャラが増えたときとみ表示
まとめ
- マスタ
- 起動時にロードするデータを少なく
- ロードするマスタは小さく(使っていないデータをフィルタリング)
- AssetBundle, ResourceFile
- 随時DL方式にして分散すさせる
- ファイルチェックも時間がかかるので不要にIOアクセスを走らせない
- プログレスバーで表現の工夫をする
効果
今後チャレンジしたいこと
- バックグラウンドDL
- 一括DL、随時D選択
- 動画のストリーミング再生
- プログレスバーなどのUX工場
所感
- 考えればそうなるよなという話だった
- UXの話が興味深かった
- 他の講演では随時DLの方法をとらない紹介がいくつかあったので、消極的な対処法という印象を受けた
[Unite2019] Google Cloud for Games 〜オープンソースからマネージドサービスへ〜
動画・スライド:なし
※ スライドが公開されてないためメモ書き程度の内容になっています
学んだ知見
- agones
- k8sを活用したサービスの場合スケールアウトをより負担なくできる
- open match
- リアルタイムマッチング機能開発を新しくする場合に使える
講演概要
フォーカスしていること
googleだからこそ
- クロスプラットフォーム
- オープンソース
- ML&データ分析
- One Google
次世代マルチプレイヤーゲーム
- real-time multiplayer experiences
- planet-scale matchmaking
1.real-time multiplayer experiences
ゲームサーバとは?
- イベントを受け持つサーバ
- 正しいゲーム世界を表示するためにゲームの状態に関するデータを送受信
- リアルタイムかつ信頼できる方法で完了しなければならない
クライアント
- PC, コンソール、モバイル
- 単一プレイヤー サーバ
- Host, VM
- 対戦プレイヤー
ゲームサーバが行うこと
- 入力を受信
- 位置トラック
- 衝突、異動管理
- 物理演算
- ゲーム状態をプレイヤーに送信
毎秒120回にも及んで処理をしている!
よく使うP2Pモデル
なぜ専用サーバが必要か?
- すでにP2Pがあるし、無料
しかし、マルチスケールしない、チート対策できない
平均以下の体験になってしまう
専用サーバモデル
- 一貫性
- スケーラブル
- セキュア
ワールドクラスの体験
最近はこちらが主流(fort night, apexなど)
→ Dedicated Game Server
典型的なアーキテクチャ
クライアント → Matchmaker ←→ Server Manager ←→ 複数のDedicated Game Server
↓
Dedicated Game Server
自前で作ると…
- 外部依存なし
- コンテナ不要
- コーディング必須
- メンテの必要性
専用サーバのデプロイ
Gameserverをたくさんよういしてやる
もう1つのやり方、コンテナ化
agonesを利用?
Agonesについて
ゲームサーバのあれこれをコンテナで正しく動作させるために作られた
SDKの機能
- ゲームサーバのライフサイクル管理
- レディネス&停止
- ヘルスチェック
- アクセスと監視の設定
- 構成値を設定
agonesを使うと、スケールダウンについて起動中のセッションを落とさずに実行できる!!
k8sだけだと起動中のものも落ちてしまう
一般的にアロケートされたものを解除したいときは、APIで解除のメソッドを呼べばallocated → readyになる
Agonesのアーキテクチャ
クライアント → Custom Matchmaker → k8s API ←→ Agones → Dedicated Game Server
Google Cloud Game Servers(agones + Google Cloud)
フルマネージドAgones
Google Cloudで グローバル&リアルタイム&マルチプレイヤー
ゲームをローンチする最もかんたんな方法
高いパフォーマンスも発揮できる
2. planet-scale matchmaking
open match
- マッチメイクフレームワーク
- 柔軟性、スケーラビリティ、拡張性にフォーカス
doodle ハロウィンで初めて利用された
アーキテクチャ
player ←→ Game Frontend → Hosted Environment(open match) ← director → Servers
Game Frontend: チート対策のために、open matchを直セスアクセスさせない(ロビーでプレイヤー情報を確認する)
director: マッチングをトリガーするプロセス
fake player0/1 → create ticket
match
return assignment to open match by director
return assignment to fake player0/1 by open match
ticker: 試合をリクエストしているプレイヤー
assignment: open matchからチケット作成者に情報が返る
現状のopen matchはv0.7
open matchの事例
- kick flight
- 360ど空中対戦アクションゲーム
- 4vs4のリアルタイムバトル
[Unite2019] AWS for Unity Developers
動画・スライド:https://learning.unity3d.jp/3248/
下田 純也 アマゾンウェブサービスジャパン株式会社
Fan Liang アマゾンウェブサービスジャパン株式会社
学んだ知見
1.ビルド時間の調査
- アセットバンドルビルド
- プロセスを並列化してビルドが効果大
- ゲーム本体のビルド
- スケールアップが効果大
2.Amazon GameLift
- セッションベースのマルチプレイヤーゲーム用サービス
- サーバの運用、デプロイ、スケーリングをサポート
- マッチング管理が楽
- ロジック作成に専念
講演概要
AWSの活用例
- ゲームサーバとしてマルチプレイヤーゲームでの利用
問題点
- リアルタイムな通信の確保
- マッチメイキングの実装
→ Amazon GameLift
- セッションベースのゲームサーバ構築
- メリット
- 手間がかからない
- 低レイテンシの実現
- ローコスト、ハイスケール
- 相手のスペックに応じた適切なメイキングシステム(Flex Match)
サンプルデモとしてAmazon GameLiftを用いた対戦型のテトリスの紹介がありました
例として以下のように「クライアント - ゲームサーバ - Amazon GameLift」の接続が行われています