機械翻訳を利用しています。ゲーム内のアイテム名は英語表記の場合があります。
バージョン、最短の再現手順、分かりやすい画像を添え、不具合とバランスへの意見を区別した簡潔な報告を作りましょう。
一つの問題から始める
有用なバグレポートは、他の人が試せるように単一の失敗を明確に説明しましょう。アクションと結果を最初に示しましょう。例えば、特定のメニューを開くとカーソルが見えなかったり、セッションの読み込みでキャラクターが床の下に隠れたりします。ゲーム全体について何段落も説明して始めないようにしましょう。読む人は何を再現すべきかを知っておく必要があります。
技術的な失敗と好みを分けましょう。何もしないボタン、進行しない目標、要求が高すぎるサバイバルメーターは異なる種類のフィードバックです。どれも報告する価値はありますが、証拠は異なります。バランスに関する苦情は、あなたが望む体験を説明するべきです。バグ報告は、期待される挙動と代わりに何が起こったのかを説明すべきです。
問題が起きた段階に合う報告先を選ぶ
ゲームクエスト、ランチャー購入問題、グラフィックスドライバーのインストール失敗には異なるサポートチームが必要です。目的地を選ぶ前に、失敗しているレイヤーを説明してください。ゲームは起動しても目標が進行しない場合は、まず開発者の報告チャネルから始めてください。ストアフロントがダウンロードを完了できない場合は、プラットフォームのサポートから始めましょう。
グラフィックスドライバーの問題が疑われた場合、ハードウェアベンダーは別の報告書を必要とする場合があります。AMDはシステム詳細を収集し、再現手順や添付ファイルを受け入れるバグレポートツールを提供しています。このツールは情報をAMDに送信します。クエストや保存セッションの問題についてゲーム開発者に伝える代わりにはなりません。証拠やサポートガイダンスがグラフィックス層やシステム層を示している場合に利用してください。
文脈なしに同じ大きな報告書をあちこちに投稿するのは避けましょう。2つのサポートチームが関与している場合は、理由を説明し、それぞれのケース識別子を個別に保存してください。簡潔なクロスリファレンスは重複作業を防ぎ、すべてのメールや添付ファイルを公開することで、技術的な境界を理解する助けにならない情報が漏れてしまう可能性があります。
後から見つけやすい件名を付ける
良いタイトルは、目に見える症状とトリガーを組み合わせたものです。例えば、フライトアクセサリーを接続した後にメニューカーソルが消えると、ゲームを直すよりも認識しやすいです。ビルドは確認した場合にのみ含めてください。未検証の理論を確立された事実のようにタイトルに入れないでください。
クエスト報告の場合は、目に見える目標名またはオブジェクト名を使い、失敗を明記してください。報告チャンネルがネタバレフラグやより中立的な説明を許可している場合は、タイトルにネタバレを避けてください。問題を調査する人のために、必要な進行の詳細を本文に記載できます。
投稿前にキーワードを検索してください。同じトリガーに一致する既存の報告があれば、その構成と結果を比較してください。必要に応じて証拠を追加し、ほぼ同じスレッドを作るのではなく、そこに証拠を追加してください。もしあなたの再現が大きく異なる場合は、その違いを説明してください。似た症状が原因によって異なる場合があるため、無関係な報告を自動的に統合したり、すべての新しい観察に全く別の会話を要求したりしないでください。
期待した結果と実際の結果を並べて書く
期待される結果は、単に望むことではなく、インターフェース指示、通常の事前行動、または明確なゲームルールから得られるべきです。行動が意図されているかどうか確信が持てない場合は、報告を質問として構成し、曖昧さを説明してください。これにより、観察の有用性を損なうことなく明確化の余地が残ります。
実際の結果は画面に表示される内容や、残る入力を記述すべきです。この操作がミッションを完全に壊すよりも、目的的なテキストは変わらないままです。もしまだ移動できるなら、メニューを開くか、別のセッションをロードできるなら、その情報を含めてください。これにより、進行ブロッカーとアプリケーションフリーズを区別できます。
報告書内でペアを近接に保つこと。読者は複数の歴史段落から期待される行動を再構築する必要はない。複製手順を踏み、その後に任意の文脈を説明すればよい。この順序は報告書のスキャンを容易にし、調査者が不確かな詳細を考慮する前に中心的な主張を検証できるようにする。
再現手順と探索の日記を区別する
ルートダイアリーはあなたが行ったすべてのことを記録します。複製には問題を引き起こすために必要な最小のシーケンスが含まれています。もしそれしか持っていなければ、まず日記から始め、確実に必要なステップ、関連性がある、あるいは単に以前に行われたことを特定しましょう。不確かな文脈は消さないでください。別のメモに移してください。
テストが安全であれば、1つの前提条件を変更してください。例えば、オプションのアクセサリーを接続する前後のやり取りを比較したり、影響を受けたセッションと既存のセッションを比較したりします。新しいキャンペーンを始めたり、よりクリーンなレポートを作るためだけに貴重な進行状況を犠牲にしないでください。何時間も操作を繰り返しプレイするよりも、保存状態の方が良い出発点となり得ます。
複製が特定のセッションに依存している場合は明確にしてください。調査者は長い書面ルートよりもそのセッションを必要とする場合があります。保存し、読み込み直後の手順を説明し、要求があれば個別に提供してください。これにより、基礎となるトリガーが目に見える故障よりはるかに早く発生しても、報告書は実用的です。
確実性を誇張せず発生頻度を伝える
カウントや記述できる観察値を使いましょう。連続した2回の負荷で発生した問題は、常に問題が起きているよりも明確です。問題は長いセッションの後に起きたもので、ランダムにクラッシュするよりもはっきりとわかりました。有用なレポートを提出するのに大量のサンプルは必要ありませんが、実際に観察したことを述べる必要があります。
後の試みがうまくいった場合は、その結果を追加してください。断続的な挙動は、特にセッションや場所、接続されたデバイスによって異なる場合は貴重な情報です。成功した試みを隠すと元の問題の信頼性が低くなるのではと心配してはいけません。目的は条件を特定することであって、ゲームの良さについての議論に勝つことではありません。
他のプレイヤーが異なる結果を報告した場合は、矛盾として扱わずに文脈を比較してください。彼らは異なるビルド、ルート、入力設定、セーブステートを持っているかもしれません。関連する詳細を求め、自分の報告は具体的にしてください。2つの記録されたセットアップ間の意見の相違は有用な手がかりとなります。普遍的な主張の交換はほとんど得られません。
目的を決めて画像や映像を用意する
Steamはスクリーンショット機能とその機能のオーバーレイ要件をドキュメント化しています。設定済みのキャプチャ方法が動作すれば、関連するエラーやインターフェースを表示するために使ってください。キャプチャ失敗は別の問題です。症状を説明したり、パソコンで利用可能な他の通常のキャプチャ方法を使うこともできます。
録画前に、視聴者が見るべきものを決めます:開始状態、入力シーケンス、そして結果です。これらの要素を含む短いクリップの方が、数分間の無関係なプレイよりも確認しやすいです。エラーがすぐに消える場合、録画は繰り返しのリスクを避けて正確な表現を保持するのに役立ちます。
共有する前にファイルを確認してください。テキストが読めるか、報告された問題の証拠が実際に示されているかを確認してください。後でサポートが文脈を必要とする場合は、元の内容を保持しつつ、無関係なプライベートデスクトップコンテンツは共有コピーから削除してください。行動の順序を曖昧にしたり、別々の試みが連続的に見せかけたりする編集は避けてください。明確な証拠は不確実性を減らすべきであり、より説得力はあるものの誤解を招く話を作るべきではありません。
添付資料や診断情報は必要なものに絞る
データが多いからといって自動的に良いわけではありません。まずは問題に合致する情報から始めましょう:入力用のデバイス詳細、解決用の表示モード、進行用の目的とセッション。サポートからログや診断エクスポートを求められた場合は、要求された資料を提供し、イベント時間にラベルを付けてください。ショートカットとしてユーザーフォルダ全体をアップロードするのは避けましょう。
AMDのレポートツールは、提出された情報のローカルコピーとドライバー履歴フィールドを提供しています。これらの機能は、そのツールの外でも有用な習慣を示しています。つまり、自分のレポートを保持し、問題がソフトウェア変更後に発生したかどうかを記録することです。この記事は、すべてのクラッシュにAMDレポートが必要だと主張したり、ツールが非AMDハードウェアを診断できるとは主張していません。
プライベートな添付ファイルについては、受信チャネルとアクセス権限を確認してください。意図したサポート受取人にのみ共有し、ファイルに個人情報が含まれている可能性のある公開リンクは避けてください。元の証拠は変更せず、コピーを送ってください。サポートチームから異なる形式を要求された場合は、診断要件と他で見かける任意の回避策を区別できるように、そのリクエストを記録してください。
不満の繰り返しではなく確認結果を追加する
サポートがテストを提案した場合は、開始バージョン、取ったステップ、結果を報告してください。症状が変わった場合は、どのように変化したかを説明してください。メニューに到達しても読み込みに失敗した場合は、ウィンドウが開く前に失敗した場合とは異なる結果です。これらの区別により、調査者は次の質問が同じ失敗経路に属するかどうかを判断できます。
アップデートで問題が解決した場合は、どのアップデートでどのように確認したかを伝えてください。もしそのままであれば、履歴全体を書き換えるのではなく、新しいバージョンでも同じ最小限の再現を提供してください。変更内容を比較できるように、以前の証拠を常に保存してください。
影響を受けたセッションが終了した場合や問題を繰り返せない場合は、その制限を明記してください。報告書を有効に保つためにクリーンな複製を作成しないでください。正直な締めの注釈は、将来の読者がどれだけ検証されたか理解するのに役立ちます。また、調査が元の出来事の決定的な説明なしに終了しても、既に提供した有用な情報への信頼を保つことができます。
確実に再現する最短の手順を記録する
開始条件を書き、次に行動を順番に書きます。失敗に関係するステップのみを含めてください。もし以前の出来事が重要かどうか分からない場合は、プレイセッションの詳細な説明に再現を埋もめるのではなく、短いコンテキストノートにまとめて記載してください。
重要な進行に影響しない場合にのみシーケンスを再試してください。同じ状態から2回発生した場合は、そう伝えてください。1回発生して再現できない場合は、そのように伝えてください。正直な一度きりの報告は、すべてのプレイヤーが同じ問題に遭遇すると自信を持って主張するよりも有用です。
ビルド、ストアフロント、関連デバイス情報を含めてください。入力の問題の場合は、コントローラーや付属アクセサリーの名前を付けてください。表示の問題の場合は、選択した解像度とゲームが実際に表示する内容を記録します。クエストの問題の場合は、目に見える目的と、それを進めなかったインタラクションを明記してください。
該当する開発者の告知がないか確認する
重複報告を提出する前に、最近の公式発表をよく読んでください。既知の修正方法は、インストールが遅れている場合や既知の問題がすでに要求された診断形式を持っている場合に時間を節約できます。もし問題が該当するアップデート後も残る場合は、それを明確に伝え、再検査の内容を説明してください。
9月4日の注記では、ワールドを落下したセーブデータを info@breathedge.com に案内してください。影響を受けたセッションを保存し、要望があれば個別に提供してください。その他の症状については、公式ディスカッションハブで適切な現在の指示を確認してください。報告された問題の連絡先が他のすべてのサポートルートに代わるわけではありません。
確認したい点に答える資料を添付する
スクリーンショットは、関連するインターフェースやエラーを明確に示す必要があります。短い録画はトリガーアクションを早めに開始し、結果が見えたら終了すべきです。どちらもデスクトップ全体、アカウントページ、または無関係な会話は必要ありません。投稿する前に添付ファイルを必ず確認してください。
トリミング画像を作成する際は元のファイルを保持してください。後でサポートがさらなる文脈を必要とした場合は、問題を再現しなくても提供できます。ログやアーカイブについては、内容を確認し、要求されたものだけを共有してください。公開レポートにはパスワード、認証ファイル、無関係な個人フォルダを含めてはいけません。
エラーを説明するときは、その正確なテキストを保持してください。理論を説明するときは、それを理論としてラベル付けしてください。コントローラー接続後に問題が始まったと言うのは観察です。コントローラードライバーが確実にセーブデータを破損させたと言うのは、もっと強力な証拠が必要な因果的な主張です。
回答を受けた後の結果も伝える
要求されたステップがうまくいった場合は、結果と使用されたバージョンを報告します。うまくいかない場合は、何が変わらず何が変わらなかったかを伝えます。これにより、開発者は部分的な改善と効果なしを区別でき、他の読者が失敗した経路を繰り返すのを避けられます。
可能な限りフォローアップコメントは同じ議論の中で行ってください。試みごとに新しいスレッドを始めることで証拠が分かれ、歴史の理解が難しくなります。作業中の更新や残存する再現を特定する短い最後のメモは、同じ症状を探す次のプレイヤーにとって価値があります。
報告書のタイトル、日付、検査済みの最終的な構成を自分のノートに保管してください。もし同じ症状が数ヶ月後に再発した場合、その記録があれば、曖昧な記憶から始めるのではなく、既知の既往歴のある再発の可能性として記述できます。以前の議論をリンクし、新たに観察されたことを説明してください。
報告書に誤ったゲームバージョンが使われていたことがわかった場合は、明確に訂正してください。古い主張を無条件にしておくと、後でそのバージョンで既知の問題を探すプレイヤーを誤らせる可能性があります。
出典と確認情報
この記事は、引用された事実と実践的な編集アドバイスを組み合わせたものです。古いルートを適用する前に、バージョンと不確実性の注意事項を確認してください。
