【イベントレポ】DeNAのサーバー”コード”レスアーキテクチャ~クライアント中心のモバイルゲーム開発を支えるサーバー&クライアント基盤~

毎回様々なゲストをお招きして、最新の技術や情報をシェアするDeNA主催のゲームクリエイター向け勉強会【Game Developers Meeting】(以下、GDM)。

2019年12月20日(金)に開催された「GDM Vol.39」では、DeNAのモバイルゲーム開発で実践されている、サーバーコードをゲームタイトルの開発チームが極力書かずにクライアント側にできるだけロジックを置く、サーバー”コード”レスアーキテクチャを実現する手法などが紹介されました。

本記事では、当日使用されたスライドを公開するとともに、各項目について一部抜粋したレポートを紹介します。

勉強会レポート

今回の勉強会では、モバイルゲーム開発における「サーバー”コード”レスアーキテクチャ」を実現するために、DeNA社内ではどのような対応をしているのか、「背景」「実践編」「臨界点と今後の展望」の3つのテーマに分類して、大竹より詳しく説明されました。

大竹悠人 | 株式会社ディー・エヌ・エー
2009年にWeb動画配信サービス会社に入社。複数の新規Webサービス、ゲーム機/家電向けのサービスの立ち上げに携わる。

2013年にDeNAに入社し、ブラウザゲーム運営、新規アプリ開発を経験。成果物の技術資産化を推し進める過程で、ライブラリなどのゲーム基盤開発業務に携わるようになる。現在はゲーム開発者の声に耳を傾けながら、ゲーム開発の課題をより良い、効率的な方法で解決できるような基盤をさまざまな方面で模索している。

背景:サーバー”コード”レスアーキテクチャとは何か

まず、クライアントとサーバーがどのように連携してゲームが進行する設計にしているのかからセッションがスタート。

モバイルゲームで主流なアーキテクチャは、プレイヤーデータを直接改変する権利を持たず、サーバーが持つ情報を必要に応じて取得する「クライアント」と、プレイヤーデータを直接改変する権利を持ち、更新や取得の内容に応じてAPIを実装する「サーバー」に分かれます。

このアーキテクチャの長所は、多くのエンジニアに馴染みがあり、サーバー側でプレイヤーデータの変更を行うため、ユーザーの手元でのデータ改変が難しく、チート対策にもなるということ。

また短所(弱点)について、サーバーとクライアントの実装の分断が発生し、サーバーロジックだけでは完結しないため「どこまでサーバーでやるのか?」といった判断が難しいことなどが挙げられました。

DeNAでは、非ブラウザのネイティブアプリ開発時代から、そのような一般的な作りにとらわれない手法でのモバイルゲーム開発を実践しており、この仕組みを一言で説明すると「クライアントコードを中心に開発するアーキテクチャ」になると大竹は述べました。

どのようなアーキテクチャなのか

「クライアントコードを中心に開発するアーキテクチャ」とは、クライアントに責任を寄せることで、クライアントはサーバーからプレイヤーデータそのものを取得し、プレイヤーが更新後のプレイヤーデータそのものを生成して、その内容をサーバー側にAPIを通じて保存する仕組みとのこと。

また、このアーキテクチャはゲーム用mBaaSに近い手法ですが、大きな違いはターゲットが異なること。簡単に動くものを作るのではなく、グローバル展開を見越して大規模タイトルも手がけることが可能なようです。

共通ゲームサーバ「Sakasho」

このサーバー”コード”レスが実現するのは、DeNAのモバイルゲームのためのプラットフォーム「Sakasho」を利用しているからであり、専用のゲームサーバーを作らずにモバイルゲーム開発が実現しているとのことです。

ただ、サーバーレスにサーバーがあるのと同様に、サーバーコードが存在しないわけではなく、クライアントに寄せた作りをした上で、サーバーの機能を共通化しています。

また本勉強会内で使用された「プレイヤーデータ」とは、プレイヤーに関わる全データのことではなく、クライアントが更新の責任を追うデータのことを指すとのこと。

責務分担

サーバー”コード”レスでのプレイヤーデータに関わる責務に分担の仕組みについて、プレイヤーデータはサーバーを単なるデータストアとしてみなして扱うこととして、概念的にはKey-Value Store、1回のAPIのリクエスト単位でアトミックな更新をします。

ただし、サーバーからはプレイヤーデータを直接編集しないことを徹底し、プレイヤーに何らかのリソースを付与する場合は、すべてプレゼントボックスを経由。

サーバーで処理すべき状況として、時刻や確率に従う形で付与する「ガチャ・ログインボーナス」、付与する経路や総量を固定化する「仮想通貨の付与、ミッション報酬」、運営側の行動として処理する「お詫び配布」などが挙げられました。

プレゼントボックスへの集約

サーバ上で付与したアイテムはプレゼントボックスに一元化。サーバ上ではプレゼントボックスの中身の意味が理解できないように作られています。

プレイヤーデータとサーバー管理のリソースの交換

プレゼントボックスの内容や、プレイヤーデータを引き換える処理をついては、プレゼントボックスのアイテムの受け取り済みフラグと、アイテム取得状態のプレイヤーデータを同時にサーバーに渡して、更新する仕組みになっています。

プレゼントボックスの中身が実際にどのようなプレイヤーデータに引き換えられるかについては、クライアント側で制御。

この仕組みにより、APIは何度も通信しているが、途中でアプリが終了指定もプレイヤーが不利益を被らないことを保証することが目的が達成できていると、と大竹は説明しました。

サーバー”コード”レスによる効果

このアーキテクチャを利用する大きな効果として、各々のゲームとしての固有の処理の大部分を、クライアント側だけで実装でき、スケーラブルなゲーム開発が実現できること。またこれまでいくつもの大規模タイトルのリリースを大きな障害なく、乗り切っていることが挙げられました。

実践編:サーバー”コード”レスアーキテクチャでの
ゲームクライアント開発

続いて実践編として、その大きな目的を「サーバー側で担保・処理していたことの一部をクライアント側で実現できるようにする」と掲げ、5つの抑えるべきポイントや失敗事例が細かく紹介されました。

2015年にリリースされたゲームタイトル『戦魂』は、Unityでのサーバー”コード”レス実現した最初の内製ゲームとなりましたが、当時の開発や運用時に問題が頻出したようです。

その後、複数タイトルの開発を経て、サーバー”コード”レスでクライアントを作る際に気をつける点、抑えるべきポイントが明らかになったとのこと。

【抑えるべき点1】プレイヤーデータのテーブル設計

プレイヤーデータの定義はクライアント側で実行、RDBMSの構造(表)以上の表現力があり、安全に扱える形でスキーマ設計を行い、プレイヤーデータは必要なものだけを読み込めるような構造にします。

失敗事例として、エンジニアが手作業でテーブルごとのシリアライズ処理を書いており、それにより実装上の凡ミスにより不具合などが発生したとのこと。

また、起動時に過去のイベントデータをロードしていたため、起動が遅くなりユーザー体験が悪化したり、回線の速度制限に引っかかったプレイヤーがタイムアウト秒数に処理が終えず、ゲーム継続不可能になった事例もあったようです。

【抑えるべき点2】プレイヤーデータの一貫性の保証

プレイヤーデータの更新時に、一貫性が担保されなければ重大な不具合につながるため、更新を伴うリクエストには冪等性が必要です。更新時にクライアントから更新の成功を100%検知することが不可能なため、成功していた更新を再度実行しても、問題ないような仕組みが必要となります。

リトライ時に意図せず二重に仮想通貨を消費してしまうこと。さらに複数テーブルに跨ったプレイヤーデータの更新が、片方のテーブルだけ更新されてしまって整合性が崩壊した、といった失敗事例が明かされました。

【抑えるべき点3】ドメインロジックのレイヤー設計

クライアントが持つロジックの量が必然的に重くなり、ひどい設計や実装をした際の影響が相対的に大きく、データの破損などプレイヤーからの信頼を既存する恐れのある不具合に直結することも、問題となります。

コントローラに処理が集中して、プレイヤーデータの操作とUIが密結合になるといった失敗事例が発生しています。

【抑えるべき点4】プレイヤーデータのチート対策

サーバー”コード”レスを採用すると、クライアントチートの危険性が高いことが分かっています。

メモリをチートツールで書き換えて保存されると、そのまま結果がサーバー上に反映可能で、クライアントは実行バイナリが手元にあるため、逆アセンブルなどでの解析が必要となっているようです。

DeNAにはセキュリティ部が存在し、メモリ書き換えの検知、デバッガ/エミュレータの検出などを実施しているとのことです。

【抑えるべき点5】時刻の正確性の保証

サーバー”コード”レスでクライアント側で処理をすると、信頼できる時計が存在しなくなる問題が発生します。

サーバー側の時間を知ることができるのは、サーバーと通信を行った瞬間のみで、リアルタイムに時間を知りたい場合に頼りにならず、毎回サーバー問い合わせすることも非現実的です。

D4L

ここまで挙げられたサーバー”コード”レスに関する多くの問題点を解決するためのライブラリ「D4L(DeNA Domain Driven Design Library)」が開発されました。

D4Lはこれまでのゲームタイトルの開発用に作られた草の根ライブラリが基になっており、累計約10タイトル、約5年の歴史を持つそうです。

現在ではSakashoの後継フレームワークのTakasho向けのバージョンの開発・保守が続いており、Takasho SDKの一部として提供されていることが明かされました。

プレイヤーデータのテーブル設計

テーブル設計には、パース用のDAO(Data Access Object)と、そのLoaderを自動生成するモジュール「D4L.Definition.Compiler」を利用して、クライアントから読み込むマスターデータも定義できるようになっています。

テーブルの自動生成

DAOSchema属性にテーブルや種別を記述し、フィールドにSchemaProperty属性を付け、Context属性によりロード時の単位を指定します。

D4Lによるプレイヤーデータのテーブル設計

生成するのは「Data Access Object」「シリアライザ」「読み込み単位を規定するDataContext」「データのコンバータ(主にマスターデータ用)」となります。

スキーマ定義に使える型

スキーマの定義に使えるのは、C#のプリミティブな型、C#のプリミティブな型に対応するメモリ改ざん保護型、構造体、enumなどになります。

D4Lによるプレイヤーデータのマッピング

Key-Value Storeへのマッピングについて、キーは「テーブルの識別子」「分割用のキー」「格納される行の主キー」の三要素となり、複数のキーでひとつのテーブルが成り立ちます。

D4Lによるプレイヤーデータの分割読み込み

Data Contextの単位でプレイヤーデータを読み込み・アンロードすることでプレイヤーデータ全体をクライアントが常時所持しなくても良い状態にしています。

また垂直分割・水平分割の2軸でのテーブル分割が可能に。またマスターデータとプレイヤーデータが同じData Contextに所属できるのも大きな特徴となっているとのこと。

D4Lによるプレイヤーデータの一貫性の保証

Storage Change Setといったクラスを1単位として、トランザクションを形成。Data Contextのアクセサクラスから更新用のDAOを取得、プロパティを更新、内容が確定したらStorageChangeSetというクラスに登録した時点でシリアライズされます。

StorageChangeSetをAPIの引数に変換して、サーバー側に送信、ApplyToDaoの呼び出しでメモリ内の参照用のDAOに更新が反映されます。StorageChangeSetは、サーバーがなくても動くため、開発の初期に有用とのことです。

D4Lによるレイヤー設計

D4Lは軽量DDDによる設計を推奨しており、Repository/ValueObject/Specificationの実装のための基礎実装が存在します。

個別のビジネスロジックはDataContextやDAOに直接アクセスしないことが推奨され、Repositoryを経由させて、ビジネスロジックから扱うEntityとDAOを分離します。

これはプレイヤーデータを運用していると頻繁にテーブルの種類が使いされるためで、ゲームタイトルによって準拠度はまちまちなので強く強制はしないが、考慮しないければならないと大竹は述べました。

D4Lによるプレイヤーデータのチート対策

ヒープ上に常時乗る値に気軽にメモリ改ざん保護をかけられるようなライブラリを作り、バンドルしています。

プリミティブ型の代わりに使うだけで、改ざんを検出した瞬間にコールバックが叩かれ、検知でき、スキーマ定義時に使用することで、メモリに乗った段階から破棄するまで一貫して保護可能です。

また、改ざんを検知してもすぐに強制終了はしないことで、改ざんが成功したことを攻撃者に悟らせにくくすることを目的としています。

クライアントでは一見成功しているように見えて、実はセーブデータが保存されていないので、アプリを落とすとデータが巻き戻ります。

D4L以外によるチート対策

さらに社内のセキュリティ部と協力し、チート対策を徹底的に実施していることも紹介されました。

その一部としてエミュレータ/ルート化の検出、署名の検出、実行バイナリのダイジェスト検証などが実施されています。

またチートユーザーの動向を観察して、継続的な対策も実施しており、チート検出を回避されたら回避策の対処を検討し、イタチごっこを繰り返して攻撃者が音を上げるまで地道に対応していることも明かされました。

D4Lによる時刻の正確性の保証

信頼できる時間軸を扱うライブラリ「D4L.Moment」を使用し、実行中の自プロセスの経過時間(ProcessTime)を信頼する仕組みになっており、理由としては、時間が十分な精度で書き換えられずに進行する相対時刻を採用しているからとのこと。

サーバー時間からの時間軸の取得するには、RTT分の誤差が発生する可能性があるため、サーバーからのレスポンスに対して「リクエスト受信開始時のサーバータイムスタンプ」「レスポンス送信開始時のサーバータイムスタンプ」の情報を付与しています。

また、誤差をすぐに補正してしまうと、時間の巻戻りや早送りで意図せぬ不具合が発生する可能性があるため、時間の流れを調整して、時間をかけて時間を修正しています。

今後:サーバー”コード”レスアーキテクチャの
臨界点と今後の展望

最後に、サーバー”コード”レスアーキテクチャの臨界点や、共通ゲームサーバー「Sakasho」の後継となるプロダクト「Takasho」を現在開発していることを明かし、D4Lもそれに合わせて再設計されていることなどが説明され、本勉強会は終了しました。

クリスマスにピッタリの豪華なデザート

今回のデザートは、渋谷スクランブルスクエアにオープンしたパティスリーの高級モンブランをご用意。フランスで最も有名と言われる日本人がオーナーパティシエを務める、連日行列が絶えない話題店に、運営スタッフが朝から並んで入手した一品です!

取材・文・撮影:細谷亮介

【イベントレポ】令和時代を生き抜くゲームディレクター談義:歴戦ディレクターの「これまで」と「これから」

毎回様々なゲストをお招きして、最新の技術や情報をシェアするDeNA主催のゲームクリエイター向け勉強会の【Game Developers Meeting】(以下、GDM)。

本稿では、2019年11月29日(金)に開催された「GDM Vol.38 ディレクター向け座談会」にて繰り広げられた当日の模様を、一部抜粋してお届けします

“ディレクターに関する”6つのテーマ

テーマその1「ディレクターに至るまでの経緯」

まずは現在ディレクターとして活躍中のセガ・インタラクティブ松永純氏、カプコン山田倫之氏に対しての1つめのテーマとして、彼らがディレクターになるまでの経緯が質問されました。

松永氏はもともとプランナー出身で、当時の業務の中で「企画や提案ではなく、自分で判断をしたくなった」と気付き、その後ディレクターを目指したと明かしました。

一方、山田氏はプログラマーからキャリアをスタート。当時担当していたMMORPGタイトル開発時にディレクターが空席となり、その権利を持った人が不在だった中、リーダー陣で補完しながらプロジェクトを進める状況を経て、その後ディレクターになったと語っています。

テーマその2「プランナーとディレクター、一番の違いは?」

続いては、プランナーとディレクターについて、実際に開発現場で感じている一番の違いは?というテーマです。

松永氏、山田氏ともに、ディレクターはゲームの完成形を判断し、プランナーは提案や企画をする役割を持つ職種だという見解を述べました。また、プロジェクトの規模に応じて、ディレクターも提案をする場合もあるとのこと。ちなみに松永氏は「自分は小さいプロジェクトの方が好きです」と微笑みました。

松永純氏 | 株式会社セガ・インタラクティブ
2002年にSEGAにプランナーとして入社。アーケードゲーム市場にて『三国志大戦』シリーズ、『戦国大戦』シリーズの企画原案、メインゲームデザイン、ディレクションを務める。その後、モバイルゲーム市場で本格RPGジャンルの草分けとなる『チェインクロニクル』を制作。このタイトルでは、企画原案、ゲームデザイン、ディレクションに加えて、キャラクター・世界観設定、シナリオ制作を担当。現在は各モバイルタイトルの総合ディレクションに従事している。CEDEC2019のアワードにて著述賞を受賞。

プランナーの延長線上、目指す先にディレクターがあるのか、それとも違うスキルセットが必要なのか?という質問に対しては、プランナーだけでなくデザイナーやプログラマーなど、それぞれのスペシャリストの中で、全体を広く見て判断したい人がディレクターになるのではないか、と山田氏は述べました。

また、プランナーは他の職種に比べ全体を見る機会が多いだけで、プログラマーなど他職種でも全体を俯瞰して見られる機会と意欲さえあれば、ディレクターになれる可能性はあると、松永氏は話しています。

ディレクターとして大事にしたいこと

一般的に大規模プロジェクトでは、プランナーからディレクターになりたての頃は、現場のプランニングの仕事ばかりに集中していると、ディレクションがおろそかになり、プロジェクトが停滞してしまう傾向があるとのこと。「ゲームを完成させる」方向を見据えてアプローチをするのが良いそうです。

ディレクターはゲームの進む道を守りつつ、チームメンバーや実際に遊ぶプレイヤーに対して、一番理解させたい部分だけに手をかけるべきで、その他の部分は思い切って他者に任せるような線引きも必要だと語られました。

描いたゲームの完成形を決してブラさず、必要な部分はディレクターが手を動かして進めていくべきですが、スペシャリストとしてこだわる部分は持ちつつも、ある程度俯瞰して全体を見ることを心がけることがポイントだそうです。

また、ディレクターに至るまでの出自はそれぞれ違うので、その人の能力やカラーを生かし、開発チームが前進するための役割を果たしながら、[su_highlight background=”#fcff99″]「ディレクターとして元気にPJの最後まで存在すること」[/su_highlight]が最も重要だと、全員が口を揃えて話していました。

企画書を大事にする意味

松永氏は自身の業務の進め方について、企画書をとにかく大事にしており、プレイヤーに届けたい本質の部分を変えないために、ゲームが完成するまで、自分の進行方向が間違っていないか、都度確認していると述べました。

さらにその企画書を開発チームのメンバーと共にチェックし、死守して欲しい箇所を再確認することも大切にしているとのことです。これに関しては山田氏も同意見だそうです。

ちなみに本イベントのモデレーターを務めるDeNA佐伯は自身の企画書の作り方について、プレイヤーが実際にゲームを遊んで感想インタビューを受けている場面を想定し、プレイ後にどのような意見が挙がるのか、指標や改善点などを探れるような手法を取っていると話しています。

佐伯嶺 | 株式会社ディー・エヌ・エー
コーエーテクモゲームスを経て、2013年中途入社。『FINAL FANTASY Record Keeper』開発から携わり、運営開始後はディレクターを担当。現在はDeNAのゲーム事業部の企画を統括する部門で副部長を担当。今回のGDMではモデレーターを務める。

テーマその3「ディレクターとして一番面白い部分」

次のテーマは、ひとりのディレクターとしてゲームを作る上で一番面白い部分について。

松永氏は、自分の頭の中のアイデアをチーム全体で共有できたときや、企画書を社内メンバーに共有して現実味について相談しながら、このプロジェクトで進めることができると確信したときが最も面白い時期だと述べました。

山田氏も作品が「これなら大丈夫、イケる!」状態にまで完成形が見えてきた時期が、達成感があって面白いと話しました。

ちなみにゲームが完成した時点は、嬉しいよりもホッとする、救われた気持ちが強くなると2人はうなづいていました。

またディレクションに携わっていると、リリース後のゲームがどのように展開して、どうやってプレイヤーが楽しむのか、ディレクターはある程度イメージできており、プロデューサーとは少し違った目線で状況判断していることも明かされました。

山田倫之氏 | 株式会社カプコン
2001年コーエーテクモゲームスに入社。プログラマからキャリアをスタートし、MMORPGやソーシャルゲームのプランナー、ディレクターを担当。2013年カプコンに入社。スマホアプリのプロデューサー、ディレクターを経て、現在『戦国BASARA バトルパーティー』のディレクターを担当。CEDEC2014~2019、運営委員会プログラムワーキンググループゲームデザイン担当。

テーマその4「ここはしんどい!と思う部分」

今度のテーマは逆にゲームを作る上で大変で苦労する部分について。「楽しい部分以外は、全部ツライです(笑)」と最初に松永氏は笑って話しました。

「孤独」との戦い

孤独感については、ゲームの完成形がディレクターの頭の中にしかない時期や、チームメンバーが増えて規模が大きくなっても、うまくアイデアや企画を共有できないときに感じることがあるようです。

※編集部補足
会話の中に登場する「孤独感」については、イベントの事前インタビューでも深く語っていただきました。以下からご覧ください。

【インタビュー】プロデューサーとの関係値にも変化が!? 現役ディレクター陣に聞く、ゲーム開発現場での本音

ゲームが世の中にリリースされる瞬間まで、開発陣や社内のメンバーに「これって本当に面白いの?」と思われ続けることも、ディレクターが孤独な時期なのかも知れません。

特にマルチプレイ搭載のゲームなどでは、プレイヤーの遊び方について一部のコアメンバーだけが想像できている状況が多く、遊び方の正解や面白さをハッキリと定義するのは難しいようです。

ただ松永氏がプランナーの時代には、周囲のメンバーが「このゲームって面白い?」と疑問に思っていても、全くツラくなかったのは、自身がディレクターという責任者(最終的に判断する人間)ではなかったためではないか、と話しました。

そしてこれまでの要素を総合して「ディレクターはタフで、最後まで生き残っていることが大切」だと共通の答えが出ていたのも印象的でした。

テーマその5「ディレクターの後進育成について」

次のテーマは、社内でのディレクターの育成とキャリア形成について。

ディレクターの定義については「これをやれば必ずディレクターになれる」と判断できる確固たる指標がないため、研修制度などもあまり導入されていないのが現状のようです。

また、いきなりプロジェクト内にディレクターとして業務することは難しいので、チームの中でどのような関わり方をするのか、現場の他の職種の人とのコミュニケーションの仕方によって、成長度合いは変わっていくようです。

ディレクターになりうる適性は「自分の意見はAですが、現在のプレイヤーはBだと感じている」といった複数方向の目線で考え、提案できるような人が向いているのかもしれないことも語られました。

また、猪突猛進型、バランス重視型、多角的な視点を持っているなど、メンバーの得意領域や能力、適性に合わせた役割分担、チームアップやディレクターのサポートが重要だと思われます。

さらに開発全般において、疑問を持つ、興味を常に持つ、好奇心旺盛といった姿勢は今後ディレクターにとって重要な素養になるようです。

テーマその6「これからのディレクターの戦い方」

これまでのディスカッションを踏まえ、最後のテーマとして今後のディレクターの戦い方や、将来必要とされるディレクター像などについて話し合いました。

現在のゲームサービスは、プレイヤーとの距離が昔より近くなり、自分たちが作ったゲームの魅力をどうやって届けるのか、収益を上げ方も含めて、プロデューサーだけでなく、総合的にディレクターが考えるべき責任の領域が大きくなっています。

そこに関して「一人で全部を対応するのは到底無理なので、信頼できるメンバーに自分の不得意な部分を任せて、各個人が責任を負えるような環境でゲームを完成させることが重要です」と松永氏は述べました。

これまで小規模のプロジェクトでの開発では、ソフトウェアやプログラム、デザインの知識が必要でしたが、現在のディレクターには「勝つ」ための要素に集中することが今後必要となるようです。

また、現在DeNAでマネージャーとして働いている山浦が当日来場者として会場に来ており、過去に松永氏と一緒に『チェインクロニクル』を開発していた時、α版の社内審査会の時は、実はサーバとまったく疎通していなかったというのを、サービスイン後に明かされて驚いた、というエピソードが紹介されました。

当時、社内にサーバ開発経験者が少なく、松永氏も実装が難航していたのは危惧していて、審査会の際にサーバが動いていないと、プロジェクト中止もありうると不安だったものの、現場を信じて任せていたら、実は山浦を含めたメンバーが、まるでサーバを介して動いているように見せかけて乗り切って、助けてくれていたことも説明されました。

この出来事にもあるように、ディレクターが何もわからないことを恥じずに、任せられるところは任せて、自分の限界をチームの限界にしてしまわないように、価値を作り上げるのがディレクターの手腕を発揮できる部分であり、醍醐味でもあると松永氏は述べました。

大切なのは、柔軟性

変に自分にこだわりすぎず、他人のセンスや意見を受け入れる姿勢、謙虚さを持つことも今後重要になると山田氏は述べています。その人の表面的な意見だけでなく、その裏側に隠された言葉、自分では理解できない要素を汲み取って形にできるディレクターが、今後必要になると予測できます。

これまで長くディレクターを続けてきても「完璧にディレクターとしてこなせた」と自負できることは全然なかったと山田氏は明かし、「今回うまくできなかった部分を次のチャレンジに活かすなど、自分なりに勉強する、そしてディレクターになることがゴールだと思っていない人が、今後は生き残るのかもしれません」と述べました。

さらに、松永氏が手がけた書籍[su_highlight background=”#fcff99″]『チェインクロニクルから学ぶスマートフォンRPGのつくり方』[/su_highlight]では、ディレクターの手法論だけでなく、開発に関わる話題が赤裸々に書かれており、ディレクターのことを深く知る機会になれば、ゲーム業界全体の底上げになると期待していると話していました。

そして最後に、ディレクター同士で情報交換できるイベントは本当に少なく、お互いのディレクターとしての手法などをもっと共有したいことを話し、実は「ディレクターは孤独じゃない!」とのメッセージで座談会は幕を閉じました。

話題のデザート

今回は、渋谷エリアに新たにオープンしたばかりの「渋谷スクランブルスクエア」の人気スイーツ店(毎日すごい行列!)で話題の、エシレバターをふんだんに使ったサブレサンドをご用意。

取材・文・撮影:細谷亮介

【イベントレポ】10年の貫禄! 平成を駆け抜けた超長期運営レジェンドタイトルの「これまで」と「これから」

GDM本番前に楽屋を直撃! グリー×DeNA若手プロデューサーが共に描くブラウザゲームの未来予想図

【イベントレポ前編】GDMプランナー向け座談会vol.13 ~コミュニティファーストなプロダクト運営~

【イベントレポ後編】GDMプランナー向け座談会vol.13 ~コミュニティファーストなプロダクト運営~

【イベントレポ】「ゲームAIにおける意思決定と地形表現~『LEFT ALIVE』を事例に紹介 ~」

毎回様々なゲストをお招きして、最新の技術や情報をシェアするDeNA主催のゲームクリエイター向け勉強会の【Game Developers Meeting】(以下、GDM)。

2019年10月25日(金)に開催された「GDM Vol.37」前半では、PS4対応タイトル『LEFT ALIVE』における、HTN(Hierarchical Task Network)を運用する上で発生した課題と解決策について、事例を交えた内容が紹介され、後半では簡単なディスカッションも実施されました。本記事ではその中から一部抜粋したレポートをお届けします。

[su_note note_color=”#ffffff” radius=”10″]

◆登壇者

長谷川 誠 氏

株式会社スクウェア・エニックス
第一開発事業本部 ディビジョン5 プログラマー

専門学校卒業後、2004年、フロム・ソフトウェア入社。『アーマード・コア』シリーズなどのゲームプレイ要素(敵・AI・イベントなど)、マルチプレイ制御を主に担当。2015年、セガゲームス入社。『PSO2』のエネミー・プレイヤークラス(サモナー)を担当。2016年から現職。『LEFT ALIVE』のAI全般を担当。CEDEC2019にて『LEFT ALIVE』の地形表現について講演。

◆パネラー

佐藤 勝彦

株式会社ディー・エヌ・エー

コンシューマ・モバイルゲームの開発会社を経て、2019年DeNAに合流。ゲーム×AIを軸足にタイトルの開発運用と技術研究に従事。エンジニア・リサーチャー・企画・ディレクターと職域を広げながら、知見共有やタイトル・R&D部署間のシナジーの向上に注力している。

[/su_note]

ゲームAIにおける意思決定と地形表現

イベント前半では、スクウェア・エニックスの長谷川 誠氏より「ゲームAIにおける意思決定と地形表現について」をテーマにセッションが実施されました。

その中で、スクウェア・エニックスより2019年に発売されたサバイバルアクションゲーム『LEFT ALIVE』に関する事例をもとに、HTNの基本的な機能や運用する上で発生した課題、解決策などが紹介されました。

スクウェア・エニックス 長谷川誠氏

『LEFT ALIVE』の意思決定とHTNの採用

『LEFT ALIVE』では、企画内容から複雑な手順のアクションを実行するAIが求められる可能性があるため、キャラクターAIの中心である意思決定の部分には、「階層型タスクネットワーク(HTN、Hierarchical Task Network)」を採用しているとのこと。

HTNとは、意思決定アルゴリズムのことで、長時間に渡る行動計画を生成することができる機能を持っています。

HTNとは?

「階層型タスクネットワーク(HTN、Hierarchical Task Network)」は、ネットワーク状のタスクを自動的に目的に沿ったタスクのリストにする、意思決定アルゴリズムのことです。

昨今ではHTNに関する情報も増えてきているようで「特にバンダイナムコスタジオの長谷洋平氏が、過去のCEDECにて発表した資料が素晴らしいので、ぜひ参照してほしいです」と、長谷川氏は述べました。

複数タイトルで使われた柔軟性の高いAiエンジン(CEDEC 2015)

プレイヤーに反応するだけのAIはもう古い!ゲームAIへのプランニング技術の導入(CEDEC 2016)

BLUE PROTOCOLの個性豊かなキャラクターを動かす意思決定システム(CEDEC 2019)

HTNを採用した理由

『LEFT ALIVE』では、シリコンスタジオ開発のOROCHIエンジンを採用したが、本作の企画内容の複雑さに本エンジンのAI機能が耐えられそうなかったため、候補として「Behavior Tree」「階層型ゴール思考」「HTN」「GOAP」の4つを選出。その中からHTNを採用し、AIアーキテクチャを自作することを考えたとのこと。

企画の細かな要望に耐えながら、複雑な状態を扱えて、さらにノード数が爆発して扱いきれなくなることを回避するため、4つのアーキテクチャを比較して最終的に「階層型ゴール思考」「HTN」の2つを採用しました。

局所的な対応もある程度は可能で、ノード数も多くないため、HTNを採用したと理由を話した長谷川氏は「正直、単純にHTNを扱ってみたかったのも理由のひとつです」と微笑んでいました。

HTNは、「敵を攻撃する」「罠を排除する」など抽象度の大きいタスクから小さいタスクへ分解し、階層型ゴール思考は「EQSで指定された位置へ移動」「N秒間トリガーを引く」など抽象度の小さい具体的な行動を扱う、といったように粒度の大きさで扱い分けをしているとのこと。

HTNの構成要素

HTNの構成要素は「ワールドステート」「タスク」「プラナー」の大きく3つに分かれており、タスク内の「プリミティブタスク」「コンパウンドタスク」はまとめてドメインと呼ばれます。

「ワールドステート」とは、自分(プレイヤー)を含めたゲーム内の世界の状態を指し、『LEFT ALIVE』に関しては、143種類存在しているとのことです。

プリミティブタスクは、実際の世界に影響を与える行動を表し、タスクを実行するための条件「プリコンディション」、実際に行う行動「オペレータ」、タスクが実行できたときにワールドステートへ与える影響「エフェクト」の3つの要素で構成されています。

コンパウンドタスクは、達成すべき結果に至る方法を記述したメソッドを複数所持し、そのメソッドには自身が選ばれるためのコンディションと、選ばれたときのタスクのリストを持っており、どちらを選択しても、このコンパウンドタスクが欲しい結果になるメソッドを記述することが、ポイントになるようです。

上述したタスクが内包されているものを「ドメイン」と呼び、ドメインをワールドステートに参照・編集してタスクリストにする機能が「プラナー」となります。

プランニングのアルゴリズム紹介

続いては、プランニングのアルゴリズム詳細について、簡単な事例を用いて、図解で説明されました。

まず、コンパウンドタスクとして「食事をする」タスク内にメソッド1として「ご飯がある場合、ご飯を食べる」、メソッド2に「常に真(どんな状態でもこれが選ばれる)、ご飯を買いに行って、食事をする」と記述。次に「ご飯を食べる」「ご飯を買う」という2種類のプリミティブタスクを用意します。

プラン作成の過程で必要なのは、分解しておく過程を積んでおく「プランスタック」、最終的な出力を担う「プランリスト」、書き換えられる現在の状態「プランニング中ワールドステート」になります。

ここからプランニングが開始され「ご飯がある」という初期状態を作り、「食事をする」プランを分解していきます。

まず、プランスタックに入っている「食事をする」タスクを取り出し、メソッドに付属するプリコンディションを参照し、現在の「ご飯がある」状態に合致するメソッドを探します。今回紹介された例ではメソッド1が合致するので採用、サブタスクの「ご飯を食べる」をプランスタックに積みます。

さらにプランスタックに積んだ「ご飯を食べる」タスクを取り出し、プリコンディションの「ご飯がある」ことが有効なことを確認後、「ご飯を食べる」というオペレータを、最終的にプランリストに追加、与えられるエフェクトをワールドステートに追加します。

この時点でプランスタックが空になり、プランリストに「食べる」が追加され、ワールドステートに「ご飯なし」「お腹いっぱい」が適用され、プランニングが終了となります。

続いては、初期状態を「ご飯なし」「お金がある」と変更し、ルートタスク「食事する」プランを分解していく過程が紹介されました。

まずプランスタックから「食事をする」タスクを取り出しますが、この例ではメソッド1には対応しないため、メソッド2が採用され、サブタスクがスタックに積まれます。

次に「ご飯を買う」タスクを取り出し、「お金がある」状態なのでプリミティブタスクは実行でき、実際にご飯を買いに行くタスクがプランリストに追加されます。そしてご飯を買って「お金がなくなる」というエフェクトが、ワールドステートに適用されます。

さらにプランスタックに残っている「食事する」タスクを取り出し、メソッド1が採用され「ご飯を食べる」タスクが取り出されて「食べる」が追加、「お腹いっぱい」「ご飯がない」状態になります。この時点でプランスタックが空になるため、プランニングは終了します。

プランニングが失敗するケース

続いて初期状態を「ご飯なし」「お金なし」に変更して「失敗する(結局ご飯が食べられない)ケース」が説明されました。

まずルートタスク「食事する」を取り出しメソッド2を採用、「ご飯を買う」「食事する」タスクがスタックされますが、ワールドステートの状態が「お金なし」なので、タスクは実行失敗となります。

プリコンディションで失敗となると、最後にコンパウンドタスクを展開する直前の状態に戻します。その時点で失敗することが判明しているメソッドは選択候補にせず、プランスタックが空となりプランニングは終了します。しかし、プランリストも空なのでプランニングは失敗(何も起こらない)となります。

完成したプランを実行するには同時に処理できない「全順序タスク」と同時に処理できる「半順序タスク」で処理されます。

HTNプランニングのまとめとして「HTNはワールドステートを仮想的に変更しつつ、将来に向かって一貫性のあるプランを立てることが可能で、BT(Behavior Tree)と違いツリー形式ではないため、比較的柔軟な組み方ができます」と、長谷川氏は述べました。

『LEFT ALIVE』のHTN実装と拡張

『LEFT ALIVE』の実装に関しては、書籍「Game AI Pro 12 Exploring HTN Planners throuugh Example」を参考にしたことが明かされ、「半順序タスクは扱わない」「タスクは引数を取らない」「プランの良し悪しはメソッドの並び順」といったシンプルな実装ができたとのことです。

続いては、HTN実装と拡張における、事例に基づいた各課題とその解決策が紹介されました。

オペレータ並列実行

【課題】
半順序タスクを扱わないHTNのため「射撃しながら移動」「シールドを構えながら移動」などができない。

【解決策】
プリミティブタスクに複数のオペレータを登録できるようにして、同時にオペレータを実行する。「移動」「射撃」「リロード」のオペレータを別々にして、ドメイン上で組み合わせる。

成功コンディション

【課題】
「10mまで敵に近づく」「見えるまで敵に近づく」など、ほぼ同様のプリミティブタスクのオペレータを共通の実装にしたい。

【解決策】
成功終了する条件をプリミティブタスクに持たせる。
オペレータの機能を「0mまで近づく」のパターンだけ作り、成功コンディションの機能を「敵との距離が10m以内」「敵が見えている」などと組み合わせて実行する。

成功タイムアウト/失敗タイムアウト

【課題】
タイムアウト処理を個別のオペレータで実装するのが面倒。

【解決策】
タイムアウト機能を、プリミティブタスクのデフォルトの機能として用意する。

プリミティブタスクのクールタイム

【課題】
強力なボスの攻撃を連発したり、牽制用グレネードを投げすぎないようにしたい。

【解決策】
プリミティブタスクを実行したら、クールタイムを設定、クールダウン中の場合、プリコンディションで常にfalseになった扱いにする。

優先実行時間

【課題】
ボスのガトリング攻撃は、比較的長めのモーションを再生して攻撃態勢になるので、極端な状態変化がない限り実行し続けたい。

【解決策】
新しいプランを計算しない時間をプリミティブタスクに設定、その時間が経過するまではプランを置き換えない。

ここで紹介された開発中の動画では、ボスが「プレイヤーが一定範囲内に入ると、ガトリングを構えて撃つ」プランを所持しており、近づきすぎる、もしくは離れすぎると射撃をやめて通常の行動に戻る様子が確認できました。

この状態では、条件に当てはまらなければ、実行してもすぐに射撃をやめてしまうため、長時間射撃するように、裏で別のプランを作成しないようにして、問題が起きていた部分を改善しているとのことです。

リプランニングについて

このテーマの冒頭ではプランの変遷に関して、「ゲームの状態は常に変化し続けるので、プランを立てた瞬間からそのプランは腐っていく」と長谷川氏は述べました。

プランを実行中に、裏側で常に優先度の高いプランを立て続け、より状況に対応する次のプラン候補を検索するよう設計について、リプランニング周期は「個別エージェント=0.5secおき」「部隊=2.0secおき」となっていることや、細かい事例や解決策も併せて説明されました。

プランの優先度

コンパウンドタスク内のメソッドでは、若い番号が優先度が高い扱いをされ、コンパウンドタスクを展開する際にメソッドの番号を取得しておき、それを優先度比較用とします。この機能はMTR(Method Traversal Record)と呼ばれます。

優先度の高いプランへの置き換え

実行中のプランを入れ換える際には、そのまま入れ換えても大丈夫な場合だけでなく、現在実行中のプランとうまくマージする必要があります。

プラン置き換え時には、現在実行しているタスクより上位のメソッドで分岐している場合には、現プランをすべて破棄、新プランに置き換えます。抽象度の高い部分で分岐しているのは、そもそもやろうとしている目的が変わっているはず、とのこと。

また、下位のメソッドで分岐している場合は、現在実行中のタスクはそのまま実装し、未実行タスク部分のみを置き換えます。

このような置き換えが必要な理由として、新旧プランでまったく同様の現在実行中のタスクがあり、新プランに置き換える際に、旧プランから中間的な状態を保存し、タスクを破棄して新しいプランの中間的な状態から復帰する、ということをやらなければいけないのですが、これをすべてのオペレータで処理するのは大変なことが挙げられました。

強制的なプランの置き換え

「非戦闘状態から戦闘状態に突入」「ターゲットが変化」「罠を発見」「部隊からの指示が変化」など、ゲーム内の状況が大きく変化した場合、現在実行中のプランに関係なく、新プランに置き換えます。

HTNの外側でルールを記述しておき、それが発火したら現在のプランを捨てると、現在のプランとのマージ処理が走らずに適用することが可能となっています。

プリミティブタスク実行の失敗時

例として「ラーメンを作って食べている最中に箸を落としてしまった場合」のように、プリミティブタスクの実行が失敗したときは、全タスクをプランし直すことは負荷が高く、コンテキストが維持しづらいです。

プリミティブタスクを実行中に失敗した場合、そのタスクを含んだメソッドを選択対象外として、そのメソッドを含んでコンパウンドタスクをルートタスクとして、部分プランニングを実行します。

また、部分プランニングが失敗した場合、さらに上位のコンパウンドタスクをルートタスクとして、部分プランニングを実行。さらに2階層上位で失敗した場合は、ルートタスクから全体をリプランニングします。

プリミティブタスクの失敗履歴

失敗したタスクを参照するメソッドの履歴を保持し、連続して失敗したメソッドが選択されないようにしています。失敗履歴は置き換えたプランが正常終了するまで保持し続けます。

プランニングの負荷軽減策

【コンティニューメソッド】

『KILLZONE 2』で紹介されていた機能で、プラン作成時の条件が成立している場合は、プランを繰り返し実行します。本メソッドの実行中は周期的なプランニングを行わず、計算コストを下げることが可能です。

その他の工夫

【ランダムメソッド】

その他の工夫として、コンパウンドタスク内のメソッドをプリコンディションによる評価ではなく、一定の割合で選択するランダムメソッドを採用。HTNの中でランダムは扱いづらい側面もありますが、ドメインを作成する上で扱えたほうが有利と考えて採用しているとのこと。

ドメインの実装

ドメインの種類

『LEFT ALIVE』では、基本形・派生型をあわせて全27種類のドメインが存在します。ほぼ同じドメインで、一部だけ違う場合にコピペせずに済むように、基本形のドメインのタスクと同名タスクを派生で記述するとオーバーライドできるようにしているとのこと。

ドメイン内のタスク数

種類に対して、コンパウンドタスク、プリミティブタスクを合計すると、かなりの数になっています。

ドメインをLuaスクリプトで実装

ドメインに関しては、Luaスクリプトのテーブルを使って実装。Luaスクリプトはロード時に実行するのみで、内部処理用に変換、スクリプトはランタイムでリロード可能にし、イテレーションを楽にできるようにしています。Luaを採用したのは、開発会社側でLuaを実行できる環境があり、可変長のテーブルが扱えるため、とのことです。記述例も併せて紹介されました。

『LEFT ALIVE』のオペレータ実装

『LEFT ALIVE』では、実際に世界に影響を与えるオペレータとして、エージェント(キャラクター)用:約160種類、部隊用:25種類が用意されており、C++で実装され、階層型ゴール指向で構成されています。

失敗と教訓

HTMの採用と実装についての失敗と教訓を紹介する前に、長谷川氏は冒頭でまず「HTNは銀の弾丸ではない(すべてに万能ではない)」と述べました。

HTN用ツールがない

先述の通り、ドメインはLuaで実装しており、デバッグは基本的のログと実行中MTRのデバッグ表示のみとなります。

そういった理由でプランが採用されたのか、採用されなかったメソッドに関しても「採用されない理由」が追跡しづらく、ログも追いにくくなっています。理想としては、BT以上のツールサポートなければ厳しいようです。

ドメインを書ける人がいない

システムが最初からは安定動作しておらず、改修するたびにドメイン自体の書き換えを実施していました。また、いざドメインの記述をお願いしようとしたとき、担当の人がキャパオーバーしていたため、最後までドメインはプログラマーが書いていました。

HTN自体をシンプルにしすぎた

実装の参考にした「Game AI Pro」におけるHTNは、引数を取らないため、非常にシンプルだったようです。それ故に複雑さを追求すると、吸収するのはドメイン部分になってしまいます。

例えば「ある位置に向かう」というプリミティブタスクで、移動速度のみを変更したい場合、オペレータに渡す「引数だけが違う、ほぼ同じプリミティブタスク」を複数用意する必要がありました。先述したドメインのプリミティブタスク数が増えてしまったのは、これが理由のようです。

今後HTNを採用する場合は、タスクに引数を渡すシステムは必須と言えると長谷川氏は話しています。

HTNだけで頑張ろうとしすぎた

個別AI/部隊AIの意思決定の最上位から、最下層の手前(オペレータが処理する手前)までHTNで対応。HTNは警戒状態のステートマシンを参照はしていますが、内包はしていません。

兵士のルートタスクを例にすると、失敗プランニング以外は常にここから展開を始め、ほとんどがプリコンディション付きメソッドで、サブタスクが一つの構成になっています。

その形は、実はBTのPriorityノードと全く同様の形とのこと。それらを踏まえると『LEFT ALIVE』のドメインの上位部分は、HTNの必要がない構成になっていること、BTで同じものが作れることが分かったと言います。

そのため無駄なコンパウンドタスクの展開や、必要なワールドステートの値が増えることが考えられます。

「一番上位層の部分は、やるべきタスクではなく何をしたいかといった願望の選択になっており、それが変化すればそもそもやるべきことも違ってきます。その結果「BT or Utility>HTN>BTが至高だと考えられます」と長谷川氏は述べました。

タスクの分解保留機能を入れていない

分解保留機能とは、すぐに実行できるプリミティブタスクがある場合、さっさと実行して、続くコンパウンドタスクの分解を後回しにする機能のことで、後に実行するタスクを曖昧にし、プランの入れ替え頻度が下がると考えられています。

導入できなかったのは、最初の実装に問題があったためで、プラナーの出力を「オペレータのリスト」にしてしまったこと、プラン作成の途中の状態を持つ場所を用意していなかったことをが理由として明かされました。

まとめ

意思決定についてのまとめとして、HTNは一貫性のあるプランを立てることができるが、採用するにあたり、ツールなど環境面の整備や、教育コストなど、高いハードルが存在します。

しかし、ゲームデザインと噛み合わせて、他のアーキテクチャでは難しいようなAIを組むこともできる力強いツールであることは確かなようです。

HTNに向いていると思うゲームデザイン

また長谷川氏は、個人的にHTNと相性が良いと思うゲームの一例として、Team17 Digitalが手がけるタイトル『オーバークック2』を挙げています。

特にタスクを達成するためのサブタスクに複雑な依存関係があったり、ワールドステートが離散的に表現されている、プランが外乱によって壊れづらい、などの理由も併せて述べました。

CEDEC2019でこぼれた地形表現

続いては、「CEDEC 2019」において実施されたセッション「『LEFT ALIVE』における地形表現とナビゲーションAI」では伝えきれなかった内容の補足として、ゲーム企画・デザインチームからの要望に対する課題と解決方法が、本セッションで紹介されました。

『LEFT ALIVE』では、地面に対してナビメッシュの上にウェイポイントとグラフが乗り、障害物を取り囲むようにカバーが存在、近似ポイントを固めて表現する上位層グラフが設置されている地形表現になっています。

紹介されている事例は、実際にゲームデザイン側から依頼があった要望を基にしています。

敵兵が「階」を認識するように

課題は、あるイベントで敵兵がスポーンし、プレイヤーを捜索しながら移動する場面で、プレイヤーが建物の1階および3階にいる際に、敵兵の到達が遅すぎるということ。特に3階で待ち構えているときは、モタモタしている印象が強かったようです。

解決方法としては、同じ階までは素早く移動し、そこからは警戒移動(周囲をキョロキョロしながらゆっくり移動)をさせたいと考えました。しかし、常に警戒移動では遅すぎるため、建物の「階(フロア)」を認識させることが重要だと考えました。

「階(フロア)」については、はしご・低カバー乗り越え・階段(=斜面)、窓などで閉じた領域と定義し、敵兵が認識するような仕組みにしています。敵兵のロジックは「プレイヤーが○階にいる」ことを見ているのではなく、接続領域に乗っているか、を判断しているとのことです。

戦闘時に敵兵を散開させたい

この要件の課題としては、プレイヤーと戦闘が始まった際に、すでに近距離に敵がいるのに攻撃権が割り振られない、つまり何も行動していない、手持ち無沙汰な兵士を適切な場所に散開させたい、というポイントになります。

解決方法は、決まった位置を攻撃できるポイントをそれぞれ地形に埋め込み、プレイヤーがいる位置からリストを取り出し、空いている適当な場所に移動させるようにしました。実はこの機能は実装済みですが、ゲームでは未使用となっていると長谷川氏は述べました。

設置されたポイントについて、どこのポイントからポイントへ撃つことが可能か、という情報を埋め込み始めると、データが膨大になり、リストが圧迫してしまいます。そこで前述した「上位層グラフ」で接続関係を表現しているとのことです。

敵兵の捜索範囲を徐々に近づけたい

戦闘時に敵を散開させる機能の応用として、プレイヤーを捜索中の部隊がいきなりプレイヤーの付近を捜索するのではなく、ギリギリ見えている範囲から徐々に捜索範囲をプレイヤーに近づけていきたい、といった要望も企画側から挙がっていたようです。

この解決策としては、射撃領域から一番遠い場所から順番に捜索するように、またひとつの捜索が終了したら近い場所を捜索するように改善しているとのこと。残念ながらこの機能も実装済みではありますが、ゲームでは未使用とのこと。

待ち伏せ誘導をさせたい

最後は、プレイヤーが屋内にいる場合、むやみに突入せず、包囲されている雰囲気を出しつつも、建物の出入り口の一箇所のみに敵兵を配置せず、プレイヤーを誘導したい、といった要望についてです。

解決策は、地面に配置されているウェイポイントの接続で、屋内から屋外へ繋がる場所の「屋外側」を取り出し、屋外へ面する場所に敵を向かわせる設定にしました。

『LEFT ALIVE』には、プレイヤーを追う敵兵が増えていくので、屋内に立てこもって敵を減らしてから進行する、というフィーチャーが当初設定されていたため、このような要望を実現した経緯があるとのことです。こちらの機能も残念ながら実装済みですが、ゲームでは未使用になっています。

ディスカッション

イベント後半では、DeNAのエンジニア佐藤勝彦がパネラーとして参加し、「ゲームAIアーキテクチャの過去から未来へ」「ゲームエンジンによるゲームAIの民主化」を主テーマにパネルディスカッションが実施されました。

余談ですが、登壇者の長谷川氏とパネラーの佐藤の両名は、フロム・ソフトウェアで同時期に働いていた経歴があるため、GDMの事前MTGでもネタについて、かなり盛り上がっていました。

まず最初は、2人の古巣でもあるフロム・ソフトウェア時代に携わっていたタイトルについて、当時活用していたアーキテクチャを振り返りつつ、今後の進化についても話し合いました。

長谷川氏は、過去に『アーマード・コア ラストレイヴン』『DARK SOULS III』などのタイトルを手がけており、『ARMORED CORE VERDICT DAY』で実装されていた、プレイヤーがゲーム内で自作できる無人AI「UNAC(UNmanned Armored Core)」には、これまで開発が使っていたツールや、AIの仕組みをそのまま使用していたことを明かしました。

それに関して佐藤は「当時のゲーム業界にはBehaviorTreeの概念自体も浸透していなかったため、プレイヤーがコントロールしやすい環境を追い求めて、自然とルールベースからBehaviorTreeに進化したと考えられますね」と答えました。

続いて「AIを開発する際に企画側とコミュニケーションするコツ」を聞いたところ、長谷川氏は「自分自身が企画側に寄り添って行くことが大事」で、ゲームデザインに積極的に関わりたい、変化を思い切りポジティブに捉えられるような人が向いている可能性があると話し、「結論は企画に優しくすることです!」と微笑みました。

また、企画が表現したいゲーム状態を制御するためのAIはどう進化していくのか?といったテーマについて長谷川氏は以下のように話しました。

「例えば100のゲーム状態の場合に100のBTを書かなければ動作しない場合に、プランニングなど少ないノード数を利用すれば10で動作できる、みたいに工数を縮小できることを考えなければ、オープンワールドのような大規模な開発の場合、対応がかなり大変になります。

もちろん、100の状態を10のルールで自動的に対応付けができた場合に、すべてをデバッグしきれるのか、という問題は残りますが、小さいノードで大きな状態を捉えるときに(小さいノードで)きちんと動作を担保できなければ、ゲームをハンドリングするディレクターなどを説得できなくなります。

今後はQAを巻き込みつつ、工数を削減、大規模なプロダクトを扱えるプロダクションレベルで、ひとつの技術だけでなく、将来的に大きな動きを意識しないといけないと考えています。」

また最近では、ゲームQA領域やアセット生産の効率化に、機械学習が導入され始めていることについて「機械学習に関して、現在の段階では条件や状況を絞った上で、プランナーが思い描く動作を実行できる程度で、フィールドの地形やバトル展開などシチュエーションのどの部分を機械学習で表現するか、判断が難しい部分もあります。」と長谷川氏は述べています。

それに対して佐藤は「機械学習にも向き不向きがあるので、要件定義において、コントロラビリティを担保するべき領域との切り分けは重要になりそうですね。QAや量産工程の支援などは比較的問題も切り分けやすく、導入も考えやすいと思います。」と話しました。

DeNA 佐藤勝彦

最後に長谷川氏は、BehaviorTreeの普及に関しては特にUnreal Engineの影響が大きく、ゲーム開発を目指す学生もダウンロードしてすぐ使用でき、ゲームAIの活用の裾野が広がっていると語りました。

「さらにプランニング技術が導入されて民主化して、次世代ではうまくゲームにフィットさせる設計力が重要な時代になるのではないか、と今後ゲーム開発に携わるエンジニアたちに期待をこめたコメントで、ディスカッションを締め括りました。

懇親会の様子

セッションやディスカッションで質問しきれなかった来場者から、たくさんの質問を受けていた登壇者の長谷川氏とDeNA佐藤。同業種の人との情報交換や、普段なかなか話せない業務上の悩みなどを話せた人も多かったのではないでしょうか。

季節のデザート

季節のデザートには、ちょうどハロウィンの時期ということで、かわいくてちょっと恐ろしい「ジャック・オ・ランタン」がデザインされたベイクドチーズケーキやモンブランが登場!もちろん大人気で、みなさんにペロッと食べていただきました。

取材・文・撮影:細谷亮介

【CEDEC2019】「大規模モバイルゲーム運用におけるマスタデータ管理事例」セッションレポート

2019年9月4日~6日の期間、パシフィコ横浜において、ゲーム開発者向けカンファレンス「CEDEC2019」が開催されました。本記事では、9月6日に行われたセッション「大規模モバイルゲーム運用におけるマスタデータ管理事例」の内容を一部抜粋してレポートします。

セッションの冒頭では、登壇者の株式会社ディー・エヌ・エー ゲーム事業部 共通基盤部人西聖樹より、近年のモバイルゲームの大規模開発に伴い、マスタデータ入力やそれ以外の作業者などチーム内のメンバーが増加し、ワークフローも複雑化している状況が説明されました。

そのような状況の中、マスタデータを管理、入力するためのワークフロー構築は、とても重要な分野であり、世の中に公開されている情報は未だ少ないと人西は述べています。

そのような背景を踏まえて本セッションでは、まずDeNAのこれまでのブラウザゲームの時代からネイティブアプリのモバイルゲーム時代の遷移を説明しつつ、これまでに実施したマスタデータの管理およびワークフローの構築の取り組みについて紹介されました。

マスタデータとは

[su_note note_color=”#ffffff” radius=”10″]

「マスタデータ」とは、モバイルゲームの運用において、デプロイ時点で運営側が先に用意しているアセット群のうち、文字列で表現されるデータのことを指し、ユーザー起因で内容は変化せず、運営側により変更されることがあり、ゲームのランタイムからするとRead Onlyなデータ。ユーザーごとに値が変化するデータは含めず、テキストデータで画像や3Dモデルのようなアセットも、今回の発表では含めない。

[/su_note]

マスタデータは、ゲームの動作やゲームバランスを決定するために、あらかじめ設定をしておくパラメータを指し、多くの場合は表形式で表示できる構造になっています。

モバイルゲームの多くは、アプリ起動時に最新のマスタデータをダウンロードして、そのデータを参照しながら動作します。

クライアント側だけではなくサーバー側のプログラムも同様に、マスタデータを参照することもあり、プログラムとマスタデータを分離しておくことで、マスタデータ部分はプランナーなどの非エンジニアでも容易に変更できるように設計されているとのことです。

マスタデータの更新のみで完了する場合

アプリバージョンアップをせずにマスタデータだけ配信することが可能です。

アプリのバージョンアップは、Apple Storeなどプラットフォームの審査を通過する必要があり、時間がかかりますが、更新内容をマスタデータに切り出しておくことで、各審査を通さずに、運営側のスケジュールのみで、迅速にゲームの更新を反映することができるようになっています。

ここでは、マスタデータの一例として、「武器」マスタや「必殺技」マスタのサンプルが紹介されました。

以下の表では「武器」マスタの中に「スキルID」という列が入っており、「必殺技」マスタのIDでも、あるマスタが別のマスタへの参照を持つことは非常に多いとのこと。本セッションでは、これについてリレーションと呼んでいました。

マスタデータの一般的なワークフローとして、最初にプランナーがマスタデータを入力、その入力したマスタデータをゲームのランタイムに読み込める形式に変換します。

その後、変換したランタイムをゲームに読み込ませ、ゲーム上で手触りを確かめ、パラメータを変更希望な部分があれば、マスタデータを修正して、ランタイム形式に変換、再度ゲーム上で確認することが一般的なフローとなっています。その後、本番環境にデプロイされます。

マスタデータの役割について、ユーザーのプレイサイクルをデザインすることが重要だと説明されました。ユーザー体験の中でも、UI、画像、音楽のような目や耳で感じられるビジュアル、オーディオ以外全般のことを指すようです。

例えば、ステージクリアやレベルアップのテンポ、アイテムや必殺技、魔法の種類や性能、敵の強さの調整、会話やチュートリアルの説明などが該当します。

新イベントやステージを、アプリ本体更新なしに追加したり、プレイヤーが挫折しやすいポイントはすぐに修正が可能なので、コンシューマーよりもモバイルゲームの方が、運営を続けていく点においては、マスタデータを更新する機会が多いと人西は述べました。

DeNAにおけるこれまでのマスタデータ管理の歴史

ブラウザゲーム時代

ここからは、DeNAにおける過去のマスタデータの管理の歴史遷移について紹介されました。

DeNAのブラウザゲーム開発運営の時期は、およそ2009年から2013年。開発の運営に携わるチーム人数は30名程度で、プランナーは10名程度参画していたとのことです。

技術的には、クライアント側はHTMLとCSS、JavaScript、サーバー側はLinuxとApache、MySQLというオーソドックスなWEBアプリケーションで、DeNAではPerl、他社だとPHPなどのスクリプト言語で構成されていることが多いようです。

当時のブラウザゲームのマスタデータは、Excelファイルを共有ファイルサーバーに置いて管理していたそうで、マスタデータの反映や閲覧は、ゲームごとに独自に存在する管理用のWEBアプリケーションで管理していました。

マスタ作成ワークフローについては、マスタの種類ごとにExcelファイルが存在し、ファイルサーバーで管理されていました。

また、マスタデータを運営する作業者ごとに、そのデータを確認するためのゲームサーバーが割り当てられており、そのサーバーで各自が、その時点でのリリースのバージョンがセットアップされているため、自身で作業することが可能になっています。

作業フローは、Excelファイルをファイルサーバーからダウンロード、ファイルを編集した上で保存し、管理用WEBアプリケーションを経由して、自身のゲームサーバーに反映します。

その後実際にパラメータの動作確認のため、モバイル端末のブラウザ経由でアクセスして動作確認後、再度修正が必要であれば修正します。

データに問題なければ、mysqldumpでCSV化してgit管理。最終的にFIXしたCSVのデータを本番環境にMySQLへ流し込むことで、マスタデータを本番反映していたとのこと。

管理については、運用時に追加するマスタデータの多くは、一時的に使用するものとして管理されていたとのこと。その理由としてソーシャルゲームでは、ゲーム内イベントで使うテーブルなど、特定の期間でのみ必要なマスタが継続的に発生するからだと考えられます。

共通テーブルには、アイテムマスタやキャラクターマスタなど、イベントに紐付かない共通のテーブルがありますが、同時編集に留意してマスタを追加することが重要で、その部分はメンバー間のコミュニケーションでカバーしていたと人西は話しています。

チームの人数が少ない時期は、コミュニケーションで問題なかったものの、メンバーが増えてくると伝達が漏れて、誰かが編集したデータを上書きしてしまうといった事故が発生したようです。

さらに、独自の管理画面でマスタデータを投入・閲覧していたため、テーブルを追加するたびに管理画面も実装が必要になり、エンジニアの工数が増えて、テーブルによっては個別にリレーション先のテーブルの内容も見たいというプランナーの要望もあったため、エンジニアが個別で実装していたとのこと。

マスタの入力に関する部分では、運用が長期化すればマスタデータも増加するため、、入力が必要な個所をマクロや関数でカスタマイズし、できるだけ判別しやすく減らすなど、作業内容を単純化してデータ肥大化に対応しています。

ただ一方で、ナレッジが個人に依存しすぎたため、担当者が退職などで入れ替わるたびに引き継ぎされない箇所が多く、その影響でExcel上の意図しないデータが入れ替わってしまったり、誤ったデータ入力につながったりしていたことが問題だったと人西は振り返りました。

基本的に作業の分業はリリースバージョンごとに担当しており、バージョンごとにシートが分かれていたため、他の人の作業の影響を受けることは少なかったとのこと。

ただ、リリースに向けて、現在のブランチまでをマージ後、本番環境に反映する段階で、CSVがコンフリクトすることが多いようです。

同じ個所を複数のリリースバージョンで調整していたことが発覚し、コンフリクト解消が非常に大変だったこともあるようです。

対応策として、各イベントのリリースバージョン担当者とコミュニケーションを取り、「コンフリクト部分において、どちらが正しいデータなのか?」など、直接議論をしながら正しい値を選択する作業をひたすら繰り返していました。

新規キャラクター追加に関しては、共通のキャラシートのテーブルが存在するため「どの範囲のキャラクターデータの値を本番に反映するのか」「未来のデータは反映しないので省く」といった細かな更新をプランナーが手作業で実行していたため、未来のキャラクターのデータが反映されかねない危険な作業をしていたことも明かされました。

ブラウザゲームの時代を踏まえて良かった点としては、独自の管理システムを用意していたため、エンジニアが自ら拡張することで、見やすいように成形することができたこと。

開発環境のデータベースにSQLを投入すれば、自身の環境を確認することが可能なので、実際にパラメータ確認の点で、ネイティブアプリと比較してイテレーションが早いこともメリットと考えられるようです。

さらに、MySQLのテーブル単位でイベントの単位に紐付けていたため、比較的管理が容易で、イベント期間が終了したら、テーブルは不要なので削除も可能、他のイベントのデータと重複することもないため、コンフリクトすることもなかったとのこと。

一方で、Excelファイルを共有サーバーで管理していたため、複数人で同時にデータを編集できないことがデメリットとして認識していたと語られました。イベントのデータは管理が容易ですが、ゲームで共通で使用するマスタは、Excelで管理する方が難しかったようです。

また、イベント単位で切られているマスタは、ブックでの管理のため比較的容易ですが、共通のマスタは同時編集不可のため、イベント専用アイテム追加などの作業中には他の人が触ることができないので、当然待ち時間が発生してしまいます。

それを回避するために、同名のExcelファイルをコピーして、一時的に入力できる運用方法でカバーしていました。

ガワネイティブ時代

この時代は技術的的にブラウザゲーム時代と同じ構成のブラウザゲームを、webviewでネイティブアプリ化しており、外側だけネイティブアプリで、中身はブラウザゲームであるため「ガワネイティブ」と呼ばれています。

この時代になると、チーム人数の規模が一気に増え、開発と運用チーム人数が100名程度、うちプランナーが50名程度という大規模なチームになりました。プランナー全員がマスタデータを編集する可能性があったため、しっかりとワークフローを考えなければならない状況だったと、人西は当時の状況を振り返りました。

ネイティブアプリ側もOpenGL APIを実行可能にすることで、中身はブラウザゲームですが、ネイティブアプリに近い、リッチなアプリゲームを開発できるようにしています。

この時期から、Excelファイルをファイルサーバーで共有して管理するのではなく、Googleスプレッドシートを使用してデータ入力するように変化していったそうです。

Googleスプレッドシートを利用すると、リアルタイムで複数人が共同編集可能になり、データの閲覧は基本的にGoogleスプレッドシート、データの反映は独自のCLIツールを開発し、それをGoogleスプレッドシートからダウンロードして、CSVに変換、MySQLにデータを投入・反映していました。

この時期のマスタ作成は、リリースバージョンごとにディレクトリを分けて、Googleスプレッドシートを管理するようになり、各ディレクトリにそのバージョンで追加変更するマスタデータのGoogleスプレッドシートだけが存在する仕組みになっていたようです。

Googleスプレッドシートに入力する内容は、基本的にマスタデータの差分のみを入力。そのため、マスタデータ全てがGoogleスプレッドシートに存在するのではなく、そのリリースバージョンで追加・変更するものだけが管理されます。

そして特定バージョンまでのマスタデータをゲーム反映したい場合、リリースバージョンごとの差分が存在するため、過去バージョンのマスタデータを独自CLIで統合し、最終的に全てのマスタデータが内包されたマスタデータを作成しています。

これにより、疑似的にバージョン管理を実現でき、Googleスプレッドシート上でマスタを入力し、Jenkins、独自CLIを使って担当リリースバージョンのゲームデータに変換して、ゲームに反映後、確認します。

実機で動作確認をして問題が発生した場合、修正後に再度Jenkinsを実行、問題なければそのままmysqldumpでCSV化して、同様にgit管理下にCSVを配備し、gitでCSVを管理しています。最終的にCSVをMySQLに流し込むことで、マスタデータの本番反映を実施していました。

企画者がリリース単位でスプレッドシートにデータを作り、Jenkinsのジョブを実行、スプレッドシートからマスタデータをダウンロードし、CSVに変換、開発環境用のデータベースに反映するのが詳細なフローになります。

反映後、企画者がゲーム上で確認して問題なければ、別のJenkinsのジョブを実行し、スプレッドシートからダウンロード、分割されたシートをマージし、CSVに変換して、githubへPullRequestとして送信されます。

そして、github上ではマスタデータのレビューを行っており、この変更で問題なければ、リポジトリにマージすることで、初めてマスタデータの変更がCSVに反映されるというフローを採用しているとのことです。

しかし、マスタデータが肥大化することが別の問題として発生しました。運用が長期化するとマスタデータが増えるため、作業に支障をきたしていたとのこと。

この問題の対応については、GoogleスプレッドシートのVLOOKUPや入力規則を利用して、なるべく編集箇所や入力できる値を絞り、自動でマスタデータが生成される仕組みを作って解決しています。

当時は、リリースバージョンごとにディレクトリを分け、Googleスプレッドシートを管理していたため、シートが独立していました。疑似的にバージョン管理の仕組みを導入することで、他のリリースバージョンの影響を一定切り分けることが可能になったとのことです。

しかし、それまでのバージョンのマスタデータを統合する際、以前のバージョンのマスタデータを他の人がまだ編集中の場合に問題が発生することが判明しました。

イベントAとBが並行で開発を進めている際、どちらも編集中の状態の場合、ゲームにそのまま投入するとエラーが発生してしまいます。

それ以降のバージョンでマスタデータを入力している人のデータが、全てエラーを含むデータになってしまうため、実際にゲームで確認したところ、自分が編集していない箇所でエラーが発生してしまい、原因が分からない混乱を招くことがあったようです。

これはリリースバージョンが異なる中で、影響範囲が切り分けられていない部分があることが原因です。

その問題を防ぐために、リリースバージョンごとにシートを独立して分けていましたが、さらに個人で作業するためのディレクトリを切り、マスタデータを編集し、その後にイベントや自分の担当したリリースバージョンに確定したデータを反映していた状況でした。

またブラウザゲームの時代と異なり、この時期にはJenkinsを活用することで、作業を自動化して入力作業以外の処理を、基本的にJenkinsの任せることが実現できたとのことです。

ガワネイティブ時代を振り返ると、Googleスプレッドシートを関数や入力規則で拡張することで、データ入力が一定自動化することができたため、特定環境にデータを挿入することや、PullRequestを送る部分については、かなり自動化を進めることができ、Jenkinsで機械的にマスタの誤りや不整合をチェックできるようになったと、人西は述べました。

ただ、Googleスプレッドシートのデータ量の増加と運用に伴って、マスタデータが増加していく一方で、シートのデータ量も増加したことが課題点として挙げられました。

さらにシートの関数機能を多用していたため、シート自体を展開、編集する処理がどんどん重くなっていったようです。

また、複数の運用開発ではリリースバージョンも複数存在するため、並行開発が進んでいく中で、疑似的にバージョン管理はできていましたが、マスタデータの変更の影響を、完全には切り分けられていないことも課題だったようです。

さらに、リリースバージョンまでのマスタデータを統合してゲームデータにする段階で、そのマスタが編集中の場合があり、エラーが発生することもあったとのこと。

マスタデータがどんどん増大していくので、それにともない線形的にマスタデータのビルド時間が長期化していく課題も発生しました。

運営が長期化すれば、マスタデータ自体も増加するため、GoogleスプレッドシートのAPIを利用してマスタデータをダウンロードする際に、APIのレスポンス速度、あるいはネットワーク通信を挟むため、通信速度がボトルネックになる課題も同時に発生しています。

ネイティブアプリ時代(現在)

現在のネイティブアプリ開発では、チーム人数としては約70名程度とやや減少傾向にあり、うちプランナーは30名程度の規模となりました。特徴として、この頃の時期からUnityを利用したゲーム開発が進んでいたようです。

マスタデータ管理については、Googleスプレッドシートを使用、Jenkins上でシートのマスタデータをゲームデータに、ゲーム側ではjson読み込みを活用しています。

バージョン管理では、gitおよびGithubを利用することで管理していました。ビルド時間が長期化する課題については、キャッシングの仕組みを導入することで、一定ビルド時間を減らすことに成功しています。

また、ネイティブアプリ化にともない、アセットデータをクライアント側に配信する概念が生まれ、後述する新たな課題が発生したとのこと。

マスタデータのワークフローの概要は、ガワネイティブ時代と同様、ディレクトリごとにリリースバージョンを作り、ディレクトリ内にさらに作業者ごとのディレクトリが存在している仕組みです。

また、それぞれのディレクトリの内部に、そのバージョンで追加変更するマスタデータのスプレッドシートが存在しており、マスタを追加変更する際は、対応する名称の空間に自身のシートを作成し、マスタデータを書き込みます。

変更後に、マスタデータ書き込みが終わった段階で、作業者のローカルPC上でゲームの変更確認を実行しています。現在ではこのように「データを入力」「ローカルにダウンロード」「変更を加え動作確認する」という作業フローを繰り返しているそうです。

そして、パラメータに問題なければ、Jenkinsを実行します。この作業は追加変更したデータを差分として見られるようなPullRequestを、自分の担当のブランチに対して投げるJenkinsのジョブになります。GitHub上でPullRequestが投げられるので、GitHub上でマスタデータの変更を作業者、あるいはレビューの担当者が内容を確認してマージしていきます。

各バージョンがリリースされるまでは、ブランチ上では別々の差分ファイルとして管理されていました。同じキャラテーブルでも、別々の差分ファイルとして管理されています。それをゲームのランタイム側で、データを読むタイミングでマイグレーションしたデータを作成しています。

この処理では、同キャラテーブルでも差分ファイルだけが増加していくため、リリース後のデータ枠で全て結合して管理していきます。実機確認の際は、特定のブランチのgit管理下にあるデータをゲームサーバーに読み込ませて利用していました。

ここでの取り組みについて、スプレッドシートでデータが複雑化しない工夫は、ガワネイティブ時代と同様に実施し、同時作業や他の人と並行作業する際は、同じバージョン内で分業できるように設計されているとのことです。

一方で、差分で表現するリスクとして、別ファイルで同じ行を変更していた場合に、どちらが正しい行と判断するかという点がありましたが、運用とコミュニケーションでカバーすることで解決していました。

ここで人西は「検知する仕組みくらいはあっても良かったのかな、と思っています」と話しました。

マイグレーションのデータの統合のフローが、ガワネイティブ時代からかなり改善されており、スプレッドシート上のデータをマイグレーションするのではなく、それぞれのバージョンのgit管理下でデータ統合するため、スクリプトなどでマスタデータ、テスト済みのものを取り込むことが可能になっています。

さらに、プログラムコードと一緒にgitのブランチに取り込むことも可能になったため、マスタデータとプログラムコードが乖離する問題も解決したようです。ただ、マスタデータを変更してから、実際にゲームで動作確認するまでに時間がかかる課題は残ったようです。

また実機で確認する際は、マスタデータをmBaaSにあげて確認する必要があります。Unity開発のゲームでは、アセットバンドルの仕組みを利用して、マスタデータおよびそれ以外のリソース、3Dデータや画像を配信していたのですが、その際にアセットバンドルをビルドする必要があり、その処理に時間がかかること。さらにゲーム上で動作確認するまで、時間が必要になる課題もあったとのこと。

作業フロー

続いて、実際の作業のフローが詳しく説明されました。

フローの最初では、各個人でイベント用の環境を持っているため、mBaaSサーバーとビルド、UnityEditorを用意し、Excelで特定のバージョンのデータを作成します。

作成したデータをスプレッドシートに投入、特定のバージョンのシートに入力したデータをダウンロード、必要なアセットを作成し

ます。この部分はJenkinsのジョブでまとまっているので、プランナーが容易にアセットが作成できる仕組みを採用しています。

スプレッドシートのダウンロードには、独自のCLIを利用してゲームデータに変換しています。この際に、特定のバージョンのシートのみをダウンロードしてゲームデータに変換しています。

理由は、直前のバージョンまではgitのレポジトリに全て入っている前提でgit管理しているためで、これまでのデータと今回のリリースバージョンで追加されたデータとなります。

ゲームデータに変換後、ビルドしたゲームデータとUnityEditorを利用して動作確認をします。動作確認で問題がなければ、ブランチに対してPullRequestを送って取り込みます。リリース後に、今回のブランチでの追加のデータ群を、これまでの場所に取り込んでいます。

例えば、リリース前にA、B、Cというブランチを並行で開発したと仮定し、これまでのデータ群、リリースした全マスタデータとブランチAでの追加分、ブランチBでの追加分のデータ、ブランチCでの追加分のデータのように、それぞれブランチA、B、Cの差分のみを管理している仕組みです。

過去の差分に対しての変更や削除も、このような差分のみを適用するパッチで実行されるので、これまでのデータ群を直接変更することがないようにしていました。

共通スプレッドシート上で企画側がデータを作成し、Jenkins上のジョブを実行していくのですが、その際に一通りマスタデータを作成するために必要な処理をしてくれるようです。

gitリポジトリを最新の状態に更新し、シートからダウンロードし、リリースされている分とマージして、ランタイム向けにデータを変換します。マスタデータをスクリプトで機械的に異なる値が入力されていないかをチェック。アセットバンドル後、gitのリポジトリにコミットして、PullRequestsを出力しています。

もし、この時点でエラーがあればJenkins上で内容を確認して、修正して解決。それから変更したマスタのデータがgitのPullRequestに出力されているので、それを他のプランナーでレビューしてマージ、最終的にgitのレポジトリまで反映するという仕組みを採用しています。

ここまで説明されたように、ネイティブアプリでマスタデータを運用した際のメリットとしては、スプレッドシートのデータを直接、差分ごとに統合しないため、ガワネイティブ時代の課題を一定解消することができたと人西は述べました。

gitのリポジトリに入っている、これまでのデータ群が正しければ、その後は自身のブランチのみ変更の影響範囲を受けるので、作業影響の切り分けが容易にできるようになったとのことです。

一方で、ビルド完了までは、マスタデータの変更をゲーム上で確認できないことは課題だったようで、ゲームデータ変換をJenkinsのジョブに任せていたため、ジョブの実行時間が肥大化していき、マスタデータを入力後にゲーム上で確認するまでのイテレーションが遅くなっていました。

これは、マスタデータを追加したことによる、アセットの用意やテストなどに時間が必要となってしまった部分です。

課題のまとめ

大きな課題感として「並行で開発する環境に対応しきれていない部分がある」と人西は述べました。

複数のイベントを並行で開発する際でも、イベント間で編集の影響範囲が切り分けられておらず、このために、前段のイベント開発でシートを編集中だと、後続のイベントも影響を受けてしまいます。

編集中のデータをゲームに反映すると、アプリクラッシュが発生したり、前段のイベントがエラーになる値を入力していると、作業中では後続も影響を受けてエラーが続発することがあったようです。

例えば、3月1週目にリリースするイベントに対して、あるプランナーがパラメータを入力していたとします。さらに並行して3月2週目にリリースするイベントを、別のプランナーが作業している状況を考えます。

その場合、1週目のプランナーがボスパラメータを編集中のため、実際にゲームに反映するとゲームが落ちる可能性のある「誤ったデータ」となります。

3月2週目にリリースするイベントの担当者が、別のパラメータを編集中の場合、実際にはゲームは動作せず、自分が編集した箇所以外でクラッシュすることも判明しています。実はボスパラメータを3月1週目のプランナーが編集していたため、ゲーム上で動作しない現象が発生していました。

もう一点、実機確認までに時間がかかる問題では、マスタデータをゲームデータに変換するところがJenkins頼みになっていることが原因でした。

Jenkinsは他の人が実行中に作業できないため、当然待ち時間が発生します。作業者が増えるほど、ビルドの待ち時間も増えるので、入力したマスタデータを実機で確認できるまで、かなりの時間が必要になることが課題となっています。

最後に「差分が見にくい」といった課題も明かされました。

DeNAではマスタデータを入力後、正しい値が入力されているのか、修正不可な内容を編集していないか確認するために、GitHub上でレビューを実施しているとのことですが、この差分の確認がしづらい課題もあり、ゲームデータに変換後のデータをGitHub上で確認しています。

そのため、ゲームが読み込む形式のjsonやCSVのフォーマットテキストで差分を確認しますが、その際には行単位で差分が表示されるため、非常に人間の目に優しくない(セルが細かくて目が疲れるなど)課題も発生しています。

共通基盤システム Oyakata

先述した課題を解決するために、DeNAでは共通でマスタデータを管理するための、共通基盤システムOyakataを開発・活用しています。このシステムは以下の4つの機能を備えていることが紹介されました。

・バージョン管理機能
・変更データをOyakata上でレビューできる機能
・CIを経由しなくてもゲームデータに変換できる機能
・入力されたデータの検証機能

Oyakataは、モバイルゲームの運用に特化したマスタデータの管理用ツールで、ゲーム内マスタデータを一元管理し、ゲームデータに変換やデータチェックする機能まで備えています。大きな特徴として、バージョン管理機能、ブランチ機能、コミット機能を備えて、細かいバージョン管理をすることが可能とのこと。

管理できるレベルに関しては、gitと同レベルのバージョン管理機能を備え、これまで述べた説明通り、DeNA社内でこれまで発生した課題を解決するための機能を備えています。

また、複数のリリースバージョンを同時並行で作業していても、他の案件から影響を受けない構造にしたい目的も実現しているようです。

特に、作業するプランナーが50名を超える規模に拡大した開発現場では、単純にチーム内のコミュニケーションやワークフローレベルの改善だけでは、影響範囲の切り分けが難しくなり、システムでのサポートが必要だという課題を感じたそうです。

また、同リリースバージョンの中でも複数人で作業を可能にしたい、という要望を叶えることも目的のひとつになっています。

さらに、プランナーのデータ入力、ゲーム側の確認のイテレーションはできるだけ迅速にしたい要望もあり、これまで使用してきたJenkinsやスプレッドシートの組み合わせだけでは実現できなかったため、内製のマスタデータ管理システムを開発することになった経緯が説明されました。

Oyakataでは、その独自のシステム上でマスタデータを作成します。Jenkins上でゲームデータに変換するのではなく、作業者のローカルPC上でゲームデータに変換するという仕組みになっています。

ゲームデータを用いて実際のゲーム、UnityEditor上や実機で確認することを繰り返し、正しいパラメータに調整していきます。

その後、Oyakata上でPullRequestを送ります。GitHub上でのPullRequestではなく、OyakataがPullRequestの機能を備えており、PullRequestを送れる仕組みです。Oyakata上でPullRequestがOKであれば、マージ、開発ブランチに内包します。

この時点では、Oyakataのシステム内部のみでマスタデータが反映されている状態なので、続いてgitに登録することが必要になります。この部分では、ゲームデータを定期的にOyakataに登録されているマスタデータをデータに変換して、gitに登録するという仕組みを採用しています。

プランナーはOyakataを使用すると、Excelもしくはアプリケーションで編集する場合もあれば、マスタデータによっては、スプレッドシートなどの他のツールで編集したほうが効率が良い場合もあります。

例として、マップデータでエディターを用意し、マップをビジュアルで参照しながらマスタを設定したい場合、マスタの種類や目的に合わせて、適切な編集ツールを使うことができます。その後、マスタデータを入力して、Oyakata上で保存します。

続いてゲームサーバーに配信しなければいけないため、OyakataのDownloaderと呼ばれるCLIツールを使うことでゲームサーバーにデプロイすることが可能です。そしてサーバーからマスタデータを実機に配信することで、リリースやQA時、デバック時などもゲームデータの反映を行っています。

Oyakataを利用するメリットは、マスタデータ入力のためのワークフローを簡単に構築することができ、さらに運用スタートしてからの並行開発にも対応しているため、複数の開発が並行で進んでも現場が混乱しないワークフローが構築可能なことです。

また、バージョン管理の仕組みでは、各個人を切り分けて作業可能で、Jenkinsに依存しないマスタデータの変換の仕組みも備えているため、マスタデータを入力してから実機確認するまでの時間を短縮するワークフローが構築できるのも強みと言えます。

さらに、Oyakata上でマスタデータの差分を表示・レビューする機能も備えており、差分表示はGitHubのように行レベルでの表示ではなく、行と列がある形式のデータに合わせた見やすい差分の表示になっているので、意図せず誤った変更についても、レビュー段階でチェックできる仕組みを構築可能と人西は述べました。

また、Oyakataには共同で編集できるメリットもあることが明かされました。

CSVファイルとgitでマスタデータを管理する方法では、CSVファイルをレビューする場合、編集差分がgit上では非常に目視しにくいが難点になります。

CSVファイルを直接編集するワークフローでは、関数機能などCSVに保存することはできません。スプレッドシートからダウンロードし、ゲームデータに変換するツールを用意する必要があります。

また、Googleスプレッドシート自体にはバージョン管理の仕組みがないため、バージョン管理の仕組みもディレクトリごとに分類する必要があるとのことです。

Oyakataには、エディター・コンバーター・バリデーターの3種のコンポーネントが実装されており、各特徴が紹介されました。

エディター

エディターは、マスタデータを一覧で表示できる機能で、WEBアプリケーションとして提供しており、特徴としてレコード数の多いテーブルを複数に分割して管理することができます。

この機能があることで、マスタデータの運用が長期化・肥大化した際に、マスタデータのレコードごとにテーブルを分割して管理できるため、編集時に重いExcelファイルを開いて作業する手間が必要なくなります。

また編集の履歴機能では、gitと同様のコミット単位でのバージョン管理を提供しており、編集差分を確認することも可能で、ブランチの差分も表示可能。イベントをリリースする際、開発側での変更部分を一覧で表示することも可能なようです。

同様にこのエディターでマスタデータを編集する機能も実装されているそうです。これはマスタデータのレコードをWEB上のアプリケーションとExcelアプリケーションとしてローカルPC上で作成、変更、削除できる機能で、編集データはOyakata上でゲームデータに変換することが可能とのこと。Oyakata上にもGitHubと同様のレビュー申請やレビュー機能を備えているので、変更内容を表形式に合わせた見やすい差分表示にすることもできると人西は紹介しました。

コンバーター

コンバーターは、Oyakataで管理しているマスタデータをゲームのデータに変換する機能で、こちらもCLIとして提供。

ゲームごとにマスタデータを読み込む形式に差異があるため、Oyakataはjson形式とCSV形式でゲームのフォーマットに合わせた出力に対応しています。このCLIツールはマルチプラットホーム対応で、プランナーもWindows・Mac上でダブルクリックするだけで実行可能とのこと。

さらに、マスタデータの実機確認をする際に、Jenkins上でゲームデータを変換せず、マスタデータを自分のローカルPC上にダウンロードしてゲームデータを変換、UnityEditorで確認するフローを作ることが可能。

バリデーター

バリデーターは、マスタデータが正しいかチェックする機能で、こちらもCLIツールとして提供。マスタ間のリレーションチェックや、ゲームタイトルごとに独自で禁止事項を精査し、DSLによって、テーブルごとに設定することができます。

これまでの仕組みと違う部分は、ブランチ管理をサポートすることにより、完全に他の作業者の影響を受けなくなっている点。マスタデータの作成時も、ブランチ管理の仕組みを完全にサポートすることで、プランナーにも提供することが可能になっているとのことです。

また、ゲームデータの変換をローカルPC上で実行することにより、課題であるJenkinsの待ち時間を短縮することができたとのこと。さらに、マスタデータの表形式に特化した差分表示が可能なため、見やすい表示を実現しています。

Oyakataは、実際に新規開発プロジェクトで導入して利用中とのことですが、主にエンジニアが機能開発に必要な仮のマスタデータを入力したり、プランナーが用意された機能開発においてデータを追加・調整するために活用していると、人西は述べました。

このようにOyakataのシステムにはメリットが感じながら、実際にプロジェクトで活用して判明した課題もあるとのこと。それは運用ではなく、新規開発に適したワークフローではなかったという部分だそうです。

新規開発時では、特にデータを大量に作成する量産フローがあるため、正しいマスタデータを入力できる仕組みと比較すると、大量のデータを効率的に入力できる仕組みが重要で、その部分に関して考慮できていなかったと省みたとのことです。

本セッションでは、これまでスプレッドシートで対応しにくかった、並行開発時の各個人の作業影響範囲の切り分けや、Jenkinsに依存した管理や順番待ちの時間、jsonやCSVの目視確認のしづらさなど、各種課題を解決するために、マスタデータ管理の共通基盤システム「Oyakata」が開発され、それを活用することで、新たな仕組みが社内に生まれ始めていることが、明らかになりました。

最後に、ゲームの新規開発時の課題対処について、今後もこの共通基盤システムを活用しながら、開発現場を通して「マスタデータはどのようにあるべきなのか?」といった定義を探っていきたいと考えている、と登壇した人西はセッションを締め括りました。

取材・文・撮影:細谷亮介

[su_note note_color=”#ffffff” radius=”10″]

GeNOM(ゲノム)とは

DeNAのゲームクリエイターを様々な切り口で紹介するメディア(運営:株式会社ディー・エヌ・エー)です。ゲーム開発の現場で生まれる様々なエピソードや、クリエイター紹介、イベント紹介などを通して、DeNAで働くメンバーの”ありのまま”をお伝えしていきます。

GeNOMの最新情報は、公式Twitterアカウントにて確認いただけます。ぜひフォローをお願いします!

[/su_note]

【CEDEC2019】「ゲーム開発者とゲームメディアの理想の関係とは?」セッションレポート

2019年9月4日~6日の期間、パシフィコ横浜において、ゲーム開発者向けカンファレンス「CEDEC2019」が開催されました。

本記事では、9月4日に行われた「ゲーム開発者とゲームメディアの理想の関係とは?」において、DeNAのゲーム事業部を率いる佐々木悠と、2019年7月より、まったく新しいメディアの形を模索して完全独立系のメディアとして再スタートした「電ファミニコゲーマー」編集長のTAITAIこと平信一氏によるセッションの内容を、一部抜粋してレポートします。

ゲームメディアの変遷

セッション冒頭で、株式会社ディー・エヌ・エー ゲーム・エンターテインメント事業本部 ゲーム事業部 事業部長の佐々木悠と、株式会社マレ 代表取締役社長の平信一氏より簡単な自己紹介と、自社での担当業務などが説明され、これまでのゲームメディアの変遷についてディスカッションが開始されました。

まず、2014年度のデータを基に、ゲーム雑誌とWebメディアについて部数やアクセス面からグラフ化した資料で現状を把握しました。

1995年頃はファミ通などゲーム雑誌が最盛期を迎えていましたが、雑誌売上が減少する中、2000年頃からWebゲームメディアが登場、2010年頃にはWebゲームメディア数も増え、攻略サイトやまとめブログなど、新興勢力が急激に台頭してきたことが読み取れます。

市場・ビジネス面から俯瞰すると、年々ゲーム雑誌の売上は下がる一方ですが、Webゲームメディアの収益は上がっています。平氏は「市場の規模がダウンサイジングしており、このままではゲームメディアの未来が危ない」と感じたため、これまでにない新しい取り組みを考えたと話しています。

また、ブラウザ型ソーシャルゲームが流行した時期には、いわゆるアイテムコードのような「おまけ」を付けて販売する冊子が、コンビニなどで飛ぶように売れていたことを思い出したと、佐々木は述べました。

続いて、攻略本の売上および攻略サイトのアクセス数をグラフ化しました。2000年頃からインターネットで個人的に攻略Wikiなどを作成して公開する人が増加、さらにアフィリエイト業者が介入して組織的に構築した攻略専門サイトが登場しはじめ、出版社はビジネスチェンジを迫られている状況でした。

佐々木は、モバイルゲームを専門的に開発してきており、攻略情報はネットで取得する世代であり、以前は時代に逆行してモノとして手元に残る攻略本のようなアイテムを作ろう、という動きが当時は多少あったことを明かしました。

リアルに対する接地面を作るため、ネットだけで完結していた時期に比べ、最近ではゲームのオフラインイベントなどを積極的に開催する動きも増えています。

さらに、あらゆるサイトがPCからスマートフォン対応に移行し始めており、広告の運用手法も変わるため、広告収益のみで運営しているサイトは現状かなり苦しく、Webメディアの危機と言えます。

過去にDeNAでは、自社で攻略サイトを制作・運営する取り組みをしてみたところ、とても効率が悪く、数年で中止となったことを佐々木は話しました。自社で攻略に使えるデータをすべて持っているのに、業者サイトに勝てない難しさがあることは確かなようです。

特にオフィシャルで攻略サイトを運営するには、工数や労力、使用した予算に対して効果が見合わず、プレイヤーにとっては、情報さえ早く、正しいものであれば、公式でも業者でもどちらでも構わないカルチャーだと認識できたとのことです。

昨今、スマートフォン向けゲームのシステムが複雑化していく中で、開発側から提供する一時的な攻略情報は「ゲームを売るための手段」として見られてしまいがちで、自身で攻略する楽しみなど、コア化が進めば進むほどその傾向は強くなると考えられます。

ネットの発達が何を変えたのか?

続いては、アクセス計測ツールを利用した2014年度の、商業ゲームメディア、ゲーム雑誌、攻略Wikiなどゲームに関連するメディアについて、発行部数やPV数に基づいた勢力図が発表されました。現在は国内ではTwitterなどのSNS運用が、かなり台頭していると思われると佐々木は話しています。

また、現在のゲーム実況に関してはYouTubeやMirrativ、Twitchなどにほとんどが移行しており、特に最近のゲーマーには動画配信が必須となっていると、平氏は述べました。

開発者とメディアの理想の関係

ここからは、現代に合わせたゲーム開発者とゲームメディアの理想の関係における、ゲームをプロモーションするためのメディア活用方法の変化などについて、フリーセッションが披露されました。

これまでは、ゲームメディアや雑誌が「ゲームを売るため」の媒体としての強い力を持っていましたが、時代や環境の変化によって、もはや現在ではプライオリティの高い媒体ではなくなっており、役割やミッションの在り方も変化しています。

開発側も、メディアに記事を書いてもらう、プレイ動画で解説をしてもらう、など違った手段でプロモーションを依頼することもありますが、大きな違いは「きちんと伝わりやすく編集されていること」「今思ったこの瞬間の気持を伝える」というどちらの手段にも価値を感じ、どうしても編集して伝えたいメッセージがあるときは、ゲームメディアに頼ることがベストに近い方法だと佐々木は話しています。

現在ではゲームメディアの役割や棲み分けも変化しており、「なぜこのゲームが好きなのか?」「ゲームのこの部分が良い」ことを言語化する、その部分をメディアがインタビューなどでシェアできれば、伝えたい情報をプレイヤーが捉えて反応するところまで含めて、メディアの役割になり得ると言えるようです。

佐々木が特に最近では、作り手の誠意や想い、どんな感情を持っているか、など注目されていることを感じており、開発者の発信が増えてきて、担当者がどんな人格を持ち、どのようなパーソナリティを発信するのかを考えることが重要だと話しました。

その手段として、SNS以外のインタビューなどで引き出させるもの、何を使って何を伝えるのかははっきりと開発側が考える必要がありそうです。特別なタイミングでは、メディア側にインタビューしてもらった記事を発信しないと、情報に偏りが出てしまいます。

一方で自社で完結する情報発信は、陽動的な印象をプレイヤーに与えてしまうことも多分にあるので、第三者が介入して良い質問や厳しい質問を含めた記事を利用することも必要となると、平氏は指摘しました。

ゲームを売るため以外の情報発信が、メディアの価値のひとつとなっていきますが、クリエイターが希望した時期や、ゲーム発売やリリースのタイミング以外のプロモーションでの情報発信を、ゲーム会社側も意識してすり合わせることが必要です。

中長期的な収益、プレイヤーとの関係性、エンゲージメントの部分に対するメディアでの発信の仕方について、KPI・KGIを計測するのはとても難しく、コミュニケーションの効果はすぐに結果として見えません。

数字として見えづらい部分に対して、開発者側が意思を持って取り組むことが重要で、投資判断も必要になります。

Webの世界では数値の換算は当然で、記事を掲載後のPV数や、実際のDL数などがKPIになりがちで、プレイヤーに広める、共感を得るようなインタビュー記事などの効果も、KPIとして計測しにくいのが現状です。

佐々木の過去の失敗事例として、あるタイトルの動画を制作したところ、約400万回再生されたが、実際のゲームDL数は約100人程度だったとのこと。蓋を開けてみると、ゲームではなく動画のファンが大多数を占めていたことが分かったそうです。

もちろん熱量を伝える手段として動画は重要ですが、プロモーションとして届ける目的地のプレイヤーが何を求めているかを正しく理解しないと、どれだけ投資しても効果は出ないことを体感したとのことです。

本当にゲームが好きなプレイヤーに対しては、メディアが発信する強い力を利用し、開発者が思っている気持ちを素直に届ける場合には、個人的に発信したほうが伝わる場合もあるので、開発側も方法を考え、選んでいくべきだと佐々木は述べています。

会場からの質問

参加者に向けて、現在悩んでいることを質疑応答形式で聞き、両者がそれぞれ回答しました。

Q:自社でIPタイトルについてTwitterで拡散をしているんですが、広告宣伝費はほとんどなく、IPの知名度も低く、現在Twitterのフォロワーが1,000人ほど、あと2ヶ月ほどで1万人にしたいのですが、どのようにすればよろしいでしょうか?

平氏:電ファミニコゲーマーでは、約1年ほどTwitterのフォロワーが伸びませんでした。良い記事は掲載されているのになぜだろうと悩んでいました。そこで学んだのは、Twitterに限らずWebの世界では、テクニカルにお客さんの背中を押すことが重要になっています。

また、他社のTwitterの取り組みの中で、フォロー&リツートでプレゼントする企画も増えていますが、単純にフォローさせるために、賞品など直接的な一手を何かしらの理由を付けて実施しています。

YouTuberとのコラボは、お互いのチャンネル登録者を交換するようなイメージの取り組みなんですね。コメントしてくれた人の中から抽選でプレゼント、番組に出演するからフォローしてね、みたいなテクニカルでフォローせざるを得ないような一手を考えると良いと思います。

佐々木:短期間で直接的にフォロワーを伸ばせれば、宣伝効果も高くなると思いますが、併せてTwitterの価値を含めて、基本的なエンゲージメントを伸ばすことも考えたほうが良いですね。

Q:プロモーションやマーケティングのコンサルや広告代理店に相談することはありますか?

平氏:僕の立場だと、広告代理店側から「どういうイベントや取り組みをすれば面白いですか?」と相談を受けることが多いですね(笑)。

佐々木:マーケティングのコンサルタントや、代理店にお願いすると、ほとんどが過去のタイトルで使用済みのパッケージ化されたアイデアが多いので、開発側が意識しなければいけないのは、これまでにない新しい手法を生み出すことですね。

また、費用対効果を含めて、(代理店などに)任せる部分、自分たちでアイデアを出して実行する部分を見極めるのが大事だと思っています。

日本モバイルゲーム産業史を制作中

そして最後に、本セッションの大きな目的とも言える、DeNA特別協賛で電ファミニコゲーマーと作る「日本モバイルゲーム産業史」の情報が公開されました。

電ファミニコゲーマーでは、平氏が率いる株式会社マレに運営が移管後、メディアとして企業協賛といった新しい試みをしています。

協賛第一社目としてDeNAが参画した理由として、まだ歴史が浅く、高速で成長したモバイルゲーム領域について、どのような変遷があり、クリエイターがどんな想いで関わっていたのかなど、これまで語られたことも少ないため、「日本モバイルゲーム産業史」を制作することを決めたとのことです。

平氏によると、「日本モバイルゲーム産業史」は約1年ほどかけて製作予定で、インタビューやコラム記事など展開予定だが、モバイルゲーム業界で過去に何が起こったのかを整理した年表をまず最初に作っていることが明かされました。

これまでどのようなことが起きたのかを当事者に連絡して、情報を持ち寄ってもらう声がけをしている最中とのことです。

取材・文・撮影:細谷亮介

[su_note note_color=”#ffffff” radius=”10″]

GeNOM(ゲノム)とは

DeNAのゲームクリエイターを様々な切り口で紹介するメディア(運営:株式会社ディー・エヌ・エー)です。ゲーム開発の現場で生まれる様々なエピソードや、クリエイター紹介、イベント紹介などを通して、DeNAで働くメンバーの”ありのまま”をお伝えしていきます。

GeNOMの最新情報は、公式Twitterアカウントにて確認いただけます。ぜひフォローをお願いします!

[/su_note]

【CEDEC2019】「ゲームと機械学習の最前線~現状と未来を正しく捉えるために~」パネルディスカッションレポート

2019年9月4日~6日の期間、パシフィコ横浜において、ゲーム開発者向けカンファレンス「CEDEC2019」が開催されました。

本記事では、9月6日に行われた「ゲームと機械学習の最前線~現状と未来を正しく捉えるために~」パネルディスカッションの内容を、一部抜粋してレポートします。

※本文は登壇者の発言をもとに対談形式で記載してあります。

ゲームと機械学習の最前線

奥村:今回のセッションは「ゲームと機械学習の最前線」というテーマでお送りします。AIに関しては、昨年頃からハイプ・サイクルでは、いわゆる幻滅期に差し掛かっていると言われていますが、それでもなお、AI技術の進展や産業への応用は増え続けています。

今回は2名の著名なゲームAI開発者をお招きし、そもそもどのような領域にAIが使われていくのか、AIはどれぐらい使えるのか、などディスカッションをしていきたいと思っています。

本パネルセッションは「CEDEC2018」で実施した「次世代QAとAI」の議論の続編に近い立ち位置になっています。当時は急速に増えて行くゲームへのAI活動の流れを感じながら、特にQA(品質保証)という領域に絞って、現状と今後について議論を行っています。

奥村:このQAに関しては、ゲームのコア部分の体系を作り込む作業とは、少し分離するようなコンポーネントであるため、会社や産学の枠を超えて連携していけるのではないか、というメッセージを発信させてもらいました。

セッションの開催背景

奥村:この1年を振り返ってみると、当時とは比べ物にならないほど多彩な変化があったと思っています。

ひとつの大きな変化としては、AI技術が進歩し続けていることです。連日のように最新のモデルが提案され、応用の幅も広がってきています。その流れはゲーム業界も例外ではなく、1〜2年ほど前まではとりあえずAIを活用してみようといった、導入検証に関する話題が多かった印象ですが、ここ1年ほどは実際にプロダクトに導入され、事業価値を生み出している事例も増加してきています。

そのような状況の中、技術に対する期待感も成熟しつつあり、「ゲーム×AI」に関する議論は、より実践的な話にシフトしてきたと考えられます。また、実際にどのくらい売上貢献可能なのか、AI導入を見据えた開発プロセスや体制の模索も続いています。また、そうした知見は広く世間に公開されており、横断したつながりも増えている印象も感じています。

セッションのモチベーション

奥村:本セッションでは、次に挙げる3つのモチベーションをもとに、ディスカッションを進めて行きたいと考えています。

まず1点目ですが、なるべく多くの実用事業を俯瞰したいということ、2点目はそれらの事例を元にして現時点でAIはどの程度使えるのか、導入の障害について議論していきたいと考えています。

パネリスト紹介

奥村:それではパネリストを紹介したいと思います。まずは株式会社スクウェア・エニックスの三宅陽一郎さんです。

三宅:スクウェア・エニックスのテクノロジー推進部でリードAIリサーチャーとして、10名ほどのAIチームを率いています。過去にはロボットゲームや『ファイナルファンタジー』シリーズのAIの設計などに携わりました。

自分はこれまで、どちらかと言えば記号主義型、シンボルを使った人工知能について担当してきましたが、これからは機械学習の方に徐々にシフトすると考えており、研究を進めています。

奥村:ありがとうございます。続いて株式会社バンダイナムコスタジオの長谷洋平さんです。

長谷:バンダイナムコスタジオで現在開発中のオンラインゲームタイトル『BLUE PROTOCOL』にて、リードAIエンジニアをしています。実際のゲームタイトル内部のAIの開発をしつつ、並行してAI関連の最先端の技術のリサーチや、技術研究を担当しています。

この技術研究の中にはディープラーニングも含まれますし、それとは別に、ゲームに関連しない汎用的に使用可能なゲームAIのエンジンも開発しています。また、キャラクターのアーキテクチャを中心に、汎用的な開発研究にも携わっています。

奥村:そして最後に私はDeNAのAI本部で、主にゲームAIや強化学習といった技術を使った案件のマネジメントを手がけております。個人的な興味領域は、どのようにAIを事業価値につなげるかを考えており、AIエンジニアとプロダクト間を横断する活動をしています。

AIにまつわる用語の整理

奥村:まず本題に入る前に、セッションで使用する用語について簡単に整理します。

一般的にAIとは、人間と同等もしくはそれ以上の処理を行うためのテクノロジー全般を指します。中でも、判断や予測する能力をデータから機械的に学習するものを「機械学習」、さらにその一種で深いニューラルネットワークを用いたものを「深層学習」、いわゆるディープラーニングと呼んでいます。また、ゲーム業界で厄介な事例として、ゲームAIという別の言葉が存在します。

こちらは、学術領域で使われているAIとは全く別の文脈で進歩した概念です。そちらは区別をして使用したいと思っています。本セッションでは、AIという言葉はあくまでも機械学習全般を指すものとして定義します。

AIが推論をする際は、まず信号を数値変換して入力し、機械学習のモデルに組み込みます。ここで行列演算が実行され、結果が出力されます。たとえば異常検知に関しては、この入力が異常である確率が出力されます。

ネコとイヌを分類するAIを作る際の例として、ネコの画像を3色のRGB値に変換してモデルに組み込みます。するとこのモデルはディープラーニングを想定し、ニューラルネットワークを使って行列演算をして、ネコかイヌかの確率を推論します。

奥村:さらに教師データを用いて、なるべくこの確率ループがネコに近づくように、再度トレーニングし、モデルをアップデートする指示、さらに学習を繰り返すことによって、ネコの認知精度がより上がる仕組みになっています。

強化学習は、動物に芸を教え込むような行動に似ており、AIエージェントに対して、ある状況で行動を取る際に報酬をもらえると仮定し、そのフィードバックを蓄積していきます。それを反復することにより、好ましい行動を取るように訓練されていきます。

AI活用の現在

意思決定

奥村:意思決定に関連して、囲碁や将棋の分野において、人間と同等かそれ以上の賢いゲームエージェントが登場しています。

最近では、AlphaGo(アルファ碁)などは、かなり有名になっていますし、特に今年に入ってからのトピックとしては不完全情報原理が話題に上がっています。

例えば『StarCraft』や『Dota』などのゲームタイトルに代表される、長期戦略を扱うタスクでも、人間を超えるパフォーマンスを出すことが可能になっています。

そのような賢いエージェントが存在するデファクトした世界で、どのようにゲーム開発が変わっていくのか、事例を基にした方向性を紹介します。

奥村:1つ目はコンテンツ応用として「Human vs. AII」になります。eスポーツも同様に、ゲーム外の思考性として、人間とAIを戦わせること自体がコンテンツとなる世界が存在すると考えられます。

またゲーム内の思考性として、プレイヤー補助のためにエージェントを使用することも考えられます。初心者の対戦相手としてバランスの良いAIを使うような、ゲーム内コンテンツとしての応用です。

2つ目にQA文脈での応用については、ゲーム内を賢く回遊できるエージェントがあれば、テストも同時に実行してほしい、という発想から生まれています。

DeNA 奥村純

奥村:ゲームの内部が正しく動作しているかを確認するために、エージェントはゲームの中をひたすら動きまわり、自動プレイのテスト環境を作るQAオートメーションを実装しています。

また、ゲームバランスの担保、そもそも「ゲームが面白いことをエージェントに評価させる」動きも生まれ始めています。

実際の事例として「Human vs. AII」のコンテンツとして、『StarCraft』や『Dota』はもちろん、『ブレイドアンドソウル』『Arena of Valor』などのゲームタイトルでも、実際に人間のトッププロを打ち負かすような成績を記録しています。

奥村:プレイヤー補助に関して『逆転オセロニア』では、初心者から上級者までさまざまな強さをパラメーターで調整しており、それをユーザーに合わせたレベル版のAIを用いた練習コンテンツを提供しています。

また、対戦格闘ゲームタイトル『サムライスピリッツ』では、エージェントをミラーリングして他プレイヤーのように振る舞うAIと、実際に対戦可能なシャドーイングのコンテンツも提供されています。

奥村:一方でQAについては『北斗が如く』では、実際にそのゲーム内をエージェントに回遊させてVRAM使用率を可視化し、コリジョン抜け検知をするエージェントを作っています。

奥村:また、GDCなどでも『Battlefield V』や『The Division』などのゲームタイトルにおいて、実際にクラッシュ検知などで役立つトピックスを紹介するセッションが、注目を浴びていました。

ゲームバランスの担保に関しては『Candy Crush Saga』に採用された、実際に人間のようにプレイ可能なエージェントを、ディープラーニングでトレーニングすることにより、これまで新マップを追加するために、人力でのテストプレイが1週間ほど必要だった工数が、およそ数分に圧縮した例が紹介されています。

さらにCEDEC2018では、『D×2 真・女神転生 リベレーション』『コトダマン』などのゲームタイトルについて、さまざまな強化学習の遺伝的アルゴリズムを使った、ゲームバランスの調整をした事例も公開されています。

奥村:このような強化学習や強いエージェントが生まれることは、もちろん素晴らしいことなのですが、ゲームごとに特徴量のアーキテクチャを設計する必要があります。それをタイトルがリリースされる度に作業が必要となることが問題でもあり、スケールしづらい要因にもなると考えています。

株式会社スクウェア・エニックス 三宅陽一郎氏

三宅:現在、採用されているフレームはエージェントアーキテクチャです。「センサー」「認識」「思考」「行動」「エフェクター」という形ですね。いわゆるロボティクスから借りてきたアーキテクチャにそれぞれのゲームの知識表現を作り、ゲームに対応します。しかし、それはやはりゲーム依存なんです。

ニューラルネットの特徴は、そのような表現の規定が不要なところにありますが、それでもインプットするパラメーターを決める必要があります。

さらに、ニューラルネットワークの形を決めるノードの組み方の問題も存在します。組み方には特に規則性がないため、現在では適当に決めています。特に最初から最後まで、すべてE2Eで組んでしまおう、という方向がこれまでは強かったですね。

ゲームをプレイする人工知能を、すべてニューラルネットで実現することに関しては、アルファ碁やアタリのゲームレベルにおいて成功したところから、若干夢を見た部分がありましたね。大型ゲームにおいてニューラルネットだけでAIを実現しようとしても、思ったとおりに実現できないことが分かりました。

昨今の複雑なコンテキストを持つゲームは、ある程度古典的なアーキテクチャが存在し、その1個のモジュールをニューラルネットで実行する方法に、今後の未来があると感じています。

特に、階層型タスクネットーク(HTN:Hierarchical Task Network)など、問題をタスクに分けた上で、各タスクをニューラルネットワークの学習に任せる、という方向が有望かと思います。

そう考えると、ゲームシステム内のターゲッティングや魔法選択、アイテム選択などの技術はむしろ再利用できるようになるのでは、と判断しています。

奥村:ちなみに長谷さんのチーム内では、BehaviorTreeやBAのアーキテクチャについて、さまざまなタイトルで展開できる標準化がされていると思いますが、その観点でお話しいただけますでしょうか。

長谷:私も三宅さんの意見と同様に、E2Eで機械学習させようとすると、問題が複雑すぎてうまく動作しないことが多い印象です。そのため、BehaviorTreeのノウハウで、機械学習で選択するような仕組みを作るほうが、問題が限定でき、機械学習でも実行しやすくなる部分と、実際サーバがコントロールしなくて良い部分、機械学習に任せて良い部分に分類できるので、最適だと考えています。

機械学習をゲームで応用する方法については、そのゲームのキャラクターの動きに関して、重厚なイメージで動く場面、もっと爽快感を打ち出したい場面など、ゲーム制作の方向性によって求めている内容が違うため、共通化に関してはやや疑問に思っています。

株式会社バンダイナムコスタジオ 長谷洋平氏

奥村:実際に『逆転オセロニア』でもディープラーニングでエージェントを組みましたが、ゼロベースでチューニングしなければならず、大変でした。最近ではオープンAIファイルというエージェントを公開しましたが、そのアーキテクチャを見ていると、結構似通っていると感じますね。

そのような理由で、しばらくはゲームが新しく作られるごとに、ゼロベースでアーキテクチャなどをチューニングする必要があるのですが、ゲームジャンルに合わせて、ある程度アーキテクチャの指針は平準化して、共通のナレッジとして蓄積できる気がしています。

ただ、お二人がこれまで述べたように、やはりE2Eではないことはその通りだと思います。今後ディープラーニングなどが生き残っていく余地は、十分残されている気はしていますね。

続いて、先ほど長谷さんが述べていた「コントロールできる余地がない」話題について、もちろんスーパーヒューマンのエージェントが誕生すること自体素晴らしいのですが、そのテクノロジーを実際にゲームに適用すると考えたとき、コントロール不能だと怖いですよね。

プランナーからは「ここで必殺技を出したい」「変な挙動は絶対やめてほしい」など要望が出ますが、AIはブラックボックスになりがちなので、出力コントロールできないことは多々あると思っています。

その場合、どれぐらいコントロールすべきだと思っているのか、完全にディープラーニングのようなAI化ができるのか、それとも人間側でのコントロールする余地は必要でしょうか?

長谷:やはりその部分もゲーム内容で違い、デザイナーが決めた通りに動いてほしい場合もありますし、最近の複雑なゲームでは、チュートリアルやルール説明では完全に網羅できない部分が増えてきているため、一部機械学習を導入する必要があると考えています。

また、ゲームにどのような遊びを組み込むかによって、どの程度の機械学習を利用するかの判断は、ゲームそれぞれで、きちんと検討しなければいけない部分ではありますね。

特にアクションゲームや格闘ゲームのCPUキャラクターは、ルールベースで書かれている部分が多く、CPU戦でいくら戦っても、対人戦ではうまく動作しないことも多いんです。

さらに、最近活発になっているeスポーツの人気を上げるために、CPU戦をもっと人間らしく動かし、対人戦スキルアップの練習場所として提供できれば、その分野では、より機械学習を活用してAIを組み込む流れが生まれるのではと考えています。

三宅:ゲームAIの活用には3つ条件があって、まずその技術で多様性があること、そして拡張性とカスタマイズ性があることだと考えています。

昨今のゲームは大規模化しているので、細かい部分まで追いきれなくなっていますが、現段階での人工知能は、フレーム問題が解決しないと学習できないため、その問題を切り分けるコンテキストスイッチみたいな上層は、従来通りのステートマシンで大丈夫だと思っています。

例えば、モンスターと戦う、宿屋に泊まる、宝物を入手する、といった単純な作業はニューラルネットで処理し、ゲーム内での変更部分があればWrapする形で、ある条件が来たら逃がすような対応が良いと考えます。

メインはニューラルネットですが、周囲はルールベースで支えるような使用方法が現実的だと考えており、コンテキストスイッチと細かいタスク学習を同時に実行するのは、少し難易度が高いと思いますね。

奥村:結局ルールベースとディープラーニング、機械学習のハイブリッドに進化していくんですかね。

また、ディープラーニングは特徴抽出が得意な部分も含めて、自動的に処理してくれるのが強みなので、どうしてもE2Eで問題を閉じたがる部分はありますが、その観点ではゲームなら存在するイメージではありますね。

さらに似たような観点で、実際にAIのエージェントを作成した際、その挙動を誰がどのようにチェックするか、QAの分野にも関わりますし、トレーニングしたデータを、そのまま野放しにプロファクションに導入していいのか、不確実なデータを出すのは怖い、といった意見があると思います。

三宅:新しいAI技術はデバッグできないことが課題になっていますね。例えば自分が15年前にパス検索を提案した際も同様の状況でした。

ある条件下で、問題のあるアウトプットが出た際には、Wrapして外部、もしくは禁止して逃がす処理が必要です。現時点では、ニューラルネットを完璧に仕上げることは、誰にも不可能であり、保証するアルゴリズムも知られていません。

品質保証については、ある程度は可能ですが、補助策を設置した方が開発工程としては現実的だと考えます。納期があと1週間ほどの時期に、ニューラルネットを再度学習させて、再発注させることは回避したいですよね。

長谷:どうしても守りたい部分だけ、セーフティネットで禁止することは必要ですね。昨今のゲームはAIに限らず、(人力では)デバッグしきれない状態になっているため、すべての不具合を取り除いてリリースすることは、ほぼ不可能だと考えられます。

また、AIや機械学習、現在使用されている技術が100%完成しているわけではないので、禁止したい行動の部分だけコントロールすることが可能なら、それほど完成形を重視することはないと考えています。

QA・デバッグ

奥村:続いてのテーマはQAデバッグについてとなります。

三宅:最近のゲーム開発では、複雑化や大規模化がキーワードになっています。特にAAAタイトルのオープンワールド化が著しく、現在では50キロ四方を超えるような、巨大なスケールのゲームフィールドに対して、人間の手ではデバッグできない規模まで来ていると考えられます。

三宅:そこで、人間の代替役という意味を含め、AIと共に人間がデバッグしていかなければ、もはやコストや時間の意味でも、現実的な世界で普及がストップしてしまいます。その品質管理の部分を自動化するフェーズに、AIの自動プレイや自動バランス調整の案件も絡んでくると考えます。

三宅:ゲームAIの歴史は、大きく分けるとゲーム内外のAIが存在し、キャラクターAI・ナビゲーションAI・ベターAIなど、おおよそ3つに分類されます。

開発工程でのAIは、ゲーム外部のAIのことを指し、さまざまな技術、勝利方法など、その中で一番の重要項目としてQAのAIが存在し、2015年頃からQAのAIについて機械学習を用いることが、GDCでの発表以降、現在ではホットトピックとなっています。

例えば『Battlefield V』の機械学習に関して、現在は実際にあまり応用はされておらず、プレイヤーのインターフェースを発揮する形で、AIがキャラクターを動作することで自動にBotを操作して、デバッグをしています。

三宅:また、Frostbite engineのスクリプト、ビジュアルスクリプトでFrostbite schematicが存在しますが、これは機械学習ではなく、スクリプトを活用してBotを動かし、できるだけcoverageを上げる形で全領域のナビゲーションを使用、多数のキャラクターを出現させて、負荷や衝突のデバッグをしています。

なお『The Division』では、ダウンロードコンテンツで自動生成することが特徴になっています。ナビゲーションの意志や既存のAIシステムを活用し、機械学習ではなく、スクリプティングやBehaviorTreeを使った形でデバッグをしている事例もあります。

三宅:さらに『The Division』では、プレイヤーのインプットを上手く活用する形で、プレイヤーをフォローイングするログデータを使用し、ログサイクルを回しながらデバッグをしています。

もちろん最初のテストプレイは人間が担当しますが、さまざまな場所でジャンプ動作をするような、特殊な操作についても、プレイヤーのインプットから記憶させてトレースしています。それにより、AIに統計的に学習させる仕組みです。

プレイヤーのアクションシステムでは、どの場所でインプットが活用できるのかをレコードし、デバッグを実行しています。

三宅:『Battlefield 1』のオンラインモードでは、16体のキャラクターを導入して、大規模戦闘のデバッグ時に、EA SEEDという研究所で、イミテーションラーニングなど機械学習のテクニックを使用しています。

『Battlefield 1』のテストマップでは、さまざまな行動パターンをキャラクターにビジュアルカメラを付け、カメラインプット、行動アウトプットの形で機械学習をさせています。また、マップ上で自動的に動くようなBotを使用し、多数のキャラクターを登場させて、オンラインの負荷をデバッグ、QAしています。

奥村:最近では、事例が増えてきており、網羅しきれない物量になってきていますよね。

三宅:恐らく現世代が、人間の手でデバックできるギリギリの物量だと思っています。要するに次のコンシューマーや次世代のゲーム機対応タイトルでは、AI抜きでは成立しないという方向に、どこの企業も同じ見解を示しています。

そのための予防策として、コストはゼロにならなくても、QAコストを維持するぐらいでのレベルで機械学習を導入するなど、研究開発として進めつつ、現実的に違ったスクリプティングやナビゲーションを使用したQAを実行、あるいはログデータを使用したQAを実施することも考えています。

奥村:単純にバグ検知などで、エージェントに回遊させてバグを発見することが、自然に導入されていくことも考えられますね。

一方で事例にもありますが、面白さのQAの話題は絶対に発生します。ゲームの面白さをどのように担保するのか、実際にQAは機械化できるのか、といった質問を受けることが増えてきましたね。

三宅:面白さのデバッグは、できないと考えます。ただ可能なのは、そのゲームが「面白くないこと」を検知することだと思いますね。

単純な問題点は、プレイ時間がかなり長いことが挙げられ、戦闘時間が長い、アイテムを上手に使えていない、などの要素も該当します。そのように面白くないパターン、あるいは問題がある部分は検出できるのではないでしょうか。さらにその部分を1つずつ潰していくのが、現実的な活用範囲ではないかと考えています。

奥村:確かにそうかもしれないですね。カードゲームなどで、追加カードのバリエーションが増えると、組み合わせばかりを推奨してしまいがちです。

そもそも、プランナーの認知限界を超えるような量の面白さを担保しないといけない時代に、突入しているのかも知れませんね。

その状況では、何かしら機械化を進めないと大変ですね。実際に長谷さんが人工知能アプリに携わって、面白さを緊張度のようなデータを、線形回帰で実施している資料を拝見したんですが、面白さはマトリクス化できるのでしょうか?

長谷:自分は過去に、ゲーム内の敵の生成や多彩な要素をAI側で整備する、メタAIの分野を担当していました。その中でプレイヤーの緊張度をコントロールする部分で、緊張度が現在どの程度なのかを推定するために、プレイヤーのプレイログから、線形回帰でプランニングからパラメータを抽出して、モデルを作成していました。

現在は、緊張度のデータが正確なのか、細部まで確認ができていないのが現状です。面白さのような、より抽象度の高い項目に関して、何かしらデータから導き出すのは難易度が高いと思っています。

奥村:その部分は本当に同意見で、どちらかと言えばAIの使いどころは、面白くない部分をどのくらい減らせるかといった「検知」に繋がることが、今後重要になっていくと考えています。

最後のトピックスは、ゲーム開発が普通のWEBサービスなどと若干異なる部分になります。ゲームでは面白さが大前提にあり、その仕様が直前に変更されることが多々あります。

例えば、当初の企画では、プレイヤーが1メートルしかジャンプしない設定だったところ、やはり1.5メートルジャンプした方が面白いのではないか、と直前に仕様が変わることが良くあるということです。

そのような開発フローは現在の現場でも続いていると思いますが、(その部分に関して)実は機械学習の導入が相性良くないのではないかと考えています。

要望通り、プレイヤーが高くジャンプできるように作り直したあと、その仕様に合わせて、もう1度ディープラーニングの学習を走らせてエージェントを作ってQA、というフローを毎回繰り返さないといけない部分もかなり多いと思うのですが、そのあたりはどう考えていますか?

三宅:QAの方にヒアリングすると、最初のデバッグは自分たちで作業したい、といった声が多く挙がっています。最初の通しプレイヤーとして、まずはどんなゲームか理解していないため、いきなりAIにデバッグをやらせるわけにいかない、という理由です。

ただ同じ検証を続けるなら、2~3回目ぐらいからはAIに任せたいという声も挙がっています。もちろん人間としても、繰り返し作業はしたくないですし、そちらをAIに作業してほしいと考えています。

ゲームは一種のアートでもあるので、プレイヤーは面白くないことがわかると絶対離脱してしまうんですよね。また、ジャンプの高さをちょっと変えたら、ナビゲーションは全部やり直しになってしまいます。

企画段階から、変更可能なサイクルを見越して体制を作っておかないと、機械学習がきちんと機能して終わりというわけにはいきません。再学習のコストも含め、作業がどれぐらいの速度で終息するのかを推測しておくことも必要ですね。

奥村:リスクマネージャーのような、ゲーム開発においてどこまで仕様の変更を許容するか、ハンドリングするポジションの人間が、どうしても開発には必要です。そこに機械学習が導入されると、再トレーニングやデータ収集プロセスも含めて、AIを活用するには、これまでの仕様を変えていく必要が出てきますね。

三宅:そうですね、海外ではゲーム開発の外部にコントロールする人間がいるんですが、日本はゲームデザインに関しては作家性を重んじる文化がありますので、ゲームデザイナーが変えると言えば、変えてしまう文化が残っており、仕組みとして止めるシステムがないのが、現実です。その部分は、日本特有の問題として今後残るかもしれないですね。

奥村:作家性と機械化の衝突みたいなのがありそうな気配がしますね。長谷さんはその部分で何か感じていますか?

長谷:現在自分が関わっているのはオンラインアクションゲームで、コンテンツや要素も多くてゲームシステム自体も複雑なんですが、複雑なゲームになればなるほど、多少の変更が多岐の要素に密接に関わるので、最初にレギュレーションを決めて、それに沿って開発をするように動いています。

もちろん面白くない部分があれば、組織全体を変更することもありますが、多少のことであればレギュレーションの範囲内で面白くするために工夫したり、現状を許容できるのであれば、AIを使ったテスティングの再学習をします。

それをしてでも、仕様変更をするべきものなのか、問題は大きくないから、この仕様は機械学習のエージェントを、再学習をする必要がないレベルで止めよう、といった判断が重要だと考えています。

異常探知

奥村:続いて最近増えている異常検知について、1つはチート対策が存在すると考えます。ゲーム内でチートしているプレイヤーを検知するものと、ゲーム開発においては、デバッグやバグ検知をなるべく上手く使い分けていきたいですね。

特に最近問題になっているのは、チート検知の部分です。多人数とマッチングする対戦プレイ可能なタイトルが増えてきており、その中のマルチ対戦のゲームでは、少数のチーターの存在が、ゲームの有益数を大きく毀損することが課題になっています。

奥村:例えば、ゲーム内に2%のチーターがいることにより、ダーティーマッチと呼ばれるチーターに巻き込まれる、本当に意味のない試合が約20%ぐらい生まれると言われています。やはりこれは無視できない数字ですよね。

少数のチーターも許せませんが、現在のプロセスではチェックしきれないほどユーザー数も多く、チートの技術も高度化しており、対処しきれないのが現状です。

その状況下で上手な対応として『Sudden Attack』の事例で、FPSでウォールハックと呼ばれる壁を透視する、敵がどこにいるかすべての情報を見れるチートがありますが、AIが判断した根拠が、注目度マップのように表示され、それをCSの人間がチェックしてチートだと判断、BANしやすくなっているシステムがあります。

奥村:このシステムによって、BANまでにかかる時間が24時間から数分に抑えられたという話題があり、結構面白いと思っています。

他には『Counter-Strike』などでも良く使用される、エイミングアシスタンスと呼ばれる必ずヘッドショットになる、銃のエイムを自動的に実行してくれるチートも存在しています。

また、ディープラーニングベースで『Overwatch』を使用して学習をしてみると、人間が報告すると精度が15%ぐらいしか出せないところ、AIを使うと80%ぐらいがチーターと判断されてしまう話もあります。このようにチートに関する部分にも、次々と導入が進んでいくと考えられます。

奥村:また、Kingではインシデント予測と呼ばれる、さまざまなメトリクスを監視して、異常らしき動きを検知すると、すぐにアラートを上げるような事例も公開されています。

異常検知については、結局人間の目検プロセスが不要になることはない、という話もありますが、どこまで自動化するのか、どこまで人間の解明が必要なのか、といった責任分界点に関係する話に関わって来ると思います。

三宅:各社の取り組みは、最終的なBANについては人間が絶対実行する方針ですね。リコメンドはAIが担当しますが、最後は人間が責任を持ってBANするシステムになっており、BANしたデータをまた機械学習に回すことで、AIがリコメンドの精度を上げて行く戦略が必要だと思います。

また、なぜそこまでコストを切るかというと、eスポーツの発展が関係しています。eスポーツの予選はオンラインで実施するため、そこで不正を検知できなければ、eスポーツそのもののビジネスが成り立たなくなります。

その問題も含め、各社コストをかけやすくなっているんじゃないかなと考えています。人間がチートするにしても、リスクとテーマはどんどん高くなるため、導入により一定の効果を発揮していると思われます。

長谷:現在開発しているゲームに関して、チート対策については、かなり話題に上がっていますね。

奥村:特にハッキングの部分ですかね。ゲームごとにチート検知の依存性ってどれぐらいあるのか話題になっていますね。

最近はクラウドゲーミングが登場して、ミドルAIも発達し、そのような機能がAPIとして提供されていくのはスゴイことですし、自社開発しなくても大丈夫なのではとも思います。異常検知に関する研究はこれからも続いていくと思いますが、今後の進め方は多岐に渡る気がしますね。

コンテンツ生成

奥村:コンテンツ生成技術に関しては、自然画像や人間の顔、食べ物や動物など、かなりフォトリアルな画像をAIが自動で生成可能になってきています。

超解像度やdenoisingの研究も大きく成長していますし、それが本物の写真なのか、AIが作った画像なのか、区別が難しい時代が訪れていますが、これからは、その技術をゲームにどうやって組み込むのか、が課題になってきます。

奥村:特にGAN(Generative Adversarial Network)などの技術は、人間の全身のように複雑な構造の生成はまだ困難なので、どうしても対象が限定されてしまうことが課題となっています。

DeNAで進めているプロジェクトでは、二次元の画像から構造などを踏まえて学習をして、後ろ向きに構造を変えてみたり、構造とセットで学習するトライアルをしています。

奥村:また、指定された構造やラフから生成する、あるいはコントローラブルな技術でGANを扱う案件は増えると考えています。

この技術を用いると、「このあたりを海や空にしたい」「この部分に木を置きたい」というざっくりとした要望を入力すると、それらしいフォトリアルな画像が生成できます。アニメ調のイラストも同様に生成が可能です。

最初に簡単なラフを作って、まず完成度70%ほどの画像を生成し、その後にアーティストが修正するみたいなプロセスの導入が進んでいくと思われますね。

奥村:それ以外にも、カメラのライティングやスタイルを変換する技術では、少ないアセットから夜や夕方のシーンを作れたり、季節の秋を冬に変えるなどの技術など、今度は可能になると考えています。

奥村:さらに、一枚の写真画像からメッシュやテクスチャを生成する技術もかなり進んできているので、3Dモデルが作りやすくなる時代も来るはずですね。普及の背景としては、学術研究はもちろん当然ですが、それ以上にゲーム業界でのニーズが高まっていることが要因と考えられます。

例えば『Assassin’s Creed Odyssey』などでは、シネマティックカットと呼ばれるストーリー上で重要なシーンの工数が、数時間から30時間に増えていますが、よりスマートにコンテンツを作るために、約20%を完全プロシージャル化しています。

つまり、あまり重要ではないシーンは、完全AI化してプロシージャル化し、草や木の位置など影響が少ない描写をAIに任せています。

ただし、重要な人間の表情や、ここはしっかりと演出したいというプランナーの思いが介在する部分については、人間がモーションキャプチャーを用いて、従来どおり細かく作り込んで演出する、というようにレベル分けをして作業しています。このような分業型の導入が今後は進んでいくと思います。

また、ラフスケッチからの生成に関して、地形などもラフのような画像からでもフォトリアルな画像が生成できるようになってきています。

長谷:最近のスマートフォン対応ゲームでは、画像が高精細になってきており、それに伴ってダウンロード時間などの課題も発生しており、それを解決するために小さい画像から超解像の技術を使って、高クオリティな画像を作れないかといった研究開発を続けています。

奥村:『Fantasy Raiders』というゲームでは、レベルに応じて自動生成するシステムを導入しており、単純に画像が生成できるだけじゃなく、マップのオブジェクトの配置や、そのユーザーの成熟度やキャラクターの疲労度などに応じて自動で生成してくれます。

キャラクターのHPの少なさなどに応じて、疲れている時はなるべく簡単なマップのオブジェクト配置にしたり、元気な時は難易度の高いマップを作ったりなど、普通はレベルデザイナーが頑張ってハンドメイドで調整している部分を、ある程度オートメーション化する未来はかなり近づいていると思われますね。

奥村:ですが、やはりコンテンツ生成のQAに関して気になるのは、場合によっては求める世界観に好ましくない画像の生成がされてしまうことです。

例えば、十字架が生成された場合、宗教のモチーフだからNGなど、倫理的に人間が見れば判断できる事象でも、AIには判断しにくいものを生成することもあります。その部分は実際どうなっていくのでしょうか?

三宅:以前、弊社のタイトルではありませんが、海外で開発ゲームタイトルで、あまり好ましくないオブジェクトが多く生成されてしまい、動画サイトにアップされ、ネガティブな意見が増えた事例がありました。QAの意味では、作った後にもう1度解析することも必要だと思われますね。

GANに関しては、あまりデザイナーの反応は良くなかったですね。3Dのオブジェクトを生成できたら使えると話していますが、現在の3DのGANについては、研究レベルでも論文が数本あるぐらいで、まだ完成は遠いと思われます。業界的には3DGANが完成してからは、かなり実用化が進むのではないでしょうか。

奥村:そうですね、実際どれぐらい機械化できるのか、完成までに何十年も必要な技術もありますしね。

アニメーションとメタAI

奥村:最後は、アニメーションとメタAIについて。アニメーションというのは主にモーションキャプチャーのような技術を想定しており、モーションキャプチャーで撮った画像を、3Dモデルに移行するときに点の位置がズレることがあります。それを人間が手動でチューニングするのではなくて、Solvingをディープラーニングで高精度化することが実施されています。

また、言語に合わせて唇の動きを変えるリップシンキングが、他の地域のローカライジングに役立っている話もあり、実際に実用化されています。

三宅:メタAIでは、ゲーム全体を俯瞰してコントロールをするAIですが、緊張度を取得して、全体をコントロールする傾向があります。

ゲーム全体の流れを作るAIにおいて、メタAIが構築するのではなく、ユーザーの心理状態をいかに把握するか、そこに機械学習を用いて、ある自動生成した時にユーザーの反応の良し悪しなど、統計から学習データを、ゲームデザイナーのノウハウを吸収していくような形の学習を考えています。

取材・文・撮影:細谷亮介

[su_note note_color=”#ffffff” radius=”10″]

GeNOM(ゲノム)とは

DeNAのゲームクリエイターを様々な切り口で紹介するメディア(運営:株式会社ディー・エヌ・エー)です。ゲーム開発の現場で生まれる様々なエピソードや、クリエイター紹介、イベント紹介などを通して、DeNAで働くメンバーの”ありのまま”をお伝えしていきます。

GeNOMの最新情報は、公式Twitterアカウントやにて確認いただけます。ぜひフォローをお願いします!

[/su_note]

【CEDEC2019】「『逆転オセロニア』における、機械学習モデルを用いたデッキのアーキタイプ抽出とゲーム運用への活用」セッションレポート

2019年9月4日~6日の期間、パシフィコ横浜において、ゲーム開発者向けカンファレンス「CEDEC2019」が開催されました。

本記事では9月5日に実施された、『逆転オセロニア』における、機械学習モデル (トピックモデル) を用いた、大規模データからのデッキアーキタイプの抽出、関連するKPIの可視化などについて紹介されたセッションの内容を一部抜粋してレポートします。

セッションの冒頭では、分析部 アナリストの安達涼より、登壇者の簡単な自己紹介のあと、DeNAゲーム事業部分析部について、現在では各ゲームタイトルに専属アナリストをアサインする体制があること、行動ログ分析、ユーザー調査など、さまざま分析手法を利用して分析に取り組んでいることが説明されました。

また、新しい分析手法や機械学習などの高度な技術を活用したR&Dにも挑戦しており、本セッションでの発表は、その実践例の一部を抜粋して紹介するとのことです。

『逆転オセロニア』では、これまで積極的にAIや機械学習の活用を実施しており、特に深層学習を用いた「対戦AI」、アソシエーション分析を用いた「デッキのオススメ編成」などをゲーム内に実装するなど、プレイヤー体験を向上させる施策を実施してきました。

最近では、ゲーム外(運営側)でも、AIや機械学習の手法を用いて、作業の効率化やプレイヤー体験の向上のために、さまざまな検証を行っていると、安達は述べました。

DeNA 安達 涼

『逆転オセロニア』とデッキアーキタイプ

『逆転オセロニア』は、オセロのルールに基づいた対戦型スマートフォンゲームアプリで、駒のスキルやコンボを組み合わせて戦う高い戦略性と、劣勢からでもドラマチックに逆転できることが特徴となっています。

ゲームプレイコンテンツとしては、キャラクター(駒)の中からプレイヤーが自由に構築したデッキでの対戦が中心で、PvPがメインで遊ばれています。

なお、PvPコンテンツ内ではプレイヤー同士でポイントを奪い合い、月間の到達クラスを競うリアルタイム対戦「クラスマッチ」が最も遊ばれていることが分かるデータも紹介されました。

『逆転オセロニア』のキャラクター(駒)には「神・魔・竜」の3種類の属性が設定されていますが、これらの属性に属性間の相克や優劣などはありません。

また、クラスマッチには「属性補正」が設定されており、「神・魔・竜」それぞれの属性のキャラクター(駒)のHP/ATKなどに対して、ステータス補正が設定され、属性補正によって毎日環境が変化するため、その日の相性の良いデッキを選ぶことで、飽きを防ぐ仕組みになっているとのことです。

プレイヤーは約3,500種類以上存在する駒の中で、自分が保有している駒から16個を選んでデッキを構築し、そのうち1つをリーダーの駒に指定します。

それぞれの駒には固有のスキルやステータスが存在するため、盤上に駒を置いた際、相手の駒を自分の駒で挟んだ場合に特定条件下で発動する「コンボスキル」を決めて勝利するには、駒同士のシナジーを考えてデッキを組むことが重要なようです。

このデッキ構築に関して、戦い方を考慮したおおまかなデッキ構成に「アーキタイプ」という概念が存在します。

『逆転オセロニア』には、現在20種類前後のアーキタイプが存在しており、アーキタイプは属性を統一することで効果を発揮するものなどもありますが、リーダー駒とアーキタイプは必ずしも紐づいていないとのことです。

デッキアーキタイプの例として、竜属性の駒のみで構成され、高い攻撃力と強力なコンボスキルで早い決着を狙える「貫通速攻」と、3属性の駒で構成され、バランス良く戦える「混合」のアーキタイプが安達より紹介されました。

アーキタイプの相互関係は、対戦環境に大きな影響を及ぼすため、バランスが崩れると「特定のアーキタイプが強すぎてつまらない」など、中長期の継続率に大きな影響を及ぼします。

特に『逆転オセロニア』のようなPvPが主体のゲームでは、プレイヤー数は非常に大切なため、バランスの把握やメンテナンスが重要になります。

運用上の問題点と、既存手法の限界

これまでの運用上の問題点として、「特定のアーキタイプが強すぎる」「アーキタイプの優劣が固定化されている」ことが挙げられ、対戦環境を平均化かつダイナミックにして、プレイヤー体験を向上させることが必要となってきたとのこと。

強い駒を単純に禁止や制限する運用もありますが、『逆転オセロニア』では、駒の追加と属性の追加がプランニングの主なアクションになるようです。

運用チームでは対戦環境の改善のためにプランニングを実施する際、これまではプランナーがクラスマッチを徹底的にプレイすること、プレイヤーの声をもとに人力で対戦環境を把握し、その定性情報を用いてプランニングをしていたと語られました。

この方法での問題点は3つあり、まず1つは、さまざまなデッキを使って、何ヶ月も膨大なバトル数を消費するため「プレイング習熟まで時間が必要となる」こと。

2つ目はプレイヤーの声や人間の主観的な見解は、ネガティブな要素に引っ張られる傾向など、心理的なバイアスにも影響を受ける恐れがあることです。

3つ目は、増え続けるアーキタイプ数への対応が難しいこと。アーキタイプが少ない時期は、徹底的にプレイすることにより、異なるアーキタイプ間の対戦を網羅的に十分なサンプル数を取得できますが、現状20種類ほどのアーキタイプがある中で、人的リソースの観点からも、人力で対応するには現実的ではなくなっているようです。

これら述べてきた理由で、定量的に対戦環境を把握することが、必要不可欠と言えるでしょう。

そこで、ログデータを参照し、リーダー駒の編成率や勝率を分析してみると、デッキアーキタイプという抽象度でデータを解釈するのが難しく、リーダー駒レベルの情報でプランニングをすると、意図せずに対戦環境のバランスを崩す可能性があることが説明されました。

例えば、勝率35%のリーダーaのデッキ、勝率50%のリーダーbのデッキがあった場合、対戦環境を整えるためにリーダーaのデッキに駒を追加すると勝率が50%に上がりますが、なぜかリーダーbの勝率が65%に上がってしまいました。

このプランニングの失敗の理由は、どちらのデッキもアーキタイプAに属しており、追加した駒はどちらのデッキにも組み込まれてしまったため、バランスが崩れてしまったことにあります

アーキタイプレベルでプランニングをすれば、デッキのコンセプト自体が異なるため、勝率を上げることを狙ったアーキタイプには効果的で、他のアーキタイプでは使用されないような駒をピンポイントに考えられ、このような事故を防ぐことができます。

アーキタイプの抽出方法について、ルールベース(定義に基づいた分類)で対応できないのは、3,500種類以上の駒が存在し、同じリーダーでも異なるアーキタイプに所属することもあるため、ルールを構築することが不可能になっているようです。

また、プランナーが抽出したいアーキタイプに含まれる駒を事前に指定しなければならず、プレイヤーが編み出した、プランナーが想定しない新しいアーキタイプは抽出できなかったとのこと。これらの問題点をふまえてチーム全体で「機械学習によるデッキのアーキタイプ抽出してみよう」という動きになったと、安達は述べています。

機械学習モデルの概要

機械学習のデータについて、プレイヤーのリテラシーが高く、デッキのアーキタイプが成立している、クラスマッチのダイヤモンドクラスデッキデータを使用しています。

このデータを用いて、数十万のデッキでアーキタイプを抽出する週次データと、月次データで属性補正ごと、2種類の粒度で分析を行っているとのことです。

概要として、トピックモデルと呼ばれる手法、その中でも良く使われるLDA(Latent Dirichlet Allocation)のアルゴリズムを用いて、アーキタイプ抽出を行っています。

このモデルに大量のデッキデータ、パラメータとして抽出するアーキタイプ数を入力すると、2つの結果を出力し、1つは自動的に抽出されたアーキタイプそれぞれの組成になります。

各アーキタイプはデッキに存在した、すべての駒上の確率分布として表現されます、つまりそれぞれのアーキタイプのデッキで各駒がどのくらい採用されやすいのか、ということが表現されているとのこと。

アーキタイプAは駒1と駒99の確率が高く、これらの駒が良く採用されているアーキタイプだと解釈することができます。

このキャラクター組成の情報をもとに、それぞれがどんなアーキタイプなのか、という解釈をプランナーが実行します。

今回のデータでは『逆転オセロニア』をある程度遊んでいるプレイヤーなら、この組成を見れば何のアーキタイプなのか、紐付けられるレベルの抽出ができていると考えられています。

これは使用データをダイヤモンドクラスに絞っていることで、成立しているデッキタイプが多く、ノイズが少ないことが考えられます。

2つ目は、1~100,000番目までのデッキがそれぞれどのアーキタイプに属するのか、という情報が出力されます。

それぞれのデッキはアーキタイプ上の確率分布として表現され、デッキ1だとアーキタイプBに属する可能性が高く、デッキ100,000だと、アーキタイプGに属する可能性が高いと言えます。

LDAというアルゴリズムは、大量のドキュメントをその中の単語の分布をもとに、トピック別に分類する用途で開発されたことも明かされました。

本モデルでは、各トピックはドキュメントに出てくるすべての単語上の確率分布、各ドキュメントはトピック上の確率分布として表現されます。

ドキュメント内の各単語に対し、そのドキュメントに紐付いたトピックの確率分布を参照し、その単語が何のトピックから生成されているのかを決めます。

次に、選ばれたトピックに対応する確率分布を参照し、その単語が生成される確率を求めます。この作業をドキュメント内のすべての単語について実行し、ドキュメントが生成されます。

続いて、トピックに紐付いた確率分布と、ドキュメントに紐付いた確率分布の事前分布に、Dirichlet分布を仮定し、サンプリング手法によってこれらの事後分布を求めます。

次にトピックモデルを用いたデッキアーキタイプ抽出に活用するために、ドキュメント内の単語を「デッキ内の駒」、ドキュメントを「デッキ」、トピックを「アーキタイプ」に置き換えます。

先述のモデル推定を実行することで、ここではアーキタイプが駒上において、各ドキュメントがトピック上の確率分布でしたが、ここでは各デッキがアーキタイプ上の確率分布として求められます。

トピックモデルの利点は、実装が簡単で、新しいアーキタイプを抽出可能、時系列でのアーキタイプの紐付けが容易、パフォーマンスも良いことが挙げられました。

デッキアーキタイプの抽出フローは、まずBigQueryからRaw対戦ログ(デッキ情報、勝敗など)を取り出し、その中からタスクキルなどの使用しないデータを取り除いたり、デッキ情報をモデルが使える形に変換したりと前処理をします。

次にルールベースで抽出できるアーキタイプを抽出します。LDAだけでもきちんと抽出できますが、ルールベースで抽出されるアーキタイプ、機械学習で抽出するアーキタイプの両方にとってノイズが減ることが判明しているとのことです。

実際の運用では、プランナーに依頼し、Googleスプレッドシートにルールベースで抽出するアーキタイプ名と駒に関するルールを書いてもらい、アルゴリズムがそのシートを読み込み、指定されたものを抽出しています。

その後、デッキデータに関してLDAアルゴリズムを適用し、指定した数だけアーキタイプを抽出します。最後にそれぞれアーキタイプに関して、過去に抽出されたアーキタイプと比較して紐付けをします。

アーキタイプは駒上の確率分布なので、分布間の距離を用いて紐付けを行います。これを抽出したすべてのアーキタイプについて繰り返し実行し、どのアーキタイプとも紐付かない場合は、新しいアーキタイプとして検出します。

可視化ツールの紹介

対戦環境の改善により、プレイヤー体験向上を実現するという目標を考えたとき、2つのポイントが重要だと、安達は述べています。

1つ目は「現状把握と運営のアクションの効果確認が容易にできる」こと。ここでは使用率や勝率などアーキタイプに関連する統計量がひと目で分かり、かつ時系列で比較できる必要があります。既存の内製BIツールでは自由度が低く、実現できなかったとのこと。

2つ目は「運営チームの誰もが対戦環境を意識できる状況を作り出す」ことです。今回の分析手法により対戦環境が誰にでもわかるようになったため、ゲームプランナーだけでなく、運営チームの他のメンバーにもプレイヤー体験向上のためにできることのアイデアを出して欲しいとの思いがあったことも語られました。

これを実現するためには、ローカルPCで結果を表示してスライドに貼って共有する方法では不十分と考えたようです。

この要件を実現するために、「Dash」と呼ばれるPython製のWebアプリケーションのフレームワークを採用しました。これを利用することでベーシックなレポート、インタラクティブなダッシュボードなどを作成することができます。

さらにDashはオープンソースであり、無料で使用できる上、開発もアクティブに実施されています。JavaScriptの知識がなくてもPythonのみですぐにダッシュボードを作ることが可能だとのこと。

高い自由度も魅力で、レイアウトも簡単に変更でき、公式ページには40を超えるダッシュボード例とソースコードが公開されています。

また、誰でも簡単に対戦環境を確認できる点に関しては、ダッシュボードをGCP(Google Cloud Platform)インスタンス上でデプロイすることで解決しています。運営チームのメンバーは、Webブラウザからダッシュボードにアクセスすることで、いつでも対戦環境を確認することが可能になったとのことです。

また、週次と月次の2種類のデータを使用してアーキタイプ抽出を行っていますが、可視化ツールも用途に応じてそれぞれに対応するものを作っています。

週次の可視化ツールは、月~日まで一週間のデータを用いてアーキタイプを抽出し、月曜日にツールを更新しています。ここでは、新しい駒の追加で対戦環境が崩れていないかなど、最新の対戦環境の把握のために使用しています。

このツールで「このアーキタイプにはどんなデッキが含まれるのか」「どの駒がどのくらいの確率で採用されているのか」「使用しているプレイヤー数や勝率」「自分が先行/後攻の場合の変化」「決着までの平均ターン数」などを簡単に確認できます。

対戦分布では、対戦表で抽出された各アーキタイプの勝率や、アーキタイプ間の勝率を確認可能で、プレイヤー分布ではそれぞれのアーキタイプを使用しているプレイヤー数を表示しています。

月次データを使ったツールでは、属性補正ごとにアーキタイプを抽出した結果を表示しています。月次のクラスマッチの補正ごとの抽出結果を表示、より詳細な対戦環境情報の把握やプランニングのPDCAサイクルに活用しているとのことです。

ゲーム運用への活用

ここからはDevelop統括部 企画部 プランナーの岩城にバトンタッチし、実際の運用現場でこの分析ツールがどのように活用されているのか、いくつかの具体例と共に説明されました。

DeNA 岩城 惇

『逆転オセロニア』の運用課題について、分析ツール導入前は「アーキタイプの優劣が固定化」「特定のアーキタイプが強すぎる」という2点の問題点を挙げました。

これまではプレイングを習熟したプランナーの意見および、プレイヤーからの定性意見を中心に、一部ですがルールベースの定量分析を加えつつ、改善とプランニングを実施してきたとのこと。

ですが、「客観的に判断をする難易度が高い」「プレイング習熟まで時間が必要」「増え続けるアーキタイプ数の対応が難しい」「新しいアーキタイプを検知しづらい」といった課題で、正確で網羅的な現状把握が難しく、改善結果が正確に評価しづらくなっていました。

分析ツールの導入後は、運用チームなら誰でもアクセスできるツールを採用したことで、運用上の問題点は変わりませんが、定性意見とツールによる定量評価を併用することにより、チームに非常に良いインパクトをもたらしたようです。

客観性に関しては「実際に数値として環境の情報が確認できるので、客観的な判断がしやすくなり、さらにトッププレイヤー傾向を分析しやすくなったことで、プレイング習熟の時間が短縮され、プランナーの属人化が大きく改善しました」と岩城は語っています。

また、アーキタイプが増えても相性があるため、相関関係をひと目で確認でき、新しいアーキタイプの検知についても、ツールが自動で検知するためスムーズに対応できるようになったようです。

その結果、正確に網羅的な現状把握を継続的に行い、改善アクションがスムーズになりました。その中でも個人的にインパクトがあったのは、ツールのデータをWebブラウザ上でいつでも手軽に確認できることによって、誰でも客観的に確認できる点だと、岩城は述べました。

プランニングの前段階の問題が改善されたことで、課題点に確信が持てなくて日々悩んでいたプランナーにとって、改善のプランニングに集中でき、今までに比べて業務効率が何倍にも向上した印象がありました。

続いては、実際に活用された改善プランニング具体例が紹介されました。

改善アクション1「対戦環境のバランス平均化」

運用チームでは対戦環境のひとつの理想状態として、アーキタイプ同士の相性が拮抗していて、プレイヤーの選択肢が多様に存在する状態を考えているようです。

その多様性が失われることがしばしばあり、一部のアーキタイプが駒追加が続いたり、属性補正に相性が良かったり、いくつかの要因によって相性の弱点がなくなり、一強状態になる状態が実際に発生しました。

一強状態が続くと、他のアーキタイプが淘汰されてしまい、代わり映えのしない対戦が続き、中長期の継続率に大きな影響を及ぼします。

分析ツールで抽出した勝率のグラフでは突出しているようには見えませんが、対戦表を見ると、他のアーキタイプにほとんど勝ち越していることから、一強になる可能性をはらんでいると判断できます。

このように実際にグラフとして可視化されることで、明確に課題が検出できると同時に、一強状態を改善し、多様性を維持するために何らかの対策が必要だと感じたとのことです。

そこで実施したアクションが「適切な抑止力の選定と対戦環境への配慮」になります。

簡単に既存のアーキタイプの弱体化を行えない制約を考慮しつつ、一強になりそうなアーキタイプを平均化しようというアクションです。平均化の実現のために、対戦表の相性比較から「すくみ」が生まれるように、抑止力となるアーキタイプを複数選出しました。

そして一強の抑止力となるアーキタイプを強化することで、相対的に一強状態を解消することを狙いました。

ここで大事なのが環境への配慮で、単純に抑止力を選定するとどちらかのバランスが崩れやすいため、必ず複数を強化することでアーキタイプの勝率バランスを平均化することを心がけた、とのことです。

そのため属性補正に関しても、複数のアーキタイプの勝率が拮抗するものを採用したり、使用率の低いアーキタイプに駒を追加して、強化と普及を促しました。

このアクションの結果、突出しかけていたアーキタイプのバランスを、対戦環境に配慮しながら抑えることができ、適切な属性補正を特定し、スムーズに調整ができた上、抑止力となるアーキタイプの選定がピンポイントに実施できたとのことです。

改善アクション2「勝てるアーキタイプの選択肢を増やす」

このアクションでは、アーキタイプ間の優劣が固定化しているという課題に対応しています。

一定のアーキタイプの勝率が相対的に他のアーキタイプより高いことから、プレイヤーの使用が偏り、他のアーキタイプが徐々に淘汰され、結果的にプレイヤーの選択肢が少なくなってしまう状況になります。

アーキタイプ間の優劣が固定化してしまうと、プレイヤーの選択肢が少なくなり、それにより「飽き」につながり、中長期的の継続率に影響が出てしまいます。

ある月の同じ属性補正で、3ヶ月後の勝率を比較すると、いくつかのアーキタイプの順位は多少上下しましたが、上位の序列に変化がないことがわかりました。

この課題に対する改善アクションは「既存のアーキタイプを強化することで、固定化した環境を変化させることを目指してプランニングしています」と岩城は話しました。

つまり固定化したグラフに割って入るように、アーキタイプを強化しました。参照したのは勝率の比較とアーキタイプの使用率の比較データになります。

まずは勝率の比較によって、勝率は悪くなく、かつ使用率の低いといった条件を満たすアーキタイプを探します。

その理由は、キーとなる駒が足りない、プレイヤーにあまり普及していないといったアーキタイプそのものの強さに比較的ネガティブな要素が少なく、強化および普及が容易だと考えられたためです。

具体的な改善アクションは、選出したアーキタイプに対戦環境をもとに、その勝率が高くなる属性補正を追加、デッキの核となる駒の追加、アーキタイプに必要な駒を普及させるために定期的に開催されるガチャを実装しました。

結果として、アーキタイプの選択肢を増やすことに成功し、キャラクターの設計方針がスムーズにでき、アーキタイプそのものを追加する場合に比べて、少ないコストで環境を変化させることができました。

改善アクション3「新しいアーキタイプの検知と使用率向上」

アーキタイプは運用から提供するもの以外でも、プレイヤー間で日々生み出されているそうです。想定外のアーキタイプは『逆転オセロニア』でも検知されており、毎月新たなアーキタイプを見つけることができます。

この事象は、アーキタイプの優劣が固定化していることに対して、新しい選択肢を広げるという意味で、良い影響を与えることが可能です。

新しいアーキタイプについては、ツール上で「NEW」と表示され、それらの勝率や使用率を参照可能になっているとのことです

検知したアーキタイプについて運用側では、対戦環境に悪影響はないのか、どうやったら強化できるかを調べる必要があると、岩城は話しました。

ここでツールを用いて対戦成績と使用率を比較して、検出したアーキタイプを分析します。まず新しいアーキタイプと既存のアーキタイプの使用率を差分比較します。一見新しいアーキタイプに見えても、広義では他のアーキタイプに含まれる可能性もあるからです。

この時点で新しいアーキタイプであると判断された場合、次に対戦成績を比較し、勝率が高くなる補正は何か、逆に勝率が突出してしまう補正はないか、について検討しています。

そこで問題ない場合、この属性補正について新しいパターンとして蓄積し、新しいアーキタイプの使用率の向上を図りたい場合、適切に使用できる体制を整えました。

このアクションの結果、新しいアーキタイプの使用率が向上するシーンを生み出すことができました。

検知に関しては、ツールがない場合は、非常に難易度が高く、明確に新しいアーキタイプを検知できたことは大きな価値になっています。

また、新しい場合でも対戦表や相性を確認できるので、対戦環境の傾向をつかむことで、もし将来的に新しいアーキタイプを強化したい、再検知したときに強化したいときでも速やかに対応できるナレッジを蓄積できたことも、大きなメリットだと岩城は述べています。

まとめと展望

最後に安達から、今回のセッションの簡単なまとめと、今後取り組みたいこととして、現在『逆転オセロニア』に実装されている駒の属性レベルでのレコメンデーションに、アーキタイプレベルでのデッキレコメンデーションを追加すること、対戦環境のダイナミックさを担保する「属性補正の最適化」「プランニングプロセスの自動化」や、対戦環境変化の予測などにも注力していきたいと、本セッションを締め括りました。

取材・文・撮影:細谷亮介

[su_note note_color=”#ffffff” radius=”10″]

GeNOM(ゲノム)とは

DeNAのゲームクリエイターを様々な切り口で紹介するメディア(運営:株式会社ディー・エヌ・エー)です。ゲーム開発の現場で生まれる様々なエピソードや、クリエイター紹介、イベント紹介などを通して、DeNAで働くメンバーの”ありのまま”をお伝えしていきます。

GeNOMの最新情報は、公式Twitterアカウントにて確認いただけます。ぜひフォローをお願いします!

[/su_note]

【CEDEC2019】「組織的にGame x AIを推進していくための方法論~『逆転オセロニア』のAIの一歩先へ~」セッションレポート

2019年9月4日~6日の期間、パシフィコ横浜において、ゲーム開発者向けカンファレンス「CEDEC2019」が開催されました。

本記事では、9月4日に行われた「組織的にGame x AIを推進していくための方法論~『逆転オセロニア』 のAIの一歩先へ~」について、ディー・エヌ・エー AI本部 データサイエンティストの田中 一樹とMLエンジニアである岡田 健によるAI開発のあるべき姿や、具体的な設計方法などが語られたセッションの内容を一部抜粋してレポートします。

DeNAにおけるAI開発の歴史

まず序盤では田中 一樹より、DeNAにおけるAIの開発の歴史から、上手くAIを使いこなすための手法が解説されました。

DeNA 田中一樹

DeNAでは、2016年頃から本格的にゲームAI開発に本腰を入れており、重要な分岐点となりました。特に古典的なゲームAIだけでなく、機械学習、ディープラーニングといった最新技術まで視野を広げて新しい領域を切り開いていきたいと田中は語っています。

2016年は「ゲームアプリ運用の課題解決にAIを活用できないか?」と考えた時期でもあり、未知の事象が多く、AIでできることの可能性を模索していたフェーズです。

その後に得られたAIの可能性に関する知見や経験をもとに、2017年に『逆転オセロニア』において強化学習を使ったバランス調整をするため、強いAIをつくることから始めて、最終的に複数のAI機能をリリースすることができました。

そして現在のフェーズは、見えてきた課題の解決を目指して今までの知見や技術をスケールさせ、さらに応用の範囲を拡大するために、組織的に注力しています。

AI利用の模索

続いて、目指している世界に確度高く近づくために、どのようなことを考えて実行しているのか、詳細が説明されました。

2016~2017年に取り組んだのが「AIにおけるゲームアプリ運用の課題解決へのアプローチ」です。

この取り組みの背景にあった課題は「ステージ設計の難易度調整が大きい」ことが挙げられました。具体的には、パラメータを設計し入力した後、意図通りの難易度になっているかをテストプレイする、という作業を繰り返すことで、理想的なステージの難易度調整をしていました。

このフローをAIで実装するために、ユースケースとして「強いAI」を作り、自動でテストプレイをして、その結果をもとにステージの難易度調整を適切、かつ効率的に実行することを目指していました。ちなみにここでの「強いAI」とは、「人間らしくて強いAI」とも呼べると田中は話しています。

手段としては、古典的なMCTS、強化学習、ニューラルネット、遺伝的アルゴリズムなども検証しており、社内ではほとんど研究されていない領域だったとのことです。

振り返りと学んだことに関しては、AIを学習してつくる部分については一定成功し、特定の条件下では強いAIを作成でき、さらにAIのプレイ結果を可視化することで、AIの可能性を垣間見ることができたのは、大きな収穫だったようです。

課題については、最終的に導入するまでに至らず、シミュレータ制作にも苦戦しましたが、さまざまな学びと自信を得たことは事実なようです。良かった点は、2016年の発想からAIが持つ高い可能性を見つけたことで、それはすなわち今後本格的にゲームでAIに取り組むきっかけとなる「テーマを発掘」したことになります。

『逆転オセロニア』へのゲームAI導入

スマートフォン向けゲームアプリ『逆転オセロニア』について、2つのAI機能「オセロニア道場」「オススメ編成」を開発しました。

「オセロニア道場」開発の背景は、手強いAIと戦える気軽な場所がなく、アーキタイプの特性を学ぶ場所もなかったためで、ディープラーニングなどを駆使しています。

所持駒からデッキをレコメンドしてくれる「オススメ編成」については、初心者プレイヤーがデッキの組み方で迷うことが課題であったため開発したもので、技術はアソシエーション分析、レコメンド技術を主に応用していますが、ゲーム特有のドメイン知識も活用しています。

この機能を開発するにあたり、一番の成果は実際にリリースして運用できたことであり、意味のあるAIを作れたこと。事業価値的にもAIのポテンシャルを実証できたことは大きな収穫だったとのことです。

しかし、苦労する点も多く、企画からユースケースへの落とし込み、技術への結び付けなどは試行錯誤を繰り返し、かなりの時間が必要となりました。事業貢献の観点では、AIを使うとプロダクトやプレイヤーにどのような価値を還元できるのか、議論を重ねたとのことです。

振り返りとして、AIはゲームに新たな価値をもたらすことは、この段階から確信に変わり、その確信を効率的に活かすには、組織的にAIの活用をスケールさせることを意識するようになりました。

また、PoCではなく「使えるAI」を企画から開発まで作りきり、リリースできたこと、プレイヤーから定性意見やKPIなどへのフィードバックを受けることができたことは、現在のDeNAのゲームにおけるAI開発に大きな影響を与えています。

どうすればもっと上手くAIを使いこなせるのか?

DeNAのゲーム開発におけるAI活用をどうすれば加速させられるかを考えたときに、今まで得た経験を無駄にせずスケールさせていくことが最も重要だと、田中は語っています。

『逆転オセロニア』だけでなく、さまざまなゲームタイトルでAIをうまく活用することができれば、DeNAはより強い組織に成長することができると考えているようです。

ここでのキーワードは、現場レベルで課題を探索する取り組み「Bottom Up」とAIを計画的にスケールさせる取り組み「Top Down」の2つになります。

「Bottom Up」は、まだ誰も気付いていない、埋もれているユースケースを探索する意味を持ち、「Top Down」はできそうなことがある程度分かっていて、価値も大きそうなユースケースを計画的に推進していく意味を持ちます。

「Bottom Up(AIでできることの探索)」

「Bottom Up」の目的は、ゲーム領域で目の前にある事業課題を、データおよびAIの力で解決することであり、サービス・データに触れている各メンバーが双方向で協力して、目的達成のために動くことが重要です。

特定のゲームタイトルだけでなく、マーケティングやCS(カスタマーサポート)など広範囲の事業と連携すること、新技術やユースケースの発掘の中で潰れてしまう取り組みも一定許容するなど、重要なことも多数明かされました。

また、明確な戦略もなく、課題や案件の探索を行うと、それぞれのメンバーの責任分界点が非常に不明瞭になり、案件を進めづらくなるため、しっかりとあるべき姿や適切な役割分担を定義して、関係者の認識を揃えることで、効率化を図ります。

成功や失敗にこだわらず、しっかり振り返って次に繋げることができる体制をつくるために、AIや機械学習、データサイエンスの案件を、円滑にすすめるための推進フローも社内で策定しています。

これにより、取り組む価値が不明確であったり、明らかにAIでは不可能な無理難題な案件が進んでしまうことを、回避できるようになっています。このような地道な地盤作りを行うことで、簡単ではないAI開発を持続可能な状態にすることが可能になりました。

この取り組みを進める中で得られた価値として、今まで見えてこなかった課題を幅広く発見することができ、組織としてAIの活用の幅を広げることができたことが挙げられます。

また、さまざまな関係者を巻き込んで議論を重ねたため、組織レベルでリテラシーが向上し、タイトル側から「こういうことを実現したい」と相談がきた場合にも、必要十分なAIリテラシーがあるため議論もしやすくスムーズに開発が進みます。

共通の推進フローを整備したため、導入プロセスが確立し、スムーズな導入の実現が可能になってきたとのことです。

「Top Down(計画的にAIを推進)」

ここからはMLエンジニア岡田 健にバトンタッチし、「Top Down(計画的にAIを推進)」についての発表がなされました。

DeNA 岡田健

「Top Down(計画的にAIを推進)」とは、前述された「Bottom Up(AIでできることの探索)」とは対照的に、事業インパクトが出せそうな領域で計画的にAI活用をスケールさせる動きのことです。

組織的な動きをするために、DeNAではAI推進チームを発足しました。ゲームの分野でAIの応用を加速させていくチームになります。

計画的にスケールさせるためには、まず過去の歴史を学ぶことが重要です。推進チームでは社内外問わず、CEDECやGDCなどの過去の事例を蓄積しています。ユースケースは課題に対して何らかの技術をもって結果に導くものであり、他社が抱える課題やその解法などを調べた上で、組織に還元する動きを大事にしています。

課題を抱える各プロジェクトの開発現場にヒアリングし、過去の事例をどうやって適用するか、工夫するか、などの提案をして、その後適切な専門家とつなぎます。

また、DeNAにはAIシステム部というAI専門家集団を擁しており、Kagglerやコンピュータビジョンの専門家なども所属しています。自動化を推進している部署ではさまざまな専門家と、ゲームの開発をつなぐ架け橋となることを意識しています。

過去の『逆転オセロニア』チームには、タイトル側と専門家しか存在しませんでしたが、現在はAI推進チームが橋渡しの役割を担い、Kagglerが問題を解決しやすいようにセッティングしたり、シミュレータを制作してサポートします。

このチームでは、機械学習の勘所、ゲームのドメイン知識やゲームの開発経験だけでなく、エンジニアリング力も必要となります。

具体的には、最も重要なのはゲーム事業を把握して、力を蓄積して何ができるかを判断することです。

Simulator

続いては、「Top Down」の動きの中でも、技術的に中心となる「Simulator(シミュレータ)」について語られました。

ゲームに機械学習を応用させる中でSimulatorはひとつの大きな役割を担っています。AIを絡めた取り組みで必要なのは「課題とユースケースの設定」で、Simulatorはそれを解決する手段であり、技術となります。

Simulatorについて「初期段階からちゃんとつくる」「ビューとロジックを分離した作りにする」ことは当たり前で、ユースケースありきで考えると「ゲーム本体とAIの境界」「要件定義が大事」と考えられます。

そこで「Simulator=境界」とは何なのか、『逆転オセロニア』で運用中のオセロニア道場では、インバトルで強いAIを教師あり学習で作ることが目的でした。

具体的なユースケースは、強いAIと自由に対戦可能な環境を作るために、プレイヤーの棋譜ログを使用して教師あり学習で強いAIを作ることです。

『逆転オセロニア』では、キャラクターやスキルが定期的に追加されます。これに対して常にAIの最新化をしたいとき、その設定で境界には何が必要になるでしょうか?

まず「内部構造」について。オセロニア道場はGCPを利用して作られており、ゲームの端末から棋譜を推論APIへ、そこから特徴量抽出APIで特徴量に変換し、AIモデルにより推論して出た打ち手の結果をクライアントに返送します。

そのフローの中で「推論API」「特徴量抽出API」はゲームとAIの境界となります。『逆転オセロニア』では、特徴量抽出は今の盤面を再現して、そこから情報を抜き出します。

情報には「どのマスに黒い駒が置かれているか」「手札にどんなキャラクターがいるのか」を数字の配列で表し、それをもとにディープラーニングの行列計算をします。

棋譜には盤面やデッキの情報などが記載されており、特に重要なのが「各ターンに何が起こったか」という事象です。1ターン目にどの駒を置いたのか、どれくらいのダメージが出たのか、などバトル開始時から順を追って、現在の盤面の状態を復元します。

この仕組みはPythonで開発していますが、もし仮に最初から作り直すとした場合、棋譜ログをあるべき設定にすること、バトルロジックの二重管理をやめることを実現したいと岡田は話しました。

このような課題をハンドリングするためのキーワードは「リプレイ可能であること」。課題解決のため、棋譜はバイナリ形式で、特徴量抽出はゲームのバトルロジックをリプレイ可能にしておき、それを使って棋譜をビューなしでバトルリプレイして特徴量を抽出します。

バトルロジックは入力を出力に変換する機械と呼べるもので、直接のインタラクトはしません。

『逆転オセロニア』を例にすると、まずプレイヤーからの「どこに何の駒を置いたのか」という入力コマンド情報をバトルロジックが現在の盤面に置き、ダメージ計算をして内部状態を変化させます。

その結果、どういった描画をするのかを「描画ロジック」に指示します。シミュレータ側では入力コマンドは棋譜ログとして保存、学習段階では棋譜ログをバトルロジックに流し込み、同じコマンドを入力して特徴量を抽出します。

バトルロジックをリプレイ可能な仕組みに作っておけば、同じ入力なら内部状態や後段の出力も同じになるはずで、これが「リプレイ可能」な機能が必要で、重要な理由になります。

作業フローに関して重要なのはAIの学習だけではないということ。AIモデルに対してもAIの専門家が品質保証をしなければなりません。

まずAIの学習については、バトルロジックをwrap(ラップ)した「特徴量抽出リプレイヤー」を使用します。ここでは複数のマシンを並べての高速化が可能です。ここでのアウトプットは「学習したAIモデル」になります。

勝率評価に関しては、AIの学習でアウトプットされたAIモデルを、NPCや既存の他のモデルと対戦させるという「ふるい」にかけ、この時点で弱いモデルは捨てられます。ここでの境界は「対戦サーバー」になります。

勝率評価で得た対戦ログは打ち手の評価に使用されます。打ち手の評価とは、AIが打った手を人間が実際に目で見て確認し評価することです。その段階でなぜ勝率が上がらないのか、どんな状況のときにどんなパターンで負けるのか、などを分析します。

このイテレーションをできるだけ短く実行するために、ゲームデバッグ機能のひとつとしてバトルのリプレイ&観戦機能が必要です。ここまで勝ち残ったモデルは、試し打ち(人間 vs AI)を経て、AIコンテンツにデプロイします。

以上のように、ひとつのユースケースにおいても、ゲームとAIの境界は多数存在します。それらをすべて機能させる必要があり、そのために(シミュレータで)重要なのがリプレイ可能であることです。

最後に岡田は「AI-native」なゲーム開発は面白いが、ゲーム開発者の設計や実装による協力が不可欠であり、密に連携して開発を続けていきたいとの言葉で、セッションを締めました。

取材・文・撮影:細谷亮介

[su_note note_color=”#ffffff” radius=”10″]

GeNOM(ゲノム)とは

DeNAのゲームクリエイターを様々な切り口で紹介するメディア(運営:株式会社ディー・エヌ・エー)です。ゲーム開発の現場で生まれる様々なエピソードや、クリエイター紹介、イベント紹介などを通して、DeNAで働くメンバーの”ありのまま”をお伝えしていきます。

GeNOMの最新情報は、公式Twitterアカウントにて確認いただけます。ぜひフォローをお願いします!

[/su_note]

【CEDEC2019】「自由に移動できるVRゲームにおけるプレイヤーの誘導、こうやってみました」セッションレポート

2019年9月4日~6日の期間、パシフィコ横浜において、ゲーム開発者向けカンファレンス「CEDEC2019」が開催されました。

本記事では、DeNAとあまた株式会社が研究開発している、謎解きアドベンチャーVRゲーム『VoxEl(ボクセル)』を実例として、VR空間内を自由に移動できるタイプのゲームにおいて、いかにプレイヤーの行動を制御しゴールまで導くかという課題を、どのように解決したかを解説する、ショートセッションの内容を一部抜粋してレポートします。

登壇者は、株式会社ディー・エヌ・エー ゲーム・エンターテインメント事業本部 ゲームデザイナーの永田峰弘、あまた株式会社 代表取締役社長・プロデューサー・ディレクターの高橋宏典氏となります。

『VoxEl(ボクセル)』とは

永田:『VoxEl(ボクセル)』は、ハイエンドVRの研究開発を目的としたタイトルとして着手し、過去に「東京ゲームショウ2018」や「LAVAL VIRTUAL 2018」などでプレイアブル出展、開発の中心メンバー10人が約5ヶ月を要してVIVE向けに開発しました。

ゲーム内容は、謎の少女「エル」と共に冒険するVRゲームで、フィールドのオブジェクトを使用したギミックを解きながらステージを進める「謎解き要素」と、そのギミックを利用して終盤に登場する巨大な敵と戦う「バトル要素」を融合させた作品になります。

VRゲーム『VoxEl』開発メンバーが語る技術的な試行錯誤

VRタイトルに必要なもの

永田:VRを利用した作品で必要なのは、その世界に「存在している」という実在感です。VRの世界に入り込んで楽しむためには必須の要素であり、その実在感を得られないものは、据え置き機のようにモニターで遊ぶ体験と大差がありません。

そして、実在感を得るために必要なのは「納得感」です。なぜプレイヤーはこの世界にいるのか、ビジュアルやサウンドはどんな理由で構築されているのか、表現がリアルである必要はなく、プレイヤーに納得してもらうことが重要になります。

DeNA 永田峰弘(左)・あまた株式会社 高橋宏典氏(右)

『VoxEl(ボクセル)』の遊び方

永田:プレイヤーはVIVEコントローラを、ワンドと呼ばれるアイテムとしてゲーム内で持つことで行動できます。移動はなるべくVR酔いをしないように、ワープ移動を採用していおり、VIVEではルームスケールで空間内を歩くことが可能なため、その機能も有効活用しています。

永田:ワンド(コントローラ)のトラックパッドを触れたまま、地面に向けるとサークルが出現し、その状態でトラックパッドを押し込むと、サークルにワープ可能です。もちろん操作によりワープ先の角度を変えることも可能です。

また、ステージに設置されているエネルギーの塊に向けてトリガーを引くと、エネルギーを抽出、再度トリガーを引くとストックしたエネルギーの発射が可能です。

永田:動かせるオブジェクトに関しては、物体に向けてトリガーを引くと、念力のように物体を動かすことが可能です。

プレイヤーへの情報提示と誘導

ゲーム開始時の情報制限

永田:ゲームを始めた際には、納得感を与えるために、プレイヤーが何者なのか、何をすればいいのかを理解してもらう必要があります。

ですが、プレイヤーを完全に自由な状態にしてしまうと、迷いを与え、余計な動作をしてしまうため、見てもらいたくない部分まで見られてしまう、という課題が発生します。

高橋氏:『VoxEl(ボクセル)』では、ゲームスタート時は真っ暗な通路のような場所に閉じ込め、少し先に光がもれている扉が見えるデザインにしています。

高橋氏:このように、情報を大きく制限することで見るべきポイントを明確にしています。その後に、扉の外からガイド役でもある少女エルから声がかかり、移動方法のレクチャーを受けるフローになっています。

チュートリアルを兼ねた初期誘導

永田:ここからは「世界観のチュートリアル」と「操作に関するチュートリアル」に分けて説明していきます。

『VoxEl(ボクセル)』は、短時間で完結するプレイアブルタイトルであり、冒頭でおおよその説明が入ります。この部分がないと、一体何をするゲームなのか理解できないまま、プレイすることになってしまいます。

家で長時間じっくりプレイをするタイトルでは、このような早急な説明は必要ありません。まずはどのようなタイトルで、どの程度のプレイ時間を必要とするのかを設計することが重要です。

ゲーム冒頭で暗い部屋から出ると、エルから「この世界について」「プレイヤーがここに存在する理由」「プレイヤーの現在の状態」など、簡単な説明が開始されます。

この演出により、ゲームシステムと世界観の融合を実行し、プレイヤー自身がVRの世界に来たことを実感させます。

高橋氏:VRにおいて、触感が得られない点は大きな問題になりますが、それを逆手に取って、プレイヤーは実体を持たずに、実際に触ることができるのは、ワンド(コントローラ)だけに限定しています。

高橋氏:その後の「不完全な召喚になった」と世界観側による補足と、エルによるキャラクター表現で補っています。

長時間一緒にゲーム内で旅をするゲームデザインでは、人間型のキャラクターを実装することは非常にコストも高いですが、その価値は大いにあると考えられます。

永田:続いて、エルから基本操作とゲームルールの説明がされますが、場所を比較的狭い空間にすることで、情報を制限しています。

永田:ゲーム内では序盤で「ゲームの操作方法」「どうやって進むのか」「何を見ればいいのか」についてレクチャーされます。

VR空間内にはデザインしたオブジェクトを自由に配置できますが、置きすぎるとプレイヤーが何をすればオブジェクトが動くのか、判断に迷ってしまいます。

そのため、この画面で印象的なオブジェクトを見せることで「この系統のデザインのモノを見て触れば次に進める」という感覚を持たせ、謎解き要素に集中できるようにしています。ここでも、テキストを使用せず、エルのセリフのみで説明、進行していきます。

謎解きステージでの情報提示

永田:本作では、進行方向について、基本的に「前を向いていれば理解できる」デザインにしています。VRでは360度自由に視点を変えることができるため、ゲームに関係する情報をさまざまな方向に置いてしまうと、プレイヤーは総当たり戦のようなプレイをしてしまう恐れがあります。

永田:それを回避するために、基本的に前進するような構造設計にしており、謎解きに必要な情報はすべて前方(進行方向)に置いてあります。実は、ゲーム内で360度の世界が広がっていても、VRに慣れていないプレイヤーは、ほとんど前方向しか見ない傾向があるんです。

分かりにくい場所にあるオブジェクトに対して、徐々に誘導して発見する体験をさせることも可能ですが、その場合にはきちんとした導線の設計が必要となります。

高橋氏:『VoxEl(ボクセル)』のレベルデザインについては、エリアを小分けにして、縦シューティングゲームのように奥に進むような構成が基本となっています。

高橋氏:エリアをまたぐたびにチェックポイントを設置し、途中で向きがわからなくなったり、エリアが変わったときに方向をリセットするようにしています。

本作では、最終ステージにて巨大なボスキャラクターが出現し、これまで駆使したギミックを使って戦いますが、このタイミングでは進行方向が逆になるので、進む方向と戻る方向を明確に認識できるようにしています。

キャラクターによる誘導

永田:現実と同様にVR空間内においても、単純に動いている物体よりも、コミュニケーションを取ろうとする物体に対して、人間は強い反応を見せます。

本作ではエルのセリフやモーションによって、「次に何を見ればいいか、何をするべきか」という情報を与えて、プレイヤーを導いています。

先に述べたとおり、VR空間内で成立する人間型のキャラクターの制作はコストが高いのですが、苦労に見合うほどの価値があるので、ぜひ挑戦してほしいと思います。

もちろん、人間型ではなく、シンプルなデザインのロボットのようなキャラクターでも、コミュニケーションを取る意思のある存在であれば、十分代用可能だと考えられます。

失敗例としては、とある場所に落ちてきた物体に対して、エルが「どかして」と話すのですが、その会話の際にエルの顔を別の方向に向けさせてしまい、かなりの人がそこで迷ってつまづいてしまったことです。

永田:視線誘導のギミックはVRタイトルでは良く採用されますが、本作では自由移動が可能なので、視線誘導の難易度が上がっています。そこで、要所ではガイドのキャラクターを動かしてプレイヤーの視線をコントロールしています。

もちろん、音による視線誘導もしていますが、ゲームのリテラシーが高くない人、ゲームに慣れていない人には、現実の音ほどの効果がないので、明確にやや長めに音を鳴らすことを意識した方が良いと言えます。

特にゲームショウなどの屋外イベント会場では騒音も大きく、それによって視覚情報がより重視されてしまう恐れがあり、サウンド設計時にはプレイする環境を考慮することも重要だと考えられます。

実在感を上げるための演出

高橋氏:VR空間において、キャラクターがプレイヤーの方向を向く、動いて話しかけてくる仕組みは、エルというキャラクターを使って表現しましたが、試遊した人のフィードバックを含めて、非常に大きな効果を上げた、とてもエモい経験でした。

高橋氏:これまでセッション内で伝えてきた通り、人間型のキャラクターをプログラムやモーションを開発して制御することは非常にコストも高く、チャレンジしづらい領域ではあります。ただ、エルと協力して謎を解いたり、敵と戦ったりする体験は、非常に魅力的でトライする価値がある演出だと感じました。

私は過去に、キャラクターとお話を楽しむPS対応タイトルの開発に携わっており、仮想キャラクターとコミュニケーション可能なゲームデザインをしていました。

VRの特徴として、自分がそのままゲーム空間に存在するような体験ができることだと考えており、キャラクターとのコミュニケーションにより、自分の心にもたらす変容のようなものが、VRの世界でも効果があると感じています。

永田:それでは最後に、サウンド開発に関する話をしたいと思います。VR空間では視覚情報の比重が大きくなりますが、サウンドの中でも特に「環境を表現する音」は非常に効果が高いと考えられます。

特に、ボイスやSEが鳴ることによって発生する「残響音」については、空間の中で鳴る、しゃべっている音声が残響するイメージを考慮して作ると、そこにいる雰囲気が強く感じられるので、コストも少なく、演出としては非常に効果が高くなります。

永田:本作のサウンドに関しては、研究開発の観点から、ミドルウェアを使用せずに、空間ごとにボイスの残響音を全て自力で計算して、エクスポートしましたが、その作業はかなり大変でした。

今回のセッションは以上となります。もし質問やVRタイトルの相談があれば、ぜひ、個別にご連絡ください!

取材・文・撮影:細谷亮介

[su_note note_color=”#ffffff” radius=”10″]

GeNOM(ゲノム)とは

DeNAのゲームクリエイターを様々な切り口で紹介するメディア(運営:株式会社ディー・エヌ・エー)です。ゲーム開発の現場で生まれる様々なエピソードや、クリエイター紹介、イベント紹介などを通して、DeNAで働くメンバーの”ありのまま”をお伝えしていきます。

GeNOMの最新情報は、公式Twitterアカウントやにて確認いただけます。ぜひフォローをお願いします!

[/su_note]

【CEDEC2019】「サービス終了寸前だったタイトルが、CMを使わずにDAUを増やして九死に一生を得たSNSプロモーション術」セッションレポート

2019年9月4日~6日の期間、パシフィコ横浜において、ゲーム開発者向けカンファレンス「CEDEC2019」が開催されました。

本記事では、9月6日に行われた「サービス終了寸前だったタイトルが、CMを使わずにDAUを増やして九死に一生を得たSNSプロモーション術」について、『天華百剣 -斬-』プロデューサーのナカムラケンタロウが登壇したセッションの内容を、一部抜粋してレポートします。

冒頭、ナカムラは今回のセッションの重要なポイントとして「プランナーとしてTwitterのプロモーション効果を意識しつつ、ゲームについて深く考えることが重要」だと述べ、マーケティングに携わる参加者には「プランナーと連携すれば、プロモーション効果をより高めることができる」といった視点で見てもらいたい、と説明しました。

『天華百剣 -斬-』とは

『天華百剣 -斬-』は、乙女の姿を持って生まれてきた刀剣「巫剣(みつるぎ)」 たちとともに、世を乱す邪悪な敵との戦いに挑む、スマートフォン向けベルトスクロールアクションゲームです。

本作はKADOKAWA社とDeNAの協業案件であり、ゲームだけでなく、コミカライズやノベライズ、キャラクターソングなど、各種メディア展開を続けているタイトルになります。

登壇者のナカムラは、2013年に株式会社DeNA Games Osakaに入社し、プランナーとして運用中および新規タイトルを担当。2017年の11月に『天華百剣 -斬-』にディレクターとして参加し、タイトルの一周年を迎えた2018年4月にプロデューサーに就任しました。

サービス終了寸前まで追い込まれた歴史

『天華百剣 -斬-』プロデューサー ナカムラケンタロウ

『天華百剣 -斬-』は2017年4月20日にリリース後、順調に運営がスタートしたものの、あるトラブルが原因となり、ユーザー数が減った経緯があります。

そんな低迷期の中、ナカムラは2017年11月に『天華百剣 -斬-』の開発チームに参加。2018年1月の半ばにプロデューサー交代の打診を受けました。

その直後の2〜3月が最も低迷した時期となり、会社から「2018年8月末の状況でサービス終了かどうかのジャッジをする」という通告も受けたとのことです。

下図は2017年4月~2018年3月の1年間の月間のアクティブユーザー数を、ざっくりとイメージしたグラフとなります。

あと数ヶ月後にはサービス終了の可能性がある状況で、ナカムラは「絶対にタイトルを終わらせたくない!」「そのためにどうすればいいか?」と自問自答していたそうです。

もともと本作のリリース時から一人のプレイヤーとして遊んでおり、個人的に思い入れが強いタイトルだったこともあって、彼のプロデューサー生活は「タイトルをサービス終了させないために、どうすればいいか?」を、具体的かつ真剣に考えることからスタートしました。

そんな彼が、絶対にサービス終了させないためにと心に決めたことは「予算が限られている中で必ず最大以上の成果を出す」こと。そして「最大以上の成果を出すために、できることは何でもやる!」ことだったそうです。そのような強い想いで様々なチャレンジを行っていきました。

Twitterのプロモーション効果に注目

『天華百剣 -斬-』の存在を、たくさんの人に知ってもらうためのプロモーション手法として、たとえば「テレビCM」はすぐに頭に思い浮かびますが、その実施にはかなりの費用が必要になります。また、電車の車体に広告を掲出するラッピング広告や、中吊り広告ジャック等もインパクトは強いのですが、こちらも一定の費用が必要になります。

そこでナカムラは大きな費用をかけてのプロモーションが不可能な中、「自分たちが届けたいと考えるターゲット層に、ピンポイントサーチで情報が届く」ことを目標設定しました。その理想の状態を実現させるためのツールとして「Twitter」がベターな選択肢だったと語っています。

Twitterの特徴

Twitterには「匿名性の高さ」と「他のSNSに比べて一人で複数アカウントを使い分けやすい」という2点の大きな特徴があります。ゲームやアニメなどのいわゆる「オタク系コンテンツ」と相性が良いため、「趣味嗜好が似た人同士が繋がっていることが多い」という状況がTwitterの世界では発生しています。

「自分が好きなゲームの話題をツイートする専用アカウントをつくり、同じゲームが好きな人をたくさんフォローする」といった使い方をしている人は珍しくありません。

そのように趣味嗜好が似た人たち同士で繋がっているため、「情報の伝播のしやすさ」と「情報の伝播の速さ」が、Twitterをプロモーションで使う際の大きなメリットになっており、それを最大利用することを考えたそうです。

たとえば、Aさんが「天華百剣の新情報」についてツイートすると、その新情報は趣味嗜好が同じフォロワーのBさんに伝わります。さらにBさんがその情報についてツイートやRTすることで、その情報はより広く、多くの人に伝播していきます。

伝播していく先々で、仮に『天華百剣 -斬-』についてまだ存在を知らない人がいた場合、その人はTwitterを通して本作を初めて知ることになります。このようにして情報が拡散していくことが「Twitterのプロモーション効果」であるとナカムラは説明しました。

Twitterを通して情報を広げるプロモーション手法と聞くと「バズる」「バズらせる」といった用語をイメージすることが多いかもしれませんが、ナカムラが目指したものは実はそうではなかったようです。

もちろん『天華百剣 -斬-』に関連する情報がバズり、これまで本作に興味がなかった層まで伝わることは、プロモーションとしては成功だと考えられます。

ただし、Twitterでバズった情報は、一定時間が経てばすぐに収束するため、中長期的にはほとんど効果がないと説明しました。

ナカムラが実現したかったのは「同時多発的にさまざまな情報がツイートされ続ける」「同時多発的に何かしらの新しい情報が発信され続ける」といった状況でした。これは「バズる」こととは、微妙に概念が違うと捉えることができます。

3つの法則

なぜ「同時多発的にさまざまな情報がツイートされ続ける」状態を目指したか、その理由は「3つの法則」を発動させられるから、と語りました。

まず上図1.のように、Twitterでつながっている人が注目している情報は、なぜか自分も気になってしまう法則です。

これは自分でCMを見て気になるより、知人が「このゲーム面白いよ」と発言しているのを見て、「あの人が言うなら、きっと面白いはず」と自然に気になってしまう現象です。

また、気になっている情報については2.「最近、○○をよく見る気がする」法則が発動すると考えられます。

ナカムラの過去の話で、母親が「緑色の車を買おうと思っている」と言った数日後に「世の中には緑色の車がたくさん走っているから、やっぱり別の色にしたい」と急に意見を変えたことがあったそうです。

そのような状況になったのは「緑色の車が欲しい」と考えていると、自然とそれに注目してしまい「世間には意外と緑色の車が多い」と感じてしまったと考えられます。

それと似たように、無意識に注目する情報は目につきやすく、記憶に残りやすい傾向があるようです。その状態をTwitter上で作りたいと、ナカムラは思っていたことを明かしました。

つまり、同時多発的に『天華百剣 -斬-』のさまざまな情報がツイートされ続けることで、今このゲームが盛り上がっている、という空気を作る部分が彼が目指したポイントになります。

プレイヤーと運営間のコミュニケーション

そしてプロモーション効果を高めるために、「プレイヤーと運営間のコミュニケーションについて、意識を変えること」をナカムラは挙ました。

ゲームプレイヤーと運営のコミュニケーション方法には、ゲーム内お知らせ、動画チャンネル、生放送やアンケート、人気投票、プロデューサーレターなど、さまざまな種類が存在します。

プレイヤーと運営の間での、何かしらのインタラクティブな要素は、全て広義にコミュニケーションだと捉えてもいいのではとナカムラは考えています。

直接的な発信はゲーム側より実施することが多く、プレイヤーからの発信手段は、Twitterでつぶやく、掲示板に書き込む、YouTubeに自分が撮ったプレイ動画をアップするなど、さまざまな手段が存在しています。

また、双方向のやりとりとして、リアルイベントで開発陣と直接会話したり、ゲーム内でアンケートを取り、意見を収集することもあります。

ゲーム内に実装している全てのコンテンツは、プレイヤーに対して何かしらの情報や運営のスタンス、メッセージを発信しています。それらをエゴサーチで受信することによって、間接的なコミュニケーションが成立するとナカムラは考えています。

つまり、ゲームに実装している全ての機能は、プレイヤーに対する広義のコミュニケーションであると認識することで、Twitterのプロモーション効果をより高めることが可能になるとのことです。

Twitterのプロモーション効果を高める3つの方法

その1:人格を意識して情報を開示

続いてプロモーション効果をさらに高めるために、プレイヤーが感じているゲーム全体の「人格」を意識しつつ、さらに運営側は可能な限りの情報を、さまざまな手段で「開示」していくことが重要だということが説明されました。

『天華百剣 -斬-』では、公式も含めてTwitterでは「天華百剣くんは~」「天華百剣ちゃんが~」のような呼ばれ方をすることが多く、ゲーム全体に人格があるかのように感じる、とナカムラは話しました。

そこに存在する「ゲームの人格」を意識することが非常に重要だと考え、運営側として、より良い人格を持っている状態を作るため、下図の2点を目指しました。

プロデューサーレター
2018年4月に1回目のプロデューサーレターを公開。プロデューサー交代の報告や、超低迷期を迎えていた時期、サービス終了の噂などでプレイヤーを不安にさせてしまったことへの謝罪や、今後のスケジュールなどが公開されました。

また、シナリオやボイス関連の制作上の都合の説明や、β版だったマルチバトル機能に寄せられた意見に対する返答などを実施し、それを重ねることでプレイヤーと運営側のコミュニケーションを具体的に進めていったとのことです。

エイプリルフール施策
エイプリルフール施策では、当時プレイヤーから嫌われていた敵キャラを主人公にした、ネタシナリオのイベントが実装されました。

その敵キャラは、主に掲示板の中でスラング的に「金棒先輩」という愛称で呼ばれていたため、ゲーム内でシナリオにそのまま採用してみたとのこと。

さらに、某人気ゲームのパロディを入れ込むことで、「運営はきちんと掲示板やTwitterを見ている」ことを、ゲームへのイベント実装で証明した形になり、それを意識させることで「自分のツイートやレスも運営側が見ている」ことを認識できるように設計したそうです。

 

このような施策の実施で、プレイヤーの声を積極的に取り入れるスタンスの表明に加え、SNSでの発信の意味や価値が高まりました。

その結果、ツイートの活性化にもつながり、Twitterのプロモーション効果を高める方法として、プレイヤーのツイートの意味と価値も高めることができたようです。

その2:ネタを仕込みまくる

さらにプロモーション効果を高める方法として、「ゲーム内にスクショを撮りたくなるポイントを仕込むこと」が挙げられました。

ツイート数が増えないとTwitterは盛り上がらないため、ゲーム内にスクショを撮りたくなるようなポイントを増やすことをまず考えたそうです。そしてスクショを取りたくなるポイントとして、「エモいポイント」と「ツッコミポイント」を2大ポイントとして挙げました。

エモいポイントの事例として、一周年イベントシナリオのエンディングの一幕が挙げられました。ここではシナリオに登場したキャラクター全員が出迎えてくれて、プレイヤー名を呼んで祝ってくれます。このような演出を入れることで、プレイヤーは思わずスクショを撮りたくなり、その中の何割かの人がTwitterなどにアップする効果が期待できます。

結果として、プレイヤーによるスクショの投稿数は大きく増加したと明かされ、「エモいポイント」をシナリオの内容や演出、バトルキャラクターの細かいこだわりなどに反映することは効果的だとナカムラは説明しました。

また、実在した刀剣をモデルにしたキャラクター同士の組み合わせも重要になっているようです、たとえば、伊達家の刀剣同士が絡んでいたり、史実をなぞるような演出やオマージュも、歴史が好きな人、他の歴史ものIPが好きな人には、特に喜ばれていると考えています。

ツッコミポイントの一例としては、普段はしゃべることのない敵キャラクターが、なぜか会話しているネタを設置したことが紹介されました。

たとえば「田舎のヤンキー口調でしゃべる」「普段の3倍くらいの長さの金棒を持っている」などのツッコミどころを用意し、スクショを撮ってプレイヤーにつぶやいてもらうことで、それ自体がツッコミとして成立することを設計しています。

そのようなツッコミポイントを増やすことが、同時にスクショポイントを増やし、さらに投稿数の増加につながっていくとナカムラは考えました。

その3:ゲーム内外の施策を連動

さらにプロモーションの効果を高める3つ目の方法として「ゲーム内外の施策を積極的に連動させる」ことが有効だそうです。

たとえば2018年6月から一か月に渡って開催されたコラボカフェでは、メニューや特典の他に、オリジナルの割り箸袋や紙ナプキンを来場されたお客様に提供しました。するとお客様が「こんな細かいところにまでこだわったグッズ作ってくれて嬉しい」とつぶやいてくれたそうです。

さらに店内ではボイスドラマを流し、実際にゲーム外の施策としてもツイートできるネタを仕込み、盛り上げていったとのことです。

それに加えてゲーム内連動として、実際にコラボしたお店の内装をそのまま再現した背景を作り、ゲーム内アイテムとして配布すると、実際に自分のお気に入りのキャラをセットして、それを撮ってつぶやく人がかなり増加したとのことです。

実際にコラボカフェに訪れた際に「配布された背景と一緒だ!」と、その様子をツイートする人もいたようです。

また、コラボカフェが終了したタイミングで、店内で流したボイスドラマをゲーム内に実装して、誰でも楽しめるようにしました。

それにより「店内で流れたボイスドラマがゲームでも聞けるようになった」「自分の好きなキャラのこの部分が可愛い」「次はこのキャラでボイスドラマ作ってほしい」など、派生したツイートも増え、連動させればさせるほど、ツイート数を増やすことが可能になったようです。

一周年に多くのお祝いツイートが

今まで紹介してきた取り組みの効果を加速したトピックスとして、2018年4月に一周年を迎えた際に、イラストレーターやキャスト、シナリオライターをはじめとする関係者やプレイヤー、ファンから、たくさんのお祝いツイートをもらったことをナカムラは明かしました。

そのおかげで『天華百剣 -斬-』をさらに多くの人に知ってもらえることができ、新たにゲームを始める人もたくさん増えたことが、本当に嬉しかったとナカムラは振り返りました。

結果、無事にタイトル継続が決定

冒頭でも述べられたように、2018年2月から3月が超低迷期、そして4月に一周年を迎えていますが、これまで説明された施策により新規ユーザー数を増やすことができ、8月に無事にタイトル継続が決定しました。

さらに上図の棒グラフが右上がりになっている部分では、2019年3月に実施した劇場版アニメ「魔法少女リリカルなのは Detonation」とのコラボの影響で新規ユーザーがさらに増え、そこから二周年に突入した時期だと読み取れます。

2019年10月より開始したショートアニメのTV放送や、2020年以降に向けての準備もスタートしているということで、継続的にタイトルを続けられる基盤が整いつつあるとナカムラは述べました。

プロデューサーそしてプランナーとして深く考える

ここまで紹介された「Twitterのプロモーション効果を高める方法」の3つの手法の組み合わせでツイート数が増え続け、比例してRT数やいいね数も増加していきました。

それらの相乗効果により、同時多発的にゲームのさまざまな情報がツイートされ続けることで「今、このゲームがアツい!」といった空気感を生み出すことができると考えられます。これがナカムラが考える『天華百剣 -斬-』が目指した状態に近いと言えるでしょう。

最後にナカムラは、

「『天華百剣 -斬-』のような、オリジナルIPのゲームは運営を続けるのが本当に難しく、さらにサービス終了の可能性と常に隣り合わせです。モバイルゲームの運営を任され、それを続けていく責任はかなり重いと感じています。

プランナーの目線で、Twitterのプロモーション効果を意識しながら、ゲームについてあれこれ考えることが重要で、チーム全体が協力して今後もタイトルを盛り上げていきたいと思っています。」

と、プロデューサーとしての自身の思い、実際に行ってきた施策のプロモーション効果など、これまでに得た知見や知識を最大限に生かして、今後も良質なタイトル運営を続けていくことを誓い、セッションを締め括りました。

取材・文・撮影:細谷亮介

[su_note note_color=”#ffffff” radius=”10″]

GeNOM(ゲノム)とは

DeNAのゲームクリエイターを様々な切り口で紹介するメディア(運営:株式会社ディー・エヌ・エー)です。ゲーム開発の現場で生まれる様々なエピソードや、クリエイター紹介、イベント紹介などを通して、DeNAで働くメンバーの”ありのまま”をお伝えしていきます。

GeNOMの最新情報は、公式Twitterアカウントにて確認いただけます。ぜひフォローをお願いします!

[/su_note]

【Unite Tokyo 2019】「Unity Test Runnerを活用して内部品質を向上しよう」セッションレポート

2019年9月25~26日にグランドニッコー東京において、技術カンファレンスイベント「Unite Tokyo 2019」が開催されました。

本記事では、9月26日に実施されたセッション「Unity Test Runnerを活用して内部品質を向上しよう」の内容を一部抜粋して紹介します。

ゲーム開発でもテストは重要

本セッションでは、Unityにおいて、ユニットテストを実行する「Unity Test Runner」の仕組みを活用して開発者の手でテストコードを書き、ゲームの内部品質を向上するためのベストプラクティスやTipsなどが紹介されました。

登壇した株式会社ディー・エヌ・エー システム本部 品質統括部 品質管理部 SWETグループに所属する長谷川 孝二は、おもにUnity向けのテスト自動化支援に携わっています。

ディー・エヌ・エー システム本部 品質統括部 品質管理部 SWETグループ 長谷川孝二

なお、本セッションの前提知識として、2019年9月開催の「CEDEC 2019」において講演された「組織にテストを書く文化を根付かせる戦略と戦術」にて、タワーズ・クエスト株式会社の和田卓人氏から、開発者がテストコードを書く必要性や、開発効率を上げる根拠、取り掛かるべき指針が数字で公開されており、その点は本セッションでは割愛しているため、ぜひ参照してほしいと紹介されました。

SWETグループとは

DeNAのシステム本部に設立されている部署「SWET (Software Engineer in Test) 」グループは、他の横断的組織と連携して、テストの自動化のアドバイザリー、テストや検証ツールの作成、CI/CD、デバイスファームの利用、形式手法によって仕様書記述の品質を上げるといったR&Dの取り組みも担当しています。

テストに関する4つの誤解

ここからは、ゲーム開発におけるテストに関して、一般的に感じられているような「誤解」を解くための説明がなされました。

【誤解1】「テスト」==「デバッグ」

おもにゲーム業界の開発現場で使用されている「デバッグ」とは、バグの発見、原因箇所の特定、修正のことを指しますが、ソフトウェア開発全般で使われる「テスト」の目的は、バグの発見だけでなく、対象ソフトウェアの品質レベルが十分かの判断や、バグの作り込みを防ぐことを意味します。

その中でも「対象ソフトウェアの品質レベルのチェック」に関しては、正しく動作することを確認するとともに「クラッシュしないか」「ユーザーが実際に遊んで問題ないか」など品質を測る、という意味を持ちます。

また「バグの作り込みを防ぐ」ことに関しては、リグレッション(デグレ・エンバグ)をテストをすることにより、時間差なくバグを迅速に発見して修正することが可能とのことです。

【誤解2】ビルドしたゲームを、手動で操作するのがテスト

次の誤解ポイントとして、ビルドしたゲームを実機でテストすることだけがテストだと思われていることが挙げられました。

ゲームを遊べる形にビルドする以前に実施するテストでは、コンポーネントやメソッドのような小さな単位で早期に確実に検証できるのが、低レベルで可能なテスト(ユニットテスト・インテグレーションテスト)のメリットです。

もちろん、この段階では実機(手動)では操作できないので、必然的に自動テストが採用されます。

ユニットテストの利点は、素早く実行してバグを早期に発見できること、個々の部品の品質を上げておくことです。

また、再現の難しい条件を作り出しやすく、タイミング的に難しかったり、乱数的に低確率であったり、画面操作では指定できない値などに対してテストできることも、特にメリットになると長谷川は述べました。

【誤解3】テストを書けば品質が上がる

続いての誤解ポイントは、「テストを書けば品質が上がる」ことです。テストでは品質を測るだけで、実際は正しい設計やプログラミングで品質は上がります。

品質の低いプロダクトはテストが書きにくい事実もあるようです。「テスタビリティ」と呼ばれるテストのしやすさや、書きやすさについての品質特性を評価する観点のひとつがあります。

テストしやすいコードは、その時点でバグも少なく、可読性も高いく、すでに一定の品質を備えていると言えることがほとんどです。

この関係は「ルンバビリティ」という言葉に例えることができると長谷川は話しました。これはお掃除ロボットが自動で掃除するには、その部屋がある程度片付いていなければ、ロボット自体が動けずに、うまく掃除ができない、という意味で使われる言葉とのこと。

また、テスタビリティを含め、外部からのテストではわからないコード自体の品質のことを「内部品質」と呼び、保守性や可読性、移植性などがこれに含まれます。内部品質を高めていくには、ユニットテストを書き、プロダクトコードを見直すことが有効なようです。

【誤解4】テストコードは、プロダクトを開発した後から書く

最後に挙げられたのは、テストコードをプロダクト開発後に後付けで書けばいい、という誤解です。

やはりプロダクトを開発しながら、並行してテストコードも書き、常に実行していくことがベターだと長谷川は述べています。

ユニットテストは人間の手で作業するテストと違い、実行時間は短いので、書いたコードをリポジトリにコミットする流れの中で、テストコードを実行することを習慣化することが大事なようです。

長谷川の持論として「テストコードは建築における足場」だと話しました。実際の建築現場では建物が完成したら足場は撤去しますが、ソフトウェア開発ではリリースに含まれなければ良いので撤去する必要はなく、増改築でも引き続きその足場を利用する、という考え方です。

Unity Test Runnerを使ってみよう

「Unity Test Runner」とは、Unity標準のユニットテスト実行環境で、Unity2019.2からはPackage化され「Unity Test Framework(UTF)」となります。

実行環境としては、UnityエディタからEditMode/PlayMode/実機の各テストを実行できるだけでなく、コマンドラインでも実行可能です。またEdit Modeテストは、JetBrains Riderからも実行可能になっています。

Unity Test Runnerウィンドウは、Unityエディタのメニュー内、Window>General>Test Runnerで起動、EditModeもしくはPlayModeを選択してRun Allすると成否がカラーで表示されます。

2種類のテストモードがありますが、できる限りEditModeを使用することを推奨とのこと。EditModeではエディタ上で素早くテスト実行することができ、PlayModeはUnityエディタのプレイモードと同じ環境で実行することができます。

EditMode Tests

EditModeでは、テストコードの置き場所が2通り指定できます。従来はEditorフォルダの下に配置するしかなかったのですが、Unity 2018以降は任意のフォルダにAssembly Definition Fileを配置して、Editorアセンブリとして認識させることが可能です。

Assembly Definition Fileの設定内容は、テスト対象のアセンブリへの参照、Test AssembliesおよびPlatforms>EditorのチェックボックスをONにします。

テストクラスに制約はありませんが、テスト対象クラスと粒度を合わせることが慣例になっており、メソッドに[Test]アトリビュートをつけたものが、テストメソッドとして認識される仕様になっています。

セッションでは、テストメソッドなど、EditMode Testsのコード例も紹介されました。テストメソッドは、もっとも重要な検証(Verify)のコードから書き、下から上に、テスト対象の実行(Exercise)、環境設定(Setup)の順に書いていくのがおすすめとのことでした。

[UnityTest]アトリビュート

このアトリビュートは、複数のフレームにまたがるテストを記述できるもので、EditModeではEditor Application.updateコールバックループで実行されますが、yield returnにはnullしか指定できないなどの制約もあります。

PlayMode Tests

Edit Mode Testsとは別アセンブリを定義します。設定の違いは、Platforms > Editor をoffにするというところです。

注意事項として、テスト用の空のSceneファイルが生成・ロードされるため、テスト実行ごとにオーバーヘッドが必要となり、やや時間がかかります。またUnityエディタがクラッシュすると、Sceneファイルが残ってしまうことがあるとのことです。

また、一連のテスト実行の際には、生成されたSceneは使い回されるため、一個のテストメソッドを実行するたびに適切にクリーンナップしないと、後続のテストに影響します。

PlayMode Testsでは、Sceneベースのテストを書くことが大変なため、インテグレーションテストを書くのであれば、Poco、AltUnityTesterなどサードパーティのライブラリ導入を検討すべきと長谷川は述べました。

ゲーム開発向けユニットテストパターン

ここから本セッションの本題とも言える、ユニットテストのパターンや、ベストプラクティスの話題に入りました。

テストとはどう考えるべきか、テストの基本は「入力」と「出力」であり、観点によって入出力の捉え方が変わり、入出力はそのメソッドの何をテストするかによって定まります。

例えば実行速度が観点のときには、普通のパラメータを与えてレスポンスを見るのではなく、実行時間を図ったり、FPSを計測することが「出力」となります。

特に重要なのが、正しい入出力の見極めです。例えば出力として「セーブしました」というメッセージが出たため、テストはOKと判断してしまうと、実はメッセージは出したけど内部的に保存はされていなかった、もしくは保存データが壊れていた、というバグを見落とす恐れがあります。

価値の高いテストを書く

ショーストッパーと呼ばれる、基本的な操作ができなくなり、ほかのテストがすべて止まってしまうような部分、また、課金周りやクレームに直接繋がる部分はリスクが高く、価値の高いテストと言えます。

また、あまりプレイヤーが触らないような通らないルートや画面に関するテストも、見落としを防ぐ意味で価値のあるテストと言えます。

逆に価値に対してコストが高なってしまうものとして、副作用的なもの、目に見えるようなエフェクトやSEなどを挙げました。これらはあえてテストを書かないという選択もあるようです。

組み合わせ条件を減らす

テストの「入力」にあたる要素が多くなり組み合わせ条件が増えれば、テストもそれだけ複雑になります。例えば「弾がヒットして敵が破壊されたかどうか」の粒度でテストをすると、敵のHPや防御力などさまざまな要因が関係し、当然組み合わせの条件も増えてしまいます。

それを避けるため、プロダクトコード側の責務を適切に分割することで、個々のコンポーネントやメソッドが扱う要素が減り、組み合わせ数も減ります。

責務を分けたらコールスタックが増えて性能が出ないのでは?

実は本当にボトルネックになる部分は少ないと言われており、見極めはかなり重要になるようです。コンパイラの最適化を信じる、引数にrefをつけて参照渡しにするなど、対処方法は多数あると長谷川は述べました。

パフォーマンステスト

パフォーマンステストは、ユニットテストの段階から意識することが重要で、特にUpdateメソッドで動作する、呼ばれる頻度の高い部分を、できるだけ小さい規模のうちに意識することが大事だとのことです。

そのためには、メソッド単位に実行時間を測定して遅くなったら失敗するテストを書いたり、PlayModeでfpsを測定するなどの手段を使うと良いようです。

ただ、実行時間は環境に依存するため、実行時間のしきい値をピーキーに設定することはせず、自分以外の人がそのコードを修正したときに気をつけてもらうための「魔除けのお守り」程度の気持ちで考えると良いそうです。

また、メソッドの実行時間ではなく、AllocatingGCMemoryによって意図しないヒープメモリの確保が行われていないことを確認するテストも有効です。

他のオブジェクトへの依存

依存オブジェクトとは、テスト対象が内部で使用している他のオブジェクトのことです。例えば、乱数を内部に発生させている場合に、乱数の結果をテストコード側がコントロールできないと、テスト結果が正しいのかどうか判定できなくなってしまいます。

また、依存オブジェクトからの戻り値でテスト結果に影響するものを「間接入力」、依存オブジェクトに渡した引数のうちテスト結果として評価しなければならないものを「間接出力」と呼ぶそうです。

依存オブジェクトを持つメソッドをテストするための「テストダブル」といったパターンも存在します。これは映画のスタントや影武者のような役割を持っている手法になります。

テストダブルパターンは、あらかじめテスト側から依存オブジェクトのダブルを生成しておき、テスト対象は依存オブジェクトを内部で生成するのではなく外から受け取れるようにします。そうすることでテストダブルが間接入力を操作し、間接出力を検証します。

仕様変更のたびにテストが壊れる

よくある誤解としては「仕様変更があるからテストは書けない」のは間違いであり、「仕様変更があるからテストで保護しておく」という考え方に変えることが大事だとのこと。

将来の仕様変更を想定することで実装が複雑になり、品質も落ちてしまうったが仕様変更は起こらなかった、という経験はないでしょうか。テストがあることで仕様変更をしてもプロダクトが意図しない振る舞いになっていないか、すぐに気づくことができます。テストコードがあることによって「今必要でないことはしない」こと(YAGNIと言うそうです)を実行しやすくなるのです。

「なぜテストコードが壊れるか?」という話について、仕様ではなく実装のテストを書いてしまうことが要因とされます。ひとつの仕様に対して実装は何パターンも存在するため、実装が変わっただけで壊れやすいテストになってしまいます。

壊れにくいテストを実現するためには、副作用は検証しない、あえて定石から外れるといった選択肢もあります。

例えば「敵のHPゲージが5割を切ったら黄色にする」という仕様に対し、テストの定石としては50%と49%をテストするものですが、あえて80%と40%で色の変化にのみ着目するなど、境界値を攻めすぎず、十分役割を果たすテストにすることもできます。

また、メンテナンスが難しくなったテストコードは捨ててしまうこと、TDDではその過程で過剰にテストコードを書いてしまいがちなので、必要ないものは早めに取り除いても良いようです。またテストコードもプロダクトと同じように構造化することで、壊れにくいコードになります。

ここで長谷川は、Jon Reid氏の言葉「テストコードはガラスのような壊れやすいものではなく、竹のようにしなやかで柔軟性の高いものを目指すべき」と挙げ、アジア圏の建築現場で良く使われている竹の足場のように、安くて軽く、使わなくなったら捨てればいいようなコードと、思想は似ていると述べました。

テストを書く文化を根付かせる試み

最後に、SWETグループが採用したアプローチに関して、社内で横断的に共通的フレームワークのリファレンス実装に対して、テストコードのサンプルを書いて新種のバグを摘出し、タイミング良く、他の部署への引き合いに繋がったことが明かされました。

また、ゲーム領域でボトムアップでテストを書くことを始めるのは難しいため、いつでもチャンスが来たら、テストを普及できるような体制を整えておくことが大事とのことです。

長谷川は「米沿岸警備隊の格言 ”Senper Paratus(常に備えよ)”に表されるような心構えを大切にしながら、本活動に興味があればぜひ声をかけてほしい、そしてスライドには本セッションで紹介できなかったUnity Test RunnerのTipsを記載しているので、ぜひ参考にしてください」とのコメントでセッションを締め括りました。

取材・文・撮影:細谷亮介

[su_note note_color=”#ffffff” radius=”10″]

GeNOM(ゲノム)とは

DeNAのゲームクリエイターを様々な切り口で紹介するメディア(運営:株式会社ディー・エヌ・エー)です。ゲーム開発の現場で生まれる様々なエピソードや、クリエイター紹介、イベント紹介などを通して、DeNAで働くメンバーの”ありのまま”をお伝えしていきます。

GeNOMの最新情報は、公式Twitterアカウントにて確認いただけます。ぜひフォローをお願いします!

[/su_note]

【イベントレポ】GDM会場で開発者向け書籍を展示! 著者であるゲームクリエイター3名が関連ショートセッションを実施

毎回様々なゲストをお招きして、最新の技術や情報をシェアするDeNA主催のゲームクリエイター向け勉強会の【Game Developers Meeting】(以下、GDM)。

2019年9月20日(金)に開催された「GDM Vol.36」では、デジタルクリエイターを支援するサービスカンパニーのボーンデジタル様の協力で、会場内にゲーム開発関連書籍の展示スペースを設置しました。

さらに、展示された書籍の中から3名の著者より、それぞれの執筆についての裏話や、今後の開発の技術について各ショートセッションも実施されたので、その模様をレポートします。

ソーシャルゲーム、どのように制作していますか?

最初の登壇者となった株式会社ドリコムの西村拓也氏からは、ソーシャルゲームの開発フローにおけるUI/UXに関連するセッションが実施されました。

西村拓也氏 | 株式会社ドリコム  エンジニア

2007年に株式会社レベルファイブに新卒入社。 以後ゲーム業界で活動し、コンシューマ携帯ゲーム、Cocos2d-xやUnityによるスマートフォンゲーム制作に携わる。2014年に株式会社ドリコムへ入社。『ダービースタリオン マスターズ』では、クライアントエンジニアリーダーを担当。

主な著書に「ダービースタリオン マスターズで学ぶ ゲームUI/UX制作 実践ガイド Unity対応版」。『ダービースタリオン マスターズ』では本書の内容であるUIフレームワークによるアウトゲーム設計や、レースロジックの実装、 クライアントエンジニアのタスクマネージメントを手がけた。

ソーシャルゲームの流れは、もともとガラケーのブラウザゲームからスタートした単純にボタンを押すだけのゲームで、インゲームなどはあまり実装されていませんでした。

その後、スマートフォンの普及により、インゲームが実装されているゲームが次々と登場、昨今ではさらにインゲームをオートプレイやスキップができることが当然のトレンドになっています。

さらに、最近のソーシャルゲームではキャラクターの強化育成など、アウトゲームの部分を触る時間も多くなり、運用が長期に渡るとアウトゲームの画面数も増えるため、制作効率を上げることが重要になります。

アウトゲームのUI制作工程について、おおまかに以下の項目が考えられます。

1.ゲームの企画仕様を作る→プランナー
2.UXを考え、画面案を考える→プランナー?UXデザイナー?
3.PhotoShop等ツールでUIをデザインする→UI/UXデザイナー?
4..png等UIパーツを分解し吐き出す→UIデザイナー
5.UnityのScene/Prefabで配置する→デザイナー?エンジニア?
6.ユーザ操作の挙動をコーディングする→エンジニア

ですが、主な項目について、どの部分をどの職種が担当するのか、曖昧になっている部分が多いです。各作業において担当職種が明確な項目は以下になると、西村氏は述べました。

プランナーの仕事
1.ゲームの企画仕様を作る
→遊びの部分の企画はプランナーの仕事

UIデザイナーの仕事
4..png等UIパーツを分解し吐き出す→UIデザイナー
→Photoshopなどのツールは高額であり、利用頻度の都合上、企業によってはデザイナーだけがインストールしていないケースが多く、UIデザイナーの仕事になる

エンジニアの仕事
6.ユーザ操作の挙動をコーディングする→エンジニア
→コーディングはエンジニアの仕事になる

次に担当する職種が曖昧な仕事として、UXを考える部分について、プランナーはExcelやPowerPointなどによる画面のレイアウト案、遷移案を作っており、UXデザイナーはプランナーよりも役割としては適切と考えられます。

『ダービースタリオン マスターズ』の開発時にはProttを採用して、画面レイアウトや遷移を提案していたことが明かされました。

続いてUIデザインをするのは誰の仕事かと考えると、そもそもUI/UXデザイナーの定義自体が曖昧で、『ダービースタリオン マスターズ』では、書籍の共同著者である冨田篤氏がUI/UXデザイナーを担当しているとのことです。

Unityで配置をするのは誰の仕事かと考えると、デザイナーはUnityを触るケースを良く耳にしますが、エンジニアがデザイナーから配置指示書をもらって配置するケースが多く、この部分が工程上一番効率が悪い箇所だと西村氏は考えています。

UnityのScene/Prefab配置の必要スキルとして、

・Unityのツール理解
・フォルダ構成の設計
・UIテクスチャアトラスの設計
・GameObjectの順番(描画順考慮)
・コンポーネントの仕様理解・アタッチ

以上が挙げられますが、これらすべての作業をデザイナーが対応するにはハードルが高いため、エンジニアが担当するケースが多いですが、実はこの作業をデザイナーがやることで効果が高くなるようです。

西村氏は、エンジニアがScene/Prefab配置をすることに関して、ずっと疑問を持っており、エンジニアはあくまでコーディングをすることが役割だと考えているとのことで、配置まわりの仕事は手放したいと述べました。

さらに、デザイナーとの連携でコミュニケーションコストが増えて「デザイナーがエンジニアにわざわざ直したい箇所を伝えるのは面倒」と判断してしまうこともあり、クオリティの妥協が生まれることもあります。

そのため、デザイナーが対応できるようにして職種間の作業を[su_highlight background=”#fcff99″]「疎結合」[/su_highlight]することで、作業効率やクオリティを上げることも可能です。

デザイナーが対応するためにはまず「Unityのツールを理解すること」です。習得の難易度が上がる要因は勉強する箇所が多いので、範囲を絞って覚え、Unityをレイアウトの配置ツールとしてみなすことも大事です。

続いては「フォルダ構成の設計」で、デザイナーが構成を考えて、構成にとらわれないシステムであることが望ましいと考えます。

また、「UIテクスチャアトラスの設計」「GameObjectの順番(描画順考慮)」の2つは、共通で使うボタンや画面の雰囲気、世界観を作るための絵素材の選定など、UIデザインの全体設計に影響を及ぼす箇所であり、それらを踏まえてエンジニアのサポートは必須だと思われます。

コンポーネント仕様の理解およびアタッチに関しては、デザイナーとしてレイアウト構成で必要なものがあれば良く、作成思想はどのプロジェクトでも使えるような特有のコンポーネントにしないことが必要です。

『ダービースタリオン マスターズ』制作時には、書籍の共同著者の冨田氏がデザイナーとして対応してくれたため、すごく楽をさせてもらったと西村氏は話しており、ゲームオブジェクトの順番や負荷などは調整したものの、アトラスの設計なども冨田氏が作業してくれたとのことです。

また、エンジニアがコーディングして実装する際には、仮レイアウトデータをもらって作業しており、デザイナーがUIリソースをGitでPushしてマージしてくれたので、その組み込みシステムのおかげで、ブラッシュアップされた最新のデザインがゲームを起動するたびに組み込まれ、それを見て心躍ることが多かったとのことです。

最後に、エンジニアはコーディング設計の際に疎結合を意識していますが、各職種の作業間も疎結合を狙うようなシステムを実装するべきで、詳細はぜひ著書を参照してほしいと西村氏はセッションを締め括りました。

OpenAI GymとBaselinesを使って
ソニックを攻略する人工知能の育て方

続いて登壇したギリア株式会社の布留川英一氏は、GDMイベントの前日が9月19日で「メガドライブミニ」が発売された日ということで、『ソニック・ザ・ヘッジホッグ』(以下、『ソニック』)を攻略する人工知能の育て方を紹介しました。

布留川英一氏 | ギリア株式会社 研究部 探索グループ リードプログラマー

1999年、「JAVA PRESS」(技術評論社)にて、携帯アプリの開発方法の連載を開始。2001年、株式会社ドワンゴにて、世界初のJava搭載携帯電話「503i」のローンチタイトル『サムライロマネスク』の開発に携わる。

以後、新端末の新機能を活用したアプリを作りつつ、技術書を書き続け、18年で40冊ほどに。現在はギリアにて、ヒトとAIの共生環境の実現を目指して、人工知能の研究開発に取り込んでいる。

主な著書に「AlphaZero 深層学習・強化学習・探索 人工知能プログラミング実践入門」「Unityではじめる機械学習・強化学習 Unity ML-Agents実践ゲームプログラミング」(ボーンデジタル)など。

機械学習と強化学習

人工知能は「ルールベース」と「機械学習」に大きく分かれ、人間が予測や判断を行うルールを考えたもの、従来のゲームはほとんどが対応しているのがルールベース、そのルールをすべてデータから自動生成するのが機械学習です。

そして、機械学習には「教師あり学習」「教師なし学習」「強化学習」の3つがあり、今回の『ソニック』の攻略には強化学習を利用します。

強化学習とは、エージェントが環境の状態に応じて、どのように行動すれば報酬が多くもらえるか、などを学習する手法です。

エージェントとは環境に対して行動を起こす主体となるもの、『ソニック』の場合はプレイヤーや人工知能を指し、環境は、エージェント側から行動を受け取って、報酬と状態を投げ返す部分を指します。

強化学習の学習サイクルについて、エージェント(人工知能)は最初は何をすべきかを判断できないため、取れる行動の中からランダムで決定して環境に送ります。

行動を受け取った環境は、それに対して状態と報酬の善し悪しをエージェントに返します。その状態と行動に応じて「報酬をどのくらいもらうのか」といった経験を記憶します。

続いて、経験に応じてエージェントが方策を求め、2回目の行動は単なるランダムな動作ではなく、編み出した「ランダム+方策」を組み合わせた行動をします。

そのサイクルを繰り返すことにより、将来的に多くの報酬を得られる方策を求めていきます。強化学習に用いられる用語も紹介されました。

開発環境と開発フレームワーク

開発環境には「Python3.6」、Pythonの仮想環境を作成するためのツール「Anaconda」、そしてクラウド環境での学習に必要な「Google Colab」を使用しています。

開発フレームワークには「OpenAI Gym」「Stable Baselines」「Gym Retro」を使用しています。以下で各フレームワークの詳細を紹介します。

OpenAI Gym

「OpenAI Gym」は、強化学習用のツールキットで、エージェントと環境間の共通インターフェース、タスク学習に利用できるさまざまな環境が構築できる特長を持っています。

「OpenAI Gym」インターフェースについて、環境の生成、リセット、1ステップ実行、描画について詳しいソースコードも紹介され、実際の実行画面も公開されました。

Stable Baselines

「Stable Baselines」は、強化学習アルゴリズムの実装セットで、「OpenAI Baselines」の改良版です。実際の学習時のソースコードと実行画面もあわせて公開されました。

Gym Retro

「Gym Retro」は、レトロゲームを「OpenAI Gym」の環境として利用する拡張ライブラリです。使えるゲームプラットフォームはファミコン・メガドライブ・スーパーファミコン・ゲームボーイ・PCエンジンなど。ROMは自身で入手する必要があります。今回はSteamで『ソニック』を購入し、retro.importでROMをインポートし、動作確認をします。

『ソニック』の攻略

・1回目

まず環境を用意して単純に学習させて、動くかどうかを確認してみますが、スタート地点で飛び跳ねているだけでうまく学習できずに、失敗となりました。

強化学習はよほど簡単なタスクでない限り、そのまま学習アルゴリズムを走らせただけでは学習に時間がかかるため、ノウハウを詰め込んで助けてあげる必要があると、布留川氏は述べました。この時点での改善アイデアは以下になります。

【前処理】エージェントに情報を渡す前に学習しやすい形式に変換する、前処理のユーティリティを選びます。ここでは『ソニック』用の行動空間の変更する前処理を作ります。『ソニック』はメガドライブ対応ソフトのため、コントローラに12個のボタンがあり、それらのオンオフが実際の行動の情報になります。ここでボタンのキー数を減らすことで、学習効率を上げることができます。

その他にも以下の前処理を組み込んでいます。

・StochasticFrameSkip:フレームスキップ
・Downsample:ダウンサンプリング
・Rgb2gray:グレースケール
・FrameStack:フレームスタック
・ScaledFloatFrame:状態の正規化
・TimeLimit:5分タイムアウト

【完了条件】最初は「ライフが0になったとき」と設定されていましたが、「ライフが2になったとき」「レベルを攻略したとき」「5分経ったとき」と完了条件を変更しました。

【報酬関数】最初は「獲得したスコアの値」でしたが、今回は1面をクリアするという目標を重視するため「現在のX座標-1フレーム前のX座標」に設定しました。

・2回目

ここまでの調整を実施して、もう一度学習をさせてみましょう。残念ながら失敗となりました。『ソニック』1面の中盤には、マップに一回転するループが設置されており、助走が必要になるギミックです。

そこで、報酬関数に関して「現在のX座標-1フレーム前のX座標」から「現在のX座標-進捗したX座標の最大値(負の報酬はなし)」に切り替えました。

・3回目

さらに学習をさせてみましたが、今回も失敗となりました。マップのループも越えられず、報酬獲得も不安定になってしまいました。

そこで、学習アルゴリズムのパラメータに関して「報酬が継続的に増加しない場合は、学習率の値を小さくする」という設定しました。ここでの「学習率」とは、今回学習したデータをどのくらい重視するか、という数値になります。

そのため新しいものを吸収しすぎると、間違ったことも学習してしまいます。学習の時間は遅くなってしまいますが、学習率を小さくしたほうが正しいことを覚えると考えられるはずと仮定できます。

・ラスト

そして、さらに学習させてみたところ、約3時間以上かかった学習によって、ソニックは無事ゴールすることができました。

最後に布留川氏は、人工知能はなんでもできそうなイメージがありますが、まだまだ不可能なこと、未知数なことはたくさんあるため、一緒に人工知能の可能性を広げて行きたいと思う人がいればぜひ声をかけて欲しいとセッションを締め括りました。

CRI ADX2について

本セッションでは、一條氏が手がけた書籍「Unityサウンドエキスパート養成講座」より、デモアプリの見かたとツールデモが紹介されました。

ちなみに一條氏は、セッションの休憩時間に、サウンドツール「CRI ADX2」を使用し、自身が開発を進めている新作ゲーム『デモリッション ロボッツK.K.』に使用しているサウンドを流し、セッションスタートに合わせて音楽をつないで終了させる、というデモを行っていました。

一條貴彰氏 | 株式会社ヘッドハイ代表取締役

ゲーム作家/Game DevRel。代表作は『Back in 1995』(PS4 /Switch等)。現在は新作4人対戦ゲーム『デモリッション ロボッツ K.K.』を開発中。ゲームミドルウェア会社の営業職を5年間務めたのち、独立。株式会社ヘッドハイを設立し、ゲーム開発ツール専門のコンサルティング 事業を展開。特にインディーゲームクリエイター向けの事業サポートを得意とする。

書籍の構成

書籍「Unityサウンド エキスパート養成講座」では、Unityのサウンドの実装について紹介されています。

大まかな構成として、Unityエンジンに搭載されているサウンド機能を使ってプログラムを書く「Unity標準サウンド」、VRならではの指向性のあるサウンドを紹介する「VRサウンド」、統合型サウンドミドルウェア「CRI ADX2」を利用したゲームの音楽の表現や負荷の低減、作業効率アップなどについて紹介する章に分かれています。

書籍のオススメの読み方として、新人クリエイターやサウンド開発がまだ良くわからない人などは0、1、2章を読み、音にこだわりがある開発者や、サウンドの物量が多い場合は4章を参照することが良いようです。

また、VRコンテンツクリエイターは0、3章を読むのがオススメだそうです。法人のモバイルゲーム開発会社は、現代ではサウンドミドルウェアを使わないと物量の管理やメンテが厳しいため、0、4、5章を読むと良いと一條氏は冒頭で述べました。

書籍第4章の「CRI ADX2」について

「CRI ADX2」は、株式会社CRI・ミドルウェアが開発する、音にまつわる演出が組み込まれたライブラリ&ツールのことです。

主な使われ方としては、音の演出開発コストを抑えることや、モバイルゲームでの膨大なサウンドの負荷軽減や圧縮、暗号化などに利用されることが多いようです。

ちなみに書籍「Unityサウンドエキスパート養成講座」は、「Unite Tokyo 2018」にて一條氏が登壇したセッション「Audio機能の基礎と実装テクニック」に来場者が多く訪れたため、ボーンデジタル社に働きかけて書籍化をした経緯があります。

CRIWAREは多くのコンシューマ・スマートフォン向けゲームに利用されており、特にキャラのボイスや音ゲーなどボイスが大量に使われているタイトルで使われることが多いようです。最近ではUnreal Engine 4と合わせて使われるケースも増えています。

Unity標準サウンドとADX2の違い

Unity標準サウンドでは、サウンドファイルと再生処理が1対1であり、「どの台詞をどのキャラクターのどの状態の部分で再生するのか?」など、サウンド情報を制御する何らかの手段が必要になります。

CRI ADX2では、複数のサウンドファイルや、パラメータを内包できる再生単位「キュー」を介して音を鳴らす仕組みで、専用ツール上で音の組み合わせテストを実施したり、Unity側のスクリプトを変えないで音の鳴らし方を変更・調整することが可能です。サウンドデザイナーとプログラマーの分業のようなイメージになります。

Unity標準サウンドのフロー

WAVEファイルをインポートし、スクリプトでAudio Clipを指定して再生、さまざまなサウンド制御を実装します。

Unity+ADX2のフロー

ADX2を使用する場合、WAVEファイルをいきなりUnityエディタに入れるのではなく、まずADX2のサウンドツール「Atom Craft」を操作して再生単位「キュー」を作り、鳴り方などをパラメータで指定します。

その後、Atom Craftから出力した圧縮データをUnity側のスクリプトでキューを指定して再生、ランタイムに実装済みのサウンド制御を指定して実行します。このフローに関しては、会場で実機デモが披露されました。

ADX2のエディション

CRI ADX2には、法人用の「CRI ADX2」と個人開発者向けの無償版「CRI ADX2 LE」が用意されています。

書籍におけるADX2章の構成

書籍「Unityサウンド エキスパート養成講座」には、最初にチュートリアルとして、まずはひとつの音を鳴らすまでが説明されており、続いてAndroid向け低遅延再生モードや低負荷コーデックの使い方、イントロ付きループ再生機能などの目玉機能の紹介がなされています。

さらにAtom Craftの詳細ツールやデモアプリ、応用編などが掲載されています。

収録されている4章で使用するデモアプリ「一方的タコ殴り ノーダメージ勇者さま」は、ちょっと懐かしめなソーシャルカードゲーム風デザインで、カードをタップしてモンスターを倒すシステムになっています。

会話シーンのサウンド演出について、台詞が流れたときにBGMのボリュームを自動的に落とす「BGMダッキング」、音声データへテキストデータ埋め込み機能、音声データへ表情変更タイミングの埋め込み機能が実装されています。

ダンジョンシーンに含まれる演出は、攻撃台詞を複数パターンからランダムに選ぶランダマイズ機能があります。また、再生制御のソースコードは同一で、データの差し替えのみでキャラクター台詞の切り替え設定や、攻撃の威力に連動してヒット音が変わるランダム設定が実装されています。

ダンジョンを進んで歩く足音に関しては、アプリ内のサウンドデータとしては「タッ」という短いひとつの音だけが収録されていますが、ツールの上で音を時系列に並べ、ピッチのランダマイズを加えて「タッタッタッ」といった長めの効果音を生成できるとのことです。

また、セリフや効果音に作用するリバーブやエコーも実装。ゲームの展開に合わせたBGMの展開変化も収録されています。こちらも実機デモで実際にダンジョンを進んで敵と戦い、クリアに合わせてBGMが終了するまでが披露されました。

そしてセッションの最後に、スマートフォン上で動作するこのデモアプリと、PCのツールをwifiで通信、連動させ、実際のスマートフォンアプリでの動作に合わせてツールでサウンドのリクエストや動きをチェックできるプロファイラ機能の様子がデモプレイされました。

書籍展示の様子

会場すぐ横のセミナールームには、登壇いただいた3名が執筆された書籍を含む、ボーンデジタル様出版の書籍が多数展示されました。来場者以外にもDeNA社員が自由に閲覧可能になっており、多くの人が手に取っている様子が見られました。

懇親会の様子

盛り上がった懇親会では、セッション中にはできなかった登壇者との質疑応答や名刺交換、来場者同士で現職の情報交換や悩みを相談するなど、交流も盛んに行われていました。

季節のデザート

今回の特選デザートは、予約殺到の専門店(受け取りのために当日スタッフが奔走しました!)の[su_highlight background=”#fcff99″]バスク風チーズケーキ(通称バスチー)[/su_highlight]をご用意。某コンビニチェーンでも話題となっているようで、どっぷりとした濃厚で新食感のチーズケーキは大人気でした。次回のデザートもお楽しみに!

 

取材・文・撮影:細谷亮介

[su_note note_color=”#ffffff” radius=”10″]

GeNOM(ゲノム)とは

DeNAのゲームクリエイターを様々な切り口で紹介するメディア(運営:株式会社ディー・エヌ・エー)です。ゲーム開発の現場で生まれる様々なエピソードや、クリエイター紹介、イベント紹介などを通して、DeNAで働くメンバーの”ありのまま”をお伝えしていきます。

GeNOMの最新情報は、公式Twitterアカウントにて確認いただけます。ぜひフォローをお願いします!

[/su_note]