- 01まず、どのような失敗かを区別しましょう
- 02最後の通常動作を記録します
- 03有用な文脈を保持する
- 04ゲームが始まるとフィードバックを送信 (Give Feedback)を使ってください
リンクされた情報源と元の分析に基づいています。実物のプレイテストは主張されていません。
英語リサーチ版からローカライズされ、ゲーム内の固有名詞は検索のために保持されています。
開発者が実際に推奨していること
9月5日のSteamスレッドでは、ゲームのクラッシュとその後のシステム全体再起動が報告されています。パブリッシャーは、ログを送信できるようにゲーム内のフィードバックを送信 (Give Feedback)を使い、フォローアップ用の連絡先を記載するよう求めました。開発元のDangaは、ボリューメトリックフォグを無効化するLow Graphicsを問題軽減の方法として提案しました。返信では、熱や電力の制限が関与する過去のケースが挙げられており、すべてのプレイヤーに対する確定診断ではありませんでした。
これらの文は適切な範囲で使ってください。低はゲームがメニューに到達できるほど安定している場合に試すための文書化された設定です。フィードバックを送信 (Give Feedback)は議論で挙げられているサポートされた報告ルートです。どちらの文も、すべてのクラッシュが同じ原因であること、ハードウェアの故障、特定の修理で問題が解決することを証明するものではありません。
このページは、故障の説明と有用な文脈の収集のためのオリジナルワークフローを提供します。クラッシュを再現したとか、あなたのログを調査したとは主張しません。目的は、起こったことを保存し、適切なチェックを少数行い、内部原因を推測する必要なしに調査可能な報告書をサポートに提供することです。
まず、どのような失敗かを区別しましょう
ゲームがデスクトップに閉じるのと、フリーズした画像、OSのエラー、コンピュータの再起動とは異なります。どのイベントが発生したかを記録してください。エラーメッセージが表示されたら、その正確な文言をコピーするか、可能な限りキャプチャしてください。メッセージがなければ、同様のオンラインレポートから作るのではなく、そのメッセージを伝えましょう。
また、音声が続行しているか、ゲームが入力に応答し続けているか、オペレーティングシステムが使えるかどうかも注意してください。これらは診断ではなく観察です。これらはゲームプロセスの終了と、より広範なシステム中断を区別するのに役立ちます。「すべてクラッシュした」といった大まかな説明は、これらの重要な区別を解決しないまま残します。
もしコンピューター全体が繰り返し再起動または電源オフになる場合は、ゲームテストとして繰り返しこの状態を引き起こすのをやめてください。既に持っている情報を保持し、適切なシステムやデバイスのサポートを求め、ゲームの状況を報告してください。再起動は普通のフレームレートの問題ではなく、本記事はハードウェア評価の代わりに使うべきではありません。
最後の通常動作を記録します
失敗直前に何をしていたかを書き出してください。部屋名や部屋名、読み込み、メニューを開く、移動、特定のパズル操作を行ったかどうか、そしてセッションが大まかにどのくらい続いていたかを含めてください。おおよその時間は、明確に「おおよその」とラベル付けすると役立ちます。
最後の行動を原因に早まって変えないようにしましょう。部屋に入った後のクラッシュは、部屋が原因であることを証明しません。それでも、そのタイミングは開発者に出発点を提供します。最も強力な報告書は一連の流れを明確に説明し、証拠なしにエンジンの欠陥やメモリリークを挙げるのではなく、調査の余地を残します。
失敗が複数回起きている場合は、その出来事を比較してください。同じシーンだったのか、似た期間の出来事だったのか、それとも異なる活動中だったのか?実際に観察した出来事の数を述べてください。完全に比較していない条件下で二度起きた場合は必ず書かないでください。
有用な文脈を保持する
ストアフロント、デモやフルゲームエントリー、オペレーティングシステム、グラフィックデバイス、プロセッサ、メモリ、そしてクライアントが公開するローカルビルド情報を記録します。これらの詳細は、開発者がレポートを環境に合わせるのに役立ちます。フィールドが不明な場合は、コンピュータのブランドから推測するのではなく、確認できるまではそのままにしておきましょう。
グラフィックプリセットと変更した関連する設定値を含めてください。実験後に作成されたレポートには、故障時にどの構成がアクティブだったかが記載されるべきです。そうでなければ、サポート側は現在の設定を元のイベントを生じた設定と解釈することがありますが、実際には違います。
複数回チェックする場合は短いタイムラインを保ちましょう。最初の失敗はあるプリセットで発生し、その後ゲームを更新し、その後の試みで異なる挙動が起きたと言えます。順序は重要で、どの変更がどの観測に先立ったかを示します。試したすべての設定のリストは同じ情報を提供しません。
ゲームが始まるとフィードバックを送信 (Give Feedback)を使ってください
ゲームとフィードバックオプションに到達できるなら、パブリッシャーが指定したルートを使いましょう。失敗の種類、最後の通常のアクション、環境を説明してください。パブリッシャーはフィードバックルートが役立つログを送ると言っています。ログだけであなたの意図や問題に気づいた正確な瞬間を説明できると考えないでください。
サポートの返信で求められたフォローアップを希望する場合は連絡先住所を添付してください。報告は問題に焦点を当て、無関係な個人情報の追加は避けてください。有用な連絡先情報があれば、開発者が特定の追加観察を求める際に、公開する必要がなくなります。
問題がクラッシュではなく繰り返しの一時停止であれば、別のパフォーマンススレッドで遅延中のフィードバックを求めます。すでにゲームが終了しているクラッシュについては、再起動時にそのタイミングを説明してください。フィードバックインターフェースや開発者が確認しない限り、特定の過去のログが添付されたと主張しないでください。
ゲームがメニューにアクセスできない場合
ゲーム内の報告ルートが利用できないことを説明します。ウィンドウが表示される前、ロード中、タイトル画面に到達した後にゲームが失敗したかどうかを明記してください。これらのステージは、単一のフレーズが起動しないよりも有用です。
まず簡潔な報告書と確認可能な情報から始めてください。インストールからのすべてのファイルを添付したり、無関係なシステムデータの大量アーカイブを送ってはいけません。必要なファイルやパスが文書化されていない場合は、特定の追加資料のリクエストを待ちましょう。調査された情報源は、ここにコピーするための最新の小売ログやセーブパスを確立していません。
ストアフロントにエラーが表示された場合は、そのメッセージをゲームエラーとは別に保持してください。ダウンロード不足やクライアントの問題がゲームプロセスが実行される前に発生することがあります。失敗が現れるレイヤーの名前を付けることで、ストアフロントのインストール問題をパズルエンジンのクラッシュのように扱うのを避けられます。
利用可能なゲームアップデートをチェックしてください
ストアフロントの通常のアップデート方式を使い、保留中のダウンロードやインストール作業が終わるまで待ってから動作を比較してください。これは一般的なサポート慣行であり、特定のHe Who Watchesアップデートがクラッシュを解決する証拠ではありません。アップデートが利用可能だったかどうか、そしてその後症状が変わったかどうかを記録してください。
最新の発表がすべてのローカルビルド変更を説明していると仮定せず、日付からバージョン番号を作ってはいけません。クライアントが識別子を公開したら、それを使いましょう。それ以外は、実際に見える更新日とストアフロントを提供してください。サポートが対応できないラベルよりも、正確で不完全な情報の方が望ましいです。
パズルやメニューのテキストを変更するアップデートは、開発者がそう指示するか、あなたのマシンでのより狭い結果を裏付ける詳細な観察がない限り、クラッシュホットフィックスとして宣伝すべきではありません。インストールの新しさの問題は、問題が解決されたかどうかとは別に考えてください。
コントロールされた比較として、ローを試してみてください
開発者の「低グラフィック」の提案は、ゲームが十分に安定して使えるかどうかの小さなテストとして妥当です。前のプリセットを確認し、低画面を選択し、通常のプレイや短い比較可能なシーンに戻ります。元の症状が再発したかどうかを記録してください。プリセットを比較するためだけにシステムを繰り返し再起動しないでください。
Lowが役立つ場合は、観察条件下での局所的な回避策として結果を説明してください。霧、負荷、熱、その他の要因が原因かどうかを推測する必要はありません。開発者は、あなたが推測的なハードウェア診断を提供せずに挙動の変化を利用できます。
ローが役に立たなければ、それも有用な情報です。失敗の種類とタイミングを報告書に含めてください。陰性テストは開発者の提案が不合理だったという意味ではありません。それはあなたのケースにさらなる証拠が必要だということです。最初の焦点を絞った比較が失敗した後、無関係な設定を何度も切り替えるのは避けましょう。
症状が合うSteamファイルを確認してください
ValveはSteamライブラリのゲーム内のプロパティおよびインストールファイルエリアでファイル検証チェックをドキュメント化しています。これはインストール済みファイルの欠落や破損に適している場合があります。これはSteam一般的なトラブルシューティングであり、このゲームの報告された再起動問題に対する実証的な解決策ではありません。インストールコンテンツを手動で削除するのではなく、クライアントインターフェースを使いましょう。
検証が終わるのを待って、クライアントの報告内容を記録してください。ファイルが再取得された場合は、それが失敗の原因であることを証明する前提にせず、その事実を記録してください。そして通常の起動時に元の症状を比較します。何も変わらなければ、検証を無期限にやり直すのではなく、その結果をサポートノートに記載してください。
インストールの検証とパズルの進行状況を混同しないでください。部屋の解決策を確立したり、古いウォークスルーが新しいレイアウトと一致することを証明したりするものではありません。チェックはファイルが欠落したり起動失敗したりといった技術的な症状に結びつけ、明確な目的がある場合に限定してください。
破壊的な推測は避けましょう
利用可能な開発者の返信は、プレイヤーにセーブデータを削除したり、設定フォルダを削除したり、レジストリを編集したり、未公開の起動コマンドを使うよう指示していません。それらの行動を不確実なクラッシュに対するデフォルトの対応にしないでください。それらは有用な状態を消去したり、最初の問題を説明せずに第二の問題を生み出したりする可能性があります。
同様に、検索結果が普遍的な解決策を約束しているからといって、システム保護を無効にしたり、サードパーティのフィクサーをダウンロードしたりしないでください。観察された故障に関連するゲーム、ストアフロント、デバイスのサポートチャネルを利用しましょう。症状と明確な関連のない劇的な手順よりも、狭い検証済みの指示の方が有用です。
サポートが後で特定のファイルや変更を要求した場合は、指示の記録を保持し、適切な場合は関連データを保存してください。すべての変更を避けることが目的ではありません。理由を明示して変更を行い、それが役立ったかどうかを見極めるための十分な文脈を保持することです。
小さくても意味のある例を捉えましょう
障害が危険または混乱を引き起こすシステムイベントを引き起こすことなく観察できる場合は、短い録画やスクリーンショットで報告内容を明確にできます。エラーメッセージや問題直前のアクションを表示してください。視聴者が気づくべきことを説明してください。注釈のない長いセッションは、関連する瞬間を隠してしまうことがあります。
プライベートなデスクトップコンテンツはキャプチャから外し、公開時は終盤の素材にマークしてください。技術的な挙動を見せても、秘密ルート全体を明かさずに済むことが多いです。シーン自体がネタバレの場合は、タイトルに答えを置くのではなく、画像や動画の前に明記してください。
実際に絞り込んでいない限り、再現が最小限だと主張しないでください。複数のアクションの後にクラッシュを観察し、どれが重要か分からないと言っても問題ありません。その正直さが、サポートが単一の目に見える入力が完全なトリガーだと決めつけるのを防ぎます。
期待される行動と実際の行動を別々に書きます
期待される挙動は、あなたが予想していたことを指します。つまり、部屋が読み込まれるべき、メニューが閉じるべき、または通常の手の後にゲームが開いたままであるべきだということです。実際の挙動は目に見える失敗を表します。それらを分けておくことで、開発者がパズルの状態のあなたの解釈を共有しなくても報告が理解しやすくなります。
ガイドからの期待がある場合は、リンクと日付を含めてください。古い部屋のレイアウトとの不一致は、クラッシュではなくバージョンの問題かもしれません。基本的なアプリケーション動作であれば、はっきりと伝えましょう。裏付けられない専門用語で単純なレポートを飾る必要はありません。
試したことと各ステップの結果を加えます。ゲームを更新してもロード時に閉じるのは有用です。すべて試したことは有効ではありません。実際のチェックを簡潔にリストすることで、どの明らかな比較がすでに完了し、どれが未検証のままかを示すことで時間を節約できます。
新たな証拠のフォローアップ
開発者が特定のテストやログを求めた場合は、そのリクエストに直接応答してください。新しい情報が同じ問題に紐づくように、元のレポート参照を保持してください。複数の無関係なスレッドを立てると、コンテキストが分断され、動作が時間とともにどのように変化したかが見えにくくなります。
変更後に問題が解消した場合は、何が変わったのか、どのくらいの期間、どの条件下でテストしたのかを報告してください。一度の成功したローンチ後にユニバーサル修正を宣言するのは避けてください。もしあなたが観察した通り、ゲームがLowで複数の通常セッションを完了したという狭い説明は、有用かつ正直です。
もし戻ってきたら、同じ問題の説明に新しい条件を加えて更新してください。再発は以前の改善を消すものではなく、その制限に関する情報を追加します。この区別は、変化が頻度を減少させたのか、特定のシーンにのみ影響したのか、あるいは無関係なのかを特定するのに役立ちます。
検査をやめるタイミングを決める
明確な失敗の説明、基本的な環境情報、いくつかの適切なチェックの結果が揃ったら、レポートを送信してください。サポートを求める前に自分でゲームを診断する必要はありません。追加のテストは、特定の質問に答えるか、関連する指示に従っている場合にのみ価値があります。
マシン自体が不安定なら、その大きな問題を優先し、繰り返し起動するゲーム起動は避けてください。ゲーム自体が終了してもシステムが使える場合は、報告を保存し、次の段階を狙った対応を待ち、インストールを繰り返し交換するのではなく、対応は実際に起きている故障に合ったものであるべきです。
良い報告書とは、何が起こったのか、どこで、どのセットアップで、記録されたステップを試したときに何が変わったのかという小さな証拠です。それだけで建設的な調査を始めるのに十分であり、推測や無関係な調整、不要なファイル変更は避けられます。
曖昧な報告を実行可能なものに変える
ゲームがクラッシュすると報告しても、いくつかの重要な疑問が残ることがあります。技術的な推測なしに、故障の種類、プレイ段階、おおよその頻度、そして最後の通常動作を追加することで改善できます。例えば、ロード中のデスクトップへの復帰と、長時間のセッション後のシステム全体の再起動を区別してください。これらは報告パターンであり、あなたのマシンで発生したと主張される出来事ではありません。
次に、環境と実際に完了した小さなチェックセットを追加します。フルゲームかデモ版を使ったか、どのストアフロントが提供したか、どのグラフィックプリセットが有効だったかを明記してください。低検証やSteam検証を試した場合は、それぞれの結果を別々に報告してください。一度だけチェックしただけですべての修正が失敗したとは書かないでください。
既知のシーケンスの下で動作が再現可能か、単に時間経過で繰り返し起こるだけかを説明してください。再現可能な失敗はサポートに試みるべきシーケンスを与えます。繰り返し失敗は依然として重要ですが、そのトリガーは不確実です。違いをラベル付けすることで、開発者は再現、ログ、セッションに関する追加情報を求めるかどうかを判断できます。
エラーメッセージがある場合、その内容を正確に保持し、原因に言い換えないでください。見慣れないコードは、グラフィックの問題だという自信のある要約よりもサポートにとって有用な場合があります。メッセージを取得できなかった場合は、その旨を伝え、欠落している詳細を作らずに覚えていることを説明してください。
現在の状態で終わらせてください。今ゲームを起動できますか？ 記録した設定比較後も問題は残っていますか？ ゲーム内のフィードバックルートは利用可能ですか？ これらの回答により、サポートが実際にどのような次の手順を行えるかがわかります。メニューから送信するよう依頼しても、報告でメニューが表示されないことをすでに説明している場合は役に立ちません。
元の報告と後続の追記をつなげておいてください。新しい観察があった場合、過去を原因がわかっていたかのように書き直すのではなく、日付と条件とともに追加してください。それにより、調査の有用な順序（症状、確認、結果、次の疑問）が保持されます。また、後で成功した変更を評価するのも容易になります。
改善された報告は長くある必要はありません。時には隠れていた事実を明らかにすることが重要です。明確な範囲といくつかの観察された詳細は、推測のエンジン説明の一頁よりも多くの時間を節約し、開発者が次の証拠を要求するための確かな基盤を提供します。