[ChatGPTによる要約をさらに手動で要約]
ゲームメカニクスは、様々な種類に分類される。ゲームプレイメカニクスはユーザとのインタラクションを伴い、非ゲームプレイメカニクスはユーザは関与しません。コアメカニクスはアプリケーションを指し、メタメカニクスはいわゆるマスターデータのこと。クライアントメカニクスはユーザーのデバイス上にあり、サーバーメカニクスはゲームサーバーにあり、クライアントサーバーメカニクスは両者間のデータ交換に関わる。
テストでは、ゲームプレイとゲームプレイ以外の機能テストを行い、コアメカニクスは機能要件と非機能要件に焦点を当て、メタメカニクスはリリース後半でテストします。クライアントテストではブラックボックステスト、サーバーテストではゲームイベントの検証、クライアント・サーバーテストではその両方を組み合わせます。
不具合は、機能的なもの、ゲームの適切性を認識できるもの、特定の環境での有効性に関連するものなどがある。テストの複雑化に伴い全数テストを行うことが事実上不可能であることから、複数のプレイヤーグループによるベータテスト中のアドホックテストによって発見された不具合を元に修正対応する。
ゲーム開発プロセスにおいて、ゲームメカニクスをテストすることは、スムーズなゲーム体験を保証し、問題を予防するために不可欠。テスターは、機能的な欠陥、適切な認識可能性の欠陥、メカニックの有効性の欠陥に対処しながら、機能的な正しさに焦点を当てます。ゲームの仕組みを確認することで、誤解や非互換を防ぐことができます。ゲームの状態テストでは、表示値と実際の値を比較する。
■前置き
こちらで注意書きをしています。
ChatGPTやDeepLを使用して体裁を整えたもののため大雑把です。
■本文
今回は「2. Testing Game Mechanics - 180 minutes (K3)」の部分を大雑把に訳したり解説してみるよ。
解説として今回気にしたい箇所は、
ゲームがどうやって動いているかということと
品質特性「ISO20510」についてだと思うよー
第2章の学習内容は以下です。
2.1 ゲームメカニクス
GaMe-2.1.1 (K2) ゲームメカニクスの種類を分類
GaMe-2.1.2 (K2) ゲームプレイメカニクスと非ゲームプレイ機構のテストを区別
GaMe-2.1.3 (K2) コアメカニクスとメタメカニクスのテストを区別
GaMe-2.1.4 (K2) クライアント、サーバ、およびクライアントサーバのメカニクスのテストを区別
GaMe-2.1.5 (K2) ゲームメカニクスの欠陥の例
2.2 ゲーム機構のテスト手法
GaMe-2.2.1 (K2) ゲーム製品を作成するさまざまな段階での主要なアプローチとテストオブジェクトをまとめる
GaMe-2.2.2 (K2) ゲームメカニクスのテストの重要性を区別
GaMe-2.2.3 (K2) ゲームメカニクスを説明するドキュメントのレビューの重要性を区別
GaMe-2.2.4 (K3) ゲームメカニクスの基本的なテスト手法の適用(セーブ・ロードについてのテスト)
第1章ではゲームにとって最も重要なことの一つはユーザの関心を引き付けて面白いと思うプレイヤーの数を維持しながら増やすことであることを述べられていましたが、
2章ではゲームメカニクスをプレイヤーとのやりとり、ゲームプレイへの影響、ゲーム構造のアーキテクチャに基づいてさまざまなタイプに分類します。
■2.1 ゲームメカニクス
2.1.1 (K2) ゲームメカニクスの種類を分類
・ゲームプレイメカニクスは、ユーザが意識的にゲームシステムとやりとりし、利用可能な情報に基づいて行動を行う場合に関連します。彼らはゲームの状態を変化させ、行動の結果を見ることができます。一方で非ゲームプレイメカニクスは、ゲームメカニクスの一部がユーザに隠されているため、ユーザがゲーム状態に完全または部分的にしか影響を与えられない場合に関連します。
・コアメカニクスはゲームの基盤を形成し、ユーザがゲームを通して繰り返す行動を定義します。これらは、ユーザがゲーム制作者によってゲームに組み込まれた特定の体験を受け取ることを目的としています。
・メタメカニクスは主要なゲームプレイの外にありますが、ゲームデザイナーが望む行動（ゲームに戻る、プレイを続ける、購入するなど）をプレイヤーに促すことを目的として影響を与えることができます。
最後に、ゲームメカニクスはゲーム構造のアーキテクチャに基づいて分類することができます。クライアントメカニクス、サーバメカニクス、クライアント-サーバメカニクスです。クライアントメカニクスは、ユーザのデバイスでのみ発生するユーザのアクションの処理を指します。一方、サーバメカニクスは、ゲームサーバでのみ処理されるメカニクスを指します。クライアント-サーバメカニクスは、ユーザのデバイスとサーバの両方で処理されるメカニクスであり、両者の間でデータが常に交換されています。
2.1.2 ゲームプレイのメカニックのテストと非ゲームプレイのテストの違い
ゲームプレイメカニックのテストと非ゲームプレイメカニックのテストの違いについて。
ゲームプレイメカニクスは、公式または非公式な仕様で記述することができ、ユーザは直接それらを操作、情報を受け取ります。
一方、非ゲームプレイメカニクスは、ユーザの行動によって引き起こされることはあっても、通常ユーザから隠されています。
非ゲームプレイメカニクスは、ゲームプレイの目標達成に影響を与える可能性があるため、ユーザに対して説明する必要があります。
ゲームプレイと非ゲームプレイのメカニズムの両方をテストするために機能テストは必要です。
例えば、コインを選んで増やす動作の機能性をテストすることはゲームプレイメカニクスのテストの一例であり、ユーザの購入をトリガーとする非ゲームメカニクスのシーケンシャルフローをテストすることは非ゲームプレイメカニクスのテストの一例です。
これらのテストは、ISTQB_FLでは機能テストと定義されています。
2.1.3 コアメカニクスとメタメカニクスのテストの違い
コアメカニクスとメタメカニクスのテストアプローチの違いについて説明します。
ゲームの根幹をなすコアメカニクスは、ゲームプレイに大きな影響を与え、これを取り除くことでゲームの本質が変わってしまう。
一方、メインとなるゲームプレイの外側にあるメタメカニクスは、影響が小さく、制作段階で後から追加することが可能です。
コアメカニクスとメタメカニクスをテストする場合、機能的な要件も重要ですが、パフォーマンスなどの非機能的な要件も考慮する必要があります。例えば、戦闘中のキャラクターの移動やアビリティなどのコアメカニクスでは、遅延が致命的になることがありますが、キャラクターの外見を変更するなどのメタメカニクスでは、多少の遅延は不具合とはみなされないことがあります。
コアメカニクスのテストは通常、ゲーム開発プロセスの初期に開始され、メタメカニクスのテストは通常、生産段階の後半に開始されます。ベータテストは、メタメカニクスがターゲットユーザに与える影響を評価するために、また、A/Bテストは、最も効果的なメカニクスを決定するために使用されることが多い。
これ何をいっているのかというと
コアメカニクスはアプリ自体のこと
メタメカニクスはマスターデータのこと
マスターデータは乱暴だけど「後で微調整や変更しやすいパラメータ」と受け取ってねー。
なんでそんな分け方になっているのかというと
単純に工数都合というのもあるけど
コアメカニクス部分は各種プラットフォームの審査とか通る必要があったりで手間で、
メタメカニクス部分は審査とか関係なく数値足したりするだけで動くものになってる。
これをうまく分けないと管理が難しいひどい構造のゲーム出来上がってしまうのです。
わかりやすく説明すると
・アプリアップデートが起こるのはコアメカニクス部分
・更新が入ってゲーム内でダウンロードしているのはメタメカニクス
A/Bテストは両方触らせてどっちの方が良い感触してる？ってアンケートみたいなもの
2.1.4 クライアント、サーバ、クライアント-サーバのテストの違い
この3種はテストの方法が異なります。
・クライアントのテスト
クライアントのテストは、通常、ブラックボックステストを使って行われ、アプリケーションのユーザインターフェイスをチェックすることもあります。クライアントメカニクスはプレイヤーの端末で処理され、クライアントに保存されている全てのデータにアクセス可能です。クライアントメカニズムはプレイヤーにゲーム内の優位性を与えることができるが、シングルプレイヤーゲームでは、これは大きな欠陥とはみなされない。クライアントメカニクスは、マルチプレイヤーゲームでも存在し得ますが、その場合はクライアントの構造は他のプレイヤーに影響を与えることはない構造で構築されます。
・サーバのテスト
サーバのテストはゲームイベントの正しい処理の確認、異なるサーバコンポーネント間の正しい相互作用の検証、ゲームロジックのエラーや誤動作のチェックに重点を置いています。サーバの仕組みは、マルチプレイヤーゲームのゲームプレイ全般にとって重要であり、サーバの仕組みに欠陥があれば、プレイヤーの体験に大きな影響を与える可能性があります。そのため、専門的なツールやテクニックを使って、サーバの仕組みを徹底的にテストすることが重要です。
・クライアント-サーバ
クライアント-サーバは、クライアントメカニクスとサーバメカニクスの特徴を併せ持ち、ロジックの一部はプレイヤーのデバイスで処理され、もう一方はリモートサーバで処理されます。両者間のデータは常に交換され、サーバ上で必須の検証を受ける。(チート判定とか…)
テスターは、クライアント-サーバメカニクスをテストする際に、最大限の数の異なるメカニクスをカバーするテストケースを作成します。
2.1.5 ゲームの仕組みに関する不具合の例とその考えられる原因・発生状況
ゲームメカニクスは、ゲームオブジェクトに与える影響と、その結果を示すフィードバックに関与し、ユニークなキャラクターを作り出します。
ゲームメカニクスの欠陥は、機能的欠陥、ゲームの適切性認識性の欠陥、特定のゲーム環境で発現するメカニクスの有効性の欠陥の3種類に分類される。
機能的な不具合は通常、発見と修正が容易であり、ゲームの適切性認識性の不具合は、特定のメカニズムを使用する際にゲームから反応を得ることに関連する。
また、メカニックの有効性と範囲は、ゲームレベルで他のメカニック、オブジェクト、必要なコンテンツと組み合わせてテストされる。
このようなテストの複雑さは、状況やその中でメカニックがどのように機能するかを予測することの難しさと関連しているため、メカニックと環境のオブジェクトとの相互作用の問題点の探索は、多くのプレイヤーグループによるベータテストの段階でアドホックテストの一部として行われることが多い。
■2.2 ゲームメカニクスをテストするための手法
2.2.1 ゲームメカニクスを全体的にテストするための手順とアプローチ
ゲーム製品のソフトウェア開発ライフサイクル
ソフトウェア開発のさまざまな段階において、ゲームテストは、さまざまな方法で実施することができます。
ゲームのプロトタイプを作る段階では、コアメカニクスのみが実装されています。ここでテスターのメインとなるのは、以下のような特徴に対してゲームメカニクスを確認することです。
・機能的な正しさ、
・プレイヤーに興味を引くか
・プレイヤーにとって魅力的か
ゲームオブジェクトに影響を与え、その結果をフィードバックするゲームメカニクスのテストについて
ゲームメカニクスに関連する欠陥には「機能的欠陥」「適切性認識可能性の欠陥」「メカニクスの有効性の欠陥」の3種類がある。すべてのメカニクスとその動作ルールは、ゲーム仕様書(企画書)にレビューされ、完全に記述されなければならない。制作段階では、メカニクスが要件を満たしているか、他のメカニクスと効果的に相互作用しているかを確認するために、機能テストと探索的テストが行われる。非機能テストは、ゲーム全体のパフォーマンスに対するメカニクスの影響をテストするために行われます。ベータテストは、プレイヤーにとっての利便性や分かりやすさを評価するために行われ、リリース後は、プレイヤーから報告されたメカニクスの不具合を修正・確認し、ゲームに追加された新しいメカニクスのテストを行う必要があります。
2.2.2 ゲームメカニクスをテストすることの大切さ
ゲームメカニクスは、プレイヤーの体験の骨格となるもので、プレイヤーの興味を持続させるために極めて重要です。
ゲームをクリアできない不具合があると重大な問題につながるため、ゲームテスターにとってこれらのメカニクスをテストすることは最優先事項です。たとえ再現率が低く、ゲームプレイに不可欠でないメカニクスであっても、その機能が不適切であれば、ゲーム全体の印象に悪影響を与える可能性があります。
2.2.3 ゲームメカニクスの見直しの重要性
開発プロセスにおいて、ゲームメカニクスを含むゲーム仕様書は非常に重要です。これらの仕組みを早い段階でレビューすることで、開発やプレイヤーの認識に関する問題を回避することができます。
レビューの際、テスターは記述の完全性、現実との適合性、文書の構造などを評価する必要があります。また、品質特性[ISO 25010]を注意してレビューを行うのも良いでしょう。
徹底的なレビューは、仕組みに関する誤解、既存の仕組みとの非互換性、実装上の問題などを防ぐことができます。また、不適切、面白くない、バランスが悪い、ゲームでの使用頻度が低いなど、プレイヤーが感じる潜在的な問題にも対処することができます。
ISOについての関連記事
ISO/IEC 25010の品質モデルを使って市場不具合を減らす テスト設計戦略～品質を「見える化」する～
2.2.4 ゲームテストの実例：ゲームのセーブ・読み込みの考え方とテストについて
ゲームのステータス
ゲームのステータスとは、特定の瞬間におけるゲーム内オブジェクトを記述するすべてのステータスと変数の値のことを指す。これらのパラメータは、可視ステータスと隠しステータスに分けることができる。可視ステータスは、経験値、武器の特性、在庫制限、ゲーム内ショップの価格など、プレイヤーが明示的に利用できるステータスである。
隠しステータスは、開発者がプレイヤーの意識によらずゲームプレイに影響を与えるために使用されるもので、精度やドロップ率などがあります。これらの隠しステータスは、ランダムアイテムの入手やプロットの展開など、ゲームの様々な側面に影響を与えることができます。隠しステータスと可視ステータスの両方が、ゲームキャラクターやその他のオブジェクトを演出します。
ゲームの状態についてのテストの目的
テストの目的は表示された値と実際に使用された値を視覚的に比較したり、ゲームデータベースにアクセスして期待値と実際の値を比較することで実施されます。ゲームのセーブとロードに関連するビデオゲームの状態をテストすることの重要性を強調しています。テスターは、仕様書に明記された計算式に導かれますが、パラメータの変化を評価するために常識を用いることも可能です。
保存と読み込み
ビデオゲームにおける「セーブ＆ロード」機能の重要性について論じています。セーブはプレイヤーに様々な解決策を模索させ、ゲームの複雑さを管理することを促すことができると述べています。セーブは、オブジェクトのリスト、各オブジェクトのパラメータの変更、各パラメータに対する特定のコードなど、ゲームの現在の状態に関する情報を保存することを意味します。健康レベル、学習した能力、キャラクターの座標など、あらゆる変数がオブジェクトとして機能することができます。
保存の種類
ビデオゲームで使われるセーブ方法の種類として、チェックポイントの利用、据え置きセーブ、オートセーブ、手動・フリーセーブなどを取り上げています。それぞれの方法は、ゲーム進行のセーブとロードの考え方が異なります。チェックポイントは特定のタイミングで自動的にセーブされ、ステートセーブはゲーム中の特定のポイントで手動でセーブするもので、オートセーブはこの2つの方法を組み合わせたもの、マニュアルセーブはゲームメニューにある特別な項目を使用していつでもセーブできるものです。各方式のテストでは、ロード情報の正確さ、ファイル名と保存場所、セーブファイルを他のデバイスで使用できることを確認する。