一般社団法人コンピュータエンターテインメント協会(CESA)が、8月30日~9月1日の3日間パシフィコ横浜にて開催している、国内最大のゲーム開発者向けカンファレンス「コンピュータ・エンターテインメント・デベロッパーズ・カンファレンス 2017」(CEDEC 2017)。
本稿では、8月30日に実施された講演「アナザーエデンにおける非同期オートセーブを用いた通信待ちストレスのないゲーム体験の実現」についてのレポートをお届けしていく。 本セッションでは、グリー<3632>の鈴木清人氏、西田綾佑氏が登壇。『アナザーエデン』の特徴ともいえるオートセーブ機構を中心に、それらの基盤技術であるLevelDBやDynamoDBおよびflatbuffersについて話を展開した。
▲グリーのWright Flyer Studios事業本部にてリードエンジニアを務める鈴木氏。『アナザーエデン』では、サーバ・クライアントのデータモデル、通信モデルのほか、アセットパイプラインやプロジェクト体制も含めたゲーム制作・運用システム全体の設計、実装を手がけている。
▲同じくグリーのWright Flyer Studios事業本部にてエンジニアを務める西田氏。『アナザーエデン』では、StateMachineを導入したゲームループとイベントハンドラの設計、UIフレームワークの整備、サウンド基盤、ネットワーク基盤、データストア、アセット管理周りを主に担当。
2017年4月12日に配信が開始されたシングルプレイ専用スマートフォンRPG『アナザーエデン 時空を超える猫』。『クロノ・トリガー』などを手掛けてきた加藤正人氏がシナリオを担当し、このご時世では珍しくシングルプレイによるストーリーモードの充実が特徴だ。同年8月には300万DLを突破し、今もなお人気を集めている。
『アナザーエデン』は一般的なスマートフォンゲームと異なり、ホーム画面がない。これにより世界観への没入を阻害しないプレイ体験が実現されているが、そのためにはサーバへの問い合わせといったシステム上の制約を、できるだけユーザに感じさせないような通信およびデータ保存の仕組みを構築する必要があった。
そもそも『アナザーエデン』は、“コンシューマゲームとスマホゲームの差異を解消する”という製作時の主要なテーマがあったと鈴木氏。そのために可能な限りコンシューマゲームに近付ける形を目指したという。
▲モバイルゲームにおけるクライアントとサーバのパラダイムシフト。現在はNativeApp全盛だが、『アナザーエデン』はその次の段階を目標に、サーバの行動が小さくなり、逆にクライントの行動が非常に大きくなると考えた。
▲スマホ、コンシューマ、アナザーエデンそれぞれのゲームサイクルや雇用形態などの特徴一覧。
『アナザーエデン』のグランドデザインは「クライント>サーバ」という構造になっている。そのためにはバックグラウンドでのデータ同期、データスキーマの共有、クライアントサイドDBMS、一歩含みこんだチート対策が必要となった。
▲「クライント>サーバ」の構図と説明。
「バックグラウンドでのデータ同期」とは、具体的にどういうことか。『アナザーエデン』では、基本的にサーバでデータを作らず、クライアントで作った差分を随時サーバーに送る。Dropbox等のオンラインストレージサービスのPC用クライアントアプリでは一般的な手法で、かなり高いレベルでバックグラウンド同期を実現できる。
これにより、ユーザ側は通信していないかのように見え、ネットワークの通信状態が悪くてもユーザのプレイが邪魔されない。サーバ側も速さではなく、遅いが他の特徴をもったDBを選択できるというメリットがあると鈴木氏は話した。
続いて、西田氏は『アナザーエデン』における「オートセーブ」について説明。他のゲームで頻繁に見られる通信中の画面を可能な限り無くすことが目標だったという。
▲上記の4項目を確保するオートセーブ機能を目指した。
▲ゲーム中は左上部分に「Auto Saving...」と表示される。この1フレーム目にオートセーブ処理が走り、2フレーム目にはゲームサーバに同期処理がバックグラウンドで走っている。
▲右のステートから、左の「ExplorerState」に戻るタイミングでオートセーブを行っている。
その後、西田氏は「オートセーブで何を保存しているのか」を説明。基本的にユーザデータに変更があるかどうかで判定しており、メモリ上のdirty flagを精査。dirtyなレコードをローカルDBに書き込みを行う。その後、差分一覧をサーバ通知用に別で保存するという流れだ。ゲーム上で「Auto Saving...」が表示されたタイミングで、クライアント側ではローカルDBにデータの書き込みが完了している。そのため、途中でアプリを落としたとしても、オートセーブの場所から再度立ち上げることが可能だ。以上が、ステートマシンにおけるセーブポイントの説明となる。
続けて話題は「キューイングとバックグラウンド通信」に。ネットワーク通信中表示を極力なくし、ネットワーク環境にできるだけ依存しないオートセーブ機能を実装した『アナザーエデン』。「クライアントの最新状態=サーバのミラー状態+前回の保存からの差分」という等式を、出来る限り、無理のない範囲でバックグラウンドで実施することに努めたという。すべては、プレイヤーの操作をなるべく止めないためだ。以下の写真は、クライアントからサーバへの同期方法を示す。
いくらバックグラウンドに寄せたとしても、プレイヤーの操作を一時的に止める場面は出て来る。簡単に言えば「ローディング画面」がソレだ。西田氏はこの通信を「ブロッキング通信」と呼び、有償通貨を使用したキャラクター抽選や、ギフトやクエスト報酬などの有償通貨を報酬にする機能に実装している。
▲ブロッキング通信が発生した場合の挙動。
「サーバはクライアントのミラーストレージである」という形式で作られた『アナザーエデン』だが、サーバ側でデータを変更したいという場合もある。しかし、それでは「クライアントの最新状態=サーバのミラー状態+前回の保存からの差分」の等式が成り立たない。そこで、西田氏たちはサーバからクライアントへのDBの更新命令セットを定義。その名も「Operation Builder」である。
▲この流れにより、クライアントが親としてデータを変更する流れを保ったまま、サーバからの変更を実現した。
▲「Operation Builder」のサーバ、およびクライアント側それぞれのキモ。
プレゼンターは再び鈴木氏へ。『アナザーエデン』で使用されている「LevelDB」「DynamoDB」「FlatBuffers」について語られた。
まず、モバイルOSで動作する信頼できるフルセットのRDBMSの存在が見当たらず、シンプルな構造のKBSならあるだろうと探していたところ「LevelDB」を発見。クライアントサイドのDBとした。そして、サーバサイドで対応するDBを「DynamoDB」に選んだという。それぞれの特徴は下記の写真の通り。
「FlatBuffers」に関しては、DSLとして利用し、独自拡張をしているという。
これまでの方式を使って開発された『アナザーエデン』は、実際にどうなっているか。「オートセーブの運用の実際」というタイトルで、その詳細が説明された。現在の規模感としては300万DLを突破し、プレイ時間は通しで約40~60時間ほど。「LevelDB」のデータサイズは最大1MB程度で、「DynamoDB」のPartition数は約128(UserData概算)。これまでのサーバ障害でのサービス停止は4回程度で、内訳は「DynamoDB」のキャパシティ管理のオペミスが3回、Redisのマスターノードダウン時の自動FailOverの失敗が1回とのこと。
▲「DynamoDB」の負荷が分かる、ローンチ後のスループットの推移。
▲1週間に切り分けた場合。平日は昼休みに山があるが、大体22時~23時がピーク。土日は朝からプレイする方が多い。
▲「DynamoDB」運用における実施一覧。
最後のまとめでは、2人が「オートセーブ機構の是非」についてコメント。鈴木氏は、オートセーブ機構を「Google Firebase Realtime Database」や「AWS Cognito」などのマネージメントサービスの独自実装版であるという。異なるのは以下の3点だと紹介した。
・「FlatBuffers」を用いることでSchemaをきちんと定義し、中規模ソフトウェア開発におけるコストやリスクを低減
・スケールアウトするDBを利用し、特性を把握しつつ運用することで、運営のリスクを低減
・チート対策においては、オートセーブ機構の一部として各種の対応をビルトインすることで、ゲーム特有のセキュリティの問題に対処している
西田氏は「なにも考えずにすべての通信をブロッキング通信にしていませんか?」と、開発者たちに問いかけた。適切に制御することでバックグラウンドに寄せられるものは多い。しかしながら、『アナザーエデン』のようなゲームデザインがあってこその通信モデルであることも認めており、適宜寄せられるところは寄せる形が良いだろうと語った。
反省点としては、データが壊れた場合の修復がスマートではなかったという。これに対して、データを2系統で持っていくべきだったという社内の声もあったが、現状はサポートツールなどを用いて、遠隔で補正するシステムを作っていたため、手を動かせば救えるという形になっているようだ。ともあれ、オートセーブ機構のおかげで、ここまで『アナザーエデン』を快適にプレイできるようになった。そのことは良かったかなと思うと感想を述べ、発表を終了した。
本稿では、8月30日に実施された講演「アナザーエデンにおける非同期オートセーブを用いた通信待ちストレスのないゲーム体験の実現」についてのレポートをお届けしていく。 本セッションでは、グリー<3632>の鈴木清人氏、西田綾佑氏が登壇。『アナザーエデン』の特徴ともいえるオートセーブ機構を中心に、それらの基盤技術であるLevelDBやDynamoDBおよびflatbuffersについて話を展開した。
▲グリーのWright Flyer Studios事業本部にてリードエンジニアを務める鈴木氏。『アナザーエデン』では、サーバ・クライアントのデータモデル、通信モデルのほか、アセットパイプラインやプロジェクト体制も含めたゲーム制作・運用システム全体の設計、実装を手がけている。
▲同じくグリーのWright Flyer Studios事業本部にてエンジニアを務める西田氏。『アナザーエデン』では、StateMachineを導入したゲームループとイベントハンドラの設計、UIフレームワークの整備、サウンド基盤、ネットワーク基盤、データストア、アセット管理周りを主に担当。
2017年4月12日に配信が開始されたシングルプレイ専用スマートフォンRPG『アナザーエデン 時空を超える猫』。『クロノ・トリガー』などを手掛けてきた加藤正人氏がシナリオを担当し、このご時世では珍しくシングルプレイによるストーリーモードの充実が特徴だ。同年8月には300万DLを突破し、今もなお人気を集めている。
『アナザーエデン』は一般的なスマートフォンゲームと異なり、ホーム画面がない。これにより世界観への没入を阻害しないプレイ体験が実現されているが、そのためにはサーバへの問い合わせといったシステム上の制約を、できるだけユーザに感じさせないような通信およびデータ保存の仕組みを構築する必要があった。
そもそも『アナザーエデン』は、“コンシューマゲームとスマホゲームの差異を解消する”という製作時の主要なテーマがあったと鈴木氏。そのために可能な限りコンシューマゲームに近付ける形を目指したという。
▲モバイルゲームにおけるクライアントとサーバのパラダイムシフト。現在はNativeApp全盛だが、『アナザーエデン』はその次の段階を目標に、サーバの行動が小さくなり、逆にクライントの行動が非常に大きくなると考えた。
▲スマホ、コンシューマ、アナザーエデンそれぞれのゲームサイクルや雇用形態などの特徴一覧。
『アナザーエデン』のグランドデザインは「クライント>サーバ」という構造になっている。そのためにはバックグラウンドでのデータ同期、データスキーマの共有、クライアントサイドDBMS、一歩含みこんだチート対策が必要となった。
▲「クライント>サーバ」の構図と説明。
「バックグラウンドでのデータ同期」とは、具体的にどういうことか。『アナザーエデン』では、基本的にサーバでデータを作らず、クライアントで作った差分を随時サーバーに送る。Dropbox等のオンラインストレージサービスのPC用クライアントアプリでは一般的な手法で、かなり高いレベルでバックグラウンド同期を実現できる。
これにより、ユーザ側は通信していないかのように見え、ネットワークの通信状態が悪くてもユーザのプレイが邪魔されない。サーバ側も速さではなく、遅いが他の特徴をもったDBを選択できるというメリットがあると鈴木氏は話した。
続いて、西田氏は『アナザーエデン』における「オートセーブ」について説明。他のゲームで頻繁に見られる通信中の画面を可能な限り無くすことが目標だったという。
▲上記の4項目を確保するオートセーブ機能を目指した。
▲ゲーム中は左上部分に「Auto Saving...」と表示される。この1フレーム目にオートセーブ処理が走り、2フレーム目にはゲームサーバに同期処理がバックグラウンドで走っている。
▲右のステートから、左の「ExplorerState」に戻るタイミングでオートセーブを行っている。
その後、西田氏は「オートセーブで何を保存しているのか」を説明。基本的にユーザデータに変更があるかどうかで判定しており、メモリ上のdirty flagを精査。dirtyなレコードをローカルDBに書き込みを行う。その後、差分一覧をサーバ通知用に別で保存するという流れだ。ゲーム上で「Auto Saving...」が表示されたタイミングで、クライアント側ではローカルDBにデータの書き込みが完了している。そのため、途中でアプリを落としたとしても、オートセーブの場所から再度立ち上げることが可能だ。以上が、ステートマシンにおけるセーブポイントの説明となる。
続けて話題は「キューイングとバックグラウンド通信」に。ネットワーク通信中表示を極力なくし、ネットワーク環境にできるだけ依存しないオートセーブ機能を実装した『アナザーエデン』。「クライアントの最新状態=サーバのミラー状態+前回の保存からの差分」という等式を、出来る限り、無理のない範囲でバックグラウンドで実施することに努めたという。すべては、プレイヤーの操作をなるべく止めないためだ。以下の写真は、クライアントからサーバへの同期方法を示す。
いくらバックグラウンドに寄せたとしても、プレイヤーの操作を一時的に止める場面は出て来る。簡単に言えば「ローディング画面」がソレだ。西田氏はこの通信を「ブロッキング通信」と呼び、有償通貨を使用したキャラクター抽選や、ギフトやクエスト報酬などの有償通貨を報酬にする機能に実装している。
▲ブロッキング通信が発生した場合の挙動。
「サーバはクライアントのミラーストレージである」という形式で作られた『アナザーエデン』だが、サーバ側でデータを変更したいという場合もある。しかし、それでは「クライアントの最新状態=サーバのミラー状態+前回の保存からの差分」の等式が成り立たない。そこで、西田氏たちはサーバからクライアントへのDBの更新命令セットを定義。その名も「Operation Builder」である。
▲この流れにより、クライアントが親としてデータを変更する流れを保ったまま、サーバからの変更を実現した。
▲「Operation Builder」のサーバ、およびクライアント側それぞれのキモ。
プレゼンターは再び鈴木氏へ。『アナザーエデン』で使用されている「LevelDB」「DynamoDB」「FlatBuffers」について語られた。
まず、モバイルOSで動作する信頼できるフルセットのRDBMSの存在が見当たらず、シンプルな構造のKBSならあるだろうと探していたところ「LevelDB」を発見。クライアントサイドのDBとした。そして、サーバサイドで対応するDBを「DynamoDB」に選んだという。それぞれの特徴は下記の写真の通り。
「FlatBuffers」に関しては、DSLとして利用し、独自拡張をしているという。
これまでの方式を使って開発された『アナザーエデン』は、実際にどうなっているか。「オートセーブの運用の実際」というタイトルで、その詳細が説明された。現在の規模感としては300万DLを突破し、プレイ時間は通しで約40~60時間ほど。「LevelDB」のデータサイズは最大1MB程度で、「DynamoDB」のPartition数は約128(UserData概算)。これまでのサーバ障害でのサービス停止は4回程度で、内訳は「DynamoDB」のキャパシティ管理のオペミスが3回、Redisのマスターノードダウン時の自動FailOverの失敗が1回とのこと。
▲「DynamoDB」の負荷が分かる、ローンチ後のスループットの推移。
▲1週間に切り分けた場合。平日は昼休みに山があるが、大体22時~23時がピーク。土日は朝からプレイする方が多い。
▲「DynamoDB」運用における実施一覧。
最後のまとめでは、2人が「オートセーブ機構の是非」についてコメント。鈴木氏は、オートセーブ機構を「Google Firebase Realtime Database」や「AWS Cognito」などのマネージメントサービスの独自実装版であるという。異なるのは以下の3点だと紹介した。
・「FlatBuffers」を用いることでSchemaをきちんと定義し、中規模ソフトウェア開発におけるコストやリスクを低減
・スケールアウトするDBを利用し、特性を把握しつつ運用することで、運営のリスクを低減
・チート対策においては、オートセーブ機構の一部として各種の対応をビルトインすることで、ゲーム特有のセキュリティの問題に対処している
西田氏は「なにも考えずにすべての通信をブロッキング通信にしていませんか?」と、開発者たちに問いかけた。適切に制御することでバックグラウンドに寄せられるものは多い。しかしながら、『アナザーエデン』のようなゲームデザインがあってこその通信モデルであることも認めており、適宜寄せられるところは寄せる形が良いだろうと語った。
反省点としては、データが壊れた場合の修復がスマートではなかったという。これに対して、データを2系統で持っていくべきだったという社内の声もあったが、現状はサポートツールなどを用いて、遠隔で補正するシステムを作っていたため、手を動かせば救えるという形になっているようだ。ともあれ、オートセーブ機構のおかげで、ここまで『アナザーエデン』を快適にプレイできるようになった。そのことは良かったかなと思うと感想を述べ、発表を終了した。
(文・長戸勲)
会社情報
- 会社名
- グリー株式会社
- 設立
- 2004年12月
- 代表者
- 代表取締役会長兼社長 田中 良和
- 決算期
- 6月
- 直近業績
- 売上高613億900万円、営業利益59億8100万円、経常利益71億2300万円、最終利益46億3000万円(2024年6月期)
- 上場区分
- 東証プライム
- 証券コード
- 3632