プレイテスターから得ることができるフィードバックにはいくつかの種類があり、それぞれのデータをどのように最適に収集するのか不思議です...
クラッシュレポート。誰かがプレイしているときに私のC ++ゲームがクラッシュした場合、どうすればそれを知っていることを確認でき、さらに良いことに...どうしてそれが起こったのでしょうか？クラッシュの原因となったファイルと行番号のような単純なものを取得することでさえ、非常に役立ちます。
設計フィードバック。プレイテスターがゲームをプレイしているとき、彼らが楽しんでいるのか、なぜ楽しんでいるのか、なぜ楽しんでいないのか、調整に何を費やす必要があるのか、どうすればわかりますか？
回答:
インターネットベータテスターではなく、オンサイトプレイテスターについて話していると思います。
ルール＃1：彼らを助けないでください。欲求不満は、あなたがチェックすべき最高のものであるべきです。理想的な状況は、チームを片側に配置し、プレイテスターを顔に1台、画面に1台のビデオテスターを備えた2面鏡にすることです。明らかにこれはほとんどの人にとって実行可能ではないので、できる限りのことをしてください。デザイナーに座って人々が行き詰まるところを見てもらうことは、非常に役立つ情報です。ゲームを持ち帰るときに肩越しに立つことはないので、特定のセクションを通過する方法についてアドバイスしても、必要な情報は得られません。 編集：それを置く別の方法はこれです：彼らが「間違ってプレイしている」とは思わないでください
ルール＃2：彼らが欲しいものを彼らに与えないでください。プレイテストセッションの後、何らかのアンケートを記入します。彼らが持っている具体的な提案は、通常、額面どおりに行うのが賢明ではありません。通常、ほとんどの反応を引き起こす根本的な原因があり、彼らはそれを表現する方法を知らないだけです。あなたがそれを理解できるなら、あなたはそれをするほうが良いでしょう。現時点では、特定の例を思い付くのに苦労しています。
ルール＃3：データが重要です。可能であれば（そして、これは本当に別のウィッシュリスト項目です）、可能な限りすべてを追跡します。プレイヤーが死ぬ場所を追跡します。特定の銃から弾薬がなくなった場所を追跡します。逃したピックアップを追跡します。購入したアップグレードを追跡します。敵が彼らに与えるダメージを追跡します。明らかにこれらはFPS固有の例ですが、実行しているゲームにはドメイン固有のものがあると確信しています。誰もが何かをしている、またはしていない場合、それらは通常、もう少し時間をかけて見なければならない領域です。
基本的に、プレイヤーがどう思うかは気にしません。あなたはプレイヤーが何をするかの生の数字を取得することを気にかけています。あなたのゲームを見て、何が彼らをイライラさせ、何が彼らを誘導しているのかを伝えるには、処女の目が必要です。
クラッシュについては、ミニダンプを調査してください。それらは完璧ではありませんが、クラッシュがどこにあるかを知るための非常に便利なツールです。
組み込みのバグ報告ツールも検討してください。ユーザーがスクリーンショットを撮って説明を追加し、ゲーム内から自動的に誰かにメールで送信できる場所。ゲームがサポートしている場合は、世界のスナップショット（クイックセーブや何らかのメモリダンプなど）が理想的です。
on-site playtesters
データを拡張するために少し感情的です（テトラッドに+1！）：
記録と再生の調査：
(key/button state, joystick/mouse coords, frame #)、入力状態が変化したときのタプルのみを保存する必要があります。再生は、入力をこのストリームにリダイレクトするのと同じくらい簡単です。（過去に多くのプラットフォームジャンプゲームでこれを行ってきました。）これらの方法に基づく「リプレイ」システムには、多くの利点があります。
記録されたストリームではなく、ランダム入力で配線すると、一晩中または開発マシンがアイドル状態のときにいつでも浸けることができる素晴らしい猿のテストがあります。
次に、イベントの記録を行います。架空のFPSの場合、「時間T：XがポイントZでYを武器Wで殺した」などのことから始めます。ログに記録します。
いくつかのデータを収集したら、収集を自動化する方法を見つけます。開発中にエレガントである必要はありません。
データを収集できれば、それほど問題ではありません。
今すぐ拡張：クラッシュダンプ、スタックトレース、入力またはイベントの記録を収集します。イベントとデータソースを追加します。
getFreeMemoryBytes() 30分ごとgetFPS() 定期的に「マップ上にプロットする」ことは、しばらくすると本当に素晴らしいものになります。RTSまたはFPSマップの航空写真を想像してください。ゲームの開始からの時間を表すスライダーをその上に置きます。イベントの種類を選択します（「金を手に入れた」、「誰かを殺した」など）。データセットを選択します。過去1か月で1ゲーム、おそらく500ゲームを選択します。スライダーを右に引いて、アクティビティがマップにポップされるのを確認します。
そして、もしあなたがこのようなことを手助けする良いライブラリを見つけられないなら（しかし、あちこちにたくさんあります！）、あなた自身を転がすことを検討してください：それは良い学習体験であり、特にエレガントである必要はありません有用であるために。
データを取得すると、それをどう処理するかがわかります。=）
もちろん、これは多くのことに依存します... a）どんな種類のテストをしたいのか、b）どんな種類のゲームをテストしているのか、c）どんな種類のテスターとインフラストラクチャが利用できるのか...
また、a）機能、b）バランス、c）ゲームデザインをテストする場合も大きく異なります。
しかし、一般的にあなたはこれらの側面を考慮したいかもしれません...
* a）仕事にふさわしい人を選ぶ 言及するのは簡単すぎるように聞こえますが、何度も見たことがありますが、またライブで見ました。いつものように、異なる仕事でどれだけ優れているかに関して、人々の間には大きな違いがあります。テストを行う意思がある、または熱心な人の中には、異常な（または単純な）バグを見つけるのに十分なほど徹底的に遊んでいない人もいます。バグの説明が苦手な人もいます。バランスの問題のテストに優れているもの、視覚的な弱点に注意を払っているもの、通常とは異なる方法でゲームをプレイして隠れた/まれなバグを見つけているもの、技術的または視覚的な品質に注意を払っているもの、側面の理解に優れているものゲームメカニックの役割であり、意味のある変更を提案できる場合もあります（テスターにそれをさせたい場合は;）。
* b）Issue-Tracker / Bug-Trackerソフトウェア の使用これらのツールは、問題を整理するのに役立つだけでなく、内部で作業するためのフレームを提供したり、受け取ったフィードバックから学習したりすることで、テスターの出力の品質を向上させるのにも役立ちます開発者から彼らの問題について。テスターの出力の品質を改善するのに役立ちます。（リモートテスターでも大いに役立ちます）ゲームスタジオで使用される典型的なソフトウェアは、Mantis、JIRAです（もちろん、他にもたくさんあります。）一般的なリストについてはWikipediaを、SOに関するこの投稿も参照してください。
c）ゲーム内テストツールを追加します。 通常は、ゲームの特定のレベルまたはセクションをテストするためのショートカットです。ゲーム中にテスターに追加情報を表示して、バグレポートに追加できるようにします。これは、レベル内の位置、シーン内のアクティブオブジェクトの数、現在使用中のテクスチャラムまたはパレットの量など、開発者に役立つものです。
d）経験豊富なテスターと新鮮な血を組み合わせる ゲームに非常に経験があり、典型的な問題が何であり、どのように（再）テストするかを学んだテスターがいることは常に良いことです。同時に、特にバランスを取るために、時々新しい「処女」プレイヤーが必要になります。
e） プロセスを調整し、手元のゲーム、現在の優先順位、利用可能なテスターおよびテスト環境に合わせて調整するテストマネージャーを用意します。
f）テストプラン文書を作成する これは追加の投稿に値します。
Tetradが述べたように、できるだけ客観的なデータを取得してください。特定のイベントを保存し、それらをすべて.csvにダンプするためにフックを入れることはそれほど難しくありません。Excelで取得したら、牛が帰宅するまで学習、グラフ化、プロットできます。
また、答えたい具体的な質問があります。科学者はただ座って、実験を行い、「科学をする」だけではありません。彼らには、データが欲しい特定の測定可能な質問があります。同じアプローチを取ると、プレイテストを最大限に活用できます。ゲームが「良い」かどうかを把握しようとすることは、定量化するのが非常に困難です。しかし、単純なチュートリアルミッションが予想どおり5分しかかかっていないかどうか、またはテスターが特定のパズルを解くのに苦労しているかどうかを実際に評価することができます。
テストするための最も効果的な方法は、短いバーストを繰り返し行うことです。午前中に数人のテスターに1時間ほど行ってもらい、特定した問題にいくつかの変更を加えて、翌朝に新しいテスターに再び行きます。明らかに、午後に改善するのに十分小さい機能を見ている必要があります。しかし、特に頑固な問題の場合、この方法は非常に効果的です。
Tetradのルール＃1に完全に同意します。彼らを助けないでください。警告は、あなたが彼らを助けないことを彼らに説明することであり、彼らが助けを必要とするなら尋ねてください。このようにして、プレーヤーはイライラすることはありません。
アンケートでは、単純なyes / noの質問ではなく、自由回答式の質問をする必要があります。年齢とテスターの数に応じて、記入するフォームにするか、質問することができます。また、彼らの歴史と、あなたが彼らにテストさせているゲームのジャンルに精通していることについて質問することも重要です。これにより、ゲームに関する具体的な回答にコンテキストが追加されます。
幸いなことに、ゲームがクラッシュすると、エラーに関する情報がダンプされます。そのため、その写真を撮り、プレーヤーが何をしていたかをメモします。通常、私は若い年齢層をテストしますので、クラッシュしたときは、彼らが素晴らしい仕事をしていることを彼らに説明することを忘れないでください-彼らはゲームを壊した後に動揺することができます。プレイテスターは、開発チームが「正しい」方法でゲームをプレイすることは決してないというあいまいなバグを見つけるのに優れていることを本当に証明しています。
クラッシュレポートについては、プレイテスターではなく、有料のQAスタッフに頼るべきです。QAは、バグを見つけて意味のある方法で報告する能力のためにあなたが特に雇う人であり、優秀なテスターは金の重さの価値があります（そしてプログラマーに比べて金の重さの1/10しかかかりません！）
「ああ、もし彼らが偶然クラッシュを発見したら、それをテストしていないからといって見逃したくない」と心配しているなら...これがロギングの目的です。十分に優れたロギングシステムは、クラッシュを正確に再現するために十分なプレイ要素を記録する必要があります。
デザインフィードバックについては、ゲームデザイナーに実際にプレイを見てもらう（または、必要に応じてビデオレコーダーを使用するなど）こと以外に代わるものはありません。悪名高い悪名高いプレイテスターの記憶や意見に頼らないでください。しかし、彼らがリアルタイムでプレイしているのを見ているなら、彼らが婚約している、退屈している、またはイライラしているかどうか、顔と体の姿勢を見るだけで明白に明らかです。
** Don't help them **