Unity AI 게임 개발

기존 프로젝트 계약에서 시작하세요

에이전트에 쓰기 권한을 주기 전에 선택한 Unity 에디터, 프로젝트 경로, 대상 플랫폼, 패키지, 렌더링 설정을 확인하세요. 프로젝트 버전과 의존성 잠금 정보를 실험 기록과 함께 보존합니다. 운영자에게 필요한 에디터 접근 권한과 대상 모듈이 있는지 확인하세요. 모델 접근은 이러한 전제조건을 제공할 수 없습니다.

프로젝트가 정해 둔 규칙을 사용해 작은 플레이 가능 씬 하나를 정의하세요. 팀에 이미 캐릭터 컨트롤러나 입력 추상화가 있다면 에이전트에 대체안을 제안하기 전에 이를 검사하도록 요청하세요. 그러면 생성된 변경을 검토하기 쉬워지고 겉보기에는 독립적인 프로토타입이 게임의 나머지 부분이 의존하는 시스템을 우회하는 일을 막을 수 있습니다.

에디터 자동화를 별도 연결로 다루세요

CoplayDev의 Unity MCP 프로젝트는 호환 클라이언트에 에디터 작업을 노출합니다. 설치 가이드는 에디터 패키지와 서버 연결을 설명합니다. 에이전트의 모델 서비스는 별개이므로 모델 자격 증명을 바꿔도 사용할 수 없는 에디터 인스턴스가 고쳐지지는 않습니다.

읽기 전용 프로젝트 검사부터 시작하고 요청을 받을 열린 인스턴스가 어느 것인지 확인하세요. 변경 승인은 폐기 가능한 씬이나 명시적으로 소유한 기능에 한정하세요. 도구가 성공을 반환한다는 것은 자체 경계에서 작업이 완료되었다는 뜻일 뿐입니다. 결과 씬에는 여전히 잘못된 참조가 있거나 플레이 중 실패할 수 있습니다. 전용 MCP 가이드에서 연결 확인과 버전 기록을 다룹니다.

관찰 가능한 결과가 있는 제한된 변경을 요청하세요

실패가 발생할 때마다 전체 씬을 다시 작성해 달라고 하지 말고 컨트롤러 조정, 메뉴 전환 하나, 작은 영속성 기능을 요청하세요. 플레이어가 무엇을 해야 하는지, 어떤 상태가 바뀌어야 하는지, 결과를 어떻게 관찰할지 명시하세요. 생성된 수정을 받아들이기 전에 이전의 정상 상태를 보존합니다.

아래 예시 브리프로 제한된 변경과 검토 기준을 정의하세요. 씬과 프리팹은 스크립트 diff뿐 아니라 객체 참조와 저장된 상태도 검사해야 합니다. 게임플레이를 결정하는 설정이 소스 파일 하나에 모두 들어 있지 않을 수 있습니다. 편집하기 전에 영향을 받는 객체를 식별하도록 에이전트에 요청하세요.

Inspect the selected project and its existing input and controller code.
Add one restart transition to the owned gameplay scene.
Keep package versions and rendering settings unchanged.
Report changed scripts, scene references, and the verification performed.
Stop before package downloads, purchases, external uploads, or publishing.

플레이 결과를 해석하기 전에 컴파일을 기다리세요

관찰 로그에서 코드 컴파일, 에디터 준비, 게임플레이를 분리하세요. 컴파일이 실패하면 가장 먼저 발생한 관련 오류와 변경된 소스 컨텍스트를 캡처하세요. 에디터가 의도한 스크립트를 로드하지 못하는 동안 이동 감도를 조정하라고 요청하지 마세요. 잘못된 기준선에 추가 수정을 만들게 됩니다.

컴파일 후 플레이에 들어가기 전에 예상 컴포넌트와 참조를 확인하세요. 수정 후 같은 플레이어 행동을 재현합니다. 오류 없는 콘솔은 유용한 근거이지만 게임이 여전히 의도한 상태에 도달해야 합니다. 증상이 바뀌지 않는 반복 변경은 더 큰 대체가 아니라 더 작은 재현으로 이어져야 합니다.

프로젝트 테스트 프레임워크를 의도적으로 사용하세요

Unity Test Framework는 명령줄 테스트 선택과 결과 출력을 문서화합니다. 이 예시는 해당 프레임워크가 이미 구성되어 있고 테스트 결과 디렉터리가 존재한다고 가정합니다. UNITY_BIN과 PROJECT는 기존 에디터와 프로젝트를 가리키는 설명용 셸 변수입니다. 참조 문서를 설치된 패키지와 맞추세요.

적절히 고립된 로직에는 EditMode 확인을, 실행이 필요한 동작에는 PlayMode 확인을 실행하세요. 이 범주들은 조작과 표현에 대한 실제 검토를 대체하지 않습니다. 테스트 중인 리비전과 함께 테스트 수, 실패, 결과 파일을 보존하세요. 테스트를 하나도 발견하지 못한 실행은 게임이 통과했다는 사실을 입증할 수 없습니다.

UNITY_BIN="/absolute/path/to/Unity"
PROJECT="/absolute/path/to/project"
"$UNITY_BIN" -batchmode -projectPath "$PROJECT" \
  -runTests -testPlatform EditMode \
  -testResults "/absolute/existing-results-dir/editmode.xml" \
  -logFile "/absolute/existing-results-dir/editmode.log"

플레이어를 만들기 전에 빌드 입력을 검토하세요

빌드는 검토된 프로젝트 씬 선택과 대상 설정을 사용해야 합니다. 현재 에디터에서 열려 있는 씬이 시작 시 포함되는 씬이라고 가정하지 마세요. 이후 실패를 정확한 산출물과 연결할 수 있도록 빌드 식별자와 로그를 보존하세요.

Unity CLI는 -executeMethod를 통해 기존 정적 에디터 메서드를 호출할 수 있습니다. 하지만 이 플래그가 빌드 구현을 만들어 주는 것은 아닙니다. 프로젝트에 명시적인 빌드 동작과 실패 처리를 가진 실제 메서드가 있어야 합니다. 존재하지 않는 실행 가능한 예시 메서드를 새로 만들기보다 팀의 기존 빌드 진입점을 우선 사용하세요.

에디터 밖에서 게임플레이를 검증하세요

선언된 운영체제에서 예상한 조작과 깨끗한 시작 상태로 전달된 플레이어를 테스트하세요. 첫 화면에서 들어가 라운드를 완료하고 재시작하고 설정을 바꾼 뒤 재실행합니다. 창이 열리는지만 확인하지 말고 승인 브리프와 영속성 및 전환을 비교하세요.

해당 산출물에서 실제 스크린샷과 짧은 입력 기반 시퀀스를 기록하세요. 에디터 실행은 통과했지만 빌드가 실패한다면 에이전트에 핵심 게임플레이를 다시 작성하라고 하기 전에 씬 포함, 리소스 의존성, 플랫폼별 동작을 검사하세요. 바뀐 경계가 원인을 추적하는 유용한 단서입니다.

사람의 작업과 해결되지 않은 의존성을 추적하세요

수동 인스펙터 변경, 에셋 수정, 추가 지시, 환경 수리를 개입 기록에 남기세요. 모델 사용량이 발생하지 않았어도 제작 노력의 일부입니다. 비용을 검토할 때 텍스트 코딩 호출, 이미지 생성, 엔진 작업, 대상 장치 테스트를 구분하세요.

이 문서 기반 안내는 선택한 에디터와 패키지 버전에 맞춰 검증해야 합니다. 연결, 변경, 컴파일, 플레이, 내보내기를 포함한 가장 작은 완결 워크플로를 인수인계에 남기세요. 다른 개발자가 반복할 수 있게 된 뒤 그 기준선을 다음 기능에 사용하고 의존성 또는 빌드 대상이 바뀔 때마다 확인을 다시 수행하세요.

자주 묻는 질문