Godot AI 게임 개발

수정 전에 프로젝트 경계를 정하세요

소유한 프로젝트 디렉터리와 허용된 변경 사항을 적은 목록에서 시작하세요. 기존 씬, 스크립트, 에셋, 플러그인을 목록화해 에이전트가 두 번째 구현을 만드는 대신 현재 구조를 확장하도록 합니다. 초기 프로젝트 상태를 복구할 수 있게 유지하고 어떤 엔진 바이너리가 프로젝트를 여는지 기록하세요.

명시적인 전환이 있는 적당한 플레이 가능 범위를 선택하세요. 예를 들어 타이틀 화면에서 한 방으로 들어갔다가 승리 또는 패배를 거쳐 돌아오면 반복 가능한 테스트가 됩니다. 시각적 구성과 조작을 누가 검토할지 정하세요. 성공적인 파서나 모델의 완료 메시지만으로는 경험이 일관된다는 사실을 입증할 수 없습니다.

실행 파일과 지원 인수를 확인하세요

Godot의 안정적인 CLI 문서가 아래 명령을 제공합니다. GODOT_BIN과 PROJECT는 이 예시에서 선택한 셸 변수이며 Godot 설정이 아닙니다. 플레이스홀더 경로를 기존 실행 파일과 프로젝트로 바꾸세요. 프로젝트 경로에는 project.godot가 있어야 합니다.

추가 플래그를 스크립트로 작성하기 전에 버전과 도움말 출력을 캡처하세요. 그러면 현재 온라인 문서에 있는 명령이 설치된 빌드에도 있다고 가정하는 일을 피할 수 있습니다. 이후 테스트 결과와 함께 바이너리 식별자를 기록하고 실패를 조사하는 동안에는 안정적으로 유지하세요. 이 예시 명령은 문서화된 CLI 형식을 사용합니다.

GODOT_BIN="/absolute/path/to/godot"
PROJECT="/absolute/path/to/project"
"$GODOT_BIN" --version
"$GODOT_BIN" --help
"$GODOT_BIN" --headless --path "$PROJECT" --import

가져오기, 파싱, 실제 플레이를 분리하세요

헤드리스 가져오기는 에셋 처리 경계를 확인합니다. 파서 검사는 스크립트를 검사합니다. 일반 실행은 게임까지 도달해 씬 연결과 런타임 문제를 드러낼 수 있습니다. 세 결과를 모두 테스트 통과로 요약하지 말고 검토 기록에서 분리하세요.

아래 예시 스크립트 경로는 프로젝트에 이미 존재해야 합니다. 파서 검사는 의도적으로 범위가 좁으며 작동하는 충돌, 반응하는 입력, 올바른 영속성을 입증할 수 없습니다. 수정 후에는 수정한 동작과 그 직전 및 직후의 전환을 다시 실행하세요. 생성된 도우미 함수마다 고립된 확인을 여러 개 만드는 것보다 이 방식이 더 많은 정보를 주는 경우가 많습니다.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --script res://scripts/player.gd --check-only
"$GODOT_BIN" --path "$PROJECT" --debug

CLI 도구와 MCP를 의도적으로 선택하세요

셸을 사용할 수 있는 에이전트는 검토된 CLI 시퀀스를 실행할 수 있습니다. Godot MCP는 별도의 프로젝트 유지 관리 도구 인터페이스이며 전용 페이지에서 설정을 다룹니다. 어느 경우든 운영자는 쓰기 또는 프로세스 실행을 승인하기 전에 어느 프로젝트를 대상으로 하는지 알아야 합니다.

에이전트의 모델 제공업체 설정과 엔진 도구를 분리하세요. 로컬 연결이 작동한다고 해서 특정 모델이 제공되거나 에이전트가 호환 게이트웨이의 모든 기능을 지원한다는 뜻은 아닙니다. 먼저 허용된 가장 작은 읽기를 실행하고, 그다음 되돌릴 수 있는 씬 변경, 마지막으로 승인된 실험의 완전한 게임플레이 사이클을 설정하세요.

실패에 충분한 씬 컨텍스트를 제공하세요

상호작용이 실패하면 관련 씬 트리, 스크립트, 입력 액션, 처음 발생한 의미 있는 런타임 오류를 캡처하세요. 기대한 전환과 관찰된 상태를 설명하세요. 플레이어가 움직이지 않는다는 보고에는 게임에 포커스가 있는지, 입력이 감지되는지, 플레이어 위치가 바뀌는지가 포함되어야 합니다.

그 근거에 연결된 설명과 함께 작은 수정안을 제시하도록 하세요. 적용한 뒤 같은 행동을 반복하고 재시작 및 씬 전환의 회귀를 검사하세요. 오류가 사라졌다는 이유만으로 수리를 받아들이지 마세요. 영향을 받은 기능을 끄면 오류는 없어질 수 있지만 원래 요구사항은 충족되지 않은 채 남습니다.

내보내기 전제조건을 명시적으로 준비하세요

내보내기에는 일치하는 프리셋과 설치된 내보내기 템플릿이 필요합니다. 빌드 전에 export_presets.cfg와 리소스 포함 여부를 검토하세요. 내보내기 자격 증명은 비공개로 유지하세요. 예시의 프리셋 이름은 설명을 위한 것이며 프로젝트와 일치해야 하고 출력 디렉터리는 이미 존재해야 합니다.

누락된 템플릿이나 프리셋은 환경 문제로 다루세요. 생성된 게임 로직이 잘못되었다는 근거가 아닙니다. 대상 플랫폼에서 발견한 문제가 특정 빌드를 가리키도록 내보내기 로그와 산출물 해시를 보존하세요. 내보내기가 성공해도 전달된 플레이어가 시작하거나 라운드를 완료한다는 사실은 확인되지 않습니다.

"$GODOT_BIN" --headless --path "$PROJECT" \
  --export-release "Windows Desktop" "/absolute/existing-build-dir/game.exe"

대상 환경에서 배포 미니플로를 실행하세요

지원하려는 운영체제에서 내보낸 게임을 실행하세요. 시작, 입력, 완전한 라운드, 재시작, 설정, 재실행 후 영속성을 테스트합니다. 각 결과에 대해 산출물 식별자, 장치 컨텍스트, 관찰된 결과를 보존하세요. macOS에서 만든 내보내기만으로 Windows 동작이 검증되지는 않습니다.

웹 대상을 위해서는 브라우저 로딩과 런타임 오류도 검사하고 실제 입력으로 캔버스를 조작하세요. 적절할 때 콘텐츠가 보이고 움직이는지 확인하세요. 로컬 에디터 실행만으로 브라우저 리소스 로딩과 플랫폼 제한을 모두 다룰 수 있다고 가정하지 말고 실제 호스팅 설정을 테스트하세요.

검토할 소스 프로젝트와 네이티브 캡처

로컬 Switchyard 사례에는 3개 방 Godot 퍼즐, 자동화된 게임플레이 확인, 저장 및 재열기 확인, 원시 로그, 소스 ZIP, Godot PCK가 포함되어 있습니다. 네이티브 캡처에는 두 뷰포트 크기에서 실제 실행 중인 프로젝트가 보입니다. 스크린샷만으로 프로젝트를 판단하는 것보다 문서화된 명령을 반복하는 편이 더 강한 확인입니다.

이 프로젝트는 정확한 생성 모델이 확인되지 않은 Codex 실행에서 Godot 4.5.1을 사용했습니다. 따라서 Astra 벤치마크가 아니라 로컬 엔진 워크플로를 보여줍니다. 내보내기 템플릿 누락으로 브라우저 내보내기가 막혔고 PCK는 독립형 Windows 실행 파일이 아닙니다. 다음 개발자가 무엇을 더 테스트해야 하는지 알 수 있도록 이러한 경계를 소스와 함께 기록했습니다.

검토 가능한 인수인계로 루프를 닫으세요

인수인계 문서에는 플레이 가능한 범위, 소스 식별자, 엔진 및 템플릿 버전, 빌드 지침, 승인된 결과, 해결되지 않은 결함을 명시해야 합니다. 테스트된 산출물의 진짜 캡처와 배포한 에셋의 출처를 포함하세요. 최종 생성 코드 덤프만 제시하지 말고 수리 시도와 수동 개입을 보존하세요.

기본 루프가 승인되면 플랫폼 제출을 고려하기 전에 자체 가져오기 및 게임플레이 확인을 거쳐 에셋과 현지화를 추가하세요. 이 안내는 엔진 문서에 기반하므로 설치한 버전에 적용하고 실제 결과를 보존하세요. 재현 단계가 포함된 짧은 미해결 이슈 목록을 유지해 다음 개발 세션이 같은 알려진 상태에서 시작하도록 하세요.

자주 묻는 질문