特許 7551287 データ処理システムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-09-06

(45)【発行日】2024-09-17

(54)【発明の名称】データ処理システムおよび方法

(51)【国際特許分類】

   A63F 13/60 20140101AFI20240909BHJP

   G06F 11/36 20060101ALI20240909BHJP

【ＦＩ】

A63F13/60

G06F11/36 188

G06F11/36 184

G06F11/36 192

【請求項の数】 10

【外国語出願】

(21)【出願番号】P 2019199652

(22)【出願日】2019-11-01

(65)【公開番号】P2020108733

(43)【公開日】2020-07-16

【審査請求日】2022-08-05

(31)【優先権主張番号】1818293.1

(32)【優先日】2018-11-09

(33)【優先権主張国・地域又は機関】GB

(73)【特許権者】

【識別番号】310021766

【氏名又は名称】株式会社ソニー・インタラクティブエンタテインメント

(74)【代理人】

【識別番号】100105924

【弁理士】

【氏名又は名称】森下 賢樹

(72)【発明者】

【氏名】ファビオ カッペッロ

(72)【発明者】

【氏名】グレゴリー ジェームズ ベッドウェル

(72)【発明者】

【氏名】バーナード ジョセフ コリー

【審査官】柳 重幸

(56)【参考文献】

【文献】特表２０１６－５２４７３０（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１５／０２１７１９８（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ａ６３Ｆ １３／００－１３／９８

Ｇ０６Ｆ １１／３６

(57)【特許請求の範囲】

【請求項1】

データ処理システムであって、
コンピュータゲームのコンピュータゲームプレイに関する情報を受信するように動作可能な情報入力部と、
前記受信された情報にもとづいて前記コンピュータゲームにおけるエラーの指標を特定するように動作可能なエラー特徴付け部と、
前記コンピュータゲームにおける１つまたは複数のプレイテストボットを制御して前記コンピュータゲームに対するプレイテストデータを生成するように動作可能なプレイテスト制御部であって、前記プレイテストデータは、前記特定されたエラーの指標に関する情報を含む、プレイテスト制御部と、
前記プレイテストデータに応じてエラーを特定するように動作可能なエラー報告部とを含み、
前記プレイテスト制御部は、前記１つまたは複数のプレイテストボットに前記コンピュータゲームの人間のプレイヤによって実行されるインタラクションをシミュレートさせるように動作可能であり、
前記エラー特徴付け部は、コンピュータゲームプレイの停止、視覚的エラー、インタラクションエラー、および／またはオーディオエラーのうち１つまたは複数を含むエラーの指標を特定するように動作可能であり、
前記プレイテスト制御部は、人間のプレイヤによって前記コンピュータゲームを通じて取られるパスを前記１つまたは複数のプレイテストボットにシミュレートさせるように動作可能である、データ処理システム。

【請求項2】

前記プレイテスト制御部は、前記１つまたは複数のプレイテストボットによって実行されるアクションに関するコンピュータゲームプレイ統計を記録するように動作可能である、請求項１のシステム。

【請求項3】

前記コンピュータゲームプレイ統計は、コンピュータゲームプレイの進み具合および／または難易度を示す、請求項２のシステム。

【請求項4】

前記プレイテスト制御部は、単一のゲーム内オブジェクトとのありうるユーザインタラクションの範囲を表すテストルーチンを前記プレイテストボットに実行させるように動作可能である、請求項１のシステム。

【請求項5】

前記プレイテスト制御部は、前記コンピュータゲームにおける特定の場所でユーザに利用可能なインタラクションの数と種類を示すコンピュータゲームデータに応じて、前記プレイテストボットの行動を制御するように動作可能である、請求項１のシステム。

【請求項6】

前記プレイテスト制御部は、教師データの分析に応じて、前記プレイテストボットの行動を制御するように動作可能である、請求項１のシステム。

【請求項7】

前記教師データは、以前のプレイテストデータ、コンピュータゲームプレイのビデオ、既知のバグ検出方法、および／またはコンピュータゲーム情報のうち１つまたは複数を含む、請求項６のシステム。

【請求項8】

コンピュータゲームのコンピュータゲームプレイに関する情報を受信するステップと、
前記受信された情報にもとづいて前記コンピュータゲームにおけるエラーの指標を特定するステップと、
前記コンピュータゲームにおける１つまたは複数のプレイテストボットを制御してプレイテストデータを生成するステップであって、前記プレイテストデータは、前記特定されたエラーの指標に関する情報を含む、ステップと、
前記プレイテストデータに応じてエラーを特定するステップとを含み、
前記プレイテストデータを生成するステップは、前記１つまたは複数のプレイテストボットに前記コンピュータゲームの人間のプレイヤによって実行されるインタラクションをシミュレートさせ、
前記エラーの指標を特定するステップは、コンピュータゲームプレイの停止、視覚的エラー、インタラクションエラー、および／またはオーディオエラーのうち１つまたは複数を含むエラーの指標を特定し、
前記プレイテストデータを生成するステップは、人間のプレイヤによって前記コンピュータゲームを通じて取られるパスを前記１つまたは複数のプレイテストボットにシミュレートさせる、方法。

【請求項9】

コンピュータによって実行されたとき、前記コンピュータに請求項８の方法を実行させる、コンピュータソフトウェア。

【請求項10】

請求項９のコンピュータソフトウェアを格納する非一時的機械可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、データ処理システムおよび方法に関する。

【背景技術】

【0002】

コンピューティングの初期の頃、コンピュータゲームは典型的には、少数の可能なインタラクションを伴う線形コンピュータゲームであった。ユーザは、コンピュータゲームが進むにつれて難易度が増していくという所定のパスに沿って（または特定の方法で目標に向かって）進むことがしばしば期待された。限定的または線形コンピュータゲームプレイの進行を提供することにより、コンピュータゲーム開発者のためのプレイテストプロセスはかなり単純になった。バグやグリッチを見つけるために、開発者がコンピュータゲームの可能な状態の大部分を探索できるようになるのに必要な時間はわずかであった。

【0003】

バグやグリッチの例には、コンピュータゲームの望ましくないパフォーマンスが含まれる。たとえば、ユーザに表示される１秒あたりのフレーム数の低下は、この点で問題として特定される。バグやグリッチの他の例には、エレメントの誤った色、クリッピングエラー、コンピュータゲームのクラッシュ、およびプレーヤが逃げられないシナリオ（オブジェクトの後ろに引っかかっているなど）が含まれる。

【0004】

もちろん、コンピュータハードウェアの能力と利用可能性が長年にわたって向上しているため、開発されているコンピュータゲームの複雑さと範囲がそれに対応して増加している。たとえば、「オープンワールド」スタイルのコンピュータゲームが増加しているが、その中でユーザは大きな地図を与えられ、（ゲーム内オブジェクトまたはキャラクタなどとの）ゲーム内インタラクションがない時でさえ、地図を探索して多くの時間をかけて完全に旅行してまわることができる。これにより、可能なコンピュータゲームの状態が非常に多くなり、それは以前のコンピュータゲームよりもしばしば多様である。

【0005】

このように複雑さが増した結果、最終バージョンにバグがないこと（または、少なくともリリースするのに十分なレベルで機能すること）を確認するテストプロセスがはるかに困難になっている。コンピュータゲーム開発者がコンピュータゲームの可能な状態のほんの一部をテストできるようにするためには、コンピュータゲームに存在するバグを発見し、その後修正する目的でコンピュータゲームをプレイするのに何年も費やさなければならなくなるであろう。

【0006】

したがって、包括的で自動化されたテストを提供できる方法を提供することが望ましい。これは、（ヒューマンテスタたちに提供されなければならない休憩を要求することなく、いわば継続的に）すべての時間で実行されるべきテストを可能にし、多数が並列に実行されることで、数年の価値のあるコンピュータゲームプレイのテストが短時間に凝縮される。たとえば、１週間に１日２０時間稼働する１０の自動テストシステムを使用すると、１人がほぼ半年間、１日８時間かけてテストするのと同じ量のテストを実行できる。

【発明の概要】

【発明が解決しようとする課題】

【0007】

しかし、包括的、高品質のテストを行うための自動化システムは、現在利用可能ではなく、コンピュータゲームによって出力される１秒当たりのフレーム数の低下やコンピュータゲームのクラッシュなどの問題だけを自動プレイテスタによって特定することができる。これに加えて、自動化されたシステムは、ゲーム内世界を通じて単にランダムなパスを採用する場合がある。これは、一部のエリアが完全に見落とされる可能性があり、（よりインタラクティブな要素を含むエリアなど）より広範なテストを要するエリアがこのような構成では十分にテストされない可能性があることを意味する。

【0008】

したがって、他の種類のバグやグリッチを見つけるとともに、テストを用いてゲーム内世界を十分にカバーできるようにするために、かなりの量の人間の時間をプレイテストに費やす必要がある。

【0009】

本発明が生じるのは、上記の問題の文脈においてである。

【課題を解決するための手段】

【0010】

本開示は、請求項１および１３で定義される。

【0011】

本開示のさらなる態様および特徴は、添付の特許請求の範囲に定義される。

【図面の簡単な説明】

【0012】

本発明の実施の形態を、添付図面を参照して例として説明する。

【図1】ゲーム内世界地図を概略的に示す。

【図2】代替パスを持つゲーム内世界地図を概略的に示す。

【図3】ゲーム内世界の一人称視点を概略的に示す。

【図4】インテリジェントプレイテストシステムの一例としてのデータ処理システムを概略的に示す。

【図5】インテリジェントプレイテスト方法を概略的に示す。

【発明を実施するための形態】

【0013】

ゲーム内世界地図の模式的な例を、地図を通してプレイテスタ（自動または人間）がたどるパスの例とともに図１に示す。

【0014】

地図１００は、ゲーム内世界の簡略化されたビューであり、たとえば、コンピュータゲームのイベントが行われる島であり、プレイヤが自由に探索することができる。多数の例示的な環境的特徴－山脈１２０、村１３０、湖１４０、および森林１５０が地図１００上に示されている。もちろん、この例は限定と見なされるべきではない－本出願内で議論される方法は任意の仮想環境に等しく適用される。

【0015】

パス１１０は、プレイヤまたはプレイテスト「ボット」が取ることができる例示的なプレイテストルートを（矢印で示される進行方向ともに）例示する地図１００上に示されており、この例ではボットが地図のエッジに到達する時、新しい方向がランダムに選択される。このアプリケーションでは、ボットとは、プレイヤが期待されるのと同じ方法でゲーム内環境とインタラクションするために使用できる仮想プレイヤをシミュレートするスクリプトを指す。

【0016】

この画像からパス１１０の明らかな欠陥が明白である。パスは、地図１００のすべての主要なフィーチャを簡単に見逃し、代わりに地図１００の（比較的）フィーチャのない部分を通過する。パスの最後１６０は、地図１００のメインエリア１８０に戻る狭いパスのために、ボットがトラップされるようになる可能性がある地図１００の狭い部分１７０にある。

【0017】

図２は、地図１００を巡る改善された経路２００の例を概略的に示す。パス２００はすぐに、オブジェクトおよび／またはＮＰＣ（非プレイヤキャラクタ）との多くの相互作用を含む可能性が高いエリアとして村１３０を調べるようになる。次に、パス２００は山脈１２０に向かって移動するが、プレイヤが入ることができる／許可されるエリアではない可能性があるため、山脈１２０に入ることはない。次いで、パス２１０は、森林１５０に至る前に湖１４０に近づき、周回し、通過する。そのようなパスは、例えば、オペレータによって事前設定されてもよく、または他の方法（以下でより詳細に説明する）で決定されてもよい。

【0018】

図３は、プレイヤに表示されるコンピュータゲームの一人称ビューを概略的に示す。このような画像は、プレイテストに使用されているボットに対しても生成される。いくつかの実施の形態では、画像または画像内のオブジェクトの特性を決定するために、ボットが何らかの形態の画像分析を実行するように動作可能であることが有利であると考えられる。以下にいくつかの例を示すが、これらはもちろん非限定的なものと見なされるべきである。

【0019】

次の例は、主に表示の問題に焦点を当てている。これらは、コンテンツを見ているプレイヤにはすぐに明らかになるバグまたはグリッチであるが、（１秒あたりのフレーム数とは違って）コンピュータゲームプレイ統計からは明らかではない。この結果、従来の自動化されたプレイテスト構成では、このような視覚的なエラーを検出することはできない。

【0020】

バー３００は、コンピュータゲームプレイ情報（残っている健康状態など）をプレイヤ（ヘッドマウントテーブルディスプレイ（ＨＭＤ）、ハンドヘルドディスプレイ、または共有モニター画面のいずれが使われようとも）に伝えるために提供されるＨＵＤ（ヘッドアップディスプレイ）を表す。これに関連する視覚的エラーは、変色または誤った値が表示されることであってもよい。このようなエラーは、視覚データとコンピュータゲームデータの比較（コンピュータゲームによって記録された残りの健康状態を表示されたバー３００のサイズと比較するなど）に基づいて、またはフレーム間の色の変化を検出することによって検出されてもよい。

【0021】

地面３１０は、空３２０のように、コンピュータゲームプレイ中に表示される画像の大部分を占める可能性が高い。これらが画像に表示される率がそうであるように、これらのそれぞれはフレームからフレームへ外観において実質的に一定のままであることが予想される。もちろん、表示は移動するカメラおよび／または視点に応じて変化するが、このような動きはいくつかのフレームにわたって発生するため、追跡することができる。ただし、１つのフレームから次のフレーム（または他の適切なしきい値）への大幅な逸脱は、表示エラーとして特定されることがある。このようなエラーの例には、地面の消失、色が変わる空、またはプレイヤの地面への落下が含まれる。

【0022】

家屋３３０は、特定のサイズおよび向きを有すると予想されるオブジェクトの例である。例えば、予想外に大きい家屋または逆さまの家屋は、バグの結果として識別されるべきである。

【0023】

木３４０は、同様の方法で考慮されてもよいが、もちろん、プレイヤに視覚的な多様性を提供するために、木はさまざまなサイズ、形状、および色を有してもよい。したがって、（多くの異なるバリエーションで再利用できるモデルの例として）木３４０に関する視覚的エラーの決定はより複雑であり、それらの間の共通の特徴と異なる値の許容範囲値（たとえば、特定の葉の形と許容される色とサイズの境界を持つ）が識別される。

【0024】

太陽３５０は、コンピュータゲーム内でほぼ固定された位置を有するオブジェクトを表す（ただし、コンピュータゲームは、これを修正する特定の昼夜サイクルを実装してもよい）。したがって、太陽３５０の位置に関する情報を使用して、その位置が期待値から逸脱しているかどうかを識別してもよい。色、形、サイズなどの他の要因も考慮してもよい。

【0025】

視覚的エラーは特定のオブジェクトに関連付けられていることがあるが、場合によっては、オブジェクトの非表示が視覚的エラーと見なされることもある。もちろん、これを検出するのは難しいかもしれない－エレメントが表示されていないことの指標、または利用可能な場所に対して期待されるオブジェクトに関する情報が必要である。

【0026】

ボットが視覚的エラーの検出に使用するパラメータのセットを定義することは可能かもしれないが、そのようなプロセスは時間がかかり、その結果、可能性のあるエラーの小さなサブセットしか検出できないボットになる。したがって、多くの場合、機械学習または人工知能（ＡＩ）ベースの方法を実装することが望ましい。

【0027】

このような方法をうまく実装するには、エラーを特定するようにＡＩボットを訓練する必要がある。訓練プロセスは、任意の数の適切な学習入力を含んでもよい。例えば、後述する入力のうち任意の１つまたは複数を単独でまたは他の入力と組み合わせて使用してもよい。

【0028】

第１の入力の例は、未加工のコンピュータゲームコードやコンピュータゲームに関連付けられた任意のアセット（画像テクスチャなど）である。期待されるコンテンツを識別するために、これらのエレメント上で分析が実行されてもよい。たとえば、色情報は、コンピュータゲームに対する期待値を確立するためにこれらのエレメントから抽出されてもよい。これは、将来のエラースポッティングに役立つことがある。たとえば、コードまたはテクスチャに現れない色が表示されるならば、これはグリッチの結果であると想定されてもよい。任意の他の情報もまたこれらのエレメントから識別することができ、色情報のみに限定されるのではなく、たとえばオブジェクトのサイズ情報が識別される。

【0029】

トレーニングデータはまた、人間の（または他の自動化された）プレイテスタによって生成されてもよい。たとえば、「通常の」コンピュータゲームプレイ（つまり、グリッチやバグがないコンピュータゲームプレイ）がどんなものであるかをボットが確立するのを支援するために、記録されたビデオ映像をＡＩに提供してもよい。ＡＩが通常の操作を最も効果的に判断するのを支援するために、このようなビデオにはバグがないか、バグが強調表示されている必要がある。ＡＩは、たとえば、画像処理方法を使用したり、コンピュータゲームプレイ統計を追跡して異常なコンピュータゲームプレイの顕著な特徴を特定することにより、通常のコンピュータゲームプレイからの逸脱を特定するように備えられるであろう。

【0030】

もちろん、そのような情報は、通常のコンピュータゲームプレイを示すだけでなく、特定のバグを示すためにも使用できる。データ内のバグ／グリッチを識別するために、ビデオコンテンツのマークアップが必要になることがある。

【0031】

ＡＩへの入力として使用されるゲーム情報は、オブジェクトに対するコンテキストを識別するのにも役立つ。これにより、オブジェクトが本来あるべき場所から外れている場合を識別するのに役立つ。たとえば、水生動物は海に関連付けられているため、他の場所で検出された場合、動物が正しく表示されていてもエラーとして識別される。オブジェクトおよび／またはイベントの特定のグループ（特定のキャラクタや武器、ゲーム内のタイミングやイベントなど）を相互に関連付けるなど、単なる場所ベースのエラーではなく、他のコンテキストエラーを特定することも可能である。

【0032】

コンピュータゲームエンジンの実装に関する情報は、自動プレイテスタに対する入力データの一部を形成してもよい。たとえば、特定のグリッチまたはバグがどのように現れるかに関する情報（視覚的エラー、認識すべき一般的なエラー、エラーが発生する特定のシナリオなど）は、エラーを検出する方法をＡＩボットにトレーニングするのに役立つ。たとえば、エラーとして「移動できない」ことを特定することは簡単に認識できるエラーであり、これを含めてもよい。これは、ユーザがオブジェクトなどの背後に閉じ込められるパスエラーを特定するのに役立つ。

【0033】

このような入力は、ＡＩがどのコンテンツが静的であり、どのコンテンツが動的であるかを確立するのにも役立つ。たとえば、ＨＵＤ３００はフレーム間で一貫している必要があり、ＡＩボットはこれをディスプレイのその部分に対する通常の操作として識別できなければならない。

【0034】

コンピュータゲームのリリース後、利用可能なビデオコンテンツの量は指数関数的に増加する。これは、ライブストリームまたはビデオホスティングプラットフォームを介してコンピュータゲームプレイをブロードキャストすることがますます一般的になっているためである。そのようなビデオは、プレイテスタのプレリリースによって生成されるものと同様の方法で入力として使用できる。実際、多くのビデオは、エンターテイメントの価値が非常に高く、特定の価値があるため、視覚的なグリッチを示すためにアップロードされることがよくある。

【0035】

いくつかの実施の形態では、画像処理技術を利用して、いくつかの異なる測定基準のいずれかを追跡することができる。例えば、視覚的エラーを示している何らかの突然の変化を特定するために、画像の全体的なカラーバランスを監視してもよい。これは、任意の適切な方法で実装できる。たとえば、色をより広いカテゴリ（より多くのグループが提供されるかもしれないが、たとえば原色など）にグループ化し、これらの色の全体的な構成を相互に監視してもよい。

【0036】

代替的または追加的に、画像処理は物体認識技術を含んでもよい。これは、オブジェクトの間違ったサイズ／向きまたは表示されている不正確なモデルのような間違った色の表示よりも微妙な表示エラーの識別を可能にする。上記のように、間違った武器を使うキャラクタや間違ったタイミング／場所に登場する動物など文脈上のエラーを特定してもよい。

【0037】

オブジェクト認識は、クリッピングエラーなどがいつ発生し、オブジェクトが正しく表示されないのかを判断するのにも適している。たとえば、キャラクタの腕が固い壁と交差していることや、人が床に落下していることを識別することができる。

【0038】

前述のように、プレイテストボットが取る適切なルートの選択がかなり重要である。

【0039】

ボットが使用するルートの有用性をボットごとまたはグループごとに評価してもよい。つまり、個々のルートはそれ自体では包括的なテストを提供しないことがあるが、異なるルートを使用するボットのグループが補完的なプレイテストルート（たとえば、それぞれが異なるエリアに焦点を合わせるが、地図全体がいっしょにカバーされるようなルート）を選択することによって包括的なテストを提供してもよい。

【0040】

適切なプレイテストルートの選択はコンピュータゲームの設計者によって決定されることがあるが、より効果的なルートを機械学習またはＡＩメソッドを使用して特定してもよい。このような方法の例示的なターゲットは、ゲーム内環境の包括的なカバレッジを提供すると同時に、バグが発生すると予想される（または発生する）エリアでより完全なテストを提供するルートの選択である。そのような領域の例には、プレイヤがより多くの時間を費やし、および／またはより多くのインタラクションを実行することが期待される領域、および／またはバグがすでに報告されている領域が含まれる。

【0041】

ボットが取るルートのプロットは、ボットがルートをどのように移動するかに関するより具体的な情報も含んでもよい。たとえば、ボットは、旅行中に走ったり、歩いたり、ジャンプするように構成してもよく、設定された数または種類のインタラクションを実行するように構成してもよい。たとえば、走りながらパス上で実行可能なインタラクションの５０％を実行するボットは、パス上で歩きながら実行可能なインタラクションの７０％を実行するボットよりもはるかに多くの仮想環境を探索することができる。

【0042】

いくつかの実施の形態では、ボットは等しいプレイテスト能力を持たないと考えられる。たとえば、第１のボットは、間違った色が表示されたときに識別するように構成してもよく、第２のボットは、オブジェクトが誤ったサイズおよび／または向きで表示されたときに識別するように構成してもよい。これにより、たとえば、各ボットに対する時間と処理の要件が削減され、さまざまな領域に、これらの領域で発生する可能性が最も高いバグまたはグリッチに応じて、さまざまなボットを向けることができるようになる。

【0043】

ボットのトレーニングに使用できるトレーニングデータは、発生する可能性のあるゲーム内イベントやインタラクションを示すコンピュータゲームデータを含んでもよい。たとえば、この情報は、ゲーム内環境のさまざまな領域（コンピュータゲームの進行状況に依存してもよい）のプレーヤインタラクション可能なエレメント（オブジェクトやＮＰＣなど）の密度に関するデータを含んでもよい。

【0044】

ボットによって実行される相互作用には、いくつかの異なる機能が含まれてもよい。インタラクションの例には、オブジェクトの獲得／使用やＮＰＣとの会話などがある。代替的または追加的に、インタラクションは、プレイヤが実行する可能性のあるアクションの少なくとも一部をシミュレートするために、異なる角度からオブジェクトに登る／ジャンプするようなものであってもよい。いくつかのケースでは非常に特定の状況下でのみバグがトリガーされる可能性があり、したがってバグを特定するためにさまざまな条件下で類似のインタラクションをテストする必要があるという事実を考慮するとこれは有益である。

【0045】

さらなるトレーニングデータには、同じコンピュータゲーム環境または異なるコンピュータゲームのいずれかで、以前にバグを特定するのに効果的であることが判明したボットの行動情報が含まれてもよい。同じジャンルのコンピュータゲームが多くの転用できるスキルと類似したコントローラ入力を持っているのと同じように、バグを見つけるために使用されるボットのアクションはコンピュータゲーム間で類似している可能性がある。

【0046】

ボットまたは人間のプレイテスタによって生成された以前のプレイテスト情報は、プレイテストボットをトレーニングするために使用することができる。たとえば、すでに特定されているバグやグリッチの発生に関する情報を活用してもよい。これは、バグのホットスポット（すなわち、バグが最も発生するか、大量のバグを生成する相互作用がある領域）、テストする必要はないバグ（いくつかのテストを省略してもよい）、および／またはバグの指標（オブジェクトが正しく表示されないときに表示される特定の色など）を識別するのに有用である。

【0047】

視覚的なバグの特定のみに限定するのではなく、コンピュータゲームの設計に関連する他の問題も監視してもよい。そのような問題の１つの例は、コンピュータゲームの進行中に特定の難易度曲線を維持することである。コンピュータゲームにおいて、難易度が徐々に増加することがしばしば望ましい。難易度が大幅に増加することによりプレイヤが特定の時点で圧倒されることはなく、難易度が増加しないコンピュータゲームが挑戦されずに残ることがないようにするためである。したがって、バランスの問題（または望ましくない難易度曲線）を本出願の文脈におけるエラーと見なすことが適切かもしれない。

【0048】

コンピュータゲームを設計する際、コンピュータゲームを完全にプレイしなければ難易度を測定するのが難しい場合が多く、現在のコンピュータゲームでしばしば提供される非線形コンピュータゲームプレイでは、かなりの数のプレイスルーを用いても難易度を評価することは難しい。たとえば、プレイヤが任意のセットの装備またはスキルをもって（無理のない範囲で）進行することが可能であるべきであり、そうであるかどうかを判断するためにはプレイテスタによるかなりの量のテストが要求される。

【0049】

同様に、コンピュータゲーム内のバランスを考慮することもできる。これは一般的に、コンピュータゲームのさまざまなオプションの範囲がどれだけ実行可能であるかを示す。たとえば、コンピュータゲームは、単一の明らかに最適なパス（取得するアイテムやスキルのセット、または採用する特定の動作など）が存在し、不均衡に高い成功のチャンスを提供する場合、バランスが悪いと見なされてもよい。バランスのとれていないコンピュータゲームは、多様性の量が減るため、バランスのとれたコンピュータゲームほど楽しくないかもしれない。ほとんどのプレイヤは、最も実行可能な（つまり、最強の）戦略を自動的に採用する。

【0050】

人間のプレイテスタは、たとえば成功のしやすさに基づいて、コンピュータゲームがどれくらい難しいかというアイデアを簡単に開発できる場合があるが、これは主観的であり、ユーザ体験のような要因（たとえば、類似のコンピュータゲームをプレイしたユーザはコンピュータゲームがより簡単に思えること）やコンピュータゲームを介してユーザがたどったパスに依存する。コンピュータゲームデータのみ（敵のダメージ値など）が与えられた場合に難易度の評価を実行することは困難であり、実際のプレイテストが必要になることがある。これらの問題と、開発プロセス全体で必要となる膨大な数のプレイテストとを考えると、コンピュータゲームのバランスや難易度の評価を自動プレイテストの構成に含めることができることは有用である。

【0051】

このような機能を実装するためには、難易度を特定するために使用することができる情報を取得するための自動化されたプレイテストボットが必要である。たとえば、敵を倒すのにかかった時間、死亡数、（ゲーム内イベント、コンピュータゲームの最後など）特定のチェックポイントに到達するのにかかった時間、プレイテストボットおよび／または敵の１秒あたりの平均ダメージ、または特定のキャラクタ／プレイスタイル／アイテムの勝率を取得する。もちろん、難易度の指標として使用される可能性のある任意の他の代替情報または追加情報も収集してもよい。

【0052】

そのような情報の収集は、特定の時間における難易度またはバランスが特定されるように、時間依存の方法で実行されてもよい。これは、たとえばコンピュータゲーム全体で望ましい難易度曲線を実装するのに役立つ。これは、未加工のコンピュータゲームプレイ時間の観点から、またはたとえば到達されたゲーム内マイルストーンに基づいて測定されてもよい。

【0053】

このような方法は、それぞれが同じバイアスと能力を共有する「プレイヤ」（つまり、プレイテストボット）を使用して大量のプレイテスト時間を生成することができるという利点がある。適切な数のプレイテストで結果を集計することにより、コンピュータゲーム全体の難易度を特定することができる。もちろん、収集されたデータを実際のユーザ体験に関連付けることができるようにするためにキャリブレーションを実行する必要があるかもしれない－例えば、人間のプレイテスト及びボットのプレイテストは、コンピュータゲームの同じバージョン上で実行されてもよく、その後、ボットのプレイテストは、（絶対的な難易度の値を測定するのではなく）コンピュータゲームに対する変化に基づいた難易度の変化を測定するために使用される。

【0054】

上記の効果を達成するためにＡＩシステムをどのように実装するかの例を提供するために、いくつかの例を提供する。もちろん、これらは限定と見なされるべきではなく、任意の適切な方法を使用してもよい。

【0055】

たとえば、敵対的生成ネットワーク（ＧＡＮ）を使用してボットをトレーニングしてもよい。このようなネットワークのターゲットはグリッチとの遭遇であってもよく、特定のアクション（生成された入力）を実行することによりこれを達成してもよい。グリッチの原因となるアクションは、（上記のような）トレーニングデータセットから特定されてもよく、識別器は、グリッチに遭遇したかどうかに基づいてトレーニングデータと生成された入力を区別するように動作可能である。有用なトレーニングデータの例には、グリッチを含むコンピュータゲームプレイのビデオ（コンピュータゲームの一部をスキップするためにグリッチをしばしば悪用するコンピュータゲームの高速実行など）またはグリッチを含まないコンピュータゲームプレイビデオが含まれる。前者においてＧＡＮはトレーニングデータに示されている行動パターンをエミュレートするように指示されるべきであるが、後者においてＧＡＮは、トレーニングデータとは異なる行動パターンをエミュレートするように指示されるべきである。

【0056】

この方法で、ＧＡＮを訓練して、グリッチやバグを生成すると予想されるボットの動作パターンを特定することができる。

【0057】

教師あり学習技術もこの目的に利用することができる。たとえば、一対のニューラルネットワークを組み合わせて使用して、バグを特定し、バグにつながる動作を特定することができる。例えば、第１ニューラルネットワークは、バグを特定するために訓練してもよい－訓練は、上述した任意の形態を取ることができ、いくつかの例では、ビデオにおけるエラーに事前にラベルが付けられていることがある。次に、第２ニューラルネットワークを使用して、特定されたバグにつながる動作を特定してもよい。いったん動作が特定されると、ボットによって再作成されてもよい。

【0058】

深層強化学習は、コンテンツのバグやグリッチを生成および／または特定するのに効果的なボットを開発するためのさらなるオプションを提供する。そのような方法は、環境で動作しているボットに「報酬」を提供することに依存する。もちろん、これは従来の意味での報酬である必要はなく、むしろボットのアクションが肯定的な結果（つまり、バグの生成／特定）につながったという承認である。

【0059】

図４は、例えばコンピュータゲームのプレイテスト情報を生成するためのデータ処理システム（インテリジェントプレイテストシステムなど）を概略的に示しており、当該システムは、情報入力部４００、エラー特徴付け部４１０、プレイテスト制御部４２０、およびエラー報告部４３０を含む。

【0060】

情報入力部４００は、コンピュータゲームのコンピュータゲームプレイに関する情報を受け取るように動作可能である。このデータは、例えば、エラー特徴付け部４１０および／またはプレイテスト制御部４２０への入力として使用されてもよい。たとえば、この情報には、コンピュータゲームコード、ビジュアル／オーディオアセット、以前のプレイテストデータ、コンピュータゲームプレイのビデオ、既知のバグ検出方法、および／またはコンピュータゲーム情報が含まれる。

【0061】

エラー特徴付け部４１０は、受信した情報に基づいて、コンピュータゲームにおけるエラーのインジケータを識別するように動作可能である。エラー特徴付け部４１０は、コンピュータゲームプレイ終了、視覚的エラー、インタラクションエラー、および／または音声エラーのうちの１つまたは複数を含むエラーのインジケータ（指標）を識別するように動作可能である。これらのエラーは、エラー特徴付け部４１０に提供される教師データに依存して識別されてもよく、教師データは、以前のプレイテストデータ、コンピュータゲームプレイのビデオ、既知のバグ検出方法、および／またはコンピュータゲーム情報（一例として）のうちの１つまたは複数を含む。上述したように、これは人工知能または機械学習ベースの方法として実施することができる。

【0062】

プレイテスト制御部４２０は、コンピュータゲーム内の１つ以上のプレイテストボットを制御してプレイテストデータを生成するように動作可能であり、プレイテストデータは、エラーの識別されたインジケータに関する情報を含む。プレイテスト制御部は、１つ以上のプレイテストボットにコンピュータゲームの人間のプレイヤが行うインタラクションをシミュレートさせ、１つ以上のプレイテストボットに人間のプレイヤがコンピュータゲームをたどるパスをシミュレートさせ、および／またはプレイテストボットに単一のゲーム内オブジェクトとのありうるユーザインタラクションの範囲を表すテストルーチンを実行させる。前者の例は、ユーザがコンピュータゲームで取る可能性のあるパス、またはユーザが実行する典型的なインタラクションセットを決定することである。後者の例は、ゲーム内オブジェクト（または同様のもの）を識別し、ユーザベースの重要な部分を代表する可能性が高い一連のインタラクションを含めてさまざまなインタラクション（拾う／投げる／格納する／打つ、あるいは異なる角度からおよび／または異なる速度でオブジェクトにアプローチ／ジャンプすることなど）を実行することである。

【0063】

プレイテスト制御部４２０は、識別されたエラーに関する情報を使用して、プレイテストボットのうちの１つ以上によって実行されるべきアクションを決定するように動作可能であってもよい。たとえば、特定の場所やインタラクションは、コンピュータゲームプレイ中に経験する可能性のあるエラーの一般的な原因であるとして、探し出すことができる。あるいは、またはさらに、プレイテスト制御部４２０は、コンピュータゲーム内の特定の場所でユーザに利用可能なインタラクションの数および／またはタイプを示すコンピュータゲームデータに応じてプレイテストボットの挙動を制御するように動作可能である。これは、（たとえばプレイヤのインタラクションが多いために）エラーが発生する可能性が高いエリア／インタラクションをプレイテストが対象にすることがあるという点で有利である。

【0064】

いくつかの実施の形態では、プレイテスト制御部は、プレイテストボットのうちの１つ以上によって実行されたアクションに関するコンピュータゲームプレイ統計を記録するように動作可能であり、この統計は、実行されたパスや実行されたインタラクションなど、プレイテストボットが経験したコンピュータゲームプレイに関する統計である。一部の実施形の態では、コンピュータゲームプレイ統計は、コンピュータゲームプレイの進行状況および／または難易度を示す。

【0065】

上記のように、プレイテスト制御部４２０は、以前のプレイテストデータ、コンピュータゲームプレイのビデオ、既知のバグ検出方法、および／またはコンピュータゲーム情報などのデータを含む教師データのＡＩまたは機械学習分析に応じてプレイテストボットの動作を制御するように動作可能であってもよい。

【0066】

エラー報告部４３０は、プレイテストデータに依存してエラーを識別するように動作可能である。

【0067】

いくつかの実施の形態では、システムはまた、エラー報告部によって特定されたエラーの発生および／または重大度を低減するためにコンピュータゲームに対する修正を特定するように動作可能なエラー訂正部（例えば、エラー報告部４３０の一部として形成される）を含んでもよい。これは、たとえば、エラーの影響を減らすか、エラーが発生する可能性を減らすために、コンピュータゲームコードまたはオーディオ／ビジュアルアセットを変更することによって実装してもよい。たとえば、コンピュータゲーム内でユーザの可動性を向上させるために、コンピュータゲーム内でオブジェクトを移動したり、サイズ／形状を変更してもよい。

【0068】

上記で説明したように、場合によっては、特定されたエラーはコンピュータゲームのバランスに関連することがある。この場合、エラー報告部４３０は、コンピュータゲーム全体を通じて難易度の進行を示す出力を提供するように動作可能であってもよく、かつ／またはエラー訂正部は、コンピュータゲーム内の異なるアイテムまたは敵の統計を修正して難易度を調整するように動作可能であってもよい。たとえば、特定のステージでコンピュータゲームが難しすぎると見なされるならば、そのステージに関連付けられた敵を弱体化させたり、ユーザの統計（および／またはアイテム）を強化してもよい。

【0069】

図５は、コンピュータゲームに対するプレイテスト情報を生成するためのインテリジェントプレイテスト方法を模式的に示す。

【0070】

ステップ５００は、コンピュータゲームのコンピュータゲームプレイに関する情報を受信することを含む。

【0071】

ステップ５１０は、受信した情報に基づいてコンピュータゲームにおけるエラーのインジケータを識別することを含む。

【0072】

ステップ５２０は、コンピュータゲーム内の１つ以上のプレイテストボットを制御してプレイテストデータを生成することを含み、プレイテストデータは、識別されたエラーのインジケータに関する情報を含む。

【0073】

ステップ５３０は、プレイテストデータに依存してエラーを識別することを含む。

【0074】

上記の技術は、ハードウェア、ソフトウェア、またはこの２つの組み合わせで実装することができる。ソフトウェア制御のデータ処理装置が実施の形態の１つまたは複数の特徴を実装するために使用される場合、そのようなソフトウェア、およびそのようなソフトウェアが提供される非一時的機械可読記憶媒体などの記憶媒体または伝送媒体もまた、本開示の実施の形態とみなされる。

【図1】

【図2】

【図3】

【図4】

【図5】