しがないエンジニアのブログ

技術的な内容をメモ代わりにつらつら

[Unite2019] 『SINoALICE -シノアリス- 』〜 それは最速のゲーム起動 〜

動画・スライド:なし

中原 雄一 株式会社ポケラボ


学んだ知見

  • ゲーム開始時のロードが重い(データ量が多い、数が多い)場合は、
    必要な場面で随時ダウンロードするようにするとよい
    • 起動の高速化
    • 開発のサイクル高速化
    • API通信料金の削減
  • UXを工夫することで体感時間を削減できる効果が見込める

講演概要

開発環境

  • Unity 2018.4.2f1
  • middle ware
    • Spine(2D animation)
    • SPARK gear(3D effect)
    • CRIWARE

対策前、対策後の紹介

起動時間:2分→5秒に短縮

ゲーム起動シーケンス紹介

  • ログイン処理
  • ユーザーデータのDL
  • マスターのDL
    • マスタごとにAPIを実行(80種類)
    • ローカルに保存(SQLite
  • 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で実行
  • 動画
    • 再生する場所で随時DL
    • 過去イベントの動画はDLしない
    • 動画管理マスタで管理
      • id, play_scene, place, start_time, end_time

プログレスバーの表現の工夫

以下のように変更
DL完了したファイル数 / DLするファイル数
→ DLした容量 / DLする容量
System.Net.WebClient.DownloadProgressChangedを併用)

表現の工夫

  • キャラ紹介画像削除
    • タイトルタップしたらマイページへ遷移
    • 新規キャラが増えたときとみ表示

まとめ

  • マスタ
    • 起動時にロードするデータを少なく
    • ロードするマスタは小さく(使っていないデータをフィルタリング)
  • AssetBundle, ResourceFile
    • 随時DL方式にして分散すさせる
    • ファイルチェックも時間がかかるので不要にIOアクセスを走らせない
    • プログレスバーで表現の工夫をする

効果

  • お客様に喜んでもらえた
  • 新規インストールのDL料が減った
  • CDN料金が減った
  • 開発のPDCAが早くなった

今後チャレンジしたいこと

  • バックグラウンドDL
  • 一括DL、随時D選択
  • 動画のストリーミング再生
  • プログレスバーなどのUX工場

所感

  • 考えればそうなるよなという話だった
  • UXの話が興味深かった
  • 他の講演では随時DLの方法をとらない紹介がいくつかあったので、消極的な対処法という印象を受けた

[Unite2019] Google Cloud for Games 〜オープンソースからマネージドサービスへ〜

動画・スライド:なし

ハムディ サミール グーグル・クラウド・ジャパン合同会社

※ スライドが公開されてないためメモ書き程度の内容になっています


学んだ知見

  • agones
    • k8sを活用したサービスの場合スケールアウトをより負担なくできる
  • open match
    • リアルタイムマッチング機能開発を新しくする場合に使える

講演概要

フォーカスしていること

  • ゲームサーバホスティング
  • プラットフォームサービス
    • マッチメイキング、アイテム管理など
  • ゲーム分析

googleだからこそ

次世代マルチプレイヤーゲーム

  1. real-time multiplayer experiences
  2. 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つのやり方、コンテナ化

  • どのk8s環境でも実行可能
  • OSSでコミュニティが開発
  • コンテナ化は必須
    • OSの選定が必要になる

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

  • シンプル
  • 柔軟
  • OSSと同じSDK

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」の接続が行われています

tips

  • 開発環境はローカルで作れない
  • ログ確認はLogErrorをみるとよい

所感

  • AWSの利用説明はざっくりとで、主にGameliftの説明が主だった
  • APIサーバの構築例なども軽く紹介されていたので、
    AWS活用のノウハウがない場合のスライドとしては有用な資料だと思う
  • マルチプレイゲームの知見がない場合にはこの資料を参考にすればとっかかりにはよい