- 01먼저 실패 유형을 구분하십시오.
- 02마지막 정상 작업을 기록하십시오
- 03유용한 상황 맥락을 보존하세요.
- 04게임이 열릴 때 의견 보내기 (Give Feedback)를 사용하세요.
링크된 출처와 원본 분석을 기반으로 합니다. 직접 플레이테스트가 이루어진 것은 주장되지 않습니다.
영어 연구 판에서 현지화되었으며; 게임 내 고유명사는 검색을 위해 유지됩니다.
개발자가 실제로 권장한 사항
9월 5일 Steam 스레드에서는 게임 충돌 후 전체 시스템 재시작이 보고되었습니다. 퍼블리셔는 플레이어에게 게임에서 의견 보내기 (Give Feedback)를 사용하여 로그를 전송하도록 요청하고, 후속 연락을 위한 주소를 포함하도록 했습니다. 개발자 Danga는 볼류메트릭 안개를 비활성화하는 로우 그래픽스를 문제 완화를 위한 가능한 방법으로 제안했습니다. 답장에서는 이전에 발생한 열 또는 전원 제한 가능성이 관련된 사례를 언급했지만, 모든 플레이어에게 확인된 진단은 아니었습니다.
이 진술들을 올바른 범위에서 사용하십시오. 로우는 게임이 메뉴까지 안정적으로 실행될 경우 시도해볼 수 있는 문서화된 설정입니다. 의견 보내기 (Give Feedback)는 논의에서 명시된 지원되는 보고 경로입니다. 어느 진술도 모든 충돌이 한 가지 원인을 공유한다는 것, 하드웨어가 문제라는 것, 특정 수리가 문제를 해결할 것이라는 것을 증명하지 않습니다.
이 페이지는 실패를 설명하고 유용한 맥락을 수집하기 위한 원본 워크플로우를 제공합니다. 충돌을 재현했거나 로그를 검토했다고 주장하지 않습니다. 목적은 발생한 상황을 보존하고, 적절한 소수의 점검을 수행하며, 지원팀이 내부 원인을 추측하지 않고 조사할 수 있는 보고서를 제공하는 것입니다.
먼저 실패 유형을 구분하십시오.
게임이 바탕화면으로 종료되는 것과 화면이 멈춘 이미지, 운영 체제 오류, 컴퓨터 재시작은 다릅니다. 어떤 이벤트가 발생했는지 기록하십시오. 오류 메시지가 나타났다면 정확히 문구를 복사하거나 가능한 경우 캡처하십시오. 메시지가 없었다면, 유사한 온라인 보고에서 임의로 만들지 말고 그것을 명시하십시오.
또한 오디오가 계속되었는지, 게임이 여전히 입력에 반응했는지, 운영 체제를 계속 사용할 수 있었는지도 기록하십시오. 이는 진단이 아니라 관찰입니다. 이러한 정보는 게임 프로세스 종료와 더 넓은 시스템 중단을 구분하는 데 도움이 됩니다. '모든 것이 충돌했다'와 같은 광범위한 설명은 이러한 중요한 구분을 해결하지 못합니다.
컴퓨터 전체가 반복적으로 재시작되거나 전원이 꺼진다면, 게임 테스트로 반복적으로 조건을 유발하지 마십시오. 이미 수집한 정보를 보존하고 적절한 시스템 또는 장치 지원을 받으며 게임 상황을 보고하십시오. 재시작은 일반적인 프레임 속도 문제가 아니며, 이 글은 하드웨어 평가를 대신할 수 없습니다.
마지막 정상 작업을 기록하십시오
실패 직전에 무엇을 하고 있었는지 작성하세요. 방 또는 공간 이름, 로딩, 메뉴 열기, 이동, 특정 퍼즐 상호작용 수행 여부, 그리고 세션이 얼마나 실행되었는지 대략적으로 포함하세요. 대략적인 시간은 명확하게 대략임을 표시하면 유용합니다.
마지막 행동을 원인으로 성급하게 단정하지 마세요. 방에 들어간 직후 충돌이 발생했다고 해서 그 방이 원인이라는 증거가 되지는 않습니다. 그러나 그 타이밍은 개발자가 조사 시작점을 찾는 데 도움이 됩니다. 가장 강력한 보고서는 순서를 명확히 작성하고, 엔진 결함이나 메모리 누수와 같은 증거 없는 판단을 하지 않고 조사 여지를 남깁니다.
실패가 여러 번 발생했다면 사건을 비교하세요. 같은 장면에서 발생했는지, 비슷한 시간 후인지, 다른 활동 중인지 확인하세요. 실제로 관찰한 횟수를 명시하세요. 완전히 비교하지 않은 조건에서 두 번 발생했다고 해서 항상 발생했다고 쓰지 마세요.
유용한 상황 맥락을 보존하세요.
스토어프론트, 데모 혹은 전체 게임 진입, 운영 체제, 그래픽 장치, 프로세서, 메모리, 클라이언트가 제공하는 로컬 빌드 정보를 기록하세요. 이러한 세부 사항은 개발자가 환경과 보고서를 일치시키는 데 도움이 됩니다. 알 수 없는 항목은 컴퓨터 브랜드만 보고 추측하지 말고 확인할 수 있을 때까지 '알 수 없음'으로 남겨두세요.
그래픽 프리셋과 변경한 관련 설정 값도 포함하세요. 실험 후 작성한 보고서는 실패 시 활성화된 구성 설정을 명시해야 합니다. 그렇지 않으면 지원팀이 현재 설정을 원래 이벤트를 발생시킨 설정으로 오해할 수 있습니다.
여러 체크를 한 경우 짧은 타임라인을 작성하세요. 처음 실패가 어느 프리셋에서 발생했는지, 게임을 업데이트한 후 다음 시도가 어떻게 달라졌는지를 기록할 수 있습니다. 순서가 중요하며, 이는 어떤 변경이 어떤 관찰에 앞섰는지 보여줍니다. 시도했던 모든 설정 목록은 동일한 정보를 제공하지 않습니다.
게임이 열릴 때 의견 보내기 (Give Feedback)를 사용하세요.
게임과 피드백 옵션에 접근할 수 있다면, 퍼블리셔가 지정한 경로를 사용하세요. 실패 유형, 마지막 정상 행동, 환경을 설명하세요. 퍼블리셔는 피드백 경로를 통해 로그가 전송되어 도움이 될 수 있다고 안내합니다. 로그만으로 의도나 문제가 발생한 정확한 순간이 설명된다고 가정하지 마세요.
지원 답변에서 요청된 경우 후속 연락을 원한다면 연락처를 포함하세요. 보고서는 문제에 집중하고 관련 없는 개인 정보를 추가하지 마세요. 유용한 연락처 정보는 개발자가 구체적인 추가 관찰을 요청할 때, 해당 정보를 공개 토론에 게시하지 않고도 요청할 수 있게 합니다.
문제가 크래시가 아닌 반복 가능한 일시정지라면, 별도의 성능 스레드에서 렉이 발생하는 동안 피드백을 요청합니다. 이미 게임을 종료한 크래시의 경우, 재열 시 그 타이밍을 설명하세요. 피드백 인터페이스나 개발자가 확인하지 않는 한 특정 이전 로그가 첨부되었다고 주장하지 마세요.
게임이 메뉴에 접근할 수 없다면
게임 내 보고 경로가 불가능함을 설명하기 위해서입니다. 창이 나타나기 전, 로딩 중, 혹은 타이틀 화면에 도달한 후 실패하는지 명시하세요. 이 단계들은 단일 문구가 실행되지 않는 것보다 더 유용합니다.
간결한 보고서와 검증 가능한 정보로 시작하세요. 설치 파일의 모든 파일을 첨부하거나 관련 없는 대규모 시스템 데이터 아카이브를 보내지 마세요. 필요한 파일이나 경로가 문서화되지 않은 경우에는 특정 추가 자료 요청이 올 때까지 기다리세요. 조사된 출처는 현재 소매 로그나 저장 경로를 제공하지 않습니다.
스토어프론트에 오류가 나타나면, 그 메시지를 게임 오류와 별도로 유지하세요. 게임 프로세스가 실행되기 전에 다운로드가 누락되거나 클라이언트 문제가 발생할 수 있습니다. 실패가 발생하는 레이어의 이름을 지정하면 스토어프론트 설치 문제를 퍼즐 엔진 충돌로 간주하는 것을 피할 수 있습니다.
이용 가능한 게임 업데이트를 확인하세요
스토어프론트의 일반 업데이트 메커니즘을 사용하고, 대기 중인 다운로드나 설치 작업이 완료된 후 동작을 비교하세요. 이는 일반적인 지원 관행이지, 특정 He Who Watches 업데이트가 크래시를 해결한다는 증거는 아닙니다. 업데이트가 사용 가능했는지, 그리고 그 후에 증상이 바뀌었는지 기록하세요.
최신 발표가 모든 로컬 빌드 변경을 설명한다고 가정하지 말고, 날짜에서 버전 번호를 만들어내지 마세요. 클라이언트가 식별자를 노출하면 사용하세요. 그렇지 않으면 실제로 볼 수 있는 업데이트 날짜와 스토어 프론트를 제공하세요. 지원팀이 맞출 수 없는 라벨보다 정확하고 불완전한 정보가 더 좋습니다.
퍼즐이나 메뉴 텍스트를 바꾸는 업데이트는 개발자가 허락하거나 신중하게 설명한 관찰이 귀하의 기기에서 더 좁은 결과를 뒷받침하지 않는 한 크래시 핫픽스로 광고해서는 안 됩니다. 설치 신선성 문제는 문제가 해결되었는지 여부와 분리해 두세요.
로우는 통제된 비교로만 시도해 보세요
개발자의 '저그래픽' 제안은 게임이 안정적으로 유지된다면 합리적인 작은 테스트입니다. 이전 프리셋을 참고하고 '낮음'을 선택한 후 일반 플레이나 짧은 비교 장면으로 돌아가세요. 원래 증상이 다시 나타나는지 기록하세요. 단지 프리셋을 비교하기 위해 시스템을 반복해서 재시작하지 마세요.
Low가 도움이 된다면, 관찰된 조건 하에서 국소적인 우회 방법으로 결과를 설명하세요. 안개, 부하, 열 또는 다른 요인이 이를 설명하는지 추론할 필요는 없습니다. 개발자는 당신이 추측적인 하드웨어 진단을 제공하지 않아도 동작 변화를 이용할 수 있습니다.
로우 검사가 도움이 되지 않는다면, 그 정보도 유용한 정보입니다. 실패 유형과 시기를 보고서에 포함하세요. 음성 테스트는 개발자의 제안이 부당하다는 뜻이 아닙니다; 오히려 당신의 사례에 더 많은 증거가 필요하다는 뜻입니다. 첫 번째 집중 비교가 실패한 후에는 관련 없는 여러 설정을 반복하는 것을 피하세요.
증상이 일치할 때 Steam 파일을 확인하세요
밸브는 Steam 라이브러리의 게임 '속성 및 설치 파일' 영역에서 파일 검증 검사를 문서화합니다. 이는 누락되거나 손상된 설치 파일에 적합할 수 있습니다. 이는 일반적인 문제 해결Steam 것이지, 이 게임의 재시작 문제에 대한 입증된 해결책은 아닙니다. 설치 콘텐츠를 수동으로 삭제하기보다는 클라이언트 인터페이스를 사용하세요.
검증이 끝날 때까지 기다리고 클라이언트가 보고한 내용을 기록하세요. 파일이 다시 수집될 경우, 그 사실이 실패의 원인이라고 가정하지 않고 기록하세요. 그 후 정상 실행 시 원래 증상을 비교하세요. 변화가 없다면, 검증을 무기한 반복하는 대신 그 결과를 지원 노트에 포함하세요.
설치 확인과 퍼즐 진행 상황 검증을 혼동하지 마세요. 이 검사는 방의 해답을 제시하거나 기존 공략이 새 배치와 일치해야 한다는 것을 증명하지 않습니다. 체크는 분실된 파일이나 실행 실패와 같은 기술적 증상에 묶여 명확한 목적이 있는 경우에 두세요.
파괴적인 추측을 피하세요
이용 가능한 개발자 답변들은 플레이어에게 저장 파일을 삭제하거나 설정 폴더를 제거하거나 레지스트리를 편집하거나 문서화되지 않은 실행 명령을 사용하라고 지시하지 않습니다. 이러한 행동들을 불확실한 충돌에 대한 기본 대응으로 삼지 마세요. 이들은 첫 번째 문제를 설명하지 않고 유용한 상태를 지우거나 두 번째 문제를 만들 수 있습니다.
마찬가지로, 검색 결과가 보편적인 해결책을 약속한다고 해서 시스템 보호를 비활성화하거나 서드파티 픽서를 다운로드하지 마세요. 관찰된 실패와 관련된 게임, 스토어프론트, 기기 지원 채널을 활용하세요. 증상과 명확한 연관성이 없는 극적인 절차보다 좁고 검증된 지침이 더 유용합니다.
지원팀이 나중에 특정 파일이나 변경을 요청할 경우, 지시사항 기록을 보관하고 적절한 경우 관련 데이터를 보존하세요. 모든 변경을 피하는 것이 목적이 아닙니다. 명시된 이유로 변경을 하고, 그것이 도움이 되었는지 판단할 수 있을 만큼 충분한 맥락을 유지하는 것입니다.
작지만 의미 있는 예시를 담아보세요
실패가 위험하거나 방해가 되는 시스템 이벤트를 유발하지 않고 관찰할 수 있다면, 짧은 녹화나 스크린샷으로 보고를 명확히 할 수 있습니다. 오류 메시지나 문제가 발생하기 직전에 수행한 행동을 보여주세요. 관찰자가 무엇을 주목해야 하는지 설명하세요. 길고 주석 없는 세션은 관련 순간을 숨길 수 있습니다.
개인 데스크톱 콘텐츠를 캡처에서 제외하고, 게임 후반 자료를 공유할 때 표시하세요. 전체 비밀 경로를 공개하지 않고도 기술적 동작을 보여줄 수 있는 경우가 많습니다. 장면 자체가 스포일러라면, 이미지나 영상에 앞서 알리고 제목에 답을 넣지 마세요.
재현이 최소화되었다고 주장하려면 실제로 좁혀야 합니다. 여러 행동 후 충돌을 관찰했고 무엇이 중요한지 모른다고 말하는 것은 괜찮습니다. 이렇게 솔직하게 말하면 지원팀이 단일 가시적 입력만으로 트리거가 완료되었다고 추정하는 것을 방지할 수 있습니다.
예상 동작과 실제 동작을 따로 작성하세요.
예상 동작은 일어나야 한다고 생각했던 것을 설명합니다: 방이 로드되어야 하고, 메뉴가 닫혀야 하며, 일반적인 이동 후에도 게임이 열려 있어야 합니다. 실제 동작은 눈에 보이는 실패를 설명합니다. 이를 따로 작성하면 개발자가 퍼즐 상태에 대한 해석을 공유하지 않아도 보고서를 이해할 수 있습니다.
예상이 가이드에서 나온 경우, 링크와 날짜를 포함하세요. 오래된 방 배치와 불일치하는 경우 버전 문제일 수 있으며 충돌 문제는 아닐 수 있습니다. 예상이 기본적인 애플리케이션 동작이라면 그렇게 명확히 쓰세요. 확인할 수 없는 기술 용어로 단순 보고서를 장식할 필요는 없습니다.
시도한 것과 각 단계의 결과를 추가하세요. 게임을 업데이트했음에도 로딩 시 여전히 종료된다면 유용합니다. '모든 것을 시도했다'는 유용하지 않습니다. 실제 점검을 간결하게 나열하면 이미 완료된 명백한 비교와 아직 테스트되지 않은 부분을 보여 시간 절약에 도움이 됩니다.
새로운 증거로 후속 조치를 취하세요.
개발자가 특정 테스트나 로그를 요청하면, 해당 요청에 직접 응답하세요. 원래 보고서 참조를 유지하여 새 정보가 동일한 문제와 연결되도록 하세요. 관련 없는 여러 쓰레드를 시작하면 맥락이 분리되어 시간이 지나면서 동작이 어떻게 변했는지 보기 어려워집니다.
변경 후 문제가 멈췄다면, 무엇이 변경되었고 이후 얼마 동안 또는 어떤 조건에서 테스트했는지 보고하세요. 한 번의 성공적인 실행 후 보편적인 해결책이라고 선언하지 마세요. 관찰한 대로 로우 설정에서 여러 정상 세션을 완료했다는 좁은 표현은 유용하고 정직합니다.
만약 다시 돌아오면, 동일한 문제에 대한 새로운 조건을 업데이트하세요. 재발은 이전의 개선을 지우지 않습니다; 오히려 그 한계에 대한 정보를 추가합니다. 이 구분은 변화가 빈도를 줄였는지, 한 장면에만 영향을 미쳤는지, 아니면 무관한 것인지 식별하는 데 도움이 될 수 있습니다.
언제 검사를 중단할지 결정하세요
명확한 실패 설명, 기본 환경 세부사항, 그리고 몇 가지 적절한 검사 결과를 얻으면 보고서를 보내세요. 도움을 요청하기 전에 직접 게임을 진단할 필요는 없습니다. 추가 테스트는 특정 남은 질문에 답하거나 관련 지침을 따를 때만 가치가 있습니다.
기기 자체가 불안정하다면, 그 더 큰 문제를 우선시하고 반복적인 게임 실행을 피하세요. 게임만 종료되고 시스템이 다른 용도로 사용할 수 있다면, 보고서를 보존하고 반복적으로 설치를 교체하는 대신 목표 달성 단계가 있을 때까지 기다리세요. 대응은 실제로 겪은 실패 상황에 맞아야 합니다.
좋은 보고서는 작은 증거 조각입니다: 무슨 일이 있었는지, 어디서, 어떤 설정에서인지, 그리고 문서화된 단계를 시도했을 때 무엇이 바뀌었는지. 이 정도면 추측, 관련 없는 조정, 불필요한 파일 변경을 막으면서 생산적인 조사를 시작할 수 있습니다.
모호한 보고서를 실행 가능한 보고서로 바꾸세요
게임이 크래시된다는 보고서는 때때로 몇 가지 중요한 질문을 남기지 못합니다. 기술적 추측 없이도 실패 유형, 플레이 단계, 대략적인 빈도, 마지막 정상 행동을 추가하면 개선할 수 있습니다. 예를 들어, 로딩 중 데스크톱으로 돌아가는 것과 긴 세션 후 시스템 전체를 재시작하는 것을 구분하세요. 이것들은 보고된 패턴이지, 당신의 컴퓨터에서 발생했다고 주장하는 이벤트가 아닙니다.
그 다음 환경과 실제로 완료한 소수의 체크 세트를 추가하세요. 전체 게임을 사용했는지, 어떤 스토어프론트에서 제공했는지, 어떤 그래픽 프리셋이 활성화되어 있는지 명시하세요. Low나 Steam 검증을 시도했다면 각각의 결과를 따로 보고하세요. 한 번의 체크만 했다고 모든 수정이 실패했다고 쓰지 마세요.
알려진 시퀀스 하에서 동작이 반복 가능한지 아니면 시간에 따라 반복되는 것인지 설명하세요. 반복 가능한 실패는 지원팀이 시도할 시퀀스를 제공합니다. 반복 실패는 여전히 중요하지만, 그 트리거는 불확실합니다. 차이를 라벨링하면 개발자가 재현, 로그, 세션에 대한 추가 정보를 요청할지 결정하는 데 도움이 됩니다.
오류 메시지가 있는 경우, 그것을 원문 그대로 유지하고 원인으로 바꾸어 바꾸어 표현하지 마십시오. 익숙하지 않은 코드가 그래픽 문제를 의미한다고 자신 있게 단정하는 요약보다 지원팀에 더 유용할 수 있습니다. 메시지를 캡처하지 못한 경우, 그것을 말했다고 하고, 누락된 내용을 만들어내지 말고 기억나는 내용을 설명하십시오.
현재 상태로 끝내십시오. 지금 게임을 실행할 수 있습니까? 문서화된 설정 비교 후에도 문제가 계속됩니까? 게임 내 피드백 경로에 접근할 수 있습니까? 이러한 답변은 지원팀에게 실제로 수행할 수 있는 다음 단계를 알려줍니다. 메뉴에서 제출 요청을 하는 것은, 보고서에서 메뉴가 절대 나타나지 않는다고 이미 설명했다면 유용하지 않습니다.
원본 보고서와 이후 후속 보고를 연결해 두십시오. 새로운 관찰이 나타나면 과거를 처음부터 원인을 알고 있었던 것처럼 다시 작성하지 말고, 날짜와 조건과 함께 추가하십시오. 이렇게 하면 조사에 유용한 순서, 즉 증상, 확인, 결과, 다음 질문이 보존됩니다. 또한 나중에 성공적인 변경 사항을 평가할 때도 솔직하게 평가하기 쉽습니다.
향상된 보고서는 길 필요가 없습니다. 때때로 단어 안에 숨겨진 사실을 드러내야 합니다. 명확한 범위와 몇 가지 관찰된 세부 사항은 엔진 추정 설명 한 페이지보다 더 많은 시간을 절약할 수 있으며, 개발자가 다음 증거를 요청하는 데 근거를 제공합니다.