【イベントレポ】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もそれに合わせて再設計されていることなどが説明され、本勉強会は終了しました。

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

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

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

【GDMゆく年くる年】多彩なクリエイター登壇で盛況だった勉強会も2020年はさらに進化!? 今年の締めくくりインタビュー実施

DeNAが主催する、ゲームクリエイター向け勉強会「Game Developers Meeting(GDM)」。自社他社問わず、多数のエンジニアやデザイナー、ディレクターなどが登壇し、最新のゲーム開発における技術や情報を、勉強会や座談会という形でお届けしています。

12月20日(金)には、2019年最後の回となる「GDM Vo.39エンジニア勉強会」が無事終了しました。そこで今年の振り返りとして、運営メンバーであるDeNAの藤村幹雄と髙橋彩に、実施して良かった点、運営上で苦労した点、登壇者や来場者から頂いた意見・要望などを聞いてみました。

2019年のGDM運営を振り返って

――まずはじめに2019年を振り返って、GDM運営で苦労した点と良かった点、気付いた点などを教えてください。

藤村イベント運営というのは、思ったより大変なのが正直な感想です(笑)。毎月開催ということもあり、GDMの主役であるご登壇いただいた皆さま、告知掲載など協力いただいたWEBメディアの皆さま、運営に協力してくれたスタッフに感謝です!

藤村幹雄
GDM運営チームのBOSS。公私ともにさまざまなゲームクリエイター、関係者と繋がりが深く、ゲーム業界での幅広い人脈を生かして登壇者を次々とアサイン。会場では司会進行や懇親会での積極的な交流も欠かさない。この人がいないとGDMは成り立たないほどのキーパーソン。出張先のうまいものと獺祭とラーメン大好き。

髙橋皆さまありがとうございます! もちろん当たり前ではありますが、毎月しっかりと開催が実現できたことは良かったと思っています。藤村さんの尽力もあって、さまざまな会社のクリエイターさんが登壇してくれました。

また、イベント管理サービス「Peatix」のGDMページに対するフォロワーさんが、約1年で1,000人以上増えたことも、とても嬉しい出来事ですね。

GDMの準備などのロジ周りに関しては、組織開発部のメンバーが交代で担当していますが、彼らのホスピタリティが本当に高くて、常に次を考えて動いてくれるので、進行もスムーズでとても助かっています。

髙橋彩
GDM運営リーダーおよびケータリング&デザート特別顧問。イベントに関連する準備や当日のロジ周りなど、事前の細かい調整をほぼ一人でこなす。Peatixの手続きや資料作成だけでなく、現場では常に動き回りイベントを円滑に進める、まさに縁の下の力持ち(裏番長)。ボードゲームでは類まれなる強運を持つ。

――運営する上で特に大変だったこと、工夫した点はなんですか?

藤村先にも述べましたがやはり、毎月開催という継続性ですね。他社のイベント主催者と交流した際に、皆さん継続開催の難しさを悩まれているといった声を良く耳にしました。

登壇者を含め、運営にご協力いただく方にもメリットがある内容にするため、日々悩みながら企画設計しています。また、社内の調整もまあまあ大変でした……(笑)。

髙橋:[su_highlight background=”#fcff9″]「DeNAのゲーム開発の本気さ」[/su_highlight]やGDM自体の認知度を広めることを目的として、これまでゲームイベントや技術者向けカンファレンスでブース出展をしていましたが、他の都市に遠征したときは設営も含めて、苦労したのを覚えています。

また、GDMを知らない人にも興味を持ってもらえるように、自社のオウンドメディアに案内ページやイベントレポートを掲載したり、目を引くような面白いノベルティグッズを企画して配布するなど、試行錯誤の日々でしたね。

GDMだけでなく「Unite Tokyo 2019」や「CEDEC 2019」など技術者向けカンファレンスの会場でも、ノベルティキャンペーンを実施。トートバッグや文庫型メモ帳などがオリジナルグッズが配布されました。

――主催、運営する上で嬉しかったこと、開催して良かった、やりがいを感じる点はどのようなところですか?

藤村立ち上げ当初は、GDMが業界内に認知されておらず、苦労も多かったですが、継続開催することで認知度が上がったタイミング、これまで参加されていない方々が初参加され、充実した時間を過ごされているのを見ると喜びを感じました。

また、社外の懇親会などで、GDMのことを知っていてくださり、会話の話題になるのも嬉しいですね。

勉強会後に実施される懇親会では、軽食を取りながら登壇者と直接交流できる場が用意され、多くのクリエイターが名刺交換をしながら毎回盛り上がっています。

髙橋イベント運営の裏方って、思ったより力仕事が多くて大変なんですが、実施後のアンケートで満足度が高い回答を読んだり、懇親会で登壇者と参加者が盛り上がって楽しんでいるのを見ると、それまでの疲れが吹っ飛びますね!

秋頃から実施しているSNSキャンペーンでは、勉強会や会場の様子を拡散してくれた方にノベルティグッズを進呈していますが、実際に使ってくれていたり、選ぶのを悩んでいるのを見ると、けっこう嬉しいんですよ。

――登壇者からイベント後にどのような意見、フィードバックを受けましたか?

藤村GDM立ち上げの大きな目的であった、ゲームクリエイターの[su_highlight background=”#fcff9″]「見たい、知りたい、会いたい」[/su_highlight]が実現できる場をつくることができたこともあり、職種によっては座談会など開催する場所やコミュニティも少なく、このようなイベントはありがたい、と言われることが増えました。

髙橋それはとっても嬉しいですよね。登壇していただいたクリエイターさんから「ぜひ第二弾を開催したいです」と言ってもらったり、持ち込み企画を提案してくれるクリエイターさんもいました。

――特に藤村さんは親交が深いクリエイターも多いので、いろいろな方面から意見や感想を聞いたのでは?

藤村確かにそうかもしれません。知り合いのクリエイターさんから再登壇の相談を受けたり、ゲーム業界で取り上げるべきテーマの打診などをいただけるのは、非常にありがたいですね。最近では「運営大変だと思いますが、ぜひ継続開催してください! 」とお願いされています。

――来場者や社内の人間からはどのような意見、感想がありましたか?

藤村GDMというイベントの名前は知っているけど、まだ参加したことはない方が、実際に行ってみたら学びも多く、同じ職種や課題を抱えたクリエイターと交流して「参加してとても良かった! 」「次回は同僚や知り合いも誘ってみます! 」と喜んでくれたのは、本当に嬉しかったですね。

回を重ねるごとに、少しずつ来場者は増加し、それに合わせて会場(セミナールームを合体させてます!)もだんだんと広くなっていきました。

――来場者からの実施後アンケートでは、どのような意見や要望がありましたか?

藤村ゲーム開発に携わっている方が多いので、これからのゲーム業界で必要になる技術や動向に関心が高い傾向がありますね。今後取り上げて欲しいテーマなど要望については、アンケートを随時参考にさせていただいています。ご意見を読みながら、私自身も勉強になることも多いです。

髙橋アンケートには、勉強会について「とても面白かった」「質疑応答の時間がもっと欲しい」など、率直なご意見やご感想をたくさん記入していただいています。すべて運営チームで目を通して、今後に活かしていきたいと思っていますので、ご期待ください。

――ちなみにGDMで提供されるフードやデザートもかなり凝っていますよね。これはどのように企画し、実現しているんですか?

藤村ここは髙橋さんの出番ですね!

髙橋はい! ケータリングなど軽食については、勉強会後の懇親会で食事をきっかけに話が盛り上がったり、華やかな見た目が会話のネタになって、より仲良くなってくれればいいな、と想像しながら企画しています。特にお寿司はGDMの定番なんですよ。

デザートは季節感を大切にしながら、流行りのスポットや話題の商品を雑誌やネットなどでチェックして決めています。会社が入っている渋谷ヒカリエのB2Fは、しょっちゅうパトロールしてるんです(笑)。渋谷スクランブルスクエアもオープンしたばかりなので、お店を回るのが大変です。

また、選ぶときの自分なりの鉄則は「私が食べてみたい! 」と感じたデザートを購入することです。自信を持って用意していますし、美味しそうに見えるようなデコレーションも、季節ごとに毎回工夫しているので、ぜひ注目してみてください!

登場したデザートの数々。実は男性の参加者にもかなり人気で、あっという間に完食状態!甘いものは別腹?

――来年のGDM運営について、それぞれが描く来年の抱負を教えてください。

藤村イベント開催に際して多くの方々の協力があり、ここまで継続できたことに本当に感謝しております。2020年からの新たな取り組みも検討していますので、楽しみに続報をお待ち下さい!

髙橋ご参加いただいている皆さまは、本当に勉強熱心で素敵な人が多いです。これまでさまざまなイベントに携わってきましたが、GDMは登壇者や参加者と距離が近いイベントなので、私にとってはHOMEのように大切に思っています。

来年も登壇者や参加者の皆さんに「また登壇したい」「参加したい」と思えるように、今後もより良いイベントにしていきたいと思っています。また、会場でお会いできるのを楽しみにしています。

――GDMは2020年も盛り上がりそうですね。ありがとうございました!

DeNAのモバイルゲーム開発のリアルな姿を世の中に伝え、クリエイター同士がカジュアルに交流できる場をつくる目的を掲げ、運営がスタートしたGDM。

社内の人間だけでなく、社外の多くのクリエイターが登壇してバリエーション豊かな勉強会が実施され、クリエイターが感じる「見たい、知りたい、会いたい」といったテーマを体現し始めています。

1年以上に渡り、運営側も手慣れてきており高いホスピタリティを発揮できています。勉強会の内容はもちろん、懇親会での積極的でとても盛り上がっているコミュニティに、ぜひ参加してはいかがでしょうか?

これまでのGDM関連記事をイッキ見!

過去にGeNOMに掲載された、GDM関連の記事リンクを時系列でババッと紹介!登壇資料を公開している勉強会もあるので、ぜひご参考ください。

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

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

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

【イベントレポ】GDM会場で開発者向け書籍を展示! 著者であるゲームクリエイター3名が関連ショートセッションを実施

【イベントレポ(前半)】GDMテクニカルアーティスト座談会~やってみる、から一歩先へ~

【イベントレポ(後半)】GDMテクニカルアーティスト座談会~やってみる、から一歩先へ~

【イベントレポ&インタビュー】GDMエンジニア向け勉強会Vol.34~今だからこそ「Unreal Engine」を学ぼう (初級編)~

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

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

【GDMイベントレポ】ゲーム要素のコントロールと感情の対応関係とは?「2次元感情マップに基づくメタAI:里井大輝氏」

【GDMイベントレポ】実際にメタAIをデザインするには?「メタAIの汎用モデルとゲームデザイナー&エンジニアの役割:水野勇太氏」

【GDMイベントレポ】表現豊かなNPCを実装したデモ映像公開!「キャラクターとのインタラクション:ボエダ ゴティエ氏」

【GDMイベントレポ】スクウェア・エニックス テクノロジー推進部メンバーが明かす、ゲームAI研究開発の最前線―三宅陽一郎氏からのイントロダクション

【イベントレポ】クーガー石井氏が語るゲーム×AI×ブロックチェーンの可能性―未来のキーワードは「マシンインターネット」と「ミラーワールド」

【イベントレポ】サウンドディレクションの在り方を変えるのは今! 座談会で語られたゲーム開発チームでの真の役割とは

【イベントレポ】GDM ローカライズ勉強会Vol.1 ~多種多様なゲームタイトルに対応する為のローカライゼーションとは?~

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

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

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

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

毎回様々なゲストをお招きして、最新の技術や情報をシェアする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 ~コミュニティファーストなプロダクト運営~

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

DeNA主催のゲームクリエイター向け勉強会の【Game Developers Meeting】では、毎月さまざまな職種のゲストを招いて、ゲームクリエイター向けに勉強会や座談会が繰り広げられています。

去る2019年11月29日(金)に開催された「GDM Vol.38」では、ディレクター向けの座談会が実施されました。GeNOM編集部では登壇者に事前インタビューを行う機会を得たので、その内容をお届けします。

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

◆参加者紹介

株式会社セガ・インタラクティブ
松永純氏

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

株式会社カプコン
山田倫之氏

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

株式会社ディー・エヌ・エー
佐伯嶺

コーエーテクモゲームスを経て、2013年中途入社。『FINAL FANTASY Record Keeper』開発から携わり、運営開始後はディレクターを担当。現在はDeNAのゲーム事業部の企画を統括する部門で副部長を担当。
[/su_note]

ディレクターの担うべき領域

今回のインタビューでは、セガ・インタラクティブの松永純氏とカプコンの山田倫之氏に、「GDM Vol.38 ディレクター向け座談会」のテーマを深堀りつつ、GDM本番とは少し違った視点で、ディレクターとしてゲーム開発に携わりながら感じる思いや苦悩、これからのディレクターの在り方などを伺いました。聞き手はイベント本番でモデレーターを務めた、DeNA佐伯嶺です。

終始盛り上がったインタビューでは、DeNA佐伯(写真右)が聞き手となり、
松永氏(写真左)と山田氏(写真中央)が快く質問に答えてくれました。

佐伯嶺(以下、佐伯:それではまず最初に、先日の事前MTG(と言う名の飲み会?)での振り返りをしながら話していきましょう!

山田倫之氏(以下、山田氏:最初は「そもそもディレクターって、どんな立ち位置なんだろう?」というクエスチョンから始まりました。各社・各開発チーム内でもそれぞれ立場が違うため、ディレクターがどんな役割を持っているのか、まずはお互いの認識のすり合わせをしましたね。

松永純氏(以下、松永氏:そうそう。その中で特に楽しかったのは「社内外の垣根を超えたドリームチームを作ろう!」といった話題でした。

佐伯:その話は盛り上がりましたね!

松永氏:ですよね! 現在のゲーム市場の課題なども含めて、最終的にどうすれば自分たちが一番面白いゲームを作れるのかを考えたときに「まずは垣根を超えていこう!」といった話で共感できたのは、非常に嬉しかったですね。

佐伯:未来に向けて、会社の枠組みや垣根も超えたチームで、ゲームを作れたら楽しいですよね。ちなみにゲームを作ること、そして売ることについて、ディレクターとプロデューサーの役割の違いはどのように感じていますか?

松永氏:本質的には同じだと感じています。ゲームはエンタメなので、基本的に面白くなければ売れないですし、その面白さをしっかり設計するのがディレクターで、そのゲームがどうすれば世の中に広まるのかを考えるのがプロデューサーだと思っています。

ただ、昨今ではディレクターのやるべき領域は広がってきており、面白さを伝えることもディレクターの仕事になりつつあるので、昔よりもハッキリとした区別はしづらくなっています。

山田氏:その部分は自分も感じています。「開発チームをまとめるのがディレクター」「ゲーム情報を外部に発信するのがプロデューサー」と役割は区別されていて、本来進むべき方向は違うのですが、[su_highlight background=”#fcff99″]「面白いゲームを作り、プレイヤーに楽しんでもらうこと」[/su_highlight]を大目的として、時代に合わせて両方の目線がどちらの職種にも必要となっているのは、確かだと思います。

佐伯:現在のスマートフォンゲームは、アプリのバージョンアップやアップデートが頻繁に行われますし、作りながら売ることを考えるといった、開発と運営のどちらの知識も必要とされているため、ゲームディレクションの難易度は高くなっていますよね。

松永氏:ええ、担当領域も広くなり、複雑になってきています。

佐伯:そうなると、昔ながらの職人気質なディレクターのように「自分の方針を曲げず、領域だけ守る」スタイルでは、壁にぶつかることも多いと思います。

山田氏:もちろん、そのような思想の人もいまだに現場には多いですし、必要ではあります。ディレクターが中心となって稼働しているプロジェクトでは、実はサポートに強いアシスタントディレクターのような人が側にいることが多いんですよ。

松永氏:そういえば確かに! スケジュール管理やチームをバランス良くまとめる存在は大事ですよね。

佐伯:なるほど。小さなチームで作るプロジェクトでは、ディレクターが「俺が全部やる!」みたいにリーダーシップを発揮していましたが、大規模開発のタイトルが多くなった最近では、ディレクターの得意領域以外の部分は、他の人に任せる運用が増えているということですね。

山田氏:さすがに100人を超える規模の開発チームでは、一人のディレクターにかかる負荷が重くなるので、やるべきことを細分化し、それを信頼できるリーダークラスに任せるのがベターだと思いますよ。

ゲームづくりの面白さを感じる瞬間

佐伯:このあとの本番でもテーマに上がる予定ですが、お二人がゲームを作っていて面白い、ディレクターやってて良かった、と感じるのはどんなときですか?

松永氏:プランニング時のかなり手前の段階にはなりますが、一番良い企画を立てられた瞬間や、全体の設計がまとまったときが、個人的に一番気持ち良いですね。

セガ・インタラクティブ 松永純氏

佐伯:ちなみに、最初に考えた企画をほぼ変えずに、ゲームを作り続けることって可能ですか?

松永氏:ええ、そのまま作り上げるのがディレクターの仕事ですからね。とは言っても開発しながら仕様もシステムも、ガラッと変わってしまうことも良くあります……(笑)。

山田氏:確かに当初の企画通りに作り続けるのは大変ですよね。私は企画を立ち上げて形になり始めて、完成版が見えてきたと判断できる状態を見たとき、ディレクターとして充実した気持ちになります。もちろん、リリース後にプレイヤーさんに「面白かった!」と言ってもらえることも嬉しいですよ。

佐伯:やっぱり作る過程は楽しいですよね。最近のゲーム開発では、売ることを考えつつ、要件に合わせて作ることはかなり難しくなっていますが、その中で自分なりのカラーを表現したり、作りたいものにこだわるための苦労はどんな部分ですか?

山田氏:すべてをバランス良く、納得できる落とし所を見極めるのは、今でも苦労しています。期限を守って中途半端なタイトルをリリースして失敗するより、納期を延ばしてでも、さらにクオリティの高い作品を作りたい信念を、プロデューサーや役員クラスのメンバーに進言することも重要です。

ただ、ディレクターはアーティストではないため、会社に求められているクオリティに対して、一部分が100点満点で、もう一方が50点という結果では説得力がありません。どちらも平均で80点を目指すような、バランス調整は必要だと思いますね。私は比較的バランス型だと思いますよ。

佐伯:特化して一点突破するよりは、バランスを意識しながら取り組むことも考慮しているんですね。

山田氏:そうですね。一方でカプコンには、クオリティを超重視して「絶対に実現したいから、予算と期間を確保して欲しい!」とプロデューサーと熱く議論しているディレクターもいますよ。

そういえば松永さんは現在、会社の役職も兼任してるので、自身の中でジレンマを抱えているように見えますけど……(笑)。

松永氏:そうそう、最近バランスが取れなくて……役職辞めたいな……って(泣)。

山田氏:どうしてもクリエイター側の気持ちが強くなってしまうと(笑)。

松永氏:それもありますし、逆に我慢している自分に気づくことが多くて。チームアップに関しても、自分の思い通りにしようと思えば可能ではありますが、他の運営タイトルに気を使っていると、自分のワガママさが消えていることに気付いてしまい、なんだか複雑な気持ちになったんです……(泣)。

山田氏:やはり部長という肩書のせいで、本人が気軽に発言したことがメンバーには「部長が指示、命令している」ように伝わってしまうのかもしれないですね。

佐伯:部長から「マネージメントされている」ような印象も受けるんでしょうかね。

松永氏:そうかもしれないですね。最近では、役職関係なく気を使わずにコミュニケーションを取ってくれるメンバーと開発することがとても心地いいな、と感じています。

佐伯:リーダーとしてのディレクター、クリエイターとしてのディレクター、と両方の立場を重視しながら、バランスを取るのは難しい局面も多いようですね。

アイデアを共有するまでは孤独?

佐伯:これも本番時にも聞いてみたいのですが、会社の中でディレクターとして孤独を感じるときはありますか?

山田氏:ディレクターだけでなく、プロデューサーも少なからず孤独な部分を持っていると思いますよ。決めることに関しても大勢から意見を聞きつつ、最終的にディレクターが決断するときには、結構勇気が必要です。

残念ながら、チーム全員の意見が完全一致することは少ないので、一人で決めなければならない場面では、孤独を感じるのかもしれません。

カプコン 山田倫之氏

松永氏:ディレクターは開発中でも少し先のことを考えるべきであり、その時点では、自分の頭の中でまとまったイメージは自分だけしか持っていないので、周囲にそれを共有できるまでは、確かに孤独です。完成しても、そのあとの運営でまた、先の計画を考え続けるときに孤独を感じたり。

山田氏:確固たるアイデアを持っているのは、その時点では本人しかいないので、それを共有して賛同してもらう作業を繰り返して、チームの足並みを揃えるまでが大切ですね。

松永氏:そうですよね。自分の中に企画やアイデアがあるだけでは、プロジェクトは成り立たないので、それを関わるメンバーに説明、共有して進行方向が本格的に決まったときが「俺、孤独じゃないんだ!」と安堵できる瞬間と言えるかも知れません。

佐伯:時期によっては「お、今はディレクターが抱えているな!」って周囲が感じるときがありますからね。

山田氏:先ほど松永さんも話していたように、常に半歩先を見ながら、自分だけが持っている情報を整理しつつ、うまく共有してチームをコントロールしていきたいですね。

松永氏:セガの昔ながらの開発現場では、作りながら考えていくカルチャーがあって、企画書もかなり簡潔で、ディレクター自身にもゴールが見えていないことが多かったです。そんな状況だと逆に、実際に現場のメンバーと話し、一緒に悩みながら作り上げていくので、作る楽しさが強い側面がありました。

でも最近では、確固たる完成形をディレクターが持ち、それを随時共有しながら作っていく開発スタイルが多く、ディレクターが必ずボールを持たなくてはならない現場が、大変だとは思いますね。

佐伯:メンバーからスーパーマンのように、すべてを要求されるのはキツイですよ……(笑)。

山田氏:まあそうは言っても、過去の現場では自分たちがディレクターに同じようなことを求めてましたし……(笑)。その立場になってはじめて気付くことも多いですよね。

佐伯:自分もディレクターになったときには「こんなに仲間っていないんだ……想像していたのと違うぞ……」って落胆したときもありました。

松永氏:そんな孤独な時期に、プロデューサーが側にいると、対等に話せて助かることもありますね。

山田氏:ええ、一歩先の話を誰かと共有できることは嬉しいですね。

求められる能力や視座

佐伯:昔のプロデューサーとディレクターの関係性に比べて、最近ではお互いが違う立ち位置が増えてきたため、その部分も孤独感に繋がっているんですかね?

松永氏:もしかしたら分業感が増しているためかもしれません。昔のプロジェクトではプロデューサーとディレクターが1人ずつのチームがメインだったのですが、最近ではプロデューサーだけでなく、ディレクターやPMも複数人が配属されていることが多いです。

同じ役割を持つメンバーが複数になると、必ず真ん中にしっかりと旗を振る人が必要なので、そこで孤独を感じる可能性はありますよね。

佐伯:そういえば昔の開発現場には、PM(プロジェクトマネージャー)って存在していませんでしたよね。私はDeNAに転職してきたときに初めてPMを知ったんですよ。そういった専門性を持つ職種も増えてきましたね。

山田氏:数人で作るチームなら、一人ひとりのスケジュールを確認する必要もないですが、大規模開発では、全体の見方や管理方法も変わってきて、どうしても細部まで見れなくなります。そうなると同じディレクターでも、視点や求められている能力も全く変わってきてしまいますね。

佐伯:本当にそうですね。コンシューマとモバイル、開発の規模感によっても全く違いますからね。育成に関しても、単純に「ディレクターを目指そう」ではなく、過去の経験や将来的なキャリアを描いていくことが重要になりそうです。弊害としては、社内で似たようなディレクターがいなくなることですかね。

松永氏:本当にいないですね~(笑)。プランナーからディレクターに、プログラマーからディレクターになるといった、その人自身がこれまで辿ってきたキャリアによっても違いますし。

ですので目指す道としては[su_highlight background=”#fcff99″]「あの人のようなディレクターを目指すべき」[/su_highlight]と示したほうがわかりやすいのかも知れませんね。

佐伯:それこそ冒頭で話した「垣根を超えるドリームチーム」のように、社内での自分に合うロールに対する疑問や、社外で同じように孤独を感じているディレクターについて、もっと情報交換ができればいいなと思いますね。

山田氏:できれば、そんな取り組みをゲーム業界全体で実現したいですね。

松永氏:本当にそれは大賛成です。クリエイターには、絶対的にその人に合った作り方って存在しますから。ちなみにうちでディレクター報告会とかをすると、どれだけフォーマットを作っても、報告の仕方がバラバラになります(笑)。

そもそもプロジェクトで大切にしていることも違いますし、進め方も違うので、報告内容も変わるのは当然ですよね。でもそれに対して無理に合わせることもなく、それぞれが違うことはむしろ面白いことだと思っています。

山田氏:プロデューサーの場合、予算や売上の報告をする相手は、マネージャークラスの人でもあり、どうしてもその話が中心になりますが、ディレクターは担当タイトルのどの部分の開発が進んでいるのか、というゲーム内部の話になってしまうので、報告の仕方は当然変わりますよね。

佐伯:そのあたりの違いもあって「あの人は果たしてイケてるプロデューサー・ディレクターなのか?」という判断をするのも難しくなっています。前任ではうまく立ち回っていたのに、新規タイトルで失敗してしまったり、マネージメントをする立場での判断も、ディレクターの難易度は上がっている気がします。

山田氏:最近ではディレクターが単独でなんとかできる時代ではないですから。プロデューサーやPM、リーダークラスとの密接なチームワークが大切になっているのではないでしょうか。

『チェインクロニクル』書籍出版の経緯

佐伯:またまた少し話題を変えて。松永さんは書籍「チェインクロニクルから学ぶスマートフォンRPGのつくり方」を執筆していますが、手がけた経緯を教えてもらえますか?

松永氏:書籍に関しては『チェインクロニクル』リリースからしばらくしてすぐ、執筆して欲しいと依頼があり、そこから約5年間も引っ張ってからの出版となってしまいました(笑)。初期の段階だと、話せないことも多くて……。

ただ運営を長く続けていく中、自社でシステムを流用した他のタイトルがリリースされたこともあり、今さら秘密にすることも少ないだろうと、その技術を若い方たちに共有したいと考えて、CEDECでのセッションで発表しつつ、情報を書籍でまとめて出版することになったんです。

山田氏:ディレクターが実際の業務について外部に話してくれることは、とてもありがたいですよ。

佐伯:そうですよね。ちなみに松永さんの書籍は部下やメンバーに「読んでみて」と伝えてないんですか?

松永氏:いや、恥ずかしいのであまり言ってないです(笑)。社内外で買ってくれた方からは声をかけていただきました。チョット提案なんですけど、もし良ければ、他社のゲームディレクターもひとつのタイトルを作りきったら、一冊このような本を書いてくれないですかね(笑)。

山田氏:そうそう! そういう流れができたら楽しいですよね。

松永氏:「分かる分かる! そこって実際大変だよね」といった、ディレクターあるあるや、悩んだり、孤独な部分を共感してほしいんです。

この本を執筆するときに、当初ロジックやメカニクスが中心のネタを考えていたんですが、それだけでは説明しきれなくて、生々しい出来事も書いてみたら、意外と反響が大きくて良かったと思っています。

佐伯:このような本がどんどん出版されれば、もっと体系化されて、ゲーム業界全体が引き上がっていくと思いますよ。

松永氏:自分も同じ意見ですね。プランナーに関する書籍は少しずつ増えているのですが、ディレクション領域に関しての書籍はほとんど販売されていないので、もう少し他のディレクターの経験論が外部に発表されると嬉しいですよね。

山田氏:本当にそう思います。世の中には多種多様なゲームディレクターがいるので、未知のディレクション手法を知ることもできますし。

佐伯:実はディレクター同士の飲み会の席でも、あまり仕事について話さないんですよね(笑)。外部メディアでは、プロデューサーのインタビューは多いんですけど、ディレクターは少なくて……。

山田氏:その原因は、ディレクターは「これが正解だ!」と思って仕事してるので、他の人から見て変わっていると気付かないからではないでしょうか(笑)。

進化する技術に合わせた遊び方を追求

佐伯:お二人とも、コンシューマ開発の経験も豊富だと思いますが、コンシューマとモバイルのゲーム開発の違いに関して思うことはありますか?

山田氏:現在ではコンシューマでもパッチやDLCなど、オンライン接続が必須なコンテンツも増えています。また、端末の性能が上がり、モバイル向けでも高クオリティのゲームが増えているので、近い将来のゲームの姿は「プラットフォームが違うだけ」のスタイルになっていくのではないでしょうか。

佐伯:確かにモバイルゲームも、以前はスピーディーに開発できたのに、現在ではコンシューマと変わらないくらいの開発規模で時間やコストも膨大になってきていますよね。

山田氏:ええ。タイトルの供給が増えれば、当然プレイヤーの目も肥え、ただポチポチするだけのゲームに飽きてくるため、求められているクオリティはどんどん上がっています。

松永氏:そうやって徐々に開発コストが膨らんでいく中で「何を本当に表現したいのか、何をプレイヤーに届けたいのか」といった絶対に揺らいではいけない部分も、当然変わってきていると考えられますね。

山田氏:その状況で「ハードの性能に合わせてグラフィックが良い」だけのゲームに留まらず、ユニークなアイデア勝負のゲームが生まれてきたりと、進化の方向は決してひとつではないと感じます。

佐伯:本当にそう思います。それでは最後に、今後作ってみたいゲームはどんなものか教えてください。

山田氏:私はじっくりと頭を使うゲームを作りたいですね。

松永氏:私はやっぱりRPGかな。今後もゲームの形が似通って、プラットフォームの区別なく混在していく中でも、一番楽しい遊び方を追求していきたいですね。

山田氏:スマホって普段ずっと持ち歩いている身近なデバイスなので、生活の一部に溶け込むようなRPGとか面白そうですね。

佐伯:最近ではスマホの特徴を生かしたタイトルも出てきていますよね。過去に私は、主人公が自分の体調と連動していて、血圧や血糖値を図りつつ、太っているとデバフがかかるような企画を考えたこともありましたね(ボツになりましたが)。

松永氏:それはなかなかユニークですね! その時代の技術に合わせて作れるゲーム開発はやはり面白いですよ。いつまでも飽きないですしね。

山田氏:技術もどんどん進化していくので、ゲーム開発の将来がとても楽しみですね。

佐伯:ありがとうございました。それでは本番に向かいましょう!

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

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

【イベントレポ】「ゲーム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佐藤。同業種の人との情報交換や、普段なかなか話せない業務上の悩みなどを話せた人も多かったのではないでしょうか。

季節のデザート

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

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

【イベントレポ】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]

【イベントレポ(前半)】GDMテクニカルアーティスト座談会~やってみる、から一歩先へ~

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

2019年8月6日(火)に開催された「テクニカルアーティスト座談会~やってみる、から一歩先へ~」では、4社のゲーム会社からテクニカルアーティスト(以下、TA)が集合し、各社の業務内容についての相互理解を中心に、今後TAが活躍するための足がかりとなるような情報共有がされました。

[su_note note_color=”#ffffff”]

テクニカルアーティストとは(CGWorld Entry.jpより引用)

[su_quote]TAと略す。会社によってはテクニカルディレクターと呼ぶ場合もある。テクニカル(技術)関連の仕事を担うプログラマやエンジニアと、アート(芸術)関連の仕事を担うアーティストとの橋渡しを担当する役割のこと。

プログラマやエンジニアの思考と、アーティストの思考の違いを理解し、両者が抱える問題を解決するための方法を提案する。機械的な作業を自動化・効率化するためのツールを開発することもある。

また、シェーダの設定、リギング、シミュレーション、エフェクト制作など、テクニカルに対する理解が必要とされる工程を担当する場合もある。[/su_quote]

[/su_note]

本記事では、イベント前半に実施されたパネルディスカッションの内容を一部抜粋してお届けします。

[su_note note_color=”#ffffff”]

■登壇者(敬称略)

塩尻 英樹(しおじり ひでき)
株式会社カプコン
技術研究開発部 技術開発室 DCCサポートチーム マネージャー兼チーム長

沼上 広志(ぬまかみ ひろし)
株式会社バンダイナムコスタジオ
技術開発統括本部 技術本部 コアテクノロジ部 コアテクノロジ2課

麓 一博(ふもと かづひろ)
株式会社セガゲームス
第3事業部 第3開発2部 テクニカルサポートセクション セクションマネージャー

今津 隆之(いまづ たかゆき)
株式会社ディー・エヌ・エー
ゲーム事業部 Develop統括部 デザイン部 テクニカルアーティストグループ マネージャー
[/su_note]

開発現場におけるTAの大切さとは

TAスキルについて

前半のパネルディスカッションでは、2019年3月に大阪府立国際会議場で開催された「GAME CREATORS CONFERENCE ’19(GCC2019)」で取り扱われた、TAに必要なスキルをテーマに、事前に4名それぞれが得意不得意な部分を「○・△・×」の3段階で評価し、議論を開始しました。

[su_note note_color=”#ffffff”]

◆TAに必要なスキル
・C#やPythonなど業務に必要な各言語でのプログラム技術、及びShader関連知識
・絵が描ける、パースが取れる、色彩の説明ができるなどアートスキル
・ゲームエンジンのフロー知識と、DCCからの出力フロー知識(描画フロー把握、用語知識など)
・ゲームハードに関しての基本知識(ハードスペック、描画性能など)
・VMやNASなどのストレージやライセンスサーバ関連、SubversionやPerforceなどサーバ知識技能
・Windows、MacOS、Linux、iOS、Androidなど色々なOSへの造詣
・Mayaや3DS MAX、Houdiniといったメジャーな3DDCCツールの知識
・PhotoshopやSubstance、ZBrushや3D-coatといったさまざまなツール知識
・過去のツールやゲームハードに関してのさまざまな知識
・Havok、Simplygon、SpeedTreeやumbraなどさまざまなミドルウェア製品知識
・MotionCapture関連での作業フローの理解と、VICONや各社ツールの知識
・画角やEV値やルーメン、カンデラといった単語が理解できるくらいの照明技術やカメラ映像知識
・SiggraphやCEDECなどでのさまざまな新規技能を能動的に取得できる知識欲
・交渉力、説得力、判断力などのコミュニケーションスキル
・技術的な仕組みをわかりやすくまとめ、説明できるプレゼン力
・アニメーション作成作業とリギングやJoint構造構築、それに関連する各種作業、またリターゲットやブレンディングなどの技術知識
・ユーザーインターフェースにおける作成手順とその技能、WindowsやAppleなどに代表されるユーザーエクスペリエンスの理解
[/su_note]

麓一博氏(以下、麓氏:それでは、各々の得意不得意な分野に関して、みんなで話し合って行きたいと思います。

株式会社セガゲームス 麓一博氏

沼上広志氏(以下、沼上氏:自分はもともとエンジニアとして入社しているので、プログラム技術に関して知識はありますが、正直に言うとプロジェクトのゲームプログラマーに比べたら、遥かにできないと思っています。TAの中では、プログラミングに関してやや得意なレベルですね。

ほとんど理解していないスキルに関しては、得意な人を探して説明を聞いたり、それでも難解なときはその人を連れて行って問題を解決する、という動きが最近は多いですね。

自分にも強み弱みはありますし、アーティストが悩んでいることを解決できる人を連れて行く、そこで伝達しづらいことをプログラマーに対して噛み砕いて教える「通訳」のような役割をTAは担っています。

また、プログラマーが欲しいデータについて、アーティストが作れるデータからプログラマーに渡す形式にできる環境を作るといった、手段に対しての通訳に相当する仕事もしています。

株式会社バンダイナムコスタジオ 沼上広志氏

塩尻英樹氏(以下、塩尻氏:沼上さんが話していたことについて、カプコンでも同じような事象が多く、TAが仲介役をしていることが多いですね。

またTAは、技術的な問題に対して自分で解決しようとする人も多いのですが、僕らの仕事は解決することが目的であり、「解決力」が重要だと考えています。所持スキルの回答を見ていておもしろいのは、全員「コミュニケーションスキル」と「プレゼン力」が○になっているところですね。

株式会社カプコン 塩尻英樹氏

沼上氏:言い換えると、図々しいってことですかね(笑)。ここが×だと、自分たちはいったい社内で何をやってるの?って言われてしまいます……。

今津隆之(以下、今津:自分はグラフィックデザイナーからスタートし、その後モーションデザイナーをしていたため、「MotionCapture関連での作業フローの理解と、VICONや各社ツールの知識」と「アニメーション作成作業とリギングやJoint構造構築、それに関連する各種作業、またリターゲットやブレンディングなどの技術知識」を得意と回答しました。

モーションデザイナーからTAへは、実はひとつの道が存在するような気がしています。モーションデザイナーはデザイナーでありながら、頭の中ではシステマチックな考え方を持っており、作る上で計算式を入れ込み、コードを書いたり、Exporterを作ったり、自分でツールを作って効率化することが楽しくなる傾向があります。

DeNAのTAグループは2019年4月に発足したばかりなので、実績が少ない現在はまず足場を固めるフェーズとなっています。

【DeNAデザイン部特集Vol.1】事業に資するクリエイティブ集団が見据える未来、そして求められる役割とは

株式会社ディー・エヌ・エー 今津隆之

麓氏:セガゲームスでも、TAとなった最初の人たちは、モーションデザイナーやリガーが多いかもしれません。モーションに強い人はロジカルな考え方もできるし、リグを組むにも、そもそも数学的知識も必要となってきますよね。

塩尻氏:確かにそうですね。カプコンでもスクリプトなどを組めるモーションデザイナーは多いですね。

沼上氏:たぶん、やらざるを得なくて、という状況の人も多いと思います。リグやアニメーター周りを手がける人は多いのですが、必要に応じて作業しているため、結果的にそのような人をTAと呼んでもいいのかもしれません。

麓氏:自分の回答については、TAのキャリアに紐付いていると考えています。TAのような仕事を始めた当初は、描画ライブラリのサポートだったんですけど、そこからシェーダーの勉強を始め、その後セッションに登壇しました。

それから、シェーダーとスクリプトが似てると感じ、モーションやリグについて勉強を始めたのはだいぶ後になります。

今津:そういえばみなさん「過去のツールやゲームハードに関してのさまざまな知識」について、どのくらい前のゲームハードまで知識がありますか?

塩尻氏:自分は1998年に入社したので、PlayStation(PS)くらいからですね。入社して1ヶ月くらいはバグチェックの担当になり『バイオハザード』のドアを、ひたすら開け締めするデバッグ作業をしていました(笑)。

特殊な構造を持つのは、PlayStation2(PS2)ですね。アーティストが半透明の表現を多用するようになったのはPS2の功罪だと思っています。

沼上氏:私が新卒で入社した年は、PlayStation(PS)が発売された翌年でした。もともと3Dのプリレンダー映像などをやりたくてゲーム業界に入ったんですが、時代の流れでゲームの開発環境に携わるようになりました。

塩尻氏:最近では、モバイルゲームの開発のほうが大変なんじゃないかと感じていますね。コンシューマゲームだと、プラットフォームの仕様が大体決まっているんですが、携帯端末って機種がたくさんあるじゃないですか?

今津:確かにモバイルゲーム開発に関しては、確立した手法みたいなのは少ないので苦労しています。コンシューマだと決まったハード性能に向かって作ればいいんですが、モバイルはターゲットとする端末が多く、その中でどの端末に合わせるのか、高性能な端末だけに絞るとシェアが少なく、収益が見込めなくなるので、まずどれだけの人数がどのレンジでどの端末を使っているのかを調査して分析します。

また、性能別に表現の段階をつけるために、描画負荷の高い要素を選別して削っていくという、デザイナーとしての苦しく大きな決断をすることも求められます。開発陣は、ギリギリまで性能の低い機種でも遊べるように調整しています。

さらに盲点であり、大変なのは、性能が時系列で並んでいないことが多く、最新機種なのに性能が低いCPUを積んでいたり、特定の端末だけシェーダーが動かない、といった特殊な動きをする端末もあるので、それをデバッグチームが調査して、なんとか対応しています。

麓氏:ちなみに、この端末では出したくないなって機種はあります?(笑)。

今津:具体的な機種名は出せませんが、苦労した端末はあります。

麓氏:詳細はこの後の懇親会で……(笑)。ちなみに自分は「過去のツールやゲームハードに関してのさまざまな知識」が△な理由は、セガは一時期ハードプラットフォームをしており、そのせいで他のハードを知らない時期があるんです。

入社して一番最初のハードがドリームキャストで、約7秒かかる起動時間のために起動画面を作ったんですよ(笑)。

今の役割に至った経緯は?

今津:DeNAにはモーションデザイナーとして入社しました。DeNAは社内で3Dのゲーム開発がスタートしたのが4~5年前で、当時は開発環境があまり整っていませんでした。モーションデザイナーとしてモーションキャプチャーを使うことは必然的なことであり、高級車が買えるような値段の機材を「将来的に絶対に必要となる」と部長に説明して、MVN Xsensというモーキャプシステムを購入してもらいました。

今後は、プロシージャルソフト「Houdini」についても、数本を購入する予定です。周辺からはこのような意思決定をしてくれるのがTAなんだ、と期待されているのかもしれません。

麓氏:最近だと「Houdini」を買いたいがために、TAになる人もいると言う噂も……(笑)。

沼上氏:先ほど少し話したんですが、自分はもともとエンジニアで入社して、ゲームを作るより3DCGを手がけたくて、当時最先端を走っていたゲーム業界に入った経緯があります。

当時ちょうどPlayStationが発売された頃で、ハイエンドな映像はなかなか作れなかったんです。どちらかと言うと最初はオフラインのレンダリングをメインで手がけていました。

一方でその技術を活かしつつ、徐々にリアルタイムと通常のゲームの開発に移っていきました。自分のように、エンジニア寄りでツールや環境を作る人を社内でTEC(テック)と呼んでおり、自分が入社するときにはすでに存在した職種でした。

当時自分が入ったナムコには、映像スタジオ会社のJCGL(ジャパン・コンピュータ・グラフィックス・ラボ)からスタッフが大勢合流していて、そこのエンジニアが映像も作りつつ、ゲームの開発環境に関しても、直接開発に参加しながら改善点を発見していました。その人たちがTECと呼ばれていたんですね。

そのような下地があったので、社内的には(TAに関して)受け入れがスムーズだったのかもしれません。ですが自分が入ったときはTECの人とは違う部署にいて、バラバラに仕事をしていたので、直接交わることはなかったんですが、全社的にそのような動きは見られました。技術屋としては、他社と比べて動きやすかったと思います。

ただ、アーティスト寄りのTAは活躍できる場所がなく、当時はまだまだ立ち位置が難しく、認められにくかったです。地道に少しずつ開発に貢献して、広い範囲に影響を及ぼそうと活動した結果、ようやく最近は認知されてきたと思いますね。

麓氏:プログラマーがプログラムを書くことで、アーティストのサポートをする、といった経緯で生まれたプログラマーTAの方が理解されやすかもしれませんね。アーティストからTA担った場合、プログラムを自ら書かなきゃいけないんですが、それってプログラマーが書いたほうが早いんじゃないの、という意識は他の職種の人には昔からありますよね。

沼上氏:純粋なコードを書くだけ、に限定するとそうなってしまいますよね。

塩尻氏:自分は、20年ほど前に入社したときはデザイナーでした。スクリプトなどの知識はまったくなく、周囲には絵を描ける能力が高い人が多すぎて、早々にデザイナーとして頭打ちをしてしまったとき、新技術を覚えるのが好きだったこともあり、技術面やハード面について勉強して、周囲から相談を受け、対応を繰り返して今に至る感じです。

逆にTAに向いているのは、なんでも積極的に興味を持てる人で、「知る」ことが苦になる人は難しいかもしれません。自分は最近でも業務時間外や帰ったあとに勉強することが多いのですが、その状況で「自分は勉強しなければ」と重荷に感じてしまう人にはツライかもしれませんね。

自分は良く、仕事中に知らない技術を聞いた時に「ああ、それね!」とすました顔して帰ったあとに、必死に勉強して次の日に反映したりしています(笑)。そういうことを繰り返しながら自分の知識が積み重なっていくことは楽しいですよ。

麓氏:確かに自分も塩尻さんと似ているな、と思います。入社後、デザイナーとして8年くらい担当していて、ある時ゲームハードが変わってリソースが増え、勉強すべきことも多くなり、ただ絵を書き続けていくだけでは、時代的にも間に合わなくなっていました。

もちろん、デザイナー全員がTAのように技術に詳しくなれるわけではないので、誰かひとり必ず技術に突出した人がいて、その人から他のデザイナーを通じてボトムアップしていけばいいのではと考え、そのひとりになるためにTA的なことを始めたことが経緯となっていますね。

当時はTAという言葉がなく、沼上さんの話を聞いていて思い出したんですが「バンダイナムコさんではTECという職種があるらしい」「じゃあうちらはデザグラマーにしようか?」みたいに話題になっていました(笑)。

沼上氏:そういえばデザグラマーって言葉、聞いたことあります(笑)。

麓氏:そんな中でGDCに参加した時に、TAという言葉が流行り始めているのを知り、グローバルスタンダードな用語なら、使っていこうと思ったのが経緯ですね。TAという言葉を共通言語にすることで、今日のイベントのように出自が全然違うクリエイターが一緒に活躍できることを期待しています。

TAがいること、集まることで何ができる?

麓氏:続いてのテーマは仕事の話や相談役だったりTAがいること、TAが集まると何ができるかについてお話を聞いていきます。

塩尻氏:TAが存在するメリットは、アーティストからの相談に対して、TA側から提案ができることですね。ツール制作に関しても、要望を咀嚼して「これならどう?」と返答できたり、より良い効率化を提案できたりすることは、自分たちの大切な仕事と言えます。

また、プログラマーとの仲介役としての役目もあります。現場ではアーティストとプログラマーが衝突することもあるので、議論と感情がぶつかってしまうシーンでTAが間に入って解決に導くこともあります。

沼上氏:確かにそれはありますね。どちらの論理にも正解不正解はないはずですが、単純に共通言語がなくて伝わっていないことも、多々ありますよね。

麓氏:うまく翻訳してあげて、早く実装に導くことが大切ですよね。

塩尻氏:TAがいない状態では、アーティストが必要以上に頑張ってしまう状況が多いと思います。効率化できる部分が多くあるのに、努力と根性で乗り切ってしまうケースもあると思います。

沼上氏:ゲーム開発の各職種間の隙間に対して、そこを埋めながら一つのプロジェクトを完成させていくのが理想形なんですが、TAはその重要な一端を担っていると考えています。

最近は自分の職種をパイプラインエンジニアとも呼んでおり、プロジェクト全体を広く見るようにしていますが、それを完璧にできる人は少ないですし、個人の強み弱みがある中、できる範囲を少しずつ広げるように心がけています。

ただ、新しいTAが入ったときにその人の強みと弱みを認識して、少しずつ広がりを増やしていけば、将来的には大きな動きに繋がります。しかし「自分はこの分野しかできません」と能力を制限しないように、加減を考えながら新人を育てていくことは課題ですね。

塩尻氏:確かに若手は大変な思いをしていますね。パイプラインやワークフローを作るにはかなりの知識力が必要になりますが、若手がそこを頑張って実現しようと日々苦労しています。ベテランは一つずつ習得して広げていけばいい、と助言するんですが、どうしても焦ってしまうようです(笑)。

今津:自分たちのグループは組織としても駆け出しで、現在TAグループは2名が所属しています。そこで個人的に、傭兵システム(タスクフォース)と呼んでいますが、案件に関していろいろなグループに一時的に力を借りるようにしています。

今後、新しい人を投入していくことは、組織を大きくするために必要ですが、万能選手はなかなか生まれないので、エキスパートな部分に限定して参加してもらったり、案件に応じて随時タスクフォースに参加してもらっています。

麓氏:組織づくりの部分では、知識や経験が豊富でないと、即効性のある対応ができませんし、各パートごとに詳しい人が一箇所に集まることで、対応力が上がったり、新しいチームの手法を共有できることも、TAが集まる意義なのかもしれませんね。

塩尻氏:他の部署にいる、案件に合わせて合致しそうな人を引っ張ってくるのは、とても良い仕組みですね。

今津:やりすぎると、本業の工数を食いつぶすといった問題がいくつかありますけどね……(笑)。

塩尻氏:カプコンでは、TAのような人を集める動きは約5年前から始まっており、そこから少しずつメンバーが集まって、ようやく結果が出始めてきました。

その経験上、ツールエンジニアやTAは孤立化しやすい傾向があるので、実はチームとしてまとまったほうが「コードこれで大丈夫かな」「エラー出てるんだけどどうしよう」といった身近な相談を簡単にしやすい環境で仕事ができるので、作業効率的にもTAやエンジニアのメンタル的にも良いことがわかりました。

困ったときに自分でひたすら調べるだけではなく、他の人に聞いて早く解決したり、他のエンジニアと協力して代替案を実現したりすることで、ツールを作るのもすごく楽になりました。また、社内ライブラリを充実させるようにすることで、ツール作成時の速度アップもできましたね。

そのような環境を構築すれば、TAだけでなくチーム単位で周囲の意見を集約できるようになり、いろいろな部署からツールを発注してくれるようになりました。それに合わせて、メンバーの知識やスキルも向上していけたと感じています。

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

▼イベントレポート後半はこちら

【イベントレポ(後半)】GDMテクニカルアーティスト座談会~やってみる、から一歩先へ~

 

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

GeNOM(ゲノム)とは

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

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

[/su_note]

【イベントレポ(後半)】GDMテクニカルアーティスト座談会~やってみる、から一歩先へ~

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

2019年8月6日(火)に開催された「テクニカルアーティスト座談会~やってみる、から一歩先へ~」では、4社のゲーム会社からテクニカルアーティストが集合し、それぞれの現在の業務や状況を座談会形式で実施しました。

本記事では、イベント後半に実施された来場者からの質問に応えるスタイルの座談会の模様を、一部抜粋してレポートします。

[su_note note_color=”#ffffff”]

■登壇者(敬称略)

塩尻 英樹(しおじり ひでき)
株式会社カプコン
技術研究開発部 技術開発室 DCCサポートチーム マネージャー兼チーム長

沼上 広志(ぬまかみ ひろし)
株式会社バンダイナムコスタジオ
技術開発統括本部 技術本部 コアテクノロジ部 コアテクノロジ2課

麓 一博(ふもと かづひろ)
株式会社セガゲームス
第3事業部 第3開発2部 テクニカルサポートセクション セクションマネージャー

今津 隆之(いまづ たかゆき)
株式会社ディー・エヌ・エー
ゲーム事業部 Develop統括部 デザイン部 テクニカルアーティストグループ マネージャー
[/su_note]

各社の内情が垣間見えた質疑応答

後半は、来場者との質疑応答と座談会が実施されました。

Q:後輩の育成について

麓氏:後輩育成といえば、自分のセクションでは、新入社員からTAになりたいという人を最初に採用したのが4年前、それが一人目で、今年さらに新人が加入し、若手が二人目となり、最初の4年目が育成を担当しています。

育成に関して、勉強はもちろん大事ですが、新人を開発現場のデザイナーの近くに連れていき、ディスカッションからスタートして、ツール設計に落とし込むところまで一緒に作業して、議事録を取りながら、実装まで携われるような体制にしています。

ナレッジベースに関しては、ナレッジを貯めたとしても、検索して参照することは少ないので、口頭ベース、もしくはまとめて伝えられる人のもとで、育成しています。

塩尻氏:カプコンも同じような感じです。若手を育成するって本当に苦労するんですよ。知識を共有することに関しても、なかなか一朝一夕にはいかないことが多く、やはり師匠と弟子のような関係性で実戦を繰り返すのが、一番の近道かもしれません。

沼上氏:うちの場合はそれ以前の話で、例えばプログラマーで入社した人は、違った方向に育てようとしても、もともとゲームプログラマーになりたい人が多いので、無理やり引っ張ってきても馴染めません。

どちらかと言えば、映像系のテクニカルディレクター希望の人がゲームの開発に来てくれれば、TAやパイプラインエンジニア的な仕事ができると思います。

育成に関しても、業務が多岐に渡るので、結局は自分の背中を見て育って欲しいとなってしまいます。大規模プロジェクトならTAを複数人配置して、他のTAと一緒に成長できるんですが、現在は投入できる人数が限られているため、そういったことができることは少ないです。

今津:DeNAでは新卒からTAになる、というのはまだ先の話かなと思っています。おそらく2~3年ほど、会社としてTA基盤を作ったあとのタイミングですね。現状考えているのは、TAを増やすにはある程度経験があり、特性を持った人材をどんどん引き込んでいく体制だと考えています。

Q:スクリプト管理ツールと効率化・共有化、アセット管理の仕組みと事例について教えてください。また現在着手されている新規ツールについて、作ってよかった、デザイナーから評判の良かったツールなどがあれば教えてください。

塩尻氏:カプコンではスクリプト管理ツールについては、MayaをメインのDCCツールを使用していますので、それを例にすると、Mayaで使うスクリプトやツール関連は一括して管理しています。アーティストにはそれを共通環境として、週に1度、こちらから保証する安定版を提供して開発してもらっています。

沼上氏:社内の共有ツールはいろいろあるのですが、会社の規模も大きいため、各部署でツールが分散して作られており、すべてをまとめることは難しいです。

共有環境で、各ツールをかき集めてビルドする仕組みは作ったんですが、きれいに配布するところまでは実現していません。ですが、ルールや仕組みを作りすぎると気軽にツールを作れなくなるので、加減が悩みどころですね。

今津:DeNAではあまり徹底できていないのが現状です。前職では、サーバにアップし、デザイナー側はランチャーで一括管理、バージョンアップは裏で進行し、起動すれば最新バージョンで使用できる仕組みになっていました。

沼上氏:社内全体だけでなく、プロジェクト単位でルールを決めて運用しており、アーティストがなるべく迷わないような環境を整えています。複数のプロジェクトを横断している開発者が、他のプロジェクトのことを考えないで環境を作ってしまうことがあると問題になります。

麓氏:大きい会社で大規模プロジェクトが複数開発されていると、それぞれが使いやすいように自由に配布しており、それをすべて一つにまとめることは難しいのですが、その間隔をつなぐような情報の共有や、渡すためのパイプ役になることは良くありますね。

沼上氏:よくある話ですが、ものすごい頑張って作ったツールではなく、30分ほどでサッと作ったツールの方が評判が良く、実はそれが10年以上に渡って使われていた、ということがありました。

要は技術力が目的ではなく、問題をどれだけいかに効率よく解決できることが目的なので、目的が一番満たされているのが、良いツールだと感じます。

塩尻氏:弊社での具体例を挙げますが、Maya上でアセット管理するのってとても大変じゃないですか? そう思って、実は社内でMaya上でアーティストがアセット管理できるツールを作ってしまいました。

アーティストが見やすいようにサムネイルを作って、メタ情報を紐付けるなど、いろいろできるようなアセット管理ツールがアーティストにかなり好評で、現在では社内のプロジェクトにほぼ導入されています。

麓氏:実は弊社もアセット管理するツールは、アーティストに喜ばれて使われていますね。また、ランチャー形式でスクリプトを共有するツールも使われています。

今津:DeNAでは、DCCツール系は当たり前に作っていますが、Adobe系のスクリプトが意外とアーティストやUIデザイナーから認知されていなくて、2人で1ヶ月くらいかかる作業の詳細を聞いてみると、ボタン2回くらい押せばできる作業になることが判明しました。

具体的には、ローカライズに関してですが、1個のバナーにおいて8言語の画像を作って出力する作業をしていました。

そこで、その言語をツールで読み込ませエイリアスを作成するツールを作成。その後、目視で確認・微調整を行い、さらに吐き出しツールで自動的に名前を付けてファイルを作成するというフローにすることで、工数の大幅削減を実現しました。

このような方法があること自体が浸透していないので、TA側からアプローチしていけば、感謝もされて嬉しいですね。

沼上氏:できることを知らないから、まず手段を伝えていくんですね。

今津氏:3D系のスタッフはツールで解決できることの幅を理解している人が多く、「これなんとかなるでしょ」という問い合わせがコンスタントにありますが、特に絵描き系のスタッフは意外にツールに頼らず地道に作業する傾向がありますね。

沼上氏:Photoshopで連続してデータを吐き出す作業は頻繁にやっているんですが、要望に応えてツールを作ってから、派生ツールがあちこちに生まれて、誰が作ったかわからないツールが回り回って修正してほしいと要望があったツールが、実は最初に自分が作ったものだった、というあるあるもあります(笑)。

Q:自分の会社でTAグループを立ち上げましたが、なかなか認知されず、自分たちが活躍できる場所を探すことがスムーズにできません。これからどうしていけば良いかアドバイスをお願いします。

塩尻氏:弊社でもTAについては、なかなか認知されませんでした。地道に営業活動をして結果を残すことが大事だと思います。ひとつ成功すれば、プロジェクトに信頼されて次に繋がるので、最初はできるだけ失敗しないように気を付けるように心がけています。

組織だけ作って、社内で「仕事ください!」と伝えても仕事は来ないんです。なので「うちのメンバーはこんなことができます」とスキルをアピールしましょう。

沼上氏:プロジェクトに属しているのなら、現場の作業をしっかり見て、不足している、改善できる部分を拾って、どんどん提案していくと良いと思います。知ったかぶりをせず、常に相談しながら学習して提案を重ねていくことが大切です。

今津:私たちは現在、まさに立ち上げの対応をしているところです。DeNAのデザイン部は100人以上配属しており、各職能に分かれているんですが、それぞれの職能のトップを順番に呼んで困っていることを片っ端からヒアリングしていきました。

また、全体会などで自分たちのグループの役割を伝えたり、何でもいいので相談してくださいとアピールして、最初は泥臭く何でも受けて作業していくと、だんだんと信頼関係が築けて「何か疲れちゃった……」みたいに気軽に声をかけてくれるようになりました(笑)。

沼上氏:信頼関係は大切ですよね。

今津:おそらくそういったお互いの信頼関係からスタートして、「TAなら何とかしてくれる」という雰囲気を作っていくことが大事だと思っています。

塩尻氏:たまに「なんで自分がライセンスサーバ作ってるんだろう……」って思いますもんね(笑)。でもNOって言ってしまうと次がなくなるので、いろいろと解決しています。

麓氏:できないとは言わずに、代案を出して、駆け込み寺のようなポジションになるのが良いかもしれませんね。まずは関係性を構築していくのが、スタートラインだと思います。

沼上氏:ひとつ注意しなければいけないのが、アーティストが「ここが困っているから、この作業をして」と手段を先に伝えてくることがありますが、そのまま受けてはダメで、今何をやりたいのか、目的を確認した上で解決策を提案してあげなければいけません。

噛み砕いて説明してあげても、実は違う方法で解決したほうが良い場合や、やってはいけない手法を頼んでくる場合もあるので、中身の流れを知らないままだと余計なツールを作って、その結果環境を壊してしまうこともありえます。

なので、極力聞き出す努力をすることが必須で、最終的な目的とやりたいことを理解してあげて、それに一番適した解法や使えるツールを教えてあげると良いですね。

Q:UnityやUEなど汎用エンジンを使用しているタイトルについて、TAとして思うところがあれば教えてください。

麓氏:汎用エンジンはフレームが完成している中で環境を作るのですが、別の環境に移行したり、エンジンが変更された時に、これまでの常識が通用しないということが多々あります。そこだけに慣れてしまうのではなく、一から作らなければいけないという覚悟は必要だと思います。

沼上氏:汎用エンジンは、誰でも使いやすい特長を持っていますが、独自な作業をするととたんにハードルが上がり、また、エンジンのバージョンが上がる度に仕様が変わってしまうので、自分的には使いにくいと感じています。ただ、うまく使えば最小限の工数でモノを作れますし、使いどころが肝心だと思っています。

塩尻氏:弊社では現在も内製エンジンを頑張って作っています。メリットはエンジン開発チームとすごく近いので、何かあったときにすぐ相談できることですね。エンジンの技術的に深い話が気軽にできるのは弊社の特殊な環境かもしれませんね。

今津:最近便利に感じるのは、シェーダーをデザイン側で攻められるようになったことですね。ただ、見た目だけは作れますが、そのままでは重すぎて絶対に組み込めないため、結局はエンジニアがそのシェーダーを解析して、一から作ることになっていますが。

まとめ

沼上氏:TAを集めることの意義として、会社の中だけでなくこのようなイベントで集まったり、麓さん、塩尻さんとは以前からやりとりは密にしていて、他社のエキスパートたちを話しているとだいたいみなさん同じようなことを考えていたことがわかりました。

最近では、ある問題について、ある集まりで塩尻さんが話題にしてくれて、自社でもその事象が起きるからちゃんと調べましょう、と二人で環境を調べながらトラブルシューティングができたんです。

その結果、問題が起きているアプリケーションメーカーも知らない、特殊な状況で起きる問題を解決できました。もちろん機密を守ってできる範囲でやれることは多くありますし、このようにTA同士が繋がっておくと必ずいいことがあると思っています。

今津:それぞれの会社にはアイデンティティがありますが、業界全体で見た場合に技術のパーツそのものを全面に出すのではなく、そのパーツを使ってゲームを作れば、こんな感動が与えられる、その感動の部分がアイデンティティだと感じています。ですので、個々の会社だけに閉じず、業界全体でつながって大きな開発環境を作っていければいいと思っています。

塩尻氏:自分も3年くらい前から横のつながりを増やさせていただいて、いろいろな話をする上で、弊社内で役に立つことが爆発的に増えました。情報を聞いているだけでも気付くことが多く、相乗効果もたくさんありましたね。

懇親会の様子

かなりの熱気(酸素も薄かった!?)で盛り上がった懇親会では、4社から集まったテクニカルアーティストと熱いディスカッションを楽しむ来場者の姿を見ることができました。

懇親会では名刺交換はもちろん、仕事についての情報共有や悩み相談など、会社の垣根を超えた交流が魅力のひとつとなっているようです。また、懇親会の最後には、登壇した4名のTAから来場者に向けて締めのお言葉もいただきました。

季節のデザート

今回用意された季節のデザートは、食べられるお花「エディブルフラワー」をたっぷりと使った、夏らしい爽やかなババロアです。当日は真夏の開催ということもあり、涼しげなデザートは大人気であっという間にみなさんのお腹の中へ……!

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

▼イベントレポート前半はこちら

【イベントレポ(前半)】GDMテクニカルアーティスト座談会~やってみる、から一歩先へ~

 

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

GeNOM(ゲノム)とは

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

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

[/su_note]

【イベントレポ&インタビュー】GDMエンジニア向け勉強会Vol.34~今だからこそ「Unreal Engine」を学ぼう (初級編)~

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

2019年7月26日に開催された「vol.34 エンジニア向け勉強会~今だからこそ「Unreal Engine」を学ぼう (初級編)~」では、Epic Games Japan サポートエンジニア 岡田和也氏を招いて、これからUnreal Engineを触ろうと考えている初心者に向けて、Unreal Engine 4の強みや、各種機能の紹介がされました。

本記事では当日のイベントレポートに加え、GDM運営を務めるDeNA藤村と岡田氏とのちょっとした対談の様子もお届けします。

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

岡田 和也(おかだ かずや)|Epic Games Japan
関西の大手ゲーム会社にてゲームエンジン開発をした後に、2016年にEpic Games Japanにサポートエンジニアとして入社。ライセンシ向けのQ&AサイトであるUDNでの回答、 直接会社に訪問してのサポート、 そして各地での勉強会などでの講演が主なお仕事。

[/su_note]

Unreal Engine 4について

Unreal Engineは比較的歴史は古く、20年前にEpic Gamesが開発したFPSゲーム『Unreal』で実装されたMODエディターが元になっているエンジンで、現在では「Unreal Engine 4」(以下、UE4)まで進化しています。

UE4は2014年には一般公開、2015年には無料化をしており、Epic Gamesアカウントを無料登録して取得すれば、誰でもダウンロードして利用することが可能です。GitHubからエンジンコード(プラットフォーム以外)を閲覧することも可能なので、学生でもプロでも同じ環境で開発や学習をすることができます。

国内でのUE4採用プロジェクトについて、現在ではコンソールだけでなくモバイルゲームやVR・ARなどのタイトルも増加しています。

Unreal Engine 4の強み

UE4の大きな特長として「高品質なリアルタイムグラフィック」が挙げられますが、UE4が目指すこと、大事にしていることは「大規模開発に耐えられるほどに高い開発効率」です。

Epic Games Japan 岡田和也氏Epic Games Japan サポートエンジニア 岡田和也氏

昨今のゲーム開発現場では、求められるクオリティは上がる一方、開発期間や予算はなかなか上がらないのが現状になっています。その中で、採用するツールに求められているのは、同じ時間、同じ人数でよりクオリティが高いものを、早く作れることになります。

従来の開発環境では、プランナーが企画を思いついてアーティストに依頼しても、エンジニアが不在だと「試す」「実装する」ことができず、チーム全体の開発スピードや、イテレーション速度の低下を招きます。

その状況を打開するために、UE4を利用して、非エンジニアが自身のアイデアを自分で実装できる環境を提供します。プランナーやアーティストが実装している時間に、エンジニアがより複雑な作業や、根本の作業効率をアップする業務に専念することができます。

このような理念を実現するための機能や取り組みとして、従来の言語を用いた開発に比べて「箱と箱を線でつなぐ」だけでアルゴリズムやシェーダーを組める「ノードベースエディタ」や、直感的でわかりやすい形式、プログラミングなどの複雑な作業を必要としないアーティストフレンドリーなUIも実装しています。

また、製品レベルの事例を参考にしながら学習が可能な機能別サンプルも豊富で、コストをかけずにプロトタイプを早く作成し「より早く遊びを研究し、早く失敗できること」が大きな魅力となっています。エディタ・ドキュメントなどの日本語化も進んでいます。

その他の強みとしては、ソースコードの公開をしており、ブラックボックス化の回避を実現しています。プロジェクトに応じたカスタマイズや最適化が可能になり、不具合による手詰まりの可能性を削減することも可能です。

また、Github経由で一般のユーザーにもコードを公開しているので、リリース直後から世界中のユーザーを通じて一斉デバッグされ、改善案を参考にしながら、さらなる安定化、新規機能を随時追加することができます。ちなみに現時点で最新のUE4.22では、数百の追加・修正項目のうち174個がコミュニティから寄せられたものになります。

このようにEpic Gamesでは、個人開発者だけでなく、大規模プロジェクトに関わる開発者がノウハウをオープンにすることを推奨しており、大型勉強会「アンリアルフェス」やSlideshare、Youtubeなどで資料や動画を公開しています。

エンジンに標準装備されているゲーム開発に必要な機能は、外部アセットやプラグインによるコストやリスクを回避するために実装されています。自社開発の『Fortnite(フォートナイト)』をはじめとしたタイトルの運用実績、コンテンツ開発を経て必要とされる機能が組み込まれています。

さらに、1つのプロジェクトがさまざまなプラットフォームで動作するように、基本的に同じようなアセット・コードで動くような対応をしており、ここ1年ほどの『Fortnite』での運用フィードバックが大きく活用されています。

Unreal Engine 4の各機能

プログラミング

Blueprint

ノードベースだけではなく、コンポーネントの階層構造を含めたもので、各パラメータやノードによるアルゴリズムの集合体です。

Blueprintの長所は、従来のプログラミング言語よりもハードルが低く、非エンジニアでも組むことが可能なところです。線を伸ばした先で右クリックすれば、その時点で使用可能なノードだけを選択することが可能で、単純な関数の誤りなど、ヒューマンエラーを回避することが可能です。

コンパイル、イテレーションも高速化され、各パラメータをリアルタイムに編集・反映が可能です。ゲームを実装しなくても処理を走らせることができる「Construction Script」機能を使えば、メッシュの数やマテリアルを変更したり、プロシージャルなワークフローも構築できます。

Unreal C++

従来のC++をUE4向けに拡張したもので、C++11ベースのモダンな言語、Blueprintとの連携も可能、エンジンのコア部分へのアクセスもできます。

短所としては、非エンジニアにはハードルが高く、Blueprintと比較するとイテレーションの速度は落ちてしまいます。もちろんヒューマンエラーの可能性も高くなります。

両機能の戦略としては、Blueprintではイテレーションの速度を求められ、かつ非エンジニアが触る部分を、Unreal C++ではシステム寄りの複雑な部分、非エンジニアにとってブラックボックスでも構わない実装部分に使用することが推奨されます。

レンダリング

UE4のレンダリングは物理ベースレンダリング(PBR)を採用しており、DesktopではDeferred Render、Clusterd Forward Renderer for VR、MobileではMobile Forward Rendererだけでなく、iOS向けに、よりリッチなレンダリングが可能なDesktop Forward/Deferred Rendererも登場しています(開発中なので2019年7月時点ではバグ発生の可能性あり)。

UE4ではギラギラした金属のようなレンダリングが想像されると思いますが、それだけではなくフォトリアルからNPR表現まで多彩な表現が可能です。

Material Editor

Blueprintと同じく、ノードを線でつなぐだけで、簡単にシェーダーを作ることが可能です。マテリアルインスタンスを使用すれば、シェーダーをコンパイルしなくてもパラメータの変更をリアルタイムで反映できます。

TA(テクニカルアーティスト)がベースとなるマテリアルを作り、実際に絵作りをするアーティストがマテリアルインスタンスで待ち時間なしで調整していくのが、基本的な戦略になると考えられます。

Post Process

標準で数多くの機能を提供しており、Materialと同様にノードベースで組むことが可能です。NPR表現ではPost Processで加工を施すことも多いと思われます。

Realtime Ray Tracing

標準機能として実装しており、最新Ver.は4.22、ある程度のGeForceグラボがあればすぐに試用することが可能です。

アニメーション

Persona

Personaエディターでは、アニメーションの調整やアルゴリズムの組成などすべての作業を実行することが可能です。一般的なステートマシンなどリアルタイムでプレビューすることも可能です。Blueprintと同じくノードベースで作業できます。

足音やエフェクトをアニメーション側に仕込んだり、複数のアニメーションをブレンドすることも可能です。量産に向けたアニメーションの使い回し「アニメーションリターゲット」も使用可能で、対象と同じスケルトン構造をベースが持っていれば流用ができます。

LiveLink

Maya、MotionBuilderなどのDCCツールとリアルタイムに連携したり、iPhone Xのフェイシャルキャプチャー機能と通信することで、エディター上でアニメーション化することもでき、簡易モーションキャプチャーのような役割を果たすことも可能です。

UI

UMG(Unreal Motion Graphics)

インゲーム用のUIエディターであり、一般的な平面UI、3D空間に浮かぶようなUIも作成することが可能です。

UMGでは、タイムラインでアニメーションを付けるなど、さまざまな機能が揃っています。Blueprintで処理を組めるため、一度覚えてしまえば学習コストも少なくて済むのが特長です。

UIのパーツであるウィジェットを、ドラッグ&ドロップで簡単に配置することができ、エディタ拡張もUMGで可能です。Pythonを使った自動化もかなり進んでいます。

エフェクト

Cascade

UE3から導入されたシステムで、エミッタ(火・煙・火花など)と呼ばれる各パーツを組み合わせてエフェクトを作成します。マテリアルと連携することで、シンプル、複雑、トゥーン描画のようなエフェクトが自由自在に作れます。

Niagara

現在開発中の新たなエフェクトシステムで、Cascadeに比べて高速かつさまざまな表現が可能になっています。スケルタル制御のメッシュに沿ったエフェクト、カールノイズ、タイムライン制御などさまざまな機能が組み込まれています。現時点では、本システムの正式リリース時期は未定です。

カットシーン

Sequencer

シネマティックカットシーンツールで、SequencerからBlueprintで作ったアルゴリズムを呼び出せるので、ゲーム中のギミックの制御などにも活用できます。現在発売、公開されている製品にも多数使用されています。

その他

Landscape

地形の作成機能です。粘土をこねるように山や谷を作成することができ、マテリアルを併用すれば高い部分に雪を積もらせ、低い部分は海に加工することもできます。

また木や草、石などをオブジェクトを自動で配置する機能は、ただ置くだけでなくカリングなどもされるので、処理負荷軽減にも役立つ仕様になっています。

Behavior Tree

イベント駆動型のAIシステムを作成するシステムです。Blueprintとは少し違うUIですが、ノードベースでアルゴリズムを組むことができます。「敵が近くにいれば右の処理、いなければ左の処理」というような分岐を経て、最終的な処理を決定する仕組みです。実際にゲームを動かしながらデバッグをすることも可能です。

Chaos

NVIDIA製「PhysX」から自社製の物理エンジンに置き換え中の、新たなシステムです。PhysXは外部のライブラリであり、不具合時の最適化が不可能だったため、ライセンシーから指摘をもらっていたことが主な置き換えの理由となります。UE4.23にて非破壊メッシュ機能がリリースしています。

プロファイリング機能

レンダリングする上でさまざまなバッファを作りますが、それを可視化したり、実機上でプロファイリングのデータを表示することも可能です。UE4.23ではUnreal Insightという機能が実装されています。

特にゲーム開発において、プロファイリングは重要視してほしい分野です。なるべく完成度の高いゲームを世に出すため、日頃からプロファイリングの作業を心がけてもらいたいと考えています。

オススメの学習方法

UEはプランナーやアーティストだけでモノづくりができるように、ほぼすべての機能がコード不要で使用でき、グラフィカルでわかりやすいUIを使用、日本語にも対応しています。

また、学習用に公式ドキュメントやサンプルも用意されており、用語の説明だけでなくプロ向けのコアな解説も記載しています。Epic Games製のサンプルも多数収録、アセットは商用利用可能で、機能別のサンプルには、UE4を学ぶ上で非常に役立つものが数多く収録されています。

Marketplaceでは、無料アセットやコミュニティが販売している高品質なアセットが多数登場しています。販売アセットは商用利用・改変可能でライセンス明記不要、再配布はNGです。別ゲームエンジン・ツールでも利用可能です。

公式動画チュートリアルサイトでは、エディターの基本操作やリッチなレンダリングについてなど、段階を分けてチュートリアルが収録されています。日本語字幕もあります。

参考書については、「Unreal Engine 4で極めるゲーム開発:サンプルデータと動画で学ぶUE4ゲーム制作プロジェクト」「作れる!学べる!Unreal Engine 4 ゲーム開発入門 第2版」「Unreal Engine 4 マテリアルデザイン入門[第2版] 」の3冊をオススメします。非公式の動画チュートリアルサイト「Udemy」では、初心者向けの動画も販売されています。

学習する上で一番大事なのは「はじめからすべての機能を理解しようとしない」ことです。UE4はハードルが低いとはいえ、初心者向けだけでなくプロ向けのツールでもあるので、ドキュメントを参照した後に、標準のテンプレートをベースに小規模なコンテンツを作ってみましょう。オススメはTPSテンプレートです。

困ったときは、公式Q&Aサイト「UE4 Answerhub」を活用してください。ここではコミュニティ同士が質問や回答している場所なので、初心者がつまづく内容については、ここで検索すると簡単に解決することが多いです。

さらに、より高度なことを学びたくなったら、SlideshareYoutube公式チャンネルで公開されている国内の勉強会における講演資料やアーカイブ動画などを参考にしてください。

また、エンジンコードを見ながら、実際に手を動かして、触ってみることが成長の秘訣です。

また、最後にお金に関わる説明ですが、ゲームの場合(一般ユーザー)、4半期(3ヶ月)毎の総売上が3,000ドルを超えた場合、その超えた分に関して5%のロイヤリティが発生します。

Epic Gamesからの有償のサポートを受ける場合はカスタムライセンスを結ぶ必要があります。なお、映像・建築などのノンゲームの場合は、ロイヤリティはありません。

GDM運営の藤村と対談

イベント直前に、今回登壇いただいたEpic Games Japan 岡田和也氏と、GDM運営を仕切るDeNA 藤村幹雄にいろいろと聞いてみました。

――今回のGDM登壇のきっかけ、経緯を教えてください。

藤村:きっかけは、20年くらいお付き合いのある、Epic Gamesの杉山明さんに相談したことです。杉山さんは、ゲーム業界や映画などエンタメの分野において「Softimage3D」を日本で広めた有名な方なんですよ。

岡田氏:それで杉山さんから直接オファーをもらったんです。もともと自分はセミナーなどに登壇する機会も多く、すぐに了承させていただきました。現在、杉山さんは映像や建築などのノンゲーム周りの業務を担当しており、ゲーム関連は自分が登壇することが多いです。

――岡田さんの普段のお仕事内容を教えてください。

岡田氏:サポートエンジニアとして、ライセンスを結んでいる方のみログインできるクローズドなQ&Aサイト「UDN(Unreal Developers Network)」で質問をいただいて回答する、会社などに直接お伺いしてパフォーマンスの計測や不具合の調査する、そして講演に登壇する、という3つの業務が主な担当になります。

――今回の勉強会の内容を初心者向けにしたのはなぜですか?

岡田氏:関東圏で実施しているEpic Games主催の勉強会は、初心者向けの内容はあまり求められておらず、すでに仕事でバリバリ使っている人向けの内容が多くなっています。今後、未経験者や初心者に向けてどのような展開にするか悩んでいたときに、今回のお誘いを受けたので、さっそくこのお題に決めました。

藤村:DeNA社内のゲーム開発現場にとっても、このようなUE初心者向けの勉強会をきっかけに新しいチャレンジや、今後の開発タイトルへのエンジン採用についても役立つとと考えました。

昨今のモバイルゲーム開発では、UEの採用も選択肢の一つとなりつつあるので、「これからUEを勉強したい」と感じている社内のゲームクリエイターが、一歩踏み出して興味を持って実際に触れるような機会になればと思っています。

GDMを立ち上げた時期は、ゲーム業界の中にプランナーの勉強会が少なく、若手向けの勉強会もあまり実施されていなかったため、あえてプランナー向けのお題を中心に実施してきました。

約1年ほど開催を続けたときに、さらにいろいろな職種を扱いたいと考え、デザイナーやエンジニア向け勉強会を実施しました。最近では内容の幅も広がってきたので、今回のような初級、中級とレベル別のお題にすることにしたんです。

――初心者向けの勉強会用の資料を作る上での工夫はありますか?

岡田氏:自分自身、前職のゲーム会社でもUEを使用していたので、当時を思い出しながら実際につまづいたところや、まとまっていたら便利かもしれないトピックスを、まずは広く紹介しようと考えて作りました。

――今後、GDMでUE中級、上級編なども実施の予定はありますか?

藤村:もし、やっていただけるのであれば!

岡田氏:ぜひ、お声がけいただければ!

――ちなみに『Fortnite』マルチプラットフォーム化の際のノウハウはかなり蓄積していますか?

岡田氏:ええ、そのノウハウがUE側に続々とフィードバックされています。モバイル最適化のシステムや、チェックの自動テストなど、より効率を上げるような機能の導入も始まっています。やはり自社開発しているゲームタイトルがあることは、大きなメリットになっていますね。

――最近ではモバイルゲームにUEが導入されることが多くなってきていますが、業界でも技術的な広がりを感じていますか?

岡田氏:先ほど話したようなQ&Aサイトでの他社・他人同士の助け合いも盛んですし、最近では質問の質が高くなってきたのを感じます。ガッツリ業務で使用した上で「技術をもっと深堀りしたい!」と思うモバイルゲームのクリエイターが増えてきたのかもしれませんね。

――使う側もかなり慣れてきたようですね。

岡田氏:確かにそう感じています。自分たちも「その問題は認識していないので、これからすぐ調べます!」と、焦ることも多くなりました

――今後UEはどのように進化していくと考えていますか?

岡田氏:ここ1年ほどで思うのは、ゲームだけじゃなく映像やバーチャルカメラ、モーションキャプチャーとエンジンの連携が強くなってきて、何でも実現できるツールに進化したと実感しています。

弊社のティム・スウィーニーも「Epic Gamesは今後もゲーム会社としてゲームを生み出していく」と強く話していますし、ゲーム開発を大きな軸にしながらも、他分野のテクノロジーの進歩にも深く関わっていきたいと考えています。

また、『Fortnite』のトレンドの勢いがすごくて、ゲームプレイだけじゃないコミュニティツールとして楽しまれている部分も含め、来年はもっとおもしろいことが起きる気がしています。

――さらなる進化が楽しみですね! 本日はありがとうございました。

アンケートに寄せられたコメントを紹介

今回のGDMに参加した方から頂いたコメントを一部抜粋して紹介します。内容はすべて運営チームが目を通しており、今後の運用に活用していきます。

[su_quote]岡田さんの説明がわかりやすく、面白かったです。(ディレクター)[/su_quote]

[su_quote]Unreal Engineおよびwiseを使用したサウンド実装の初心者向け講習会や、ワークショップ的なものがあれば是非参加したいです。(サウンド開発)[/su_quote]

[su_quote]関西でもたまにやっていただけると、大変ありがたいです。(プログラマー)[/su_quote]

[su_quote]岡田さんの講演はよく聞きに行くのですが、このような初心者向けのものはレアで良かったです。缶バッジも嬉しかったです!(経営者)[/su_quote]

岡田氏のご厚意により、来場者全員に配られたUEのステッカーと缶バッジ

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

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

GeNOM(ゲノム)とは

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

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

[/su_note]

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

DeNA主催のゲームクリエイター向け勉強会「Game Developers Meeting」(以下、GDM)。

6月21日(金)に開催されたVol.33では、プランナー向けの座談会が開催され、グリー株式会社より『探検ドリランド』プロデューサー井口博貴氏と、株式会社DeNA Games Tokyo『怪盗ロワイヤル』プロデューサー下島海が登壇しました。

https://genom.dena.com/event/20190621_gdm_report/

GeNOM編集部では、座談会開始直前の楽屋においてインタビューを敢行。登壇時には明かされなかった(言えなかった?)話を事前に聞くことができました。モデレーターを担当したDeNA佐伯嶺も交えて、ぶっちゃけトークをお届けします。

グリーとDeNAの関係

――本番前に失礼します! まずは今回のGDMに登壇するにあたり、過去にグリーとDeNAがライバル関係のようなイメージがあったことに関して実際、どう感じていますか?

佐伯嶺(以下、佐伯:そう、それって実際どうなの? すごく気になる!

井口博貴(以下、井口氏:DeNAさんに対してネガティブな感情はまったく感じていないのが、正直な気持ちです。でも昔からグリーで働いている社員に『怪盗ロワイヤル』とコラボすることを話すと「マジで!?」とビックリされることはありました。

コラボの進め方については、いつもの企画と特に変わらず、むしろやりやすかったんですよ。やっぱり時代の流れと、社内・社外の印象って違うことを感じましたね。

下島海(以下、下島:僕もほとんど同じ印象です。むしろ当時の関係のことは詳しく知らないので何も気にせず、「おもしろいから、ぜひコラボやりましょう!」といった軽い雰囲気で井口さんとコラボの話を進めました。

――若い世代だからこそ、過去に囚われないクリアな気持ちでできたんですね。

井口氏:ええ、まったく気にならなかったです。

下島:そうですね(笑)。

佐伯:実は今回のGDMのテーマを考えていて、『怪盗ロワイヤル』10周年を迎えるタイミングで、超長期運営のタイトルを絡めたテーマにできないかな、と思っていたんです。そこで『探検ドリランド』はどうかな……と、まず下島くんに相談したんですよ。

下島:その提案を受けて「あ、それおもしろそうですね。後でチャットしておきますね。」となりました(笑)。

井口氏:ものすごくカジュアルに決まりましたよね。

――座談会実現のためにいろいろ準備して……ではなかったんですね。

佐伯:自分もそれなりに長くDeNAで働いているんで、本音では大丈夫かなってビビってました。ですが2人の関係を見て、なにも心配することはないと感じることができてホッとしました。

井口氏:すでにかなり仲良かったですし(笑)。コラボが決定してからも、月イチくらいで情報共有会をやってたんで、すぐ連絡を取り合いました。

佐伯:もしかしたら、社内のメンバーより会ってるんじゃないですか?

下島:そうかもしれないですね(笑)「髪切りました?」くらいの頻度です。

井口氏:「また筋肉大きくなったんじゃない?」みたいにね(笑)。ホントに最初からカジュアルな付き合いだったので、今でもとても楽ですね。

長期運営の裏側

――ブラウザタイトルでここまで長期運営しているタイトルは他にはないと思うんですが、いわば戦友とも言える2人が感じているシンパシーなどはありますか?

井口氏:長期運営タイトルの担当だけでなく、新卒で入社した経緯や、ゲームが大好きでタイトルに配属されたわけではない、という背景まで2人ともすごく似ていて、ちょっと話しただけで「それ、分かる!」みたいに意気投合しちゃったんですよ。

下島:ゲーム業界ではちょっと珍しいキャラクターの井口さんに会ったとき「あ、自分と似てるな、話しやすいな」って思ったんです。

井口氏:話していると、ヤバイくらいの勢いで企画がガンガン決まっていくんです。

下島:「そのアイデア、いいっすね!」「おもしろいからやりましょう!」といった感じで話も早いし、考え方も似ているのでとにかくやりやすかったです。

佐伯:心地良すぎるスピード感ですね。タイトルと個人の立ち位置がうまく噛み合っていたのかもしれませんね。

そういえば、打ち合わせ飲み会からすぐ別の日に、両社の他のブラウザタイトルのプロデューサーが15人集まって飲み会が開かれたって聞きました。

――え!? そんなすごい飲み会が……。もうすでに両社の垣根を超えてるじゃないですか?

佐伯:そう! 垣根なんて、とっくに超え終わってるんですよ。その盛り上がった結果を教えてください(笑)。

井口氏:もちろん、ものすごく盛り上がったんですが、真面目に話すグループとバカみたいに飲むグループに分かれてしまって。

下島:僕らは「ハイボーラー」という、ハイボールをひたすら飲むグループにいました(笑)。

DeNA Games Tokyo 下島海DeNA Games Tokyo『怪盗ロワイヤル』プロデューサー 下島海

――今でも他のプロデューサーとの関係は続いているんですか?

井口氏:はい! 飲み会自体がつい最近だったこともあり、別プロダクトでも何かおもしろい動きができないかと今いろいろ探っています。

――それでは話題を少し変えて。長期運営タイトルについて、どの部分の数字を見ながら運営を維持しているのか教えてください。

井口氏:どちらのタイトルも、見ているKPIはあまり変わらないと思いますが、『探検ドリランド』は比較的ARPPUが低いゲームなので、特にUU(ユニークユーザー)を意識して運営しています。

『探検ドリランド』のプレイサイクルは、みんなでキングモンスターを倒すスタイルなので、過疎化するとコンテンツが終わってしまいます。そこで一番意識しているのが「いかにUUを離さずに維持させるか」ということです。もちろん、売上に関して会社からのプレッシャーは強いんですが……(泣)。

下島:『怪盗ロワイヤル』も結構似ている部分が多いですが、ARPPUはやや高く、コアUU(頻繁に遊んでくれているプレイヤー)をセグメント別に分けて、計測しています。

――長年の運営で「分析する練度」も上がっていると思うんですが、独特なツールや歴代プロデューサー直伝の技などはありますか?

井口氏:長年管理されているドキュメントは、もはや「秘伝のタレ」状態になっています。2012年くらいからのデータについての関数は自動化されており、過去の優秀なエンジニアが手がけたツールを使って、欲しい情報が一発で自動で出力できるので便利です。

佐伯:まさに老舗のタレの継ぎ足しのようですね(笑)。

下島:うちもほぼ、一緒ですね。過去のデータを閲覧したり、必要な情報のための分析ツールは揃っています。ただ「こんなの見ても何もわからん!」となるくらい、情報過多になってしまっていることはありますが(笑)。

佐伯:どちらも洗練された直感的に使えるツールを、積極的に運営に活用しているんですね。そういえば、グリーもDeNAも他社に比べると分析志向が強いイメージがありますよね。

井口氏:分析だけでなく、ロジカル思考が強いですよね。課題の答えを導くにはどのアクションをすればいいのか、と論理的に考えるスタイルは、最初にプランナーとして入ったときに叩き込まれます。

下島:DeNAもまったく同じですね。最初はロジカルに考えて基礎を作り、その延長上にブッ飛んだ企画を掛け合わせることが大事だと考えています。

――今後の運営は、やはりこれまで蓄積されたノウハウや洗練されたツールがあるから実現できると思いますか?

佐伯:それもあると思います。また、単純に開発する物量感が小さくて済むからだと思いますね。

井口氏:確かに、ネイティブアプリの開発に比べると、コストはかなり低いと思います。

佐伯:当時は、リリースして3時間後に新しいガチャを入れ直すとかやってましたよね。

井口氏:もちろん、今でもやろうと思えばできますよ(笑)。

――ブラウザゲームにしかできない企画を活かせればいいですよね。

佐伯:確かにおもしろいですね。それこそリアルタイム性の高いSNSと連携したり!

下島:アイデアの即時反映とか(笑)。

佐伯:YouTuberの番組終了時にあわせてゲーム内に実装するとか。なんだか、ブラウザゲームの明るい未来の話ができて嬉しいですね。

グリー 井口博貴グリー『探検ドリランド』プロデューサー 井口博貴氏

コラボ実現の裏側

――ちなみに2018年12月に実施した『探検ドリランド』×『怪盗ロワイヤル』のコラボの結果はどうでしたか?

夢のコラボでは特別イベントや豪華報酬が用意、SNSキャンペーンも積極的に実施された。

井口氏:反響も大きく、かなり良い結果が出ましたよ。『探検ドリランド』では当時、IPコラボがすでに2本決まっていて、その合間に『怪盗ロワイヤル』とのコラボを実施するスケジュールになったため、どちらかというと既存プレイヤーがワイワイ盛り上がってくれればいいな、と考えていたんです。

ですが、当初の想定より反響があって、本当にやって良かった、ありがとう! といった気持ちです。

佐伯:『怪盗ロワイヤル』のプレイヤーから、驚きの声などはありました?

下島:もちろん来ました! コラボが始まる直前に、キャラクターがゲーム内から消えて、それぞれのゲームに遊びに行くという導入ストーリーを作ったら、ゲーム内がすぐにザワついて「これ、ドリランド(コラボ)じゃない?」と早くからSNSなどでバズっていました(笑)。

佐伯:かなりのインパクトを生んだ座組みだったんですね。

――コラボの際に、お互いの古参・既存プレイヤーからネガティブな意見などはなかったんですか?

井口氏:これが、全然なかったんですよ。むしろ「よくやった!」と褒められました。『探検ドリランド』のキャラクター「ハルカ」が長期運営に疲れているところに、声をかけてきた『怪盗ロワイヤル』の3人組に悪の道に引きずり込まれる、という自虐的な設定の物語も好評だったようです。

コラボについては、毎回いろいろと練ったストーリー設計を考えるんですが、今回が一番盛り上がったのかも知れません。

『探検ドリランド』メインキャラクターのハルカ。公式Twitterのナビゲーターも務める。

佐伯:ある意味、プレイヤー視点に対してブレずに設計した導入だったから、自然に盛り上がったのかも知れませんね。これはスゴイいい話ですよ~(笑)。まさにWin-Winの関係ですね。

もし、自分がこんなコラボやるとなったら、プレイヤーからの批判とか考えて、慎重になっちゃいそうですもん。

――好評だったということで、第2弾とか期待しちゃいます。

井口氏:そうですね。なんせゲームだけでなく(お互いのロイヤリティも)無料なんで(笑)。

佐伯:両タイトルとも、今でもかなり多くのプレイヤーがプレイ継続していますし、他のタイトルにもコラボすれば効果が期待できるって、もっと広めたほうがいいですよ!

下島:ですよね! このような座組は、今後もたくさん実施していきたいです。

――当時遊んでいた人にとっては、ある意味懐かしさも感じますよね。約10年前にプレイを始めた人がいまだに遊んでいるゲームってなかなかスゴイですよ。

佐伯:2人ともサービス開始当時は完全に10代ですもんね。そんな若い世代が今、まさかプロデューサーを務めているなんて……。

DeNA 佐伯嶺

これからのブラウザゲーム

――それではそろそろ本番の時間も迫ってきたので、ブラウザゲームを今後どう進化させたいか、展望などありましたらどうぞ!

井口氏:10周年を機に、自分たちが目指す戦略として、数百万人単位の「休眠ユーザー」にアプローチしていくことで「もう一回、ドリランドをプレイしてみたくなる」ような施策をいろいろな角度で実施しています。

他のゲームでは、新規ユーザー獲得の成功事例は山ほどありますが、休眠ユーザー復帰の施策はなかなか少ないですし、成功しないことが多いんです。それでも、ブラウザゲームという括りだけでなく『探検ドリランド』を、もう一回遊んでもらいたいな、と頑張っています。

下島:『怪盗ロワイヤル』もほぼ、一緒ですね。長期運営の魅力でもある、歴代の多くのプレイヤーと触れ合ってきた知見を活かし、休眠ユーザーに再び復帰してもらうことを10周年のメインテーマにしています。

佐伯:じゃあ、今はガッツリとネタを仕込み中ということですね!

下島:そうですね。アプリだけじゃなく「ブラウザゲームってまだまだ面白いじゃん!」ということを伝えたいですし、その効果を『怪盗ロワイヤル』『探検ドリランド』のみならず他のブラウザタイトルにも波及させられればいいなと思ってます。

佐伯:やっぱりブラウザはダウンロードがなくて気軽ですし、通信も早いですもんね。これから先もブラウザゲームはまだまだ頑張っているよ! という流れを作れたら面白いですね。

そして将来、このプロデューサー2人が旗印となって、業界を盛り上げてくれることを信じています!

――ここまで2人が密接な関係だとは思わなかったので、驚きでした。今日はありがとうございました!

本番前の楽屋は、3人の爆笑トークで終始大盛り上がりでした。次世代を担う若きプロデューサーの彼らが、『探検ドリランド』『怪盗ロワイヤル』をはじめとしたブラウザゲームに、近い将来、さらなる驚きと楽しさを届けてくれると信じています。GeNOMでは今後も彼らの動向をチェックしていきます!

インタビュー・執筆:細谷亮介
編集・撮影:佐藤剛史

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

GeNOM(ゲノム)とは

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

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

[/su_note]

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

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

6月21日(金)に開催されたプランナー向け座談会Vol.33では、グリー株式会社より『探検ドリランド』プロデューサー井口博貴氏をゲストに招き、『怪盗ロワイヤル』プロデューサー下島との対談形式で、超長期運営だからこその苦労や、ファンに愛され続けるための工夫に迫るトークを繰り広げました。モデレーターはDeNAの佐伯嶺が務めました。

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

井口 博貴(いぐち ひろき)|グリー株式会社
2015年グリー株式会社に新卒入社。『釣り★スタ』にてCSとして携わったのち、『探検ドリランド』の企画・開発・運用を経て、同タイトルのプロデューサーを務める。

下島 海(したしま かい)|株式会社 DeNA Games Tokyo
2017年にビジネス職として新卒入社。その後『怪盗ロワイヤル』にプランナーとして配属され、2018年9月より同タイトルプロデューサーに就任。

佐伯 嶺(さえき りょう)|株式会社ディー・エヌ・エー
コーエーテクモゲームスを経て、2013年中途入社。『FINAL FANTASY Record Keeper』開発から携わり、運営開始後はディレクターを担当。現在新規タイトル開発チームの企画マネージャーを担当。[/su_note]

座談会の冒頭では、『探検ドリランド』と『怪盗ロワイヤル』の簡単なゲーム概要とこれまでの歩みが紹介され、長期間に渡る運営の歴史が説明されました。本記事では座談会で繰り広げられたトーク内容をレポートします。

 

10年の歴史を引き継ぐということ

佐伯嶺(以下、佐伯:まず最初にプロデューサーとして、約10年近く運営を続けているタイトルをこの先引き継いでいくことについて、談義していきましょう。

井口博貴(以下、井口氏:『探検ドリランド』プロデューサーを引き継ぐ際に、プレッシャーの重さや、いろいろ考えるところがあるんじゃないか、と思われがちでしたが、そんなことは全然なくて、純粋にワクワクした気持ちのほうが強かったのが率直な気持ちです。

僕がグリーに入ったのは、ビジネスに特化した仕事がしたかったためで、当初はゲーム志向ではありませんでした。ゲーム事業に所属になった際、チームを構築したり、大きな金額のPLを管理する業務に携われる可能性があることに気づき、視座を上げつつ、プロデューサーを目指すのが最初の目標になりました。

そんな経緯があったので、プロデューサーになれたのは「ついに来た!」といった嬉しいタイミングでした。もちろん、会社からのプレッシャーもありましたが、それよりワクワクする気持ちが強くて、新しいことに挑戦できることが嬉しかったですね。

グリー井口博貴氏グリー『探検ドリランド』プロデューサー 井口博貴氏

下島海(以下、下島:入社してからの背景は井口さんと似ています。僕もビジネス志向が強く、ゲーム好きというタイプではありませんでしたが、ヒトモノカネに一番裁量を持って携わることのできるプロデューサーという仕事にやりがいを感じて最初の目標としました。そのためプロデューサーになった時はプレッシャーなどはなく単純にワクワク感が強かったですね。

また、『怪盗ロワイヤル』は今年で10周年を迎えるので、このタイミングで活躍できるプロデューサーは1人しかいませんし、ここでおもしろいことをやって、強烈なインパクトを残すチャンスだなと思ってます。

DeNA Games Tokyo下島海DeNA Games Tokyo『怪盗ロワイヤル』プロデューサー 下島海

佐伯:なるほど。2人とも出自も背景も似ているんですね。そういえば最近では仲も良いとお聞きしましたが?

井口氏:そうなんです、しょっちゅう一緒に飲んでます(笑)。以前『探検ドリランド』と『怪盗ロワイヤル』でコラボをしたんですが、その時の企画の進め方がやりやすくて(笑)。下島さんとは考え方も近いので、「こんなアイデアおもしろいですよね!」みたいに、話がバンバン通るんですよ。

過去に似た座組のIPコラボもやったことはあるんですが、下島さんとは同じ会社で働いているのかなって思えるほどやりやすくて、すごく楽しかったです。

佐伯:ブラウザゲームでここまで長期運営しているタイトルは少ないので、プロデューサーとして、まさに戦友みたいな関係になってますね。

ちなみに今回のGDMの座談会を企画を提案した際に、下島くんが「(井口さんと)この前飲んだばっかりなんで、すぐ連絡しておきます!」とラフに快諾してくれたのは、正直驚きました。こんなに両社が仲良く情報交換しているなんて、意外でしたね。

長期運営タイトルのチーム作り

佐伯:続いては、長期運営タイトルでのチーム形成の方法や、どのような施策をしているのかを聞いていきましょう。

下島:『怪盗ロワイヤル』では、運営期間にかかわらず、前提としてゴール(※UXビジョン)を決めて、そのための戦略やロードマップを明文化してメンバーに提示し、きちんと同じ方向に進むチーム作りが大事だと考えています。

※UXビジョン:DeNA Games Tokyoが提唱する「プレイヤーにゲームを通して体験してもらいたい理想状態を言語化・共通化したもの」のこと

その上で超長期運営中のタイトルでは、多くの工数をかけて新規開発するフェーズではないため、事業観点では「仕組み化」、組織観点では「自走化」を重視しています。

井口氏:やはり長期タイトルだけあって、考え方が似ているところも多いですね。僕が『探検ドリランド』に携わって一番スゴイと感じたのが、優秀なメンバーが運営してきた長い歴史の中で、効率化が徹底されていることでした。無駄のないスケジュール管理方法も素晴らしいです。

ですが、最近の運営はクリエイティブ集団ではなく、いかに期日を守れるか、足元の数字に追われているようなチームになっていました。

まずその状況を変えるため、年間目標を掲げて、メンバー単位で1年後にどうなりたいかを意識し、例えば「定常月のMAU200%を目指します!」のような、ありえないような設定をしてみます。

メンバーはそんな数字を見ると「無理でしょ!」という反応になりますが、とんでもない数字を目標に設定すると、それを実現するために「毎週違ったIPとのコラボやってみよう!」みたいなハチャメチャな企画が出てくるときがあるんです。

ゼロベースで考えるより、今あるものを使って、いかに効率的にコスパ良く落とし込めるかを考え、あわせて年間の目標を立てることでチーム全体の目線を自然に上げることを、最近の運用で心がけています。

佐伯:目線が上がればこれまで見えなかったチャレンジができて、成功したときにはチームの士気が上がりますよね。

井口氏:いい結果が出れば「やった、狙い通り!」と喜べますし、さらに次はもっとデカイ結果を出そうとテンションが上がりますね。

佐伯:長期運営のタイトルだと「おもしろいことをやろう!」という意見は、チーム内であまり出てこないイメージがありました。

下島:メンバーには常におもしろいことはなんでもやっていこう、と話しています。長期運営のために仕組み化した土台を作ったうえで、プレイヤーさんに新しい体験を届けられるように「仕組み化×おもしろいこと」を掛け合わせていくことが、この先の運営のあるべき姿なのかな、と考えています。

佐伯:方法は違っても、意識的に高い目線を保つことを、プロデューサーが率先してやっていかなくては、という考えは2人とも共通しているようですね。

DeNA佐伯嶺DeNA 佐伯嶺

超コアプレイヤーの方との向き合い方

佐伯:次のお題は、サービス開始からタイトルを支えてくれているコアプレイヤーさんとの向き合い方、付き合い方についてになります。

井口氏:2012年くらいからのデータを見ると、カードモデルに変更後もずっとプレイし続けていただいている方がかなりの割合でいらっしゃるので、ほとんどの方はコアプレイヤーさんと言える存在かもしれません。

『探検ドリランド』は、みなさんが想像されているよりARPPUが低いゲームなんです。課金ベースで見ると、コアプレイヤーさんもまんべんなく平均値が取れているので、超コアプレイヤーさんたちに向けて何か特別な施策をすることはしていません。どちらかというと、平均的に平等感を意識して運営しています。

下島:『怪盗ロワイヤル』も考え方は似ていて、初心者プレイヤーさんもコアプレイヤーさんも分け隔てなく遊べるように配慮しています。また、弊社で実施するユーザーインタビューに招待して意見を聞いたりもしています。

佐伯:ちなみに、古参のプレイヤーさんと交流する際に、自分が知らない過去の情報が飛び交ったときはどうします??

下島:「なるほど!」と急いでメモします(笑)。

井口氏:リアルイベントなどで「200x年xx月に登場した、あのハンターは今どうなってるんですか?」みたいな自分が入社する前の、とんでもないマニアックな質問が投げかけられるときがありますが、そのときには合わせて色々な情報をキャッチアップしようと当時の『探検ドリランド』の状況を含めて耳を傾けるようにしています。

古参プレイヤーさんの中には、運営に意見を伝えたい方、要望を聞いてほしい方も多く、そのような方から新しい情報を入手して、次のイベントなどに活かすようにしています。定期的なインタビューで意見を取り入れてゲームに反映すると、感謝の言葉もいただきますし、プレイヤーさんと良い関係が築けますね。

佐伯:ゲーム運営ってどうしてもヘイトがたまりやすいですけど、お互いをリスペクトしあえる関係性ができているのはいいですね。

井口氏:そうですね。ゲームに限らず、匿名性の高いメディアにはさまざまな思いが投稿されることも多いです。でも、プレイヤーさんと実際にお会いすればニュアンスを柔らかくして話してくれたり、意図の違いなどもその場で認識しあえることができます。

やはり直接会いに来ていただける方の熱量はかなりのものなので、運営する側としてそれに応えられるだけの熱量をもって接することは常に意識しています。

佐伯:リアルでプレイヤーさんと会うことによって、一体感を作れているのはスゴイですね。運営とプレイヤーさんが一緒にゲームを作り上げていくことは、すでにゲーム運営に重要なファクターとなっています。

長寿タイトルだからこその挑戦

佐伯:長期運営を続けているタイトルだからこその、これまで挑戦してきたイベントなどについて、お話しいただきましょう。

井口氏:自社イベントである「GREEファン感謝祭」については、2015年頃から取り組んでいます。当時は社内全体で「リアルイベントをやるなんて、チャレンジャーだ」と恐れられており、「どんな人が来るかわからないので怖い」と、様々な不安が渦巻く中、手探り状態でのスタートでした。

このタイミングで自分が『探検ドリランド』にジョインしたんですが、謎解きイベント会場となった八丈島内で「挑戦者を正解に導くヒントマンになる」というのが最初の仕事でした(笑)。

初リアルイベントに参加したプレイヤーさんからは『探検ドリランド』がもっと好きになりました、次回も参加したいです、などのポジティブな声が寄せられ、反応も良かったため、次に開催したのが東京でのオープンイベント「キングスアカデミー」でした。

このイベントもかなり好評で、次のタイミングでは東京と大阪の2都市で「探検ドリランドファン感謝祭 ~キングスアカデミーフェスティバル~」を開催し、ここでもプレイヤーさんと運営が楽しく交流できました。来場者が両都市で約2,000名規模になったのも驚きでしたね。

もちろん、増える来場者にあわせて、運営チームメンバーにもQ&Aを大量に用意して、様々な角度からのプレイヤーさんの質問に対応していたことで、規模が大きくなっても年々満足度を高めていくことができました。

佐伯:来場者2,000人ってスゴイです。大変だけど価値のあるイベントになったんですね。

井口氏:さらにもうひとつの施策として『探検ドリランド』10周年を迎えて何かやろうと思ったときに、休眠プレイヤーさんにアプローチするために、CMなどでおなじみの「ド、ド、ドリランド♪」のフレーズを使うプランを考えました。

ですが、有名人を使って無難なプロモーションをするだけでは、いまいち盛り上がらないと考え、比較対象にすらならないだろうアフリカの部族の人をアサインして、特別なお祝い動画を作ることを考えました。

佐伯:アサインって……(笑)。

井口氏:改めて動画を見ても、結構振り切ってますね~(笑)。これは僕が「世界ウルルン滞在記」や「探検隊シリーズ」が好きなので、そんなドキュメンタリーっぽいニュアンスを入れてみたんです(笑)。

この時期にはキャンペーンを同時に実施していたので、動画の効果はハッキリ分析はできていないんですが、休眠プレイヤーさんはかなり復帰してくれました。さらに、既存プレイヤーさんにも「まだこんなおもしろいことやってるんだ」と、10周年を迎えてもまだ、おもしろさが続くことを理解してもらえたのが良かったですね。

佐伯:10周年でこんな奇抜な動画が作られるなんて、プレイヤーさんも驚きますよね。

井口氏:ただ、この動画の準備期間のほかに、撮影クルーのワクチン接種に数ヶ月かかってしまったのは想定外でした……(笑)。

佐伯:これを踏まえてではないですが、『怪盗ロワイヤル』はさらにこの企画を超えていかなきゃいけない企画力が必要ですね(笑)。

下島:この動画の後に話すのは非常にツライんですが……(笑)。『怪盗ロワイヤル』でも長期運営に関わらず、これまでになかった取り組みを続けていき、プレイヤーさんに新しい体験を届けたいと考えています。

最近では、『探検ドリランド』とのコラボがトピックスですね。もともとIPコラボは年に何回か実施していたんですが、ゲームタイトル同士のコラボは初めてでしたし、これまでやったことのないTwitterキャンペーンなども実施し、イベントとしても、売上にもすごく効果がありました。

また、某飲料メーカーとのコラボも実施し、飲料水を擬人化してボスとして登場させるイベントを企画しました。上位のプレイヤーさんに、インセンティブとして飲料水を1ケースを贈るといった、なかなかインパクトのあるリアルインセン企画でした。

しかし企画を進める中で、攻撃時に銃に撃たれるエフェクトに対して先方様からNGが出てしまい、メンバーと思案した結果、そのエフェクトの代わりに、その飲料水に含まれる成分名を表示するエフェクトを提案して認めてもらう、といった裏話もありました。

このように確かな結果だけを狙うだけではなく、ちょっとユニークな取り組みも積極的にやることが、長期運営タイトルでプレイヤーさんに飽きられない秘訣なのかも知れませんね。

佐伯:普段は誠実に運営してるからこそ、たまに繰り出すパンチが強烈でウケる、ということもありますよね。

下島:そうですね。このコラボ自体が掲示板でも話題に上がってくれて、結果プレイヤーさんは楽しんでくれたようです。

佐伯:10年運営していたら、だいたいのことはやってるわけじゃないですか? その中で突拍子もないことを意識してやるのは大事ですね。

井口氏:ですね。ある程度のネタは、先人たちがやってしまっているので、同じような路線で攻めてもダメなんです。そんな理由で「10周年でアフリカだ!」と思いついたところでもあります(笑)。

また、こんな突拍子もない企画を実現していると、プレイヤーさんも楽しみにしてゲームから離れなくなりますし、『怪盗ロワイヤル』とのコラボについても社内で賛否両論あったんですが、この10周年記念動画で残した実績があったんで、力強く提案できました。

佐伯:グリーとDeNAってお互いライバルみたいな関係性に近かったので、なかなかインパクトがあるコラボだったんですが、信頼関係を得るような、相乗効果も生み出したんですね。

下島:自分たちが思っている以上にプレイヤーさんは両社の関係性は気にしていないこともわかって、ブッ飛んだコラボをやっても受け入れてもらえる事例ができたので「何でもやってみよう!」みたいな挑戦する楽しみは増えましたね。

佐伯:運営側が本気で楽しもうとする姿勢が、プレイヤーさんに伝わっていたんですね。

下島:確かにそうかもしれません。某飲料メーカーさんとのコラボのときは、自分たち運営が一番楽しんでいましたね。飲料水のキャラクターに手足を生やすアイデアをチャットで話していたら、それを見たデザイナーがささっとデザインを作ってくれて「これ、おもしろいからやりましょう!」って話が広がりました。

これからの10年に向けて

佐伯:最後のお題ですが、今後の10年に向けて、両タイトルの展望などをお聞かせください。

井口氏:自分たちの強みとしては、長期運営タイトルにおける「圧倒的な休眠プレイヤー数」だと思っています。

世の中のゲームの戦略では「新タイトルをリリースするときに、新規プレイヤーさんを多く獲得する」ことが普通です。

ですが、『探検ドリランド』では新規と休眠どちらも狙うミッションがあり、戦略方法はまったく違うので悩みました。新規なら他のゲームとの勝負、休眠なら懐古心をあおるような攻め方が必要になるんです。

そこで自分たちは他にはない強み、絶対的な優位性を保てる休眠プレイヤーさんに復帰してもらう戦略を選びました。休眠プレイヤーさんを獲得するメリットは、復帰してすぐに成果が出やすく、売上に早くつながるからです。

一方で新規の獲得手法や事例は多いんですが、休眠の復帰事例は少ないため、A/Bテストの繰り返しや、先ほど紹介した10周年動画のような手法も含め、日々試行錯誤を繰り返しながらさらなる成長を目指して、チームとして頑張っていきます。

下島:この先20年、30年とサービスを続けて「怪盗ロワイヤルってまだ続いてるんだ」と多くの人に驚かれるくらいに運営を続けていきたいと思ってます。

また、長く遊んでいるユーザーさんには、『怪盗ロワイヤル』がライフサイクルの一部になっている人もいるので、その人たちの生活の潤いのためにも、自分たちの使命はとにかく長く続けることだと考えています。

事業面では、長期タイトルとして仕組み化を基軸とした一つモデルケースになりたいと思っています。一種の教科書として長期運営のためのノウハウを他タイトルにも伝えていきたいですね。

また、組織面では持続的に成果を上げ続けられる組織を目指し、人の入れ替わりなどがあってもずっとタイトルを運営し続けられる自走集団を作れたらいいな、と思っています。

佐伯:2人とも、とても熱い想いを語ってくれました。本日はありがとうございました! 

懇親会の様子

イベント後に開かれた懇親会では、登壇した井口氏と下島を囲んで積極的な交流が行われました。今回の開催場所はDeNA本社のSAKURA Cafeとなったため、カフェ手作りのフードが振る舞われました。

さらに特別メニューとして、横浜スタジアムで提供されているベイスターズオリジナル「ベイ餃子」も並びましたよ!

取材・文:細谷亮介

■関連リンク

https://genom.dena.com/event/20190621_gdm_interview/

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

GeNOM(ゲノム)とは

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

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

[/su_note]

【GDMイベントレポ】ゲーム要素のコントロールと感情の対応関係とは?「2次元感情マップに基づくメタAI:里井大輝氏」

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

2019年5月17日に開催された「GDM Vol.32 エンジニア向け勉強会:ゲーム産業におけるゲームAI研究・開発の最前線~会話AI、メタAI、ユーザ感情推定~」では、スクウェア・エニックスのテクノロジー推進部のメンバーをお招きして、GDC2019で発表した内容を中心に、最新の研究成果を紹介していただきました。

本記事では、スクウェア・エニックス テクノロジー推進部 AIリサーチャー「里井 大輝」氏より発表された「2次元感情マップに基づくメタAI」について、セッション内容をレポートします。

2次元感情マップに基づくメタAI

里井氏は冒頭で、自分の作っているゲームにメタAIをどのように適応させればいいか、イメージすることがなかなか難しい理由を語りました。

キャラクターAIなら賢そうに動く、ナビゲーションAIなら上手に経路探索してくれる、と役割がわかりやすいですが、メタAIはゲームを面白くするのにどうしたらいいかを判断するという、人間でもなかなか答えを判断できない難しいことをAIに任せているのが現実だと話しました。

例えば、ゲームのバトル部分について、プレイヤーキャラ・味方NPC・敵NPCが配置されているフィールドがあるとします。

このバトルを「面白くしてください」と言われたときに、何をどこまで改修するかを考えたときに、「プレイヤーが使える装備は大量にある(かも)」「各敵NPCは大量のパラメータを持っている(かも)」「このゲームには大量のレベルがある(かも)」などなど、想像できる要素が多く、バトルを面白くするのは容易ではありません。

このような場合、メタAIを使えば、ゲーム全体をまとめてコントロールすることが可能ですが、どの要素をどのようにコントロールすれば面白くなるのかを判断するのが、難しいポイントです。

ゲーム要素のコントロールの項目には「仲間NPCにプレイヤーを回復させる?」「敵NPCにもっとうまく回復させる?」「敵NPCにもっと強力な攻撃を使わせる?」など考えられることは無数にあります。

ここで達成したいことは「プレイヤーの感情を知り、それを特定の方向に動かす」ということです。例えば「ナーバスな気持ちのときは警戒させたい」など、企画している人はこのようなことを考えてシステムに落とし込んでいるはずです。

そこで、ゲーム要素のコントロールと、感情の動かし方との対応関係について考えます。

先行事例では、『Left 4 Dead』や『Warframe』のメタAIについて、GDC2009で発表された緊張度(intensity)に基づくメタAI(AI Director)について提案されています。

これは、ゲームのプレイログから計算したプレイヤーの緊張度が、周期的に上昇と下降を繰り返すようにコントロールすることで、プレイの流れに緩急をつける(ペーシング)ことができます。新規にスポーンする敵NPCの数や位置を変動させて、緊張度をコントロールしています。

このAI Directorの問題点は、多くのゲームでNPC数をメタAIの判断で変えることができないことです。シューターや格闘ゲーム、カードゲームなど、キャラクターやオブジェクトの数が固定されているゲームは実装が難しいと思われます。もし固定されていなくても、ゲームデザインやレベルの制約によって、メタAIが望んだタイミングや位置にNPCをスポーンさせることが難しいです。

もうひとつの問題点は、扱える感情の種類が少ないことです。これを解決するためキーアイディアが「2次元感情マップ」になります。

これは、プレイヤーの感情を横軸「勝利への期待感(H:Hope of Winning)と縦軸「敗北への不安感(F:Fear of Losing)を軸として、2次元平面上のベクトル(EP:Emotion Point)で表示します。このマップは認知心理学での感情分類モデルを参考にしています。

2次元感情マップが便利な理由は、さまざまなプレイヤーの感情とゲーム状況を紐付けて表現できることです。ここでは格闘ゲームを例として4つのケースを紹介します。

Case1:敵がプレイヤーを圧倒

勝てそうではなく、負けそうだと思っているため「ナーバス・ストレス」になります。

Case2:プレイヤーが敵を圧倒

勝てそうだと思い、負けないと思っているため「穏やか・リラックス」になります。

Case3:激戦

同じくらいの力量で殴り合っている状態は「勝てそうだけど負けるかも?」と言う気持ちで「興奮・うれしい」になります。

Case4:膠着状態

どちらも何もできず、動きが少ない膠着状態では、勝てそうではないけど負けそうでもない気持ちになり「落ち込んだ・退屈」となります。

このように直感的に感情のイメージと、HopeとFearの高低の対応ができていることがわかり、ゲームの状況を複雑に表現できます。

また、このマップを使うと、ゲーム要素と感情変化の対応付けを設計しやすくなるメリットがあります。

この手法の概要として、まずSensorsがゲームプレイデータを収集、メタAIで判断し、Effectorsでゲームワールドを操作します。本セッションでは2次元感情マップに基づくメタAIの内部機能「World Analyzer」「Game Maker」について詳細を公開します。

「World Analyzer」では、Current EPがプレイヤーの現在の感情を2次元座標でまず表示します。それを元に、数秒後にプレイヤーの感情が向かって欲しいポイント「Goal EP」を決め、続いて次にプレイヤーの感情を持っていく場所「Next EP」を更新します。

つまり、具体的なゲーム環境への操作は「Next EP」をベースにして決めていくということです。

格闘ゲームを例にすると、プレイヤーキャラと敵NPCがそれぞれHPと攻撃ヒット率を持っています。それぞれがHPは満タン、ヒット率50%の状態では、プレイヤーのヒット率が高ければ高いほどHope値は上がり、敵NPCのHPは低いほどHopeが高くなります。

逆に、プレイヤーのHPが低ければFear値が上がり、敵のHPが高ければFear値が上がります。

Current Hopeの計算方法の例として、攻撃ヒット率やHPの残量によって、変動するカーブ値を用意し、それぞれの評価値を足して判断します。

また、ゲームの状況が変わり、プレイヤーの攻撃ヒット率が60%に上がり、敵のHPが下がった場合は、Hopeの値が少し上がり、Current EPの数字が右にズレます。

Goal EPのプランニングについて、決め方はゲームデザインに大きく依存します。あるプロジェクトでは5秒ごとにCurrent EPの反対側に設定し、メタAIがプレイヤーの感情を常に揺さぶろうと試みました。

また、便利機能としてGoal EPにバイアスをかけることができ、あるプロジェクトではGoal EPの移動可能範囲を、バトルに進行度に応じて狭める処理をしており、終盤に向けて興奮もしくは幸せの感情になっていくと思われます。

この仕組みの良い点は、ゲームデザイナーがプレイヤーがどのように感じてほしいか、平面上で直接視覚的に設定できることです。

続いて、Next EPの更新にて、どうやってゲームをコントロールするのかを説明しましょう。

格闘ゲームを例にすると、Hope値は敵がプレイヤーに対してどれくらい攻撃しやすいか、という要素と結びつきます。危険な攻撃の使用頻度や、攻撃の開始距離(避けにくさ)に影響します。

Fear値は、プレイヤーが敵に対してどれくらい攻撃しやすいかという要素に結びついており、スキを見せる行動の使用頻度や使用距離、プレイヤーの攻撃に対する反応速度などに影響します。

これをまとめると、ゲームジャンルに対して「Current EPに影響を与えるもの」「Next EPから影響を受けるもの」という要素があることが考えられます。

単純な1on1バトルを用いたデモで、プレイヤーと敵NPCモデルと、2D感情マップのデバッグ表示が公開され、Next Fearが高い状態だと敵は避けにくい攻撃を使用する様子が、モデルの動きとともに確認することが可能です。

反対にNext Fearが低い場合(プレイヤーのHPが瀕死状態)は、敵は避けやすい攻撃を使うことが分かります。メリットとして、AIに「敵を攻撃しなさい」という指示を与えれば、内部でどの攻撃アクションを選択するのか、Next EPを見て攻撃種の区別をしてくれることです。

スクウェア・エニックス テクノロジー推進部 AIリサーチャー「里井 大輝」氏

この仕組みを実際にゲームで利用するには、大量のデータ収集が必要になるため、ブラウザベースの「ゲームプレイ分析ツール」を導入しました。このツールでは、2次元感情マップ上でのEPの軌跡を表示できます。

感情の強さのタイムライン表示では、8つの感情がそれぞれがどの時点でどう強かったかを可視化しています。この感情の強さの計算は、いろいろな感情が少しづつ混ざった類似度を計算しています。

また、企画側からの要望で、HPやMPのようなステータス情報や「プレイヤーの攻撃がヒット」のようなイベント時の感情の強さを並べて表示し、感情が動いた理由を分析しやすくしています。

この仕組みのテストプレイ時フィードバックでは、ほぼ狙い通りの結果が出ており、ゲームデザイナー側からは、プレイ中の様子を録画しながらメタAI側のパラメータを調整することで、今までのワークフローに比べて改善したとの声が上がっています。

最後に里井氏は、今後の展望として、最近プレイヤーが経験した感情に次は向かないようにする「ヒートマップ」や、Goal EPのプランニングに位置検索システムを導入する、などさまざまな可能性があることを語りました。

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

▼関連レポート記事はこちらから

■イントロダクション ゲームAI研究・開発の全容:三宅 陽一郎氏

■キャラクターとのインタラクション:Gautier BOEDA(ボエダ ゴティエ)氏

■メタAIの基本モデルとゲームデザイナーの役割:水野 勇太氏

※本記事は2019年5月時点の情報です。

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

GeNOM(ゲノム)とは

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

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

[/su_note]