ゲーム開発を扱う場合、ソフトウェアテストは異なりますか？

一般にソフトウェア開発とゲーム開発の違いについてこの論文を読んでいて、著者はソフトウェアテストに関していくつかの良い点を指摘しました。たとえば、

...ゲーム開発者は、ゲームデザイナーの創造的な欲求の変化に直面して、これらのテストが急速に陳腐化するため、自動テストの使用をためらいます。

それで、この読書は、ゲームを扱っている/テストしているときに、ソフトウェアテストの他のどの側面を異なるまたは特定と見なすべきかを考えさせましたか？誰かがこれを経験したことがありますか、それについて何か他のことを聞いたことがありますか？

実際、現代のゲームは、社内または独自のゲームエンジンを使用して開発された大量の創造的なアートコンテンツです。エンジン自体は、ほとんどの部分（レンダリング、ジオメトリ、物理学、AIモジュールなど）でユニットテスト可能です。同様に、開発されたコンテンツの個々の部分に簡単なテストを添付することもできます。これは、ユニットおよびホワイトボックステストが実際に実行可能で成功していることを意味します。

「製品全体」に関する限り、ゲームはシミュレーションです。単純なビジネスプログラムよりも生成的な複雑さがあります。数え切れないほどよく計画された振る舞いを備えたエンタープライズリソースプランナーとは対照的に、無限でユニークな手続き型の世界を考えてください。簡単に言えば、ゲームのコンテキストで何かを行うための可能なユニークな方法の数は、数学的に非常に大きくなる可能性があります。実際、ゲームのセールスポイントと見なされます。

それに加えて、最終出力は純粋にオーディオビジュアルであり、そのような出力の絶対的な正確性の決定論的標準はありません。GPUチップは、正確でない計算であっても、実際には正確な計算を実行する必要はなく、多くの計算を実行する必要があります。

そして最後に、主な目標はエンターテイメントです。ゲーマーは、60以上のFPSを実行し、素晴らしく見え、何時間にもわたる娯楽コンテンツを持っている場合、グリッチに問題はありません。

これは、ゲームに適用された場合、従来の自動化されたブラックボックステストのアイデアを「それほど具体的ではなく価値のある」領域に置くだけです。

ただし、NNを訓練してゲームをプレイするという最近の試みがあります。これは、事実上、探索的自己学習型のサルテストです。

gamedevをやってから何年も経ちましたが、いい答えに加えて、いくつか追加したいことや詳細があります。

最初に述べたのは、出力が「FPSに厳しい」厳しい制約と計算/メモリバジェットに対して視覚的かつ聴覚的であることです。質問が「見栄えが良いか？スタッターなしでスムーズに実行されるか？素晴らしいサウンドですか？」のような質問になると、正確さのアイデアがぼやけます。開発者は微調整と調整を行い、設計者と開発者のコ​​ラボレーションは見た目と音が急速に繰り返されるたびに少しずつ異なるものになります。

もう1つは、テスターがすごいことです！彼らが望んでいるので、私は他のドメインでより専用のテスターのグループを見つけたことがありませんソフトウェアをテストします。彼らは楽しんでいます。彼らは中毒になっていて、コンピューターの隣で寝ている間、ゲームの隅々を探検します。人々が実際にソフトウェアの隅々まで徹底的にテストし、実際には中毒になっているときに、あいまいなグリッチでさえ発見するのはかなり簡単になります。私の現在の業界では、テスターの多くはソフトウェアに生計を立てている専門家であるため、作業が少し難しくなります。したがって、テスターは仕事を終わらせるためにいくつかの機能に依存しており、すべての隅々に常に。当然、人間のテスターに​​それほど頼ることができない場合、より自動化されたテストが必要です。

さらにもう1つは、ゲームのコードベースは通常、長年にわたって維持、変更、拡張されないことです。6502アセンブリで最初に開発したスーパーマリオの開発者が、ゲームの出荷後も元のコードに似たものを維持しなければならなかったということはありません。Doom 3は、おそらくDoom 1のゼロ行のコード（またはクローズ）を使用します。継続的なフランチャイズがある場合、新しいゲームは「アップグレード」というよりも「続編」に似ています。ほとんどのゲームはただ出荷され、おそらくいくつかのパッチ、DLCがリリースされ、その後コードが完成します。これは、数十年にわたって移植および保守されていたAmigaの時代にまで遡るコードの保守に取り組んできた私のVFX業界とは非常に対照的です。ゲームは通常

ゲームコードベースのこの短命な性質の理由の1つは、それらがハードウェアに非常に結び付けられていることです。最先端の性質とFPSクリティカルな要件と組み合わせると、ハードウェアの詳細を抽象化するような方法で開発することはできません。ハードウェアのターゲット世代向けに特別に書かれていることが多く、PS3がPS4に置き換わり、その後PS4が廃止されてPS5に置き換わるなど、すべてが非常に迅速に行われます。ハードウェア機能は、ゲームの設計と開発において極めて重要な役割を果たしているため、PSX向けにPS4向けに記述された同じコードの多くを維持することは一般的には価値がありません。主に最新のハードウェアの基礎から。

存続期間の短いコードベースでは、メンテナンス時間が限られています（つまり、コードを変更する必要がある限られた時間）。エンジンの範囲がアップグレードごとにますます大きくなり、ゲームがミッションクリティカルに近いところにないという事実と相まって、コードが変更される期間は限られています。最も徹底的な単体テストと統合テストを適用することが重要です。将来の変更が行われない場合、将来の変更の整合性を確保することでそれを行うことには利点がありません。また、そもそも「レガシー」がない場合、レガシーコードベースのユニットテストとリファクタリングの側面は自然に無関係です。

常に関連するとは限らないもう1つの小さな問題は、ゲームがデスクトップポートなしで非常に狭い範囲のハードウェアのみをターゲットとする可能性があることです。これらの場合、これらのコンテキストで予測できないグリッチの巨大な原因、つまり根本的に異なるハードウェアとドライバーでソフトウェアを実行しているユーザーは排除されます。

そうは言っても、最高/最も粗いレベルでの統合テストは、すぐに役立つ傾向があります。たとえば、多くのゲームでは、「リプレイ」のためにゲームの状態が時間とともにどのように変化するかを記録する方法を利用できます。このようなリプレイ機能は、ゲームが決定論的であることを保証し、他の誰かによって以前に記録されたゲームセッションをリプレイするためのテストツールのフォームとしても使用できます。

また、小さなスタジオで働いているゲーム開発者と出会い、ゲームのボットを書くなどのことをして、ボットに最高速度でゲームをプレイさせ、そのシミュレーションを実行しました。最初は1、2日後に不明瞭なクラッシュに遭遇し、それを修正してから、シミュレーションを再度実行し、何週間も続けて実行した後でもショーを止めるクラッシュがなくなるまで繰り返しました。したがって、ゲーム開発者からソフトウェアのテストまで見たような興味深い実用的なアプローチがありますが、多くの場合、最も粗いレベルの統合テストに似ており、プレイヤーが実際にゲームとやり取りする方法に非常に近いものをシミュレートします。

最後に、これらの大きなAAAゲームエンジンは、まったく異なる種類の獣に似始めています：レベルエディタが本格的な開発環境に似始めている間、より長いコードベースとより長いメンテナンススパンで、寿命が長く、ハードウェアを少しうまく抽象化することに成功しています。これらの大きなエンジンはおそらく、特にコードの保守時間が大幅に長くなる場合、より徹底的なテスト手順を必要とするでしょう。それでも、多くのゲームスタジオは巨大なAAAゲームエンジンを作成していません。ライセンスを取得するか、スコープがかなり小さく、数年間維持されない独自の小さなエンジンを開発します。