TOPへ戻る
ゲームにおいて最も重要なのは、プレイヤーの関心を引きつけ、それを維持・拡大することです。
プレイヤーは、ゲームの「
グラフィック」「
操作性」「
メカニクス(ゲームの仕組み)」を特に重視します。
中でも「
ゲームメカニクス」は、プレイヤーとゲームをつなぐ重要な要素です。
また、ゲームメカニクスは、ゲームのさまざまな側面や目的に応じて、複数の種類に分類されます。
プレイヤーが「自らの操作によってゲームに影響を与えている」と
直接実感できる要素です。
たとえば「キャラクターを動かす」「敵を倒す」といったアクションが該当します。
プレイヤーが「自らの操作によってゲームに影響を与えている」と
直接認識できない、あるいはその影響を実感しにくい要素です。
これは、メカニクスの一部がプレイヤーから隠されており、ゲーム内でどのような変化が起きているのかを把握しにくいためです。
たとえば、ゲーム内でアイテムを購入したときに裏で処理されるシステムや、イベントの進行に応じて自動的に変化する内部データ(例：イベントフラグの更新)などが該当します。
これらの仕組みは、プレイヤー自身が自分の操作による影響やフィードバックを明確に感じることができないため、
ゲーム内でどのような変化が起きているのかをプレイヤーが認識しにくいのが特徴です。
プレイヤーがゲーム内で繰り返し行う、ゲームの基礎となるシステムです。
これにより、開発者の意図するゲーム体験をプレイヤーに提供できます。
メインのゲームプレイとは異なりますが、ゲーム体験を補完し、影響を与える仕組みです。
たとえば、ゲームの継続を促したり、課金要素を組み込んだりする仕組みなどが含まれます。
これらはプレイヤーにデザイナーの意図した行動を促すことを目的としており(例：ゲームに何度も戻ってプレイさせる、継続して遊ばせる、課金を促すなど)、
「コア」メカニクスと組み合わせることで、より魅力的で没入感のあるゲーム体験を提供することができます。
プレイヤーの操作が
自身のデバイス(スマホやPC)のみで処理される仕組みです。
プレイヤーの操作が
サーバー側で処理される仕組みです。
プレイヤーの操作が
プレイヤーのデバイスとサーバーの両方で処理される仕組みです。
この場合、デバイスとサーバー間で継続的なデータ通信が発生します。
プレイヤーがゲーム内のすべてのメカニクスに直接触れられるわけではありません。
「ゲームプレイ」メカニクスは、プレイヤーに明示されることがありますが、一方で「非ゲームプレイ」メカニクスはプレイヤーからは見えず、表には現れません。
これらのメカニクスは、ゲームの目的に直接影響を及ぼす場合もあります。
たとえば、制限時間内にキャラクターがすべてのコインを集めるゲームを考えてみましょう。
この場合、「コインを拾う動作」や「コインのカウントが増える機能」は
「ゲームプレイ」メカニクスの一部です。
これらはゲーム体験の核となる要素であり、正しく機能しているかを確認する必要があります。
一方で、
「非ゲームプレイ」メカニクスは、プレイヤーから見えないゲームの内部処理を指します。
たとえば、ゲーム内で課金アイテムを購入すると、裏側ではさまざまな処理が行われます。
具体的には、次のような処理があります。
1. データベースからアカウント情報を取得し、プレイヤーのアカウントを確認
2. プレイヤーの残高から購入金額を引き落とす
3. 購入履歴を記録し、専用ファイルに保存
4. 購入完了通知をプレイヤーに送信
さらに、購入日時や商品の種類を記録することで、関連商品の割引情報を自動で通知することも可能です。
こうした
「非ゲームプレイ」メカニクスはプレイヤーからは見えませんが、ゲームにとって重要な機能です。
プレイヤーが直接目にすることがないからこそ、開発段階で詳細な要件として仕様書に明記し、確実にテストで検証することが求められます。
そのため、正しく機能しているかを確認するテストが欠かせません。
「ゲームプレイ」メカニクスと
「非ゲームプレイ」メカニクスのテストはいずれも
機能テストの一部です。
「コア」メカニクスと「メタ」メカニクスはゲームへの影響が異なるため、それぞれ異なるテスト方法が求められます。
「コア」メカニクスとは、ゲームの基本となる仕組みやルールを指します。
これがなければ、ゲーム自体の根幹が揺らいでしまうような重要な要素です。
たとえば、レースゲームにおいて「車」がなくなると、それはもはや「レースゲーム」とは呼べなくなります。
一方、
「メタ」メカニクスはゲーム体験を補完する追加的な要素や機能です。
これがなくてもゲームの本質は変わりませんが、あることでより面白さが増します。
たとえば、特定のレースコースに合わせて車の種類を選ぶことや、戦闘前にキャラクターに防具を装備させることなどが挙げられます。
なくても遊べますが、あることでゲームに深みや幅が生まれます。
機能要件(ゲームがどう動作するべきか)だけでなく、
「コア」メカニクスと
「メタ」メカニクスには、
性能や使いやすさといった非機能要件もあり、テストではこれらも重要なポイントとなります。
たとえば、アバターの見た目を変更する
「メタ」メカニクスでは、「意図した通りに正しく変更されること」が最も重要です。
変更を確定した後に少し遅れて反映されても、大きな問題にはなりません。
しかし、キャラクターがジャンプしたり、バトル中にスキルを発動するタイプの
「コア」メカニクスでは、
わずかな遅延でもプレイヤーの勝敗に影響を与えるため、非常に重要な要素となります。
そのため、
「コア」メカニクスでは「パフォーマンステスト
[1]」の実施が不可欠です。
[1]パフォーマンステスト
フレームレートやメモリ使用量などを測定し、ゲームの動作速度や安定性を評価するテストです。
これにより、快適なプレイ体験を提供し、動作環境に合わせた最適化を行います。
また、
「コア」メカニクスと
「メタ」メカニクスはその性質上、テストを行うタイミングも異なります。
「コア」メカニクスは
開発の初期フェーズで導入されます。
「キャラクターの動作」や「報酬の受け取り」などがテストされ、正しく機能しているか、ターゲット層の関心を引く内容となっているかが確認されます。
「メタ」メカニクスは通常、
本格的な開発フェーズで実装されます。
ベータテストの段階で「平均プレイ時間」「招待したフレンドの数」「平均課金額」「人気のある課金商品」などが分析されます。
この段階では、最も効果的なメカニクスを決定するために、「ABテスト
[2]」がよく用いられます。
[2]ABテスト
ゲーム開発において、2つの異なるバージョン(AとB)を用意し、それぞれのバージョンをプレイヤーに試してもらい、どちらがより良い評価を得られるかを比較する手法です。
ゲームの構造に応じて、「クライアント」「サーバー」「クライアント-サーバー」各メカニクスのテスト内容は異なります。
それぞれの特性に応じた適切なテスト方法が必要となります。
「クライアント」メカニクスは、プレイヤーのデバイス上で処理が行われる仕組みです。
サーバーを介さず、すべてのメカニクスがクライアント側で実行されます。
このタイプのゲームは「シングルプレイヤーゲーム」と呼ばれ、
インターネット接続を必要としないスタンドアロン型のゲームです。
クライアントには、ゲームの実行コード、パラメータ、ダメージ計算式、ステージマップ、キャラクターモデルなどのデータが含まれています。
そのため、悪意あるプレイヤーによるデータ改ざんも可能です。
たとえば、処理速度やキャラクターパラメータ、ミッション報酬の量などを自由に変更できます。
シングルプレイヤーゲームでは、こうしたデータ改ざんはゲーム進行に有利に働くことはありますが、大きな問題とはなりません。
たとえば、武器のダメージ量を改ざんしても、データはサーバーに影響を及ぼしません(そもそもサーバーを使用していないため)。
このため特定のプレイヤーがクライアントのデータを改ざんしたところで、
他のプレイヤーには何の影響もありません。
「クライアント」メカニクスはマルチプレイヤーゲームにも存在しますが、通常は他のプレイヤーに影響を与えません。
たとえば、ステージマップの表示やキャラクターのインベントリの開閉などは、クライアント側のみで処理されます。
このような機能は、機能テストによって確認されます。
「クライアント」メカニクスのテストは通常ブラックボックステストで実施され、UI(画面や操作)の動作確認を行います。
テストでは、実際のプレイヤーと同様の操作を行いながら進行します。
「サーバー」メカニクスは、すべての処理がサーバー上で行われる仕組みです。
プレイヤーはサーバー上のプロセスに直接干渉できないため、開発者は
重要なゲームロジックをサーバー側に配置します。
「サーバー」メカニクスのテストは、マルチプレイヤーオンラインゲームにとって最も重要な要素です。
たとえば、PvPモードのチーム戦では、サーバーがゲームレーティングやキャラクターレベルを基に公平な対戦相手をマッチングします。
この処理が正しく行われない場合、PvPモードの公平性が損なわれ、ゲームの楽しさが失われます。
サーバー側のテストは、
「クライアント」メカニクスのテストとは異なり、通常UIを使用せず、サーバーコンソールや専用ツールを用いて実施されます。
テスターは主にログの分析やデータベースの動作確認を中心に作業を行います。
「サーバー」メカニクスにおける重要なテストには、機能テスト、パフォーマンステスト、セキュリティテストが含まれます。
「クライアント-サーバー」メカニクスは、
クライアントと
サーバーの両方を組み合わせた仕組みです。
ゲームのロジックの一部はクライアント側で、もう一部はサーバー側で処理されます。
このようなメカニクスの部分では常にデータを送受信しています。
マルチプレイヤーゲームでは、サーバーはクライアントからデータを受信し、処理結果を関連するプレイヤーに送信します。
サーバーに届いたデータは必ず検証されます。
たとえば「ゲーム内のショップ」でアイテムを購入しようとした際、プレイヤーが「購入に必要なゲーム内通貨」を持っているかどうかを確認します。
もしプレイヤーがクライアントでデータを改ざんして不正なパラメーターをサーバーに送信しても、
サーバーが必ず受信データを検証し、
不正なデータを正しい値に修正したり排除したりします。
「クライアント-サーバー」メカニクスのテストでは、テストケースの数をできるだけ抑えつつ、
多くの異なる機能を一度にカバーできるよう設計することが重要です。
たとえば、「敵(Mob
[3])を倒す」シナリオを通じてクライアントがゲームサーバーにログインするテストでは、必要なアクションは少ないものの、
クライアントとサーバー間のほぼすべてのメカニクスが使用されます。
● クライアントから認証用のサーバーへリクエストを送信する
● 認証サーバーがデータベースにリクエストを送り、認証処理を実行し、前回のゲーム状態を復元する
● サーバー上にあらかじめ読み込まれているマップを選択するか、新たなゲームメカニクスをサーバー上で生成する
● マップが存在するゲームメカニクス用サーバーにクライアントを接続する
● サーバーがゲームキャラクターおよび周囲のオブジェクトを生成し、それらをユーザーに表示するようクライアントに命令を出すことで、キャラクターと周辺オブジェクトの画面表示を提供する
● キャラクターをマップ上で移動させながら、新しいゲームオブジェクトを表示する
● コンピュータ制御の敵(Mob)を発見し、その攻撃をクライアント側で表示する
● サーバーから「攻撃」コマンドを受信する
● キャラクターとMobが攻撃可能な距離にあり、かつ間に障害物が存在しないことを確認し、攻撃が可能かどうかを検証する
● 攻撃が可能な場合、Mobに対して「ダメージを受けた」旨のメッセージをサーバーから送信する
● サーバー側でMobが受けたダメージ量を計算し、Mobの体力パラメータを減少させる
● Mobがプレイヤーに与えたダメージをクライアント側に表示する
このような一連の処理を通じて、クライアントとサーバー間の重要なやり取りを網羅的に検証することができます。
[3]Mob
いわゆる「モブキャラ」の略称。ゲーム内でプレイヤーが対峙する敵や中立NPCなどを指します。
ゲームメカニクスとは、ゲーム内におけるキャラクターやアイテムの挙動を決定するルールや仕組みのことです。
たとえば、Aボタンを押すとキャラクターがジャンプしたり、アイテムを拾うとSE(効果音)が鳴るような仕組みです。
これらのルールや仕組みによって、ゲームの特徴や雰囲気が作られます。
ほとんどのゲームには、多くの異なるゲームメカニクスが組み込まれています。
以下は「ゲームメカニクス」に関連する「欠陥」の種類です。
● メカニクスの機能的な欠陥
● ゲームメカニクスの適切なフィードバックや認識性に関する欠陥
● メカニクスの有効性に関する欠陥
ゲームメカニクスにおいて最も多く見つかるのが「
機能的な欠陥」です。
たとえば、「武器がリロードできない」「アイテムが拾えない」「双眼鏡を使っても画像が拡大されない」などがあります。
これらは、開発者がゲームのコードを記述する際にミスを犯したことが原因で発生することが多く、発見や修正が比較的簡単な欠陥です。
この欠陥は、特定のメカニクスを使用した際に「ゲームからの反応がない」または「反応が不自然である」といった状態を指します。
たとえば、「プレイヤーがなぜゲームオーバーになったのか分からない」「自分の操作に反応が返ってこない」などの状況です。
このような「
プレイヤーが状態の変化を認識できない」問題は、ゲームメカニクスに対する十分な視覚・聴覚的なフィードバックが不足している場合に発生します。
そのため、通常、ゲームメカニクスには視覚的や音響的な効果が設定されています。
たとえば、「爆発エフェクト」「タイムカウントのSE」「テキストメッセージ」などです。
テストでは、メカニクス使用時に「適切な反応があるか」「反応の内容が妥当か」を確認します。
一方、「演出」の内容や「正確さ」については、グラフィックテストやサウンドテストで確認します。
この欠陥は、「特定のゲーム環境(地形や状況)」でメカニクスが十分に機能しなくなる場合に発生します。
単体では正しく機能する仕組みでも、他のメカニクスやゲーム内の要素、特定の地形や環境と組み合わさることで意図しない動作やバランス崩壊が生じることがあります。
たとえば、「あるアイテムは
どこでも使用できるが、特定の場所では
使用できない」といった状況がこれにあたります。
こうした問題を防ぐために、メカニクスは他のメカニクスやゲーム内のオブジェクト(キャラクターやアイテム)、さらにはマップ上のすべての要素と組み合わせてテストする必要があります。
そのため、メカニクスがゲーム全体で適切に機能するかを確認するために、「統合テスト
[4]」と「ユーザビリティテスト
[5]」を同時に実施します。
[4]統合テスト
ゲーム内のさまざまな要素が同時に正しく動作するかを確認するテストです。
たとえば、「キャラクターがジャンプして壁に当たる」など、個々の機能が単独では正常に動作していても、組み合わせた際に問題が発生しないかを検証します。
[5]ユーザビリティテスト
ゲームがプレイヤーにとって操作しやすいかを確認するテストです。
たとえば、直感的に操作できるか、メニューの使いやすさ、プレイ中にストレスを感じずスムーズに進行できるかを実際にプレイして評価し、フィードバックをもとに改善を行います。
たとえば、ゲームデザイナーが以下の「特性」を持つ敵Aと敵Bをそれぞれゲームに配置したとします。
敵A：移動速度が「速い」& ジャンプ力が「高い」& 攻撃力が「低い」
敵B：移動速度が「遅い」& ジャンプ力が「低い」& 攻撃力が「高い」
この2種類の敵は、それぞれ
長所と
短所があり、理論上は互角の強さに見えます。
しかし、ステージマップが「高低差のある地形」で構成されており、操作キャラクターが「高い場所」に登れる場合、バランスが崩れる可能性があります。
敵Bはジャンプ力が
低いため、「高い場所」に登ることができず、プレイヤーが一方的に攻撃できる状況が生まれます。
一方、敵Aは高い場所まで登れるため、簡単には倒せません。
この問題の解決策として、「メカニクスの調整」や「ステージマップの変更」が考えられます。
このテストの難しさは、メカニクスがさまざまな状況下でどのように機能するかを見極める点にあります。
そのため、メカニクスと環境オブジェクトの相互作用に関する問題は、
ベータテスト中にプレイヤーによって行われる「アドホックテスト
[6]」で多く発見されることが一般的です。
[6]アドホックテスト
あらかじめ決められた計画やテスト手順に縛られず、テスターの経験や直感を活かして自由にプレイしながらバグを発見するテスト手法です。
日本では慣習的に「フリーデバッグ」とも呼ばれることもあり、予期しない動作や見落とされがちな問題を発見するのに適しています。
ゲームメカニクスのテストは、ソフトウェア開発の各段階で異なる手法を用いて実施されます。
プレプロダクション段階では、
主に「コア」メカニクスのみが実装されます。
この段階では、テスターが以下の観点で「ゲームメカニクス」を検証します。
● 機能的な正確さ
● プレイヤーの興味を引く仕掛け[7]
● プレイヤーが継続して遊びたくなる魅力[8]
すべてのメカニクスや動作ルールが、ゲームデザインドキュメント(設計仕様書)に明確かつ完全に記載されていることを確認します。
また、プレイヤーがどのようにメカニクスと関わるのかを分析し、各メカニクスがゲーム全体に与える影響を評価します。
[7]プレイヤーの興味を引く仕掛け
プレイヤーが最初に「面白そう」と感じるポイントや、ゲームへの関心を持たせる仕組みです。
[8]プレイヤーが継続して遊びたくなる魅力
プレイヤーが繰り返し遊びたくなる要素や、何度でも楽しめる仕掛けです。
プロダクション段階では、実装されたメカニクスが要件を満たしているかを確認する「機能テスト」が行われます。
通常、この段階では「テスト条件セット」と「チェックリスト」を用いてテストを進めます。
可能な限り多くのメカニクスを網羅するよう、テストの順序を設定します。
また、異なるメカニクス同士の相互作用を検証するためには、「探索的テスト
[9]」や「アドホックテスト
」が効果的です。
特に大規模なマルチプレイヤーゲームでは、メカニクスとさまざまなゲーム要素の組み合わせが多岐にわたるため、事前にすべてのテスト条件を定義することが困難です。
[9]探索的テスト
テスト実施とテスト設計を同時に行う手法で、テスターがシステムを操作しながら即興でテストケースを作成し、バグや問題を発見する方法です。
特にテスターの経験や知識が重要で、仕様に沿って柔軟にテスト範囲を調整しつつ進行する方法です。
非機能テストでは、ゲームメカニクスがゲーム全体のパフォーマンスに与える影響を確認します。
リソースの使用状況(RAMやCPU負荷など)や、それに伴う現象(フリーズ、フレームレートの低下等)を詳しく検証します。
また、ウイルス対策ソフトとの互換性など、他のソフトウェアや各種コンポーネントとの相性にも注意が必要です。
サーバーを使用するゲームの場合は、サーバー自体の性能テストや負荷試験も実施し、同時接続時のパフォーマンスや安定性も評価します。
パフォーマンスに影響を与えるメカニクスが実装される段階で、計画的にパフォーマンステストを実施します。
ベータテスト[11]では、多くの一般プレイヤーが参加し、
「コア」メカニクスだけでなく、「
メタメカニクス(補助的な仕掛けや継続プレイを促す要素)」も評価されます。
特に「コア」メカニクス(基本操作やバトルなどの中核要素)の検証が重視されますが、
メタメカニクス(課金、継続ログイン促進、ランキング機能など)の体験や効果についても、プレイヤーのフィードバックを収集してバランスや満足度を確認します。
実際には、コアメカニクスの安定性や面白さが特に重要ですが、メタメカニクスの完成度も、プレイヤーの満足度や運営の成功に大きな影響を与えます。
このテストでは、実際にプレイしたときの楽しさや、操作やルールの分かりやすさが特に重視されます。
非ゲームソフトウェアのテストと同様に、この段階では「機能の欠陥を見つける」ことよりも、
エンドプレイヤーからのフィードバックを収集することが主な目的となります。
大規模なマルチプレイヤーゲームでは、ベータテストの前に
アルファテスト[10]が実施されることもあります。
ゲームリリース後は、プレイヤーから報告されたメカニクスの欠陥や、アップデート・新規追加されたメカニクスについても継続的なテストが必要です。
[10]アルファテスト
目的: ソフトウェアが仕様通りに動作しているかを確認する初期段階のテストです。
実施場所: 通常、開発チーム内や社内のテストチームによって実施されます。
[11]ベータテスト
目的: アルファテストでの修正を踏まえた製品を、より実際の利用環境に近い状態でテストすることが目的です。
実施場所: 限定された一般プレイヤー(社外テスターや応募者など)や、一般公開に近い形で実施される場合もあります。
「
ゲームメカニクス」は、ゲームの核となる要素です。
これはプレイヤー体験の根幹を成す要素であり、ゲームへの興味を維持するうえで最も重要です。
そのため、「ゲームメカニクス」が正しく機能するかどうかを確認することは、テストにおいて最優先事項となります。
こうしたテスト中に発見された欠陥は、通常「最も重大な問題」となり得ます。
たとえば、「キャラクターがジャンプできない」といった
「コア」メカニクスの欠陥は、
ゲームプレイに直接影響を与え、最悪の場合、ゲームクリアが不可能になります。
さらに、たとえ使用頻度が低かったり、クリアに必須でないメカニクス(例：馬に乗るアクション)であっても、
その挙動が不自然であれば、ゲーム全体の品質が損なわれる可能性があります。
ゲーム開発において重要な工程のひとつが、「ゲームメカニクス」を含む「仕様書」の作成です。
開発初期段階で「ゲームメカニクス」の仕様をレビューすることで、後のトラブルを未然に防ぐことができます。
これらの問題には、「開発プロセス」そのものに関わるものや、「リリース後のプレイヤーの反応」に影響を及ぼすものが含まれます。
レビュー時には、テスターは以下の品質特性に注意を払う必要があります(ISO 25010参照)。
● 記述の完全性：すべてのメカニクスが漏れなく、詳細に記載されていること
● 現実との整合性：物理法則や常識と矛盾しない内容であること
● 構造の明瞭さとナビゲーション性：構成がわかりやすく、情報に素早くアクセスできること
レビューによって防げるゲーム開発プロセスの問題
● 仕様の記述が曖昧または不完全であるため、メカニクスの本質を正しく理解できず、作業工数を見誤るおそれがある
● 新たに導入するメカニクスが既存のものと互換性を持たない
● 特定のプロジェクトにおいて、設計上メカニクスの実装が困難である
レビューによって防げるプレイヤーのメカニクスに対する認識の問題
● そのゲームに適さないメカニクスの導入
● ゲームの面白さを損なうメカニクス
● バランスが取れていないメカニクス
● ゲーム内で使用頻度が極端に低いメカニクス
「ゲームの状態」とは、特定の時点におけるゲーム内のすべてのオブジェクト(キャラクター、アイテム、環境など)に関するすべてのパラメータや変数の値を指します。
ゲームが複雑になり、プレイヤーに多くの選択肢を提供するほど、各オブジェクトのパラメータも増えていきます。
パラメータは、大きく「
可視パラメータ」と「
不可視パラメータ」に分類されます。
「
可視パラメータ」とは、プレイヤーが画面上で直接確認できるものを指します。これには以下のような要素が含まれます。
● プレイヤーの経験値(ミッション完了時)
● 選択した武器の特性
● アイテムの所持上限数
● ゲーム内ストアでの商品価格
「
不可視パラメータ」とは、プレイヤーが画面上では確認できず、主に開発者しか直接見ることのできない隠しパラメータのことです。
これらは主に開発者によって制御され、ゲームバランスやシステムの動作に関与します。
たとえば、プレイヤーが目にする「攻撃力」や「防御力」のほかに、「命中率」のような隠れたパラメータが存在し、攻撃の成否を決定していることがあります。
不可視パラメータは、ゲーム内のさまざまな要素に影響を与えています。たとえば、以下のようなものが挙げられます。
● ドロップ率(報酬としてランダムなアイテムが得られる確率)
● 射撃速度や地形ごとの移動速度
● プレイヤーの選択がストーリーの展開に与える影響
ゲームパラメータをテストする際には、ゲームが表示値だけでなく、内部的にも正しいパラメータで動作しているかを検証することが重要です。
「
可視パラメータ」の場合、「表示されている値」と「ゲーム内部で使用されている値」が一致しているかどうかを視覚的に検証できます。
攻撃力が「1」のキャラクターが敵に「10」のダメージを与える場合、
攻撃力を「2」に増やした後、同じ敵に与えるダメージが「20」になるはずです。
プロのテスターは、仕様書に記載された「パラメータの計算式」や「原則」に基づいてテストを実施します。
しかし、仕様書に明確な情報が記載されていない場合、テスターもプレイヤーと同様に、一般的な常識や経験をもとに相対的な評価を行うしかありません。
※一般的なプレイヤーは、ダメージの数値が若干正確でなくても気にしないかもしれませんが、ダメージが変化しない、あるいは減少する場合にはすぐに気づきます。
「
不可視パラメータ」をテストする際には、テスターがゲームデータベースにアクセスし、実際のパラメータ値を確認することもあります。
これにより、仕様と異なる値が設定されていないかを検証できます。
また、プレイヤーがゲーム内で「
可視パラメータ」を変更できる場合、その変更が正しく適用されるかどうか(変更の可否や数値の正確性)もテスト対象となります。
さらに、「ゲームの状態」をテストすることは、
ゲームのセーブおよびロード機能の検証とも密接に関連しています。
多くのゲームでは、一度のプレイで全てをクリアするのが難しいことがあります。また、エンドレス型のゲームも存在します。
そのため、多くのゲームでは「
セーブ」および「
ロード」機能が導入されており、
プレイヤーが毎回最初からやり直さずに済むよう設計されています。
さらに、「セーブ機能」には、他にも重要な役割があります。
たとえば、「アイテムコンプリート」や「分岐ルートの探索」など、
やり込み要素を楽しむために活用されたり、ゲームの難度調整にも役立ちます。
特に「ボス戦」などの難関ステージの前にセーブできることで、ミスによるゲームオーバーのリスクを減らし、最初からやり直す必要を避けることができます。
「セーブ」とは、
ゲームの進行状況に関する情報を
ハードディスクやクラウド上に保存することを指します。
セーブデータは「
ゲームの現在の状態を記録するファイル」として作成されます。
このファイルのサイズはゲーム本体と比べて非常に小さく、一般的に以下のような情報が含まれます。
● 保存が必要なオブジェクト(キャラクター、アイテム、環境など)のリスト
● 各オブジェクトのパラメータ情報
● ゲームの状態を判定するための各種コード
ほとんどの「変数」は「オブジェクト」として扱われ、ゲームシステムによって状態が管理・保存されます。
たとえば、「キャラクターのHP」「習得したスキル数」「キャラクターの現在位置」なども
「変数オブジェクト」に含まれます。
セーブ方法、セーブファイルの形式、保存されるパラメータの内容はゲームによってさまざまです。
ゲームの進行状況を保存するために、これまで数多くの方法が考案されてきました。
ここでは、代表的なセーブ方式を紹介します。
開発者が指定した「
チェックポイント」(特定の場所)に到達すると、
自動的にセーブが行われる仕組みです。
次のチェックポイントに到達すると、それまでのデータが上書きされます。
チェックポイントによってセーブされたゲームの状態はそのセッション中にのみ保持され
ゲーム終了時に削除されます。
チェックポイントでセーブされたことが明示されない場合もあります。
このセーブやロードの正確な動作を検証するには、すべてのチェックポイントとその正確な位置が記載された仕様書が必要です。
後述する他のセーブ方式では、仕様書にこの情報が含まれていない場合や、詳細が記載されていないこともあります。
【例】
プレイヤーが特定エリア内の「クリスタル」に近づくと、自動的にセーブが行われます。
セッション中にプレイヤーが死亡した場合、そのクリスタルのそばでリスポーンされます。
ゲーム内の特定の場所に「
セーブポイント」が設置されており、プレイヤーは
手動で進行状況をセーブできます。
これらのセーブポイントは通常、
特別な状態を記録する必要のないエリアに配置されています。
この仕組みにより、不要なデータを減らし、セーブファイルのサイズを抑えることができます。
テストでは、各セーブポイントで正しくセーブできるか、繰り返しセーブとロードを行っても問題が発生しないかを確認します。
【例】
「セーブ専用の部屋」を設けることで、保存対象を限定し、ファイルサイズの増加を抑える工夫がされています。
「
チェックポイント方式」と「
セーブポイント方式」の要素を組み合わせたセーブ方式です。
プレイヤーの進行状況は、プレイ中の特定のポイントで
自動的にセーブされます。
多くのゲームでは、終了時にオートセーブが行われます。
ゲームを再開する際、プレイヤーは新しいゲームを始めるか、前回のセーブデータをロードするか選択できます。
テストでは、各オートセーブポイントで正しくセーブが行われているか、該当するゲーム状態を問題なくロードできるかを確認します。
【例】
「特定エリアに入った時」や「イベントをクリアした時」など、さまざまなタイミングで自動的にセーブされます。
「チェックポイント方式」との主な違いは、ゲームを再開する際に「ロード」が可能である点と考えられます。
プレイヤーは
好きなタイミングでメニューを開き、進行状況を
手動でセーブできます。
「
クイックセーブ」機能がある場合は、ボタンを押すだけでセーブやロードが可能です。
「オートセーブ」と同様に、マニュアルセーブではゲームの状態を記録したファイルが作成されます。
テストでは、以下の点を確認します。
● セーブファイルから正しくゲーム状態がロードできるか
● ファイル名が仕様書に基づいて正しく設定されているか
● OSの適切なディレクトリ構造に保存されているか
● 新しいゲームバージョンでセーブファイルが利用可能か
● 別のPC環境でもセーブファイルが正常に動作するか
以下のような条件下では、マップやステージのロードが正しく行われるかの確認が主なテスト項目となります。
● 一本道ゲーム(例：迷路からの唯一の正しい出口がある場合)
● キャラクターの能力が変化しないゲーム(例：レベルが進んでも攻撃力や移動速度が変わらない)
一方で、次のようなゲームでは、複雑な情報のセーブとロードが求められます。
● 多くのパラメータを持つキャラクター(例：移動速度、攻撃力、装備、3Dモデルの外見など)
● プレイヤーの行動でパラメータが変化するゲーム(例：アイテム取得で移動速度が上がる)
このようなタイプのゲームでは、テスターは、
プレイヤーキャラクターの位置情報(マップ上の座標)や、
装備・ステータス・所持アイテムなどの
キャラクター固有情報が正しくセーブ・ロードされているかを検証する必要があります。
セーブ機能をテストする際、テスターは以下の点を確認しなければなりません。
● プレイヤーが前回ゲームを終了した時点のマップに正しく配置されていること
● プレイヤーのキャラクターが、セーブ時に所持していたアイテムを正しく保持していること
● アイテムの効果により、ゲームキャラクターの速度パラメータが適切に上昇していること(パラメータが正しく保存・反映されていること)
International Software Testing Qualifications Board(以下、ISTQB®)
ISTQB®はInternational Software Testing Qualifications Boardの登録商標です
Certified Tester Game Testing (CT-GaMe) Syllabusの著作権
ISTQB®、著者 Andrey Konushin(議長)、Alexander Alexandrov、Evgeny Glushkin、Dmitriy Karasev、Elena Karaseva、Elizaveta Kruchinina、
Vadim Lukovaty、Dmitry Melishev、Maxim Nikolaev、Alexander Prokhorov、Anton Savvateev、Ayrat Sayfullov、
Pavel Sharikov、Kirill Shevelev、Artyom Stukalov、Nikita Sysuev、Tatiana Tepaeva、Alexander Torgovkin、
Margarita Trofimova、Yaroslav Vereshchagin、Svetlana Yushina、Lyubov Zhuravleva
画像は「
Microsoft Designer」
「
ChatGPT」にて生成しております。意図せず権利関係を侵害しておりましたら大変申し訳ございません。
テスター
ゲームテスター
デバッガー
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
