- 01何が違和感を感じるのか説明してください
- 02繰り返しできる基準を確立しましょう
- 03まずプリセットのみを変更します
- 04フレーム制限を個別に評価する
リンクされた情報源と元の分析に基づいています。実物のプレイテストは主張されていません。
英語リサーチ版からローカライズされ、ゲーム内の固有名詞は検索のために保持されています。
検証済みグラフィックスリード
低グラフィックは、He Who Watchesがパフォーマンスが悪い場合の最初の比較として有用です。9月6日の議論で、開発者のDangaは、ボリューメトリックフォグがプレイヤーのGPU負荷がMediumとLowで大きく異なる原因であると指摘しました。別の9月5日の返信で、開発者はLowでボリュメトリックフォグを無効にすると述べています。これらの声明はプリセットのテストをサポートしています。しかし、フォグがすべてのカクつきを引き起こすことや、Lowがすべてのマシンでスムーズなパフォーマンスを保証することを証明しているわけではありません。
ハブパフォーマンスレポートには不規則な動きアニメーションも記載されていました。開発者は予想以上に悪いと考え、問題が発生している間は一時停止メニューからのフィードバックを求めました。これは依然として重要な違いであり、同じレポート内のすべての症状に対する確定診断とは限りません。
以下のワークフローは、その狭い開発者リードを中心に構築されたオリジナルの一般的なトラブルシューティングです。この記事のテストマシンではベンチマークされていません。自分のセットアップでクリーンな比較を行い、結果を保存し、有用な回避策か報告が必要な問題かを判断してください。
何が違和感を感じるのか説明してください
まずは目に見える症状から始めましょう。動きが一貫して遅いのか、画像が間隔で一時停止しているのか、あるいは入力がアニメーションの一部を飛ばしているように見えるのか?問題は静止している時、回転している時、あるいはハブ内を移動しているときに起こるのか?これらの観察は、単なるパフォーマンスが悪いという一言よりも有用です。
すでにフレームレート表示がある場合は、表示した値を記録してください。ただし、説明を一つの数字に置き換えないようにしましょう。ゲームは許容できる平均を示しつつも、目立つ一時停止を生じさせることができます。逆に、低くて安定したレートの方が予測しやすく感じられるかもしれません。サポートの質問は、単に空のシーンで到達した最高値ではなく、あなたの観察体験についてです。
クラッシュとシステムの再起動は別のカテゴリに分けてください。それらは控えめなフレームレート差から異なる応答を求めます。パフォーマンスサンプルを取るためにマシン全体が再起動するシーンを繰り返し実行しないでください。クラッシュ&フィードバックページには、その症状を通常のベンチマークとして扱わずに記録する方法が説明されています。
繰り返しできる基準を確立しましょう
戻れる場所と繰り返せる短い動作（小さな回転や、ハブの見える部分に沿った短い動きなど）を選択してください。部屋の名前、グラフィックプリセット、可能であれば解像度、フレーム制限（使用している場合）、およびマシンが通常の電源設定になっているかどうかを記録してください。部屋の状態を簡単に復元できる程度にテストを短く保ちます。
設定を変更する前に、同じ動作を数回観察してください。移行中の一時的な一回限りの停止は、シーンの安定した挙動を表しているとは限りません。後で比較して意味のある差が分かるくらい明確なパターンを探します。短い観察で問題が確認できる場合に、1回のプレイセッション全体を数字の収集に費やさないでください。
ベースラインはあなた自身のローカルリファレンスであり、普遍的な基準ではありません。他のプレイヤーは、同じプリセットを異なるハードウェアで使用すると、異なる結果が得られる場合があります。自身の比較において前後を公平にするだけの十分な文脈を記録してください。これは他のすべての人への保証として提示するものではありません。
まずプリセットのみを変更します
ゲームのグラフィックオプションで表示されているメニューラベルを使用してLowを選択してください。同じシーンに戻り、同じ短い動作を繰り返します。この最初の比較では、可能な限り他の設定は変更せずに保ちます。目的は、同様の条件でプリセット変更が明確な違いを生むかどうかを確認することです。
元のプレイヤーレポートでは、グラフィック品質とフレーム制限の両方が変更されました。その結果、1つの変数の効果を単独で分離していません。開発者のフォグの説明はプリセットを重要な手がかりとしていますが、制御されたローカルの比較により、いくつかの値をまとめてコピーするよりも、自分の環境に関して多くのことを知ることができます。
Lowが明確に役立つ場合、実用的な設定の選択肢があります。改善を証明するために不良設定を繰り返し復元する必要はありません。どの部分が改善されたか、どの部分が変わらなかったかを記録してください。負荷が減少してもハブでの停止が残る場合は、両方の症状が消失する結果とは異なり、その違いは有用なレポートにとって重要です。
フレーム制限を個別に評価する
ゲームが現在のメニューでフレーム制限を表示している場合、2回目のテストとして低い制限を比較できます。その比較ではグラフィックプリセットを固定してください。これは一般的なグラフィックのトラブルシューティングであり、このタイトルに対する開発者確認済みの解決策ではありません。別のプレイヤーの数値を理想の目標としてコピーするのではなく、表示や好みに合った値を使用してください。
限界が一貫性や応答性、最初に述べた症状に変化をもたらすかどうかを観察してください。目標値が低いとシステムの負荷が変わることがありますが、実際の結果はセットアップやシーンによって異なります。機械で測定せずに特定の温度や負荷の減少を推測しないでください。
もし便宜上フレーム制限とグラフィックプリセットを一緒に変更する場合は、それらを統合テストとして記録してください。それでも、快適な構成が目標であれば有効です。どの変更が改善をもたらしたかは単に教えてくれません。正直なラベル付けは、あなたが行っていない実験を主張することなく、結果の価値を保ちます。
ハブと小さなシーンを比較してみてください
開発者はハブが大きいと指摘しつつ、報告された挙動は予想以上に悪質に聞こえたとも述べています。シーン固有の問題を区別するには、同じ基本的なアクションをハブと、アクセスできる小さな部屋で比較することで判断できます。比較中はグラフィック設定を固定しておきましょう。
問題が確認したすべてのハブに現れるか、あるいは1つの名前のあるチャンバーだけに発生しているかを記録してください。最初に気づいた1つのスペースから一般化しないでください。特定のハブに関するレポートは、1つのエリアだけをテストしたときに「すべての大きなエリアが壊れている」と言うよりも、開発者に調査の焦点を絞る場所を提供します。
問題がハブ内の特定の視点に沿っている場合は、見えるランドマークや方向に注目してください。これでどの効果やオブジェクトが原因かを証明するわけではありませんが、動作の再現を容易にします。短いビューの説明は、レンダリングエンジンに関する根拠のない推測よりも有用であることが多いです。
モーション問題を区別しておきましょう
2つのタイルを同時にカバーしているように見えるアニメーションは、自動的に入力バインディングの問題ではありません。同様に、左右にキャラクターを回転させて横に動かさず、それ自体はフレームレートの問題ではありません。一度の意図的な入力後に最終的な位置と向きを比較してください。これにより、タイミングや入力状態、あるいは両方を調査するかを判断できます。
既知のShift回避策には特定の症状があり、開発者の回答もあります。オーバーレイの後は、回転が横方向の動きに代わる場合はそのページを使いましょう。両方の問題を観察し、別々にテストしている場合を除き、グラフィックの変更と組み合わせて使わないでください。そうしないと、どの変更が効果的だったか判断できなくなるかもしれません。
シーンが一時停止しても最終的な行動が正しい場合は、そう言いましょう。最終的な状態自体が期待していた入力と異なる場合は、そのように言いましょう。開発者はその違いを使って、視覚的な表現の問題と、異なる処理ができたかもしれない行動を区別できます。
推測せずにシステムのコンテキストを記録する
オペレーティングシステム、プロセッサ、グラフィックデバイス、メモリ、そして特定可能な場合は互換レイヤーを通じてプレイしているかどうかを含めてください。ゲーミングノートパソコンのような曖昧な説明ではなく、システムが報告する名前を使いましょう。有用なハードウェアの文脈を提供するために、無関係な個人情報を公開する必要はありません。
部品に確信が持てない場合は、確認できるまで不明マークを付けてください。コンピュータのブランドやマーケティングステッカーからグラフィックモデルを推測しないでください。正確な情報は有用ですが、作り上げた精度はサポートを誤った方向に導くことがあります。
また、比較中に他の要求の高い作業が進行していたかどうかも記録してください。これはすべてのバックグラウンドアプリケーションを責める理由ではありません。単に、2つの局所的な観測が異なる理由を説明するのに役立つだけです。ゲーム設定の違いを理由にしたいなら、テストを大まかに似た条件で行うと良いでしょう。
GPUの使用状況を慎重に解釈してください
高いGPU使用率だけでバグを特定するわけではありません。その意味はワークロード、設定、フレームターゲット、そして観察する症状によって異なります。開発者のコメントは、1つのレポートで2つのプリセットの違いについての合理的な説明であり、すべてのシステムが故障している閾値を示すものではありません。
すでに使用状況を監視している場合は、シーンや設定と一緒に記録し、単独の数値として記録しないでください。ハブの値とメニューの値だけでは、きれいな比較にはなりません。同じことは、異なるプレイ時間や他の作業がバックグラウンドで実行されている場合に取られた測定にも当てはまります。
他のプレイヤーの温度値を自分のハードウェアの安全または不安全な制限としてコピーしないでください。このページはハードウェア診断マニュアルではありません。もしコンピュータ自体がシャットダウンまたは再起動した場合は、セッションをパフォーマンステストとして扱うのをやめ、適切なデバイスサポートと事実に基づくゲームレポートを活用してください。
サポートされていない最適化レシピは避けましょう
ここでの情報源は、特別な起動フラグ、レジストリ編集、設定ファイルの削除、あるいはハブのスタッターを修正するゲーム固有のドライバーオーバーライドを設けていません。こうした変更を長くリストすると、記事を包括的に見せつつ、アドバイスの信頼性を下げてしまいます。まずはドキュメント化されたプリセットリードと通常の可観測比較から始めましょう。
サポートソフトウェアの最新性維持などの一般的な保守はシステムに適している場合もありますが、実証済みのHe Who Watches修正案として宣伝すべきではありません。ドライバーやOSコンポーネントを自分で変更する場合は、ビフォー・アフターの状態を記録し、同じテスト内で他の変数を複数変更しないようにしてください。
他人のマシンからターゲットを追いかけるために、動作するセットアップを犠牲にしないでください。有用な結果は、ハードウェア上で安定して快適にプレイできることです。比較動画で使われたからといって選んだより、安定して動作する控えめなプリセットの方が、より実用的な選択肢になり得ます。
メニューに表示されている数値を使いましょう
9月4日のパッチでは、スライダーの横に表示された数値が追加されました。該当するオプションがスライダーを使用している場合は、その位置を曖昧に記述するのではなく、表示された値を記録してください。これにより設定の比較が繰り返しやすくなり、サポートレポートの解釈も容易になります。
変更によってすべての選択肢の名前や範囲が定められるわけではありません。メニューの現在のラベルを読み、メモに記録してください。他の言語と比較する場合は、翻訳ラベルが英語のガイドと同じだと決めつけるのではなく、スクリーンショットや機能の簡単な説明を含めてください。
好みの設定に合わせて小さな設定記録を残しておきましょう。後で試す際には、複数のスライダーがどこにあったか覚えていなくても、既知のローカルベースラインに戻すことができます。これは特に、快適性に影響を与える設定がパフォーマンスのために変える設定と異なる場合に有効です。
回避策が十分かどうかを判断してください
Lowで問題が解決され、視覚的な結果があなたに合うなら、続けることは現実的な合理的な結果です。明確な説明があれば、元の挙動を報告することは可能です。自分の快適なプレイ目標を達成した後も、トラブルシューティングを続ける必要はありません。
Lowで負荷が改善しても一時停止が改善しない場合は、2つの結果を分けて保管してください。プリセットは別の問題が残っている間に役立つかもしれません。全く動作しなかったと言うよりも、その方が情報的です。推奨比較の下で報告された体験のどの部分が変わったかを開発者に伝えます。
目に見える改善が見られない場合は、新しい質問なしで同じ検査を繰り返すのをやめてください。現場、環境、症状の詳細を集め、フィードバックのルートを用いましょう。条件が明確であれば陰性の結果は有用な証拠となります。ボトルネックに関する自信ある理論に変換する必要はありません。
問題が関係しているうちにフィードバックを送ってください
ハブパフォーマンススレッドでは、開発者が遅延が発生している間に一時停止メニューのフィードバックレポートを特に求めていました。ゲームが十分に使えるなら、そのルートをたどってください。ハブ、アクション、プリセット、そして同じ動作が他の場所でも現れているかどうかを説明してください。Low比較の結果も含めてください。
短いレポートでは、名前のあるハブが単純なターン中に一時停止し、小さな部屋はそうでないこと、プリセットの変更が負荷を減らしたと述べても、その間は変わらないと言えます。これはレポートのパターンであり、あなたのマシンに関する主張ではありません。実際に行った観察だけを使い、未検証の比較は除外してください。
録画を添付する場合は、再現可能な瞬間に焦点を当ててください。入力と予想される動きを説明し、開発者が意図的な間と問題を区別できるようにしましょう。公開投稿する場合は秘密のエリアを適切にマークし、無関係なデスクトップコンテンツを公開しないようにしましょう。
何か重要な変化があったときだけ再確認してください
実行可能なセットアップを選んだら、関連するアップデートやハードウェアの変更、新しい開発者指示で理由が見つかったら再度問題を見直します。毎回同じベンチマークを繰り返しても情報はほとんど得られません。日付のメモがあれば、後の変更をすでに記録した状態と比較することが可能です。
新しいパッチがパフォーマンス修正をするとは、ノートやあなたの観察がそれを証明していない限り、必ずそう考えないでください。9月4日の発表はパズルやメニューの変更をカバーしており、普遍的なスタッター修正ではありません。後の改善は、ビルドや観察した環境に紐づけておきましょう。
有用なサポートループは小さく、症状を記述し、同じシーン内の設定を比較し、結果を保持し、文脈とともに持続的な問題を報告するだけです。これにより、開発者のフォグリードは実行可能になりつつ、確定した設定挙動と未解決のパフォーマンス診断の区別を保ちます。
簡単な比較ログを読んでみてください
ローカルログを想像してください。元のプリセットのハブ、低の同じハブ、そして低の小さな部屋の3つのエントリです。これは推奨されるテスト構造であり、この記事のベンチマークデータではありません。最初のペアはプリセットが症状を変えるかどうかを尋ねます。2番目のペアは、残りの挙動がシーンに依存するかどうかを尋ねます。これらの質問を区別することで、結果の解釈がしやすくなります。
ハブが低より改善され、小さな部屋も滑らかであれば、実用的な構成ができます。設定コンテキストで元の問題を報告できますが、単に詳細な説明を作るためにオプションを何度も変える必要はありません。安定したプレイというローカルな目標はすでに達成されている可能性があります。
ハブが部分的にしか改善せず、小さな部屋が正常に動作する場合は、残りの症状を挙げてください。短く繰り返される一時停止、突然のアニメーション、または他の目に見える効果かもしれません。部分的な改善を「完全に固定」か「無差」にまとめて考えないでください。この区別は、プリセットが何に影響するかを開発者により明確に示します。
両方のシーンが同じ問題を示す場合、比較はハブ固有の問題を特定していません。それは原因がゲーム外にあることを証明するものではありません。単に、あなたがテストした条件下では、シーンのサイズがケースを分ける要因にならなかったということです。結果を含め、結論を捏造するのではなく、関連するサポートの質問に進んでください。
測定値があまりにもばらついて解釈できない場合は、テストを短くし、条件を安定させてください。次の観察では同じ視点、アクション、設定を使用してください。ノイズの多い比較は観察を改善する理由であり、自分が好む理論を支持する数値を選ぶ理由ではありません。
ログは読みやすい程度に小さく保ってください。シーンや設定が付随していない何百もの値よりも、明確に説明された少数の比較のほうが役立つことがあります。開発者は何が変わり、何が変わらなかったのかを知る必要があります。また、将来のあなた自身も、後のアップデートが問題に影響を与えたかどうかを判断する際に同じ情報を必要とします。