イベント

2019.12.05

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

  • Facebookでシェア
  • Twitterでツイート
  • はてなブックマークでブクマする!
  • LINEで送る
  • follow us in feedly
  • Facebookでシェア
  • Twitterでツイート
  • はてなブックマークでブクマする!
  • LINEで送る
  • follow us in feedly

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

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

◆登壇者

長谷川 誠 氏

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

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

◆パネラー

佐藤 勝彦

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

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

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

季節のデザート

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

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