プレイヤーがゲームメカニクスを理解しているかどうかを、どのように見極めればよいでしょうか？
巧妙に思えるメカニクスを設計したなら、プレイヤーがそれが何をするのかを発見し、結果を予測し、意味のある選択のために使えるかどうかをテストしましょう。そのメカニクスに依存する小さなタスクをプレイヤーに与え、説明する前に彼らの行動を観察します。アニメーションがうまく再生されたり、ヒントの後に正解を当てたり、プレイヤーが「わかった」と言ったりするだけでは不十分です。それらは、テストしたい理解度の一部しか示していない可能性があります。
このメカニクスにおける「理解」の意味を定義する
誰かをプレイに招待する前に、メカニクスの意図するルールを平易な言葉で書き出してください。そして、それに依存するプレイヤーの決定を挙げます。たとえば、近くのオブジェクトを押し戻すパルス（衝撃波）を持つ架空のプラットフォームゲームを想定してみましょう。有用なテストでは、プレイヤーがパルスを発見できるか、どのオブジェクトに影響を与えるかを特定できるか、押される方向を予測できるか、そしていつ使うかを選択できるかを問うことが考えられます。これらは別々の観察事項です。プレイヤーは効果を理解していても範囲を理解していない場合もあれば、両方を理解した上でパルスを使う価値がないと判断する場合もあります。
この内訳は実践的なテスト計画であり、検証済みの普遍的な尺度ではありません。これは、ゲームをメカニクス（Mechanics）、それらがプレイ中に生み出すダイナミクス（Dynamics）、そしてそれらのダイナミクスが支える体験・エステティクス（Aesthetics）の観点から説明するMDAフレームワークに基づいています。メカニクスの実装そのものがデザインの問いのすべてではないため、このフレームワークは有用です。プレイヤーがそれを使って何をするのか、そしてそのプレイがどのように感じられるかを確認する必要もあります。
セッションの前に短い予測を書いておきます。「プレイヤーがXを理解していれば、Zという指示がなくてもYという行動をとるはずだ」。パルスの例であれば、「オブジェクトが動くのを見た後、プレイヤーは別の動かせるオブジェクトの近くでパルスを試し、それを障害物に向かって飛ばせる位置に自分を配置するだろう」となります。これにより、誰かが夢中になっているように見えたという主観的な印象ではなく、観察可能な行動にテストの焦点を絞り続けることができます。
プレイヤーが自身のメンタルモデルを示せるテストを設定する
各参加者に同じ初期条件と、答えを教えることなくそのメカニクスが重要になるタスクを与えます。「木箱を動かすためにパルスを使ってください」といった指示は避けてください。これでは指示に従えるかどうかをテストすることになってしまいます。そうではなく、木箱を動かすことが前進するための妥当なルートの1つである状況を作り、プレイヤーがパルスに気づき、それをオブジェクトと結びつけられるかどうかを観察します。
彼らが何が起きていると考えているかを知りたい場合は、プレイしながら声に出して考えてもらう（思考発話法）ように促します。Nielsen Norman Groupは、この手法を、代表的な参加者に代表的なタスクを実行させながら思考を言語化してもらい、ファシリテーターは選択を指示するのではなく、耳を傾けて発話を続けさせるプロンプトを出すものとして説明しています。彼らのガイダンスは一般的なユーザビリティテストに関するものであるため、これをゲームメカニクスに適用することは手法の応用であり、ゲームに特化した研究結果ではありません。
プレイヤーが黙り込んでしまった場合は、「何を考えていますか？」といった中立的なプロンプトを投げかけます。「パルスのボタンに気づきましたか？」といった、メカニクスやその答えを暗に含む質問は避けてください。後者のような質問は、自発的な発見テストを単なる再認テストに変えてしまう可能性があります。プレイ中に話すことでタイミングや集中力が乱れる場合は、まず短い試行を完了させ、その後に重要な瞬間で何が起こると思っていたかを説明してもらいます。ただし、事後の説明は、プレイ中に決定が下されるのを見ることよりも信頼性が低い可能性がある点に注意してください。
行動、予測、そしてリトライ時の立ち直りを観察する
事前に書き出した具体的な仮説に照らして証拠を記録します。有用なメモには、プレイヤーが促されずにメカニクスを試したか、どの対象を選んだか、どのような結果を予測したか、結果がその予測と一致したか、そして予期しない結果の後に何をしたかが含まれます。プレイヤーが偶然パルスをうまく使えたとしても、2回目の試行で結果を予測できない場合、最初の成功は安定したメンタルモデルの構築を意味しません。
安全に一時停止できるタイミングで、次の試行の前に予測に関する質問をします。「ここでそれを使ったらどうなると思いますか？」その後、プレイヤーに行動させます。これにより、実演された動きを単に繰り返すだけでなく、ルールを新しい状況に結びつけられるかどうかを確認できます。質問はオープンで短いものにとどめてください。質問する前にルールを説明してしまうと、結果の解釈が困難になります。
メカニクスの理解と、その他の阻害要因を切り離して考えます。プレイヤーはルールを理解していても、操作方法を見落としていたり、関連するオブジェクトに気づかなかったり、レベルデザインによって行動を阻まれたりしている可能性があります。これらは別々の観察事項として記録してください。たとえば操作方法が不明確な場合、そのセッションからメカニクス自体が理解されているかどうかを判断することはできません。後続のビルドやセッションでは一度に1つの変更のみを行い、どの問題がその変更によって対処されたのかがわかるようにしてください。
簡潔なエビデンス記録を活用する
各セッションの後は、「理解できた」といった曖昧なスコアを付けるのではなく、証拠を要約します。以下の小さなマトリクスは参考用の補助ツールであり、標準化された指標ではありません。
最後の質問は、理解度とは明確に分けて考えてください。プレイヤーはメカニクスを理解していながらそれを使うことを好まない場合もありますし、ルールを理解しないまま演出の派手さを楽しむ場合もあります。どちらの知見も重要かもしれませんが、必要とされるデザイン上の判断は異なります。
デザインを変更する前にパターンを解釈する
繰り返し発生する失敗とその文脈を探します。プレイヤーがメカニクスを試そうとしない場合は、発見しやすさ（操作プロンプト、視覚的な手がかり、レベルが実験する動機を与えているか）を点検します。試してはいるものの結果を誤認している場合は、フィードバックとルールの整合性を点検します。正しく予測できているのに任意選択時に使われない場合は、それが意思決定を意味のある形で変化させているか、あるいは別のアクションの方が単純に有用ではないかを検討します。これらは診断のための仮説であり、自動的な結論ではありません。セッションで起きたことと照らし合わせて検証してください。
一握りのわずかなセッションを母集団全体の推定値として扱わないでください。定性的な観察は、デザインのどこが混乱を招いているかを明らかにし、何を修正すべきかを提案できますが、それだけでその問題がプレイヤー全体の中でどれほど一般的であるかを確立することはできません。修正版は同じタスクで再テストし、最初に問題を露呈させた状況だけでなく、見慣れない状況でも確認してください。後で比率や好みを比較する必要がある場合は、適切にリクルートされたより大規模なサンプルと、その問いのために設計された指標を使用してください。
実践的なテスト終了基準
初期のプロトタイプにおいては、想定される数人のプレイヤーがメカニクスを発見し、見せられていない少なくとも1つの状況でその効果を予測し、誘導的なヒントなしに目標のためにそれを使用できるようになり、残りの失敗がメカニクスの機能に関する混乱ではなく特定の修正可能な問題を示している段階で、説明の改訂を終了します。セッションの正確な数はプロジェクトや下すべき判断のリスクによって異なり、ここで引用した情報源によって普遍的な閾値が確立されているわけではありません。
このテストの目的は、あなたのアイデアが巧妙であることを証明することではありません。ゲームがルールを伝え、意図した選択を可能にしているかどうかを確かめることです。プレイヤーがメカニクスを理解した上でそれでも面白くないと感じるなら、それもまた有用な証拠です。デザインには異なる役割、見返り、または文脈が必要なのかもしれません。