AI 생성 게임 디버깅

수정을 요청하기 전에 실패를 분류하세요

가장 먼저 실패한 단계를 식별하세요. 프로젝트 검색, 가져오기, 파싱 또는 컴파일, 씬 시작, 플레이어 입력, 게임플레이 상태, 내보내기, 대상 실행 중 하나입니다. 이후 증상은 처음 실패의 결과일 수 있습니다. 엔진 버전, 프로젝트 리비전, 대상, 정확한 재현 절차를 함께 유지하세요.

예를 들어 씬이 시작되지 않으면 재시작 버튼이 작동하는지 알 수 없습니다. 브라우저가 게임 패키지를 가져오지 못하면 컨트롤러를 테스트할 수 없습니다. 코드를 바꾸기 전에 오류를 올바른 경계로 보내세요. 그러면 원래 전제조건이 깨진 채로 남아 있는 동안 수리 루프에 관련 없는 패치가 쌓이지 않습니다.

처음 발생한 의미 있는 엔진 오류를 캡처하세요

Godot에서는 디버거 패널과 관련 런타임 출력을 사용하세요. Unity에서는 컴파일 오류와 런타임 오류를 분리해 검사하고 플레이 결과를 해석하기 전에 에디터가 준비될 때까지 기다리세요. 실패한 스크립트와 이를 유발한 작업을 식별하는 스택 또는 위치를 보존합니다.

에이전트에 집중된 발췌와 관련 씬 또는 객체 컨텍스트를 보내세요. 처음 오류가 가려지는 거대한 무차별 로그는 피하되 나중에 검사할 수 있도록 전체 기록은 로컬에 보존합니다. 자격 증명과 개인정보를 정제하세요. 유용한 보고서에는 플레이어가 한 일, 일어나야 할 일, 엔진이 실제로 보고한 내용이 들어갑니다.

요구사항은 바꾸지 않고 재현을 줄이세요

복구 가능한 프로젝트 상태에서 시작해 결함이 여전히 나타나는 가장 작은 씬 또는 행동을 분리하세요. 문제에 실제로 관여하는 컨트롤러, 충돌 규칙, 저장 경계를 유지합니다. 실패하는 시스템을 완전히 제거하면 깨끗하게 실행될 수 있지만 고쳐야 했던 동작을 잃게 됩니다.

아래 브리프는 독창적인 진단 템플릿입니다. 모델에 원인을 가정하라고 하지 말고 관찰된 세부사항으로 채우세요. 하나의 제안된 설명과 범위가 좁은 변경을 요구합니다. 테스트가 끝나면 전체 플레이어 여정에 다시 합류해 로컬 수리가 깨진 씬 전환을 가리지 않는지 확인하세요.

Project revision: <record actual revision>
Engine and target: <record actual environment>
Steps: launch -> start round -> perform the failing action
Expected state: <specific result>
Observed state: <specific result>
First engine error: <relevant error and location>
Inspect the referenced scene and script before editing.
Propose one cause, make a scoped fix, then repeat these steps.
Preserve the required behavior and report any remaining failure.

빈 화면을 계층별로 조사하세요

먼저 엔진이 시작되었고 의도한 씬이 로드되었는지 판단하세요. 그런 다음 카메라 선택, 뷰포트 크기, 객체 가시성, 위치, 씬을 덮는 오버레이를 검사합니다. 엔진 상태와 실제 캡처를 함께 사용하세요. 이미지 하나만으로는 씬이 일시 정지했는지, 카메라 밖에 있는지, 비어 있는지 드러나지 않을 수 있습니다.

아무것도 보이지 않을 때도 입력을 적용하고 상태가 바뀌는지 관찰하세요. 위치는 바뀌지만 이미지가 바뀌지 않으면 렌더링 또는 씬 참조에 집중합니다. 둘 다 바뀌지 않으면 아트를 조정하기 전에 시작과 입력을 조사하세요. 각 가설을 관찰 결과에 연결해 에이전트가 두 시스템을 불필요하게 다시 작성하지 않도록 합니다.

게임플레이 전환을 따라 입력을 추적하세요

포커스와 매핑에서 핸들러로, 다시 바뀌어야 하는 상태까지 행동을 따라가세요. 이동 수학을 탓하기 전에 일시 정지 상태와 UI 가로채기를 확인합니다. 재시작 실패는 누락된 핸들러, 오래된 씬 참조, 재설정되지 않은 상태 때문일 수 있습니다.

수리 후에는 관련된 여러 상태에서 행동을 테스트하세요. 최초 실행, 승리 후, 해당하는 경우 패배 후가 포함됩니다. 반복 라운드 뒤에만 나타나는 중복 핸들러나 오래된 객체도 확인하세요. 작고 완결된 미니플로가 버튼을 고립해 반복 테스트하는 것보다 이런 생명주기 결함을 더 효과적으로 좁힐 수 있습니다.

브라우저 로딩과 게임 로직을 분리하세요

Godot 웹 내보내기에서는 게임플레이 코드를 수정하기 전에 브라우저 네트워크와 콘솔 패널을 검사하세요. 내보낸 HTML, JavaScript, WebAssembly, 게임 패키지가 의도한 위치에서 로드되는지 확인합니다. 선택한 스레드 구성의 요구사항을 포함해 호스팅 설정을 공식 웹 내보내기 문서와 비교하세요.

내보낸 동반 파일 이름을 일관되게 유지하고 오래된 파일과 새 파일이 섞인 상태가 아니라 산출물을 테스트하세요. 잘못된 프로젝트가 나타나면 테스트 브라우저에서 service-worker 캐시를 검사합니다. 그런 다음 입력을 실행하고 움직이는 콘텐츠를 확인하세요. 비어 있지 않은 캔버스는 초기 렌더링 확인이지 게임 루프가 작동한다는 증거가 아닙니다.

대상에서 내보내기 전용 실패를 확인하세요

에디터는 작동하지만 배포 빌드가 실패하면 시작 씬 선택, 포함된 리소스, 구성, 대상 로그를 비교하세요. 나중에 다시 내보내도 재현 기록이 무효화되지 않도록 정확한 산출물 해시를 보존합니다. 기존 저장 파일이나 에디터 캐시에 의존하기 전에 깨끗한 시작 상태로 테스트하세요.

패키징된 파일 누락을 해결하려고 핵심 메커니즘을 바꾸지 마세요. 패키징 경계를 수정하고 대상 빌드에서 같은 승인 경로를 다시 실행합니다. 데스크톱 산출물은 실제 운영체제를, 브라우저 산출물은 의도한 브라우저와 호스팅 설정을 사용하세요. 단순히 다른 형식으로 내보내는 것만으로 대상 동작이 확인되지는 않습니다.

수리를 전후 결과로 마무리하세요

실패한 재현, 범위가 정해진 diff, 이제 예상 상태를 만드는 반복 행동을 보존하세요. 결함을 만든 경계에 회귀 확인을 추가한 다음 주변 게임 루프를 다시 실행합니다. 수동 수정과 실패한 수리에 소비된 요청도 기록하세요.

여기 예시들은 공개된 실패 및 수정 사례가 아니라 진단 절차입니다. 자신의 프로젝트에서 구체적인 보고서를 만드는 데 사용하세요. 반복 제안 뒤에도 같은 증상이 지속되면 자동 루프를 중지하고 새로운 근거 없이 광범위한 재작성을 확대하지 말고 누락된 관찰을 수집하세요.

자주 묻는 질문