GAME TESTING

第3章：グラフィックステスト

3.1 ゲームグラフィックスの原則と概念

3.1.1 ゲームにおけるグラフィックコンテンツの特徴

役割と責任

アーティスト

ゲーム内のさまざまなグラフィックコンテンツを制作する

3Dモデラー

ゲームオブジェクトの3Dモデルを作成する

テクスチャアーティスト

ゲームオブジェクトに使用するテクスチャを作成する

アニメーションスペシャリスト

ゲームオブジェクトのアニメーションを制作する

テクニカルアーティスト

技術的なテストのほか、技術サポート、ツール開発、パイプラインの最適化を担当する

テスター

ゲームエンジン内でグラフィックオブジェクトのテストを行う

レベル ( ステージマップ )

レベル(ステージマップ)とは、ゲーム内の仮想世界のことであり、特定の場所(建物や地域など)を指す場合が一般的です。
この概念は初期の「テーブルトークRPG(TRPG)」から生まれ、もともとはダンジョンの階層(Level)を表す用語として使われていました。

たとえば、ダンジョンの最深部(Level 1)からスタートし、階層を上へ進んでいき、最上層(例：Level 100)に到達するとゲームクリアとなる、という仕組みです。
現在では、ほぼすべてのゲームに何らかの形で「レベル(ステージマップ)」の概念が取り入れられています。

モデル

「モデル」とは、コンピュータグラフィックスにおけるすべてのオブジェクトのことを指します。
画像の作成方法によって、グラフィックスは以下のカテゴリーに分類されます。

● 2Dグラフィックス
● 3Dグラフィックス
● コンピュータ生成画像(CGI)グラフィックス

2Dグラフィックス

2Dグラフィックスは、「表示形式」と、それに基づく「画像処理アルゴリズム」によって分類されます。
一般的にベクター[1]とラスタ[2]の2種類に分けられますが、 フラクタル[3]という表現も存在します。

3Dグラフィックス

3Dグラフィックスとは、3次元空間内のオブジェクトを扱う技術です。
映画やゲームをはじめとするさまざまな分野で広く活用されています。

3Dグラフィックスには、主に以下のような種類があります。

● ポリゴン
● ボクセル

ポリゴン

「ポリゴン」とは、「頂点」「辺」「面」で構成された2Dの多角形のことを指します。
「ポリゴングラフィックス」は、複数のポリゴンを組み合わせることで「3DCG」や「ボリュメトリックモデリング[4]」を表現する手法です。

ポリゴンで構成される「面」は、通常、三角形や四角形といった単純な形状で構成されており、これによりレンダリング(描画)の処理を効率的に行うことができます。

ボクセル

ボクセルは「ボリュームピクセル(volume pixel)」とも呼ばれ、
6つの四角形の面で囲まれた立方体として3D空間内に配置されます。
2D画像の「ピクセル(画素)」を立体化したものが「ボクセル」と考えると分かりやすいでしょう。
ボクセルグラフィックはラスタ画像と似ており、主に立方体を多数組み合わせて3Dオブジェクトを表現します。
仮想世界のピクセル・ポリゴン・ボクセルは、いずれも最終的にディスプレイ上のピクセルとして描画されます。

コンピュータ生成画像 ( CGI ) グラフィックス

CGI(コンピュータ生成画像)は、コンピュータの計算により生成された3D画像であり、視覚芸術、印刷、映画の特殊効果、テレビ、シミュレーターなどで使用されます。
動画の場合は、CGIの一分野である「コンピュータアニメーション」によって作成されます。

モニターに表示されるすべての画像は、その平面構造上、必ず「ラスタグラフィック」(ピクセルの集合)として表示されます。
つまり、どんなに高度な3Dグラフィックスであっても、私たちが目にするのは「2D平面上に投影された3D画像」です。

実際に3D空間が存在しているわけではなく、3D表現は人間がモニター上の映像から「頭の中で」立体を想像しているにすぎません。
そのため、可視化の方法として「ベクターグラフィック」や「ラスタグラフィック」が用いられますが、最終的なレンダリング(描画)はすべて「ラスタ(ピクセル)」として行われます。

画像の鮮明さや表現力は、ピクセル数(解像度)が多いほど向上します。

テクスチャ

テクスチャとは、ポリゴンモデルの表面に貼り付けるビットマップ画像(2D画像)のことで、色や立体感を疑似的に表現するために使用されます。
広い意味では、テクスチャは彫刻の表面に施された装飾のようなものと考えることもできます。

テクスチャを活用することで、ポリゴンのみでは表現が難しい微細な凹凸や質感を、比較的少ないリソースで再現できます。
(例：肌の傷、衣服のしわ、壁や地面の小石など)

コリジョン

コリジョンとは、ゲーム内のオブジェクトが互いにすり抜けるかどうかを判断・制御する仕組みです。

ゲームでは限られた「ハードウェアリソース」と「プレイ時間」の中で、多くの処理を行う必要があります。
そのため、ゲーム開発者は、比較的単純かつ精度の低い衝突検出アルゴリズムを用いて、衝突の検出と処理を最適化しています。

衝突検出の基本
定義：ゲーム内のオブジェクト同士が衝突しているかどうかを判定する技術やアルゴリズム。
目的：オブジェクトが重なったり、通り抜けたりしないようにし、リアルなゲームプレイを実現すること。

ほとんどのゲームでは、ステージマップ上の地形やオブジェクトに衝突判定が設定されています。
たとえば、山、木、建物、フェンスなど、固定された破壊不可能なオブジェクトには衝突判定が適用されます。


3Dステージマップでは、キャラクターの位置は「1つの点」として管理されます。
この点の座標を元に、キャラクターの移動や衝突判定を行います。
空間を分割すること(Binary Space Partitioning法など)で、効率的に位置情報を処理し、特定のエリア(例：山や道)内にキャラクターがいるかどうかを判定できます。

この空間の分割情報は「データ構造」として管理され、オブジェクト同士の衝突検出や、キャラクターと他のオブジェクトの距離計算に活用されます。
なお、キャラクター同士や動くオブジェクト(敵キャラなど)との衝突は別の方法で処理されます。

アニメーション

キャラクターをアニメーション化するためには、まず「スケルトン」と呼ばれる骨格をモデル内に設定します。
この工程は「リギング」と呼ばれます。

生き物に限らず、アニメーションさせるオブジェクトも仮想的な骨格を持つことができます。
たとえば、主人公のマントのような衣服も対象になります。

モデルの骨格は互いに連動しており、腕を動かすと手の骨も連動して動くように設定されます。
アニメーションの品質は、リギングとスキニング(モデルの表面に皮膚を適用する工程)の精度によって大きく左右されます。

アニメーションとは、画像に動きや形の変化を与え、静止画を連続的に表示することで動いているように見せる技術です。
モーフィングは、静止画像(フレーム)を高速で切り替えて変化を表現するアニメーション技法で、人の顔が滑らかに変わるといった視覚効果で用いられます。
手描きアニメーションでは通常1秒間に12フレーム、コンピュータアニメーションでは30フレームが用いられます。

エフェクト

視覚効果(ビジュアルエフェクト)は、大きく2つのカテゴリに分けられます。

● ゲームプレイエフェクト(インタラクションエフェクト)
● 自然エフェクト(環境エフェクト)

どのエフェクトを適用するかは、プロジェクトの内容によって異なります。

特に格闘ゲームやRPGでは、ゲームプレイエフェクトが重要になります。
たとえば、プレイヤーキャラクターが他のプレイヤーキャラクターを押した場合、それぞれに正しいリアクションアニメーションが再生される必要があります。
一方、シューティングゲームなどリアルさを重視するジャンルでは、ゲームプレイエフェクトと同じくらい自然エフェクトも重要になります。
たとえば、滝、霧、雨などの環境エフェクトがリアリティを高めます。

シーンライティング ( 照明 )

シーンライティング(照明)とは、ゲーム内の各シーンを適切に照らし、プレイヤーが世界を視認・体感できるようにするための光の演出です。

光はゲームの雰囲気だけでなく、プレイヤーの感情や没入感にも強く影響を与えます。
キャラクターやストーリー、サウンド、ゲームメカニクスなどと組み合わせることで、より効果的な体験が演出できます。
光がオブジェクトの表面に当たることで、明るさや色、コントラスト、影の表現が大きく変化し、シーン全体の印象も左右されます。


人間の目は構造上、約110°の範囲で立体的に物体を認識できますが、フルカラーで捉えられる範囲はさらに狭くなります。

そのため、中心視野にはプレイヤーが必ず見てほしい情報や重要なオブジェクトを配置し、
周辺視野では状況や文脈、雰囲気などを補う情報を配置するのが効果的です。

逆に、周辺視野に配置したエフェクトや光が中心視野の内容と矛盾していると、デザイナーが意図した体験がプレイヤーに正しく伝わらなくなります。

以下は、シーンライティングを効果的に活用する例です。

● 「中心視野」に光を当ててプレイヤーの視線や進行方向を自然に誘導する
● 暗闇の中で懐中電灯などの強い光源を使い、見える範囲を限定して緊張感を演出する
● ライティングの強弱や色彩で「恐怖」や「緊張感」などの雰囲気を生み出す
● 光の方向や遮蔽物を使い、隠し要素を見つけやすくしたり、逆に発見を難しくする
● 光量を調整して、特定のアイテムの使用や特別なアクションをプレイヤーに促す

シーンライティングは、ゲームの没入感を高める重要な要素であり、グラフィックテストの中でも特に重要な項目です。
そのため、視覚芸術、映画、建築などの照明技術が多く応用されています。
これにより、ゲーム内の仮想空間の美しさが際立ち、プレイヤーのゲーム体験の質が向上します。

ただし、ゲームは映画や劇場とは異なり、動的で予測不可能な環境が特徴です。
そのため、静的なライティングだけでなく、動的な光源を活用することで、より臨場感を高める工夫がされています。

歴史的な正確性

グラフィック、アニメーション、エフェクトなどのあらゆる要素は、 ゲーム全体のプレイスタイル(作品のテーマや世界観など)と一致している必要があります。
特に歴史がモチーフの作品では、オブジェクトやモデル、テキスト、サウンドも史実や実際の文化に即していることが求められます。

グラフィックコンテンツの豊かさや複雑さは、ゲームソフトならではの特徴であり、これが他のソフトウェアと大きく異なる点です。
そのため、グラフィックステストでは物理・光学・色彩だけでなく、歴史や文化の知識も重要な要素となります。
なかでもグラフィックステストは、ユーザーのゲーム体験や印象に直接影響する欠陥が集中しやすい領域であるため、非常に重要なテスト活動の一つとされています。

3.1.2 グラフィックコンテンツの欠陥の種類

グラフィックテストで最も一般的に発生する欠陥は「視覚的な欠陥」です。
この視覚的な欠陥には「画像の切れ目(ティアリング)」「テクスチャが欠落している」「意図しない画像のトリミング」などの問題が含まれます。

モバイルゲーム用のグラフィックやアニメーションの制作には、PC向けゲームと同じゲームエンジンが使われますが、
エンジン自体は各プラットフォームのハードウェアや技術的制約に合わせて最適化されています [Gregory18]。
そのため、発生する欠陥の傾向には共通点が多く見られます。

テクスチャの欠落

テクスチャに関連する代表的な欠陥には、以下のようなものがあります。

● オブジェクトにテクスチャが適用されていない
● ゲームプレイ中にテクスチャが消えてしまう
● 仮の画像(プレースホルダーやスタブ)が表示される

特に最初の2つの問題は、GPUの処理能力が不足している、またはグラフィックドライバーが古いことが原因で発生することが多いです。
一方で、プレースホルダー[5]やスタブ[6]が表示されるのは、開発時の設定ミスや実装の不備が原因である場合がほとんどです。

レベル・オブ・ディテール ( LoD：Level of Detail )

レベル・オブ・ディテール(LoD)は、カメラ(プレイヤーの視点)からの距離に応じて、オブジェクトの詳細度を動的に調整する技術です。
これにより、システムの負荷を軽減し、パフォーマンスを向上させることができます。

ゲーム開発者は、新しいオブジェクト(例：木、建物、車など)を作成する際に、複数のバージョンを用意した3Dモデルをゲームに実装します。
これには「細部まで作り込まれた高ポリゴンモデル」や「簡略化された低ポリゴンモデル」が含まれます。

● ハイポリモデル：細部まで精細に作られた高ポリゴンモデル
● ローポリモデル：ポリゴン数を抑えた簡略版のモデル
● シルエットまたは非描画：遠距離では単純なシルエット表示や完全非表示になる

同じオブジェクトでも、カメラとの距離によって「異なるモデル」が使用されます。
カメラに近い場合は高ポリゴンモデルが使われ、遠ざかるにつれて簡略化されたモデルに切り替わります。

十分に遠くなると、オブジェクトはシルエットのみが表示されるか、完全に非表示になります。
これにより、ポリゴンの描画負荷を軽減し、ゲームの処理速度を向上させます。


たとえば「遠くの森林」は低解像度のテクスチャのみで表現され、立体感や光の反射などの表現は省略されます。
しかし、プレイヤーが近づくと、木々が詳細に描写されるようになります。

LoD技術は、アニメーションやスケルトン、さらには「Botの人工知能」にも応用されています。
※Botとは、自動でゲームをプレイするプログラムのことです。

たとえば、画面上に多くの敵が表示されているシューティングゲームでは、Botの詳細度が異なります。
遠くにいるBotは粗いテクスチャで表示され、単純な動きをしますが、
近くにいるBotは精巧に描かれ、プレイヤーと対等に戦える知能を持った動きをします。

開発者は、フレームレート(1秒間に表示されるフレーム数)、オブジェクトの移動速度、および同時に表示されるオブジェクトの総数に応じてLoDを調整します。

LoD技術に関連する「欠陥」は、主に低パフォーマンスなシステムで発生しやすくなります。
開発者は、オブジェクトの詳細度の調整やモデルの切り替えをできる限りスムーズに行えるよう設計しますが、常に完璧にできるとは限りません。

スペックの低いハードウェアでは、低ポリゴンモデルから高ポリゴンモデルへの切り替えが遅れる場合があります。
その結果、プレイヤーがオブジェクトに近づいた際に、最初に「粗いテクスチャ」のモデルが表示され、
その後少し遅れて「精細なテクスチャ」のモデルへと切り替わることがあります。

コリジョン

ゲームにおける「コリジョン(衝突)」とは、オブジェクトが物理的なサイズを持ち、他のオブジェクトと衝突した際に行われる処理を指します。
オブジェクトには、環境や他のオブジェクトとの相互作用を管理するための「コリジョンメッシュ[7]」または「コライダー[8]」が設定されます。

コライダーとは、他のオブジェクトとの衝突を計算するために、オブジェクトに紐づけられた見えない簡略化された形状です。
コライダーは「物理モデル」とも呼ばれ、実際のゲーム内の物理演算や衝突判定は、この形状に基づいて行われます [Buttfield19]。

コライダーの形状は、基本的にオブジェクトのメッシュと一致させる必要がありますが、実際には大まかに設定されることが多いです。

建物や岩、壊れた車などの静的なオブジェクトには、低ポリゴンのコライダーが適用されます。
見た目に大きな違いはありませんが、ゲームの処理負荷を軽減するために最適化されています。

プレイヤーキャラクターが直接接触できるオブジェクトの場合、コライダーのサイズはオブジェクトの見た目と一致させる必要があります。

もしコライダーが小さすぎると、キャラクターが「めり込む」あるいは「すり抜ける」といった現象が発生します。
ゲーム業界ではこの現象を「テクスチャに落ちる(fall into the texture)」などと呼ぶことがありますが、
厳密には「テクスチャ」ではなくコライダーの設定ミスによるものです。
しかし、プレイヤーには「キャラクターが他のオブジェクトの中に入り込む」現象として伝わりやすいため、便宜的にこの表現が使われています。

なお、この現象は特にマルチプレイヤーゲームでは重大な問題となり、不公平なプレイを生む原因にもなります。

たとえば、戦車が「岩のオブジェクト」にめり込むと、他のプレイヤーからほぼ見えなくなってしまいます。
これにより、隠れた状態で一方的に攻撃できるという不公平な状況が生じます。

そのため、PvPモードのマップでは、こうしたオブジェクトに対して特に注意深くテストを行う必要があります。

一方で、特定のオブジェクトにはコリジョンが設定されていない場合もあります。
これは意図的な仕様で、戦車が茂みを簡単に通り抜けたり、キャラクターが小さな障害物(石ころや缶)を乗り越えたりできるようにしています。

ゲームでは、現実とは異なる「慣習的な処理」が行われることがあります。
たとえば、長い武器を持つキャラクターを狭い通路に移動させると、敵を一方向にまとめて戦いやすくなります。
現実なら武器が壁に当たりますが、ゲームでは「壁をすり抜ける」ことが許容されています。
同様に、キャラクターの長い髪が装備(肩当てなど)を突き抜けることもあります。

しかし、見た目には簡単に乗り越えられそうな低い壁が乗り越えられないと、プレイヤーにストレスを与えることもあります。

逆に、コライダーが視覚的なモデルよりも大きい場合、 キャラクターが見えない壁にぶつかったり、何かの上に浮いているように見えることがあります。
このような不具合は、ゲームデザイナーが想定していない「短時間クリア」を狙うプレイヤーに悪用されることがあります。

いわゆる「最速クリアを目指すプレイヤー」は、開発者がオブジェクトのコライダーサイズを調整し忘れた「抜け道」を意図的に探し、
これにより、プレイヤーはマップの広い範囲をスキップして、クリア時間を大幅に短縮できる場合があります。

ヒットボックス

キャラクターがダメージを受ける仕組みがある場合、敵の攻撃がどの位置にヒットしたかを計算し、命中の有無を判定する必要があります。
しかし、複雑な形状のオブジェクトに対して正確な衝突判定を行うのは計算コストが高く、非効率です。

この処理を効率化するために、「ヒットボックス」という概念が用いられます。(いわゆる当たり判定です)
たとえば、2Dアクションゲームや格闘ゲームでは、1つ以上の長方形でヒットボックスを表現することがあります。
長方形同士の衝突判定は比較的シンプルな計算で済むため、処理負荷を抑えることができます。

3Dオブジェクトの場合、最も単純なヒットボックスの形状は球体です。
この場合、中心座標と半径の情報があれば衝突判定を行うことができます。

この方法を使用すれば、任意の時点で弾丸や攻撃判定が球体の内部にあるかどうかを簡単に判定できます。
しかし、球体は不要な空間を含みやすいため、より効率的な形状として「直方体」のヒットボックスが用いられることもあります。
直方体を使用する場合は、オブジェクトの中心座標と長さ・幅・高さの情報があれば判定が可能になります。

よりリアルな表現を目指して、キャラクターの各部位(例：腕、脚、頭、尾、武器など)に個別のヒットボックスを設定する場合があります。
しかし、ダメージを与えるエリアと、ダメージを受けるエリアは必ずしも同じとは限りません。

そのため、一部のゲームでは「ヒットボックス[9]」(攻撃判定)と「ハートボックス[10]」(被ダメージ判定)を別々に設定し、
攻撃を当てるエリア(例：武器、拳)とダメージを受けるエリア(例：頭部、手足)を明確に区別します。
ダメージの有無は、攻撃側ヒットボックスと防御側ハートボックスが重なった場合にのみ判定されます。

テスターが「ヒットボックス」を検証する際には、「見た目」と「衝突範囲」が適切に一致しているかを確認します。
大規模なゲームでも、プレイヤーが「明らかに攻撃が敵に当たったように見えたのに、 ダメージが発生していない」と感じる場合があります。
逆に「ヒットボックス」が大きすぎると、本来攻撃が届いていないはずの距離でダメージを受けることもあります。

その他の欠陥

大規模なプロジェクトでは、モデルの制作過程において多数の承認や確認が行われます。
モデルはアーティスト、モデラー、テクスチャーアーティストなどによってテストされますが、 それでも、テスターが制作過程で発生した視覚的な欠陥を発見することがあります。

歴史上の実物との差異

ファンタジーやSFゲームでは、巨大な肩当ての鎧や非現実的な形状の飛行機が登場しても、 プレイヤーは違和感を抱かずに受け入れることができます。
しかし、ゲームが史実に基づいている場合、実在する航空機のプロペラの位置が異なっていたり、 実際の戦艦に搭載されていた砲門の数が違ったりすると、一部のプレイヤーが指摘する可能性があります。

そのため、テスターは可能であればオブジェクトの元となった実際の写真を確認し、 現実でどのように見えていたのかを理解した上でテストを行うことが重要です。

空中に浮いているオブジェクト

開発中、複数の専門家が同じロケーションで作業を行うことがあります。
ある担当者はオブジェクトの追加や削除を行い、 別の担当者は地形の形状を変更したり、 タイル(地形用テクスチャ)を修正することがあります。

この結果、元々あったオブジェクトが地形に埋もれてしまったり、 地形がずれて「オブジェクトが空中に浮いて見える」といった欠陥が発生することがあります。

テクスチャの継ぎ目

この問題は、大規模なステージマップや地形において、 複数のテクスチャが組み合わさる際に特に発生しやすい傾向があります。
たとえば、草地と砂地、石などの異なる素材が隣接する部分で、 「継ぎ目」が目立つことがあります。

オブジェクトの破壊

通常、モデルにはリアリティを持たせるため、 「初期状態」「損傷状態」「破壊状態」といった複数のバリエーションが用意されます。

破壊可能なオブジェクトの場合、 特別なクラッシュモデル(破壊後のモデル)が作成されることがあり、 場合によっては専用の衝突判定モデルも追加されます。
破壊時には「初期状態」から「破壊状態」のモデルへと置き換えられます。

しかし、この際「破壊状態」が適切に表現されていることが重要です。
たとえば、破壊された車は元の状態とは異なる見た目になっている必要がありますし、 「壊れたレンガ造りの建物」の破片が「木製」になっているのは不自然です。

ライティングの欠陥

ライティングに関する欠陥には以下のようなものがあります。

● グローバルイルミネーションの欠陥
● 点光源の欠陥
● サーチライト光源の欠陥
● エリア光源の欠陥
● 指向性光源の欠陥
● 発光光源の欠陥
● 拡散光源の欠陥

現代のゲームエンジンには、光学の法則に基づいた多様な光源の作成機能が備わっています。
しかし、ライティング設定のミスや開発者の経験不足によって、 理想的なライティングが実現されていないゲームもあります。

光の位置、角度、色、視野、動きなど、「視覚的構成」(コンポジション)は、
プレイヤーがゲーム環境をどう認識し、どのような感情的な雰囲気を感じ取るかに大きな影響を与えます。
デザイナーは、こうした要素を意識して、プレイヤーが意図した情報や感情を受け取れるように
シーン全体の一貫性や雰囲気作りに注意を払う必要があります。
[Lee16] [Tavakkoli18] [Romero19]

アニメーションの欠陥

この欠陥は、スケルトン(骨格)をモデルに結びつける作業であるスキニングによって発生することがあります。
※「スキニング」とは、「リギング」されたスケルトンをモデルの表面に適切に結びつける工程のことです。

モデルの骨の数が多いほど、よりリアルなアニメーションを作成できます。
たとえば、主人公の髪の毛など、さまざまなオブジェクトにアニメーションが適用されます。

モデルの骨は互いに連動しており、腕を動かすと手の骨も自然に動きます。
アニメーションの完成度は、リギングとスキニングの段階でどれだけ適切に設定されたかによって決まります。

スケルトン適用でのミスが原因で、体の一部が「切り離されたように見える」「異常に伸びる」などの現象が発生することがあります。
こうした不具合は、他のモデルとの衝突や、特定のアニメーションの際に発生しやすいです。

視覚効果 ( VFX ) の不具合

ゲームでは、キャラクターの動作やイベント、自然現象を表現するために、爆発・火花・煙・オブジェクトの出現や消失といった視覚効果(VFX)が活用されます。

VFXは、キャラクターの骨格(ボーン)、ヘルパー(モデルを動かすための補助オブジェクト)、またはゲーム内オブジェクトに関連付けられています。

VFXの作成には、アニメーションチームとエフェクト担当のアーティストが協力し、何度も調整を重ねる作業が求められます。
たとえば、以下のような調整が行われます。

● 剣の軌跡を滑らかに見せるためにキーフレームを追加する
● キャラクターが攻撃を受けた際の血しぶきの向きを調整するためにヘルパーの回転を変更する
● 煙や火花などのパーティクルエフェクトの見栄えを向上させるためにカメラの切り替えを調整する

こうした効果は、それを引き起こすイベントと正確に同期している必要があります。
たとえば、銃口から発生する火や煙は、発砲の瞬間や弾丸が銃口から出るタイミングと一致していなければなりません。
そうでない場合、演出のリアリティが損なわれ、不具合と見なされることがあります。

VFXの不具合の一因として、「フレームレートの維持」や「正しい表示」のためのハードウェアリソースの最適化不足が挙げられます。

どれほど迫力のある演出であっても、処理落ちによってカクつく砂ぼこりや、フリーズした爆発エフェクトでは、プレイヤーの没入感が損なわれます。
そのため、ゲーム内の特殊効果(VFX)には、常に一定のフレームレートを維持できるよう、非常に厳しい技術的制限が課せられています。
どれほど迫力があっても、カクつきやフリーズがあれば体験は損なわれるため、「派手さ」と「快適さ」のバランスが求められます。

VFXのテストでは、ゲームデバイスのハードウェアリソースが最適に活用されていること、
さらに「効果」と「発動するイベント」が適切に同期していることを確認する必要があります。

欠陥はできるだけモデル制作の早い段階で発見することが望まれます。
たとえば、モデルのポリゴン数が多すぎる、またはテクスチャの設定に欠陥があると、
ハードウェアの負荷が増加し、ゲームの動作遅延の原因になります。

これを防ぐためには、開発者がLoD(レベル・オブ・ディテール)や衝突モデルに関する要件を事前に把握しておくことが重要です。

テスターは、こうした欠陥の兆候や、それによって引き起こされる問題をいち早く検出する役割を担います。
特にポリゴン数が過剰なコリジョンモデル(衝突判定用モデル)などは、通常プレイ時には気付きにくいものの、
フレームレートの低下や描画遅延など深刻な不具合の原因となるため、十分な注意が必要です。

3.2 ゲームにおけるグラフィックテストの手法

3.2.1 アーティスティックテスト

ゲーム内のグラフィック要素は、複数の工程を経て制作されます。

デザイナーがデザインを考案し、それを別の担当者がゲームに実装します。しかし、その過程でデザインの意図が正しく反映されないことがあります。

テスターはデザインが規格に準拠しているかを検証し、欠陥を発見できますが、
微妙な色合いの違いや透明度の不足、拡大・縮小時の欠陥など、アーティストでなければ気づけない問題も存在します。

一方で、アーティストが開発の全工程を把握するのは難しく、ゲーム内で実際に動作している状態を見て初めて問題に気づくこともあります。
そのため、実装後にデザイナーによるレビューを行うのが一般的です。
この際、テスターは、テスト環境の準備やテスト用アカウントの作成、欠陥の記録、および必要に応じたアーティストへのレビュー依頼を担当します。

コンテンツ量が多いプロジェクトでは、グラフィックテスト専門の担当者が配置されることもあります。
これらの担当者は、主にモデル制作プロセスに精通したアーティストです。

彼らは以下の各工程でテストを行います。

● ジオメトリの作成[11]
● テクスチャの作成
● 衝突モデルの作成

この作業の目的は、ゲームエンジンにモデルを読み込む前に品質を向上させることです。
たとえば、ジオメトリのポリゴン数[12]、形状の正確さ、 UV展開の適切さ[13]、 ポリゴンの引き伸ばしやモデルのシーム(継ぎ目)[14]などをチェックします。

アーティスティックテストは、単純な形状やテクスチャの作成段階から、最終的なゲームエンジンでの表示確認まで、さまざまな段階で行われます。

特別なツールやコンテンツエディタがなくても、ゲームを直接実行してテストを行うことは可能です。
しかし、ツールやコンテンツエディタを使用すれば、欠陥をより迅速かつ効率的に発見できます。

以下はアーティスティックテストの担当者とその役割です。

● アーティスト：オブジェクトがデザインの意図通りに表現されているかを確認する
● 3Dモデラー：形状やポリゴン数、テクスチャの適用精度を確認する
● スーパーバイザー：アートスタイルや品質基準に沿っているかを確認する
● テストエンジニア：ゲームエンジン上での動作や表示を確認する
● プレイヤー：プレイテストを通じて実際のゲーム内での見た目や使用感を確認する

3.2.2 テクニカルテスト

テクニカルテストでは、グラフィックに関する技術的要素が適切に実装されているかを検証します。

具体的には、以下のような項目をチェックします。

● モデルのポリゴン数が規定の範囲内であるか
● テクスチャのフォーマットが仕様に準拠しているかどうか
● LoD(レベル・オブ・ディテール)の切り替え距離が仕様と一致しているか
※これについては、利用可能なリソースと仕様書を比較することで判断できます。

テクニカルテストは、主にテスターやテクニカルアーティストが担当します。
主な手順は以下の通りです。

未使用・不要なファイルの検索

アーティストとの共同作業では、誤って「不要なリソース」がリポジトリに追加されることがあります。

たとえば、開発者が「すべてのリソース」をリポジトリにアップロードする際に、未使用のリソースも含めてしまうことがあります。
こうした不要なファイルは、ゲームクライアントのディスク使用量を増やし、パフォーマンスを低下させる原因になります。
また、最終的にプレイヤーがダウンロードするパッチのサイズも増加してしまいます。
これを防ぐために、未使用のリソースを特定し、除外することが重要です。

必要なリソースがすべて含まれているかの確認

ゲームのグラフィックデータは、他のリソースと密接に関連しています。

たとえば、モデルデータがテクスチャを参照し、マップデータがモデルを参照するといった形です。
必要なリソース確認では、たとえ小さな欠陥でも、ゲーム全体に予期しない影響を与える可能性があるため、慎重なチェックが必要です。

テクスチャ形式のテスト

各テクスチャタイプには、テクニカルアーティストが個別に適切な圧縮率や解像度を設定します。
これは、グラフィックのパフォーマンスと視覚的な品質とのバランスを取る必要があるためです。
テクスチャ形式とは、主に圧縮方式とサイズを指します。

圧縮方式やサイズ(フォーマット)によって、データの保存や処理にかかる負荷が変わり、ゲームのパフォーマンスにも影響します。
解像度が高すぎればパフォーマンスが低下し、逆に低すぎれば画質が劣化するため、適切なバランスを取ることが必要です。

クライアントログを用いたコンテンツのテスト

クライアントのサブシステムの動作は、表面的には分かりづらい場合があります。

たとえば、ポストエフェクトとは、レンズフレアのように、画像の上に追加される視覚効果のことです。
各ポストエフェクトには、それに対応する専用テクスチャが作成されます。

たとえば、太陽の光を見る場面でポストエフェクトが設定されていなくても、プレイヤーは気づきません(光そのものは見えているため)。

視覚的に欠陥がなくても、ログには必ずエラーが記録されるため、クライアントのログを分析することが必要です。
※ログには、レンダリング時に存在しないリソースを参照しようとしたエラーが記録されています。

テクスチャやモデルの数の制限が適切に守られているかの確認

各コンテンツには、それぞれグループごとに共通の制限が設定されています。

たとえば、高層ビルのような壊れない建物は最大15,000ポリゴンまで使用できますが、一階建ての建物は10,000ポリゴンまでといったルールがあります。

新しいモデルが追加・更新・エクスポートされるたびに、これらの制限や要件が適切に遵守されているかをテストする必要があります。
これは、ビデオプロセッサでの計算に必要なハードウェアリソースの不足を防ぐためです。

テクニカルテストは一見すると単純な作業に思えますが、ゲーム全体のパフォーマンスに大きな影響を与えます。
適切に管理されていない場合、フレームレートの低下やクライアントのメモリ使用量の増加といった重大な問題を引き起こす可能性があるため、非常に重要な検証項目です。

テクニカルテストの重要性

テスト自体は単純な作業に見えるかもしれませんが、その重要性を正しく理解することが不可欠です。

グラフィックの品質や最適化は、システム全体のパフォーマンスに直接影響を及ぼします。
そのため、テクニカルテストでは、ゲームのパフォーマンスやデータサイズが適切に維持されているかを確認します。
さらにパフォーマンステストも含まれ、ゲーム全体の動作安定性を保証する役割も担っています。

テクスチャやモデルの数が増えると、ゲームのビルドサイズも増加します。
テクスチャ形式が一致しないと、フレームレートが悪化し、クライアントが消費するメモリが増加します。

テクニカルテストは、アーティストが制作したコンテンツを、最大限のスケール・品質でプレイヤーに届けるための重要な検証プロセスです。

3.2.3 ゲームプレイテスト

ゲームプレイテストでは、グラフィックがゲームの操作性やプレイの快適さにどのような影響を与えるかを検証します。

たとえば、当たり判定のモデルが見た目のモデルと適切に一致しているか、
また、ゲーム内のアイテムやキャラクターの設定がゲームのルールや仕様に適合しているかを確認します。

ゲームプレイテストでは、次のような検証を行います。

HPの適正確認テスト

HPは、RPGやPCゲームなどでオブジェクトの耐久力を示す数値です。

HPは通常、「オブジェクトの材質」「サイズ」「種類」などに基づいて自動的に設定されますが、
設定ミスやバランス調整の欠陥により、不適切な値が割り当てられることがあります。
そのため、各オブジェクトのHPが適正であるかを手動で確認します。

衝突モデルとビジュアルモデルの整合性チェック

衝突モデルは、ビジュアルモデルよりも単純化された形状で設定されることが一般的です。

この違いにより、プレイヤーが見た目では遮蔽物に隠れているのに、実際には敵の攻撃を受けてしまうといった欠陥が発生することがあります(視覚モデルと衝突モデルの不一致に起因する実行時の欠陥)。
こうした欠陥を防ぐため、「衝突モデル」と「ビジュアルモデル(見た目)」が適切に一致しているかをテストします。

3.3 グラフィックテストの実行

3.3.1 オブジェクト制作の各段階におけるグラフィックテストの実行

グレーボックスの作成

「グレーボックス」とは、ゲームプレイのテストを目的としたシンプルなモックアップモデルです。
この段階では、主にゲームプレイテストを目的としてシンプルなモデルが作成されます。
同時に、アーティストがこのモデルを扱いやすいかどうかも確認され、問題があれば早期に発見できます。

可視ジオメトリの作成

この段階では「オブジェクトのモデリング」と「UV展開」が行われ、オブジェクトの形状と、3D表面(X,Y,Z)とテクスチャ座標(U,V)の対応が設定されます。

オブジェクトの形状や空間内での配置が考慮され、この段階で可視ジオメトリとUV展開が作成されます。
これにより、3Dオブジェクトの表面座標(X, Y, Z)とテクスチャ座標(U, V)の対応が正しく設定されているかを確認します。

テストは3Dグラフィックエディタを使用して行い、アーティストや3Dモデラーが欠陥を発見することもあります。
主な欠陥の例として、以下のようなものがあります。

● 重複したジオメトリ：ポリゴンの重複によるパフォーマンス低下の可能性
● 不要な詳細：プレイヤーが見えない部分に細部が多すぎると、ハードウェアリソースの無駄遣いにつながる
● モデルの単純化不足：簡素すぎるモデルは、不自然に角ばって見える可能性がある
● レンダリングされないジオメトリ：必要な部分が欠落すると、リアリティが損なわれる

モデルのテクスチャリング

この段階では、アーティストやアートディレクターが「テクスチャ」のビジュアル品質を確認します。

主に「全体のカラーパレット」や「汚れの表現」(不自然な色やランダムに混入した異なる色のピクセル)が適切かをチェックします。
※この時点では、シーム(継ぎ目)の目立ちやポリゴントポロジーの問題など、テクスチャの貼り方自体の細かい問題は通常はチェック対象外です。

よくある問題例としては、異なる部分に異なる色のテクスチャが適用され、不自然な継ぎ目が発生してしまうケースがあります。

LoDとコリジョンモデルの確認

この段階では、アーティストとレベルデザイナー(ステージマップデザイナー)がモデルの品質を評価します。

レベルデザイナーは、コリジョンモデル(衝突判定用のモデル)がゲームプレイに適しているかを評価します。
たとえば、プレイヤーがオブジェクトをスムーズに通過できるか、遮蔽物として隠れられるかなど、実際のプレイへの影響を考慮し、
特定の場所で詳細なモデルが必要か、または簡略化が可能かを判断します。

典型的な欠陥には、過度に詳細なモデル(許容ポリゴン数を超えている)や、逆に詳細さが不足しているモデルがあります。

モデルをゲームエンジンへエクスポートする

この段階では、LoDの切り替え距離やオブジェクトの耐久値(HP)が正しく設定されているかを確認します。

テストは、コンテンツエディタやゲーム内で、テスターが直接ゲームエンジンを使用して行います。
アーティスティックテストでは、オブジェクトの視覚的な品質を重点的に評価し、アーティストやモデラーによるテストと重複することもあります。

テストの主な確認項目は以下の通りです。

● オブジェクトの配置や使用状況に応じて、自然にLoDが切り替わるか
● オブジェクトのジオメトリに隙間や不自然なシームがないか
● 各種グラフィックオブジェクト上の文字が判読しやすいか
● モデルの破壊エフェクトについても、破壊後の形状や色、サイズが自然かどうか
● オブジェクトアニメーションに視覚的な欠陥がないか

アーティスティックテストでは、プレイヤーが直接コンテンツを視覚的に評価し、他のグラフィック上の欠陥を発見することもあります。

グラフィックテストはステージマップのテストと並行して行われることが多いです。
この場合、いくつかの手順を踏んでテストが実施されます。

ステージマップ上でのオブジェクト配置

これはテストの中でも特に重要なプロセスの一つです。
オブジェクトの配置はレベルデザイナーが担当します。

この過程では、オブジェクトが「宙に浮いている」または「地形に埋もれている」といった典型的な欠陥が発生することがあります。

これは、複数の専門家が同時にステージマップのジオメトリを変更したり、オブジェクトを配置・編集することによって生じやすい問題です。

エフェクトの作成と配置

この段階では、エフェクトアーティストが特殊効果を作成し、ゲーム内に配置します。

エフェクトをさまざまな状況で確認することで、視覚的および技術的なレンダリングの欠陥を特定できます。
たとえば、ゲームエンジン内でエフェクトの見た目をテストし、設定ミス(例：消滅時間が短すぎるなど)を検出します。
エフェクトアーティストは、各エフェクトがゲームクライアント上で適切に動作しているかを個別に確認します。

グラフィックテストとプレイテスト

グラフィックテストは、プレイテストを通じて行われることが多いです。

このテストでは、ステージマップが実際のゲームプレイ状況下でどのように機能するかを検証します。
テストの目的は幅広く、開発のあらゆる段階に適用されます(例：ステージマップ上でのゲームプレイ評価)。

開発の最終段階では、プレイヤー視点からの「マップの視覚的な印象」と「ゲームプレイ上の使いやすさ」の両方を評価します。

また、ゲームデザイナーはプレイテストを通じて統計データを収集し、マップバランスを調整する材料とします。
プレイテストにより、浮いているオブジェクトや、グラフィックのレンダリングに関するさまざまな芸術的・技術的な欠陥(例：フリーズ、欠陥や不具合など)も発見できます。

このテストにより、プレイヤー視点での問題が明らかになります。

ステージマップのテスト

これは、ステージマップが完成し、原則として修正作業が終了した最終段階で行われるテストです。

テスターは専用のチェックリストに基づいて、ステージマップ全体を徹底的に検証します。
オブジェクトの配置状態(浮いている、埋もれているなど)や、アニメーションの動作など、幅広い観点でテストが行われます。

テスターは専用ツールを活用して問題箇所を詳細に検出するため、単なる視覚チェックを行うアーティストよりも、多くのグラフィック上の欠陥を発見できます。

3.3.2 グラフィックの歴史的整合性テスト

ゲームのグラフィックテストには、歴史的な正確性を検証するテストも含まれます。
ここでは、「歴史的臨場感の再現」と「正確な歴史の再現」という二つの異なる側面を考慮する必要があります。

歴史的臨場感の再現

この側面では、特定の歴史時代を舞台にした際に、その時代の雰囲気や文化的背景をリアルに再現することが重視されます。

ここで重要なのは、具体的な歴史的出来事や実在の人物を忠実に再現することではなく、
あくまでプレイヤーがその時代に生きているように感じる体験を提供することです。

正確な歴史の再現

一方こちらでは、実際の歴史的出来事や実在の人物、重要な日付などを厳密に再現することが求められます。

特定の戦争、事件、政治家、兵器などについて、史実に基づいた描写が行われることが重要です。
その時代特有の要素を取り入れることが求められます。
その時代に存在しなかった要素(例：近代兵器が中世に登場するなど)は排除する必要があります。

一般的に、ゲームで歴史的事実を完全に忠実に再現することは難しいとされています。

なぜなら、ゲームは単なる事実の再現ではなく、プレイヤーにとって魅力的な体験を提供することが目的だからです。
そのため、完全に決まった歴史的ストーリーをゲームに取り入れると、プレイヤーの自由度が制限され、没入感を損なう可能性があります。

しかし、ゲームのストーリーが特定の歴史的時代に基づいている場合、
「臨場感」と「正確さ」のバランスを適切に取ることが、プレイヤーの没入体験を大きく向上させる要素となります。

歴史的正確性をテストする際に考慮すべき主なポイントは以下の通りです。

● キャラクターの外見が実在の歴史上の人物に近いか
● 建物や構造物がその時代の特徴を正しく再現しているか
● 武器、装備、乗り物、衣服などのデザインや仕様が正確か
● それらのアイテムが当時の特徴や使用方法を忠実に再現しているか
● 当時の人々の生活様式や日常が正確に描写されているか
● ゲーム内の歴史的な出来事や日付が、史実と一致しているか

歴史的正確性を検証するテストでは、テスターには幅広い知識と深い理解が求められます。
そのため、多くの場合、開発チームは歴史の専門家やコンサルタントをテストに参加させ、より正確な歴史再現を目指します。

3.4 グラフィックテスト用のツールサポート

グラフィックテストでは、ゲーム内のオブジェクトやマップ、キャラクター、エフェクトなどを検証するために、
ゲームエンジンのエディタや自動化ツール、テストスクリプトなど、さまざまなツールが活用されます。

一般的に、ゲームはゲームエンジンを用いて開発されており、
その中にはオブジェクトエディタ[15]、ワールドエディタ[16]、 ライティングエディタ[17]など、グラフィックテストに役立つ組み込みツールが備わっています。

これらのツールを使用することで、ゲーム内のオブジェクトや環境を自由にカスタマイズできます。

たとえば、オブジェクトエディタを使うと、キャラクターやオブジェクトに音やイベント(トリガー)を関連付けることができます。
また、ワールドエディタでは、ステージマップの作成や、オブジェクトの配置、ゲームプレイメカニクスの調整が可能です。

テスターは、これらの開発者向けツールを活用してテストを行います。
また、これらのエディタには、コンテンツの設定やテストを行うための高度なツールキットが備わっています。

専門ツールとその使用

グラフィックボード(GPU)メーカーによって開発されている専用ツールも存在します。
これらのツールは、ゲーム内の映像をキャプチャし、2D/3Dグラフィックを生成する各種APIの動作を詳細に分析するために使用されます。
これにより、描画負荷の高いオブジェクトの特定や、ボトルネックの早期発見、メモリリークや描画遅延などの技術的問題の洗い出しが可能になります。

また、次のような評価も可能です。

● ゲームのフレームがどのように処理されているかの評価(例：ジオメトリ、テクスチャ、描画コールなど)
● パフォーマンスの問題が発生している箇所の特定
● 3Dオブジェクトの形状や配置の検証
● 3Dモデラー、グラフィックアーティスト、アニメーター向けのデバッグ機能

これらのツールの詳細な使用方法については、各ソフトウェアの仕様書に記載されています。

自動化スクリプトの役割

グラフィックテスト用ツールには、キャラクターがゲーム内の特定ルートを自動で進行するスクリプトも含まれます。
こうしたスクリプトは、特にパフォーマンステストや互換性テストにおいて活用されます。

テスター

ゲームテスター

デバッガー

ISTQB

Game Test

Game Tester

Game Testing

Game QA

QA

테스터

게임 테스터

디버거

Người kiểm thử

Người kiểm thử trò chơi

Trình gỡ lỗi

Kiểm thử trò chơi