Procedural Pixel Creatures (Claude Code - Opus 5.5)
핵심 요약
Claude Opus 5.5를 활용해 Godot 엔진에서 완벽하게 절차적으로 생성되는 픽셀 아트 크리처 프레임워크를 개발함.
절차적 생성 — 사전 제작된 스프라이트 없이 코드만으로 신체, 애니메이션, 색상 등을 생성함
다양한 종족 — 9가지 생물군(인간형, 파충류, 곤충형 등)과 유전적 변이 시스템 지원
워크숍 환경 — 유전자 편집, 특성 고정, 변이 강도 조절 및 개체 조합 기능 제공
기술적 완성도 — 오프라인 실행 가능, AAA급 품질을 목표로 한 데이터 기반 프레임워크
이거 거의 95%는 Claude Opus 5.5 프롬프트 하나로 만들었음. 나머지 5%는 나중에 몇 번 더 찔러본 거고. Godot .NET이랑 C#으로 짰다.
생명체들은 전부 코드로 생성됨. 몸 형태, 팔다리, 얼굴, 색깔, 무늬, 리깅, 움직임까지 싹 다. 미리 만들어둔 스프라이트나 AI로 뽑은 소스 이미지 같은 거 하나도 없고, 완성된 앱은 AI 서비스 연결 없이 오프라인으로도 잘 돌아감.
종류는 총 9개야. 사족보행, 휴머노이드, 파충류/드래곤, 절지동물, 날개 달린 놈들, 뱀, 수중 생물, 슬라임/촉수 괴물, 그리고 식물형 생물까지. 변형되는 범위가 꽤 넓어서 같은 종 안에서도 말, 덩치 큰 초식동물, 판타지 괴물 같은 게 다 튀어나옴. 휴머노이드는 옷이나 갑옷, 장비도 절차적으로 생성된다.
워크숍에서는 유전자 하나하나 수정할 수 있고, 마음에 드는 특징은 잠가두고 나머지만 다시 돌리거나 변경 사항 되돌리기도 가능함. 부모 하나당 애니메이션 들어간 새끼 4마리가 나오고, 돌연변이 강도도 조절할 수 있어. 호환되는 부모 둘을 합치는 것도 됨. 개요 화면에서는 생명체를 최대 100마리까지 한꺼번에 뽑아볼 수 있는데, 마음에 드는 건 킵해두고 나머지만 다시 돌리거나, 특정 개체를 다시 에디터로 보내서 수정할 수도 있음. 생각했던 것보다 결과물 구경하느라 시간 순삭당하기 딱 좋음 ^^.
Godot에서 완벽하게 절차적으로 생성되는 픽셀 아트 크리처와 절차적 애니메이션을 위한, AAA급 퀄리티를 필수로 하는 최상위 수준의 프로덕션용 프레임워크를 개발해라. 워크숍 인터페이스와 인터랙티브 테스트 환경을 갖춘 독립 실행형 레퍼런스 애플리케이션인 'Procedural Pixel Creature Workshop'을 결과물로 내놔라. 프레임워크, 파일, 실행 가능한 메인 씬, 테스트, 문서화까지 시스템 전체를 빠짐없이 구현해라.
최고 수준의 품질 표준은 이 작업의 핵심 요구사항이다. 리드 테크니컬 아티스트, 애니메이션 엔지니어, 그리고 엔진/툴 개발자로서 책임감을 가져라. 최종 결과물을 캐릭터, 애니메이션, 툴, 런타임 통합까지 상업용 게임을 바로 만들 수 있는 수준의 프레임워크로 취급해라. 목표 설명은 시각적 기준점일 뿐이니, 형태, 표현, 움직임, 다양성, 구현 방식에서 그 이상을 보여줘라.
여기서 AAA란 엄격한 예술적, 기술적 완성도를 의미한다. 확실한 아트 디렉션, 고퀄리티 픽셀 아트워크, 설득력 있는 해부학적 구조, 캐릭터성이 살아있는 움직임, 신뢰할 수 있는 툴, 견고한 런타임 아키텍처, 그리고 수많은 생성 결과물에서 증명된 품질이 뒷받침되어야 한다. 낮은 픽셀 해상도는 의도된 예술 형식이며, 보이는 모든 픽셀 하나하나에 높은 수준의 요구사항이 적용된다.
MVP, 개념 증명(PoC), 플레이스홀더 시스템, 아키텍처 설계, 혹은 잘 다듬어진 캐릭터 하나만 달랑 내놓는 건 이 작업의 목적에 부합하지 않는다. 철저하게 개발된 레퍼런스 애플리케이션을 포함한 프로덕션용 프레임워크를 완성해라. 기능 목록이 길다고 품질을 대체할 순 없다. 지원하는 모든 신체 계열, 애니메이션, 핵심 제어 기능은 공통 품질 표준을 충족해야 한다.
아트 디렉션: 실루엣, 비율, 표정, 재질 렌더링, 윤곽선, 색상 계층 구조에 대한 일관된 시각적 언어를 구축해라. 모든 캐릭터는 게임 화면 크기에서 즉시 식별 가능해야 하며, 확대했을 때도 공들여 만든 티가 나야 한다.
생성 품질: 생성 규칙은 체계적으로 좋은 결과가 나오도록 설계해야 한다. 해부학적 제약, 구성 규칙, 그리고 제한적이고 추적 가능한 수정/재생성 단계를 통해 망가진 형태나 예술적으로 엉망인 결과물이 나오지 않게 해라. 엄선된 샘플 외에도, 수정되지 않은 재현 가능한 무작위 샘플을 제시해라.
애니메이션 품질: 무게감, 균형, 의도, 개성을 전달해라. 포즈, 예비 동작(anticipation), 타이밍, 움직임의 궤적, 레이어링, 후속 동작(follow-through), 접촉 지점을 정밀하게 다듬어라. 상태 전환, 방향 전환, 속도 변화도 개별 루프와 동일한 품질 표준을 만족해야 한다.
기술적 성숙도: 명확한 계약(contract)을 통해 데이터, 생성, 포즈, 렌더링을 분리해라. 라이프사이클 관리, 리소스 정리, 에러 상태, 버전 관리, 재현 가능한 결과를 완벽하게 다뤄라. 이 프레임워크는 워크숍 인터페이스 없이도 다른 Godot 게임에서 바로 쓸 수 있어야 한다.
툴 품질: 파라미터는 예측 가능하게 반응해야 하고, 실행 취소/다시 실행은 작업을 안전하게 보존해야 하며, 프리셋과 내보내기는 신뢰할 수 있어야 한다. 진행 상황과 에러는 명확하게 표시해라. UI는 개발자나 아티스트가 작업에 집중할 수 있게 만들어야 한다.
검증 및 반복: 기술적, 시각적 결과를 반복적으로 검증하고, 구체적인 결함을 찾아내 근본 원인을 해결해라. 핵심 기능에 플레이스홀더가 남아있거나, 치명적인 버그가 있거나, 신체 계열이 현저히 미완성인 상태라면 프로젝트를 계속 열어둬라. "AAA"라는 용어는 결과물과 테스트를 통해 증명되는 품질 목표다.
예술적 다듬기, 애니메이션 폴리싱, 통합, 안정화에 충분한 시간이 남도록 구현 계획을 짜라. 일찍 끝내려고 합의된 범위나 품질 표준을 멋대로 낮추지 마라. 만약 환경이나 세션 제한에 걸린다면, 정확한 체크포인트를 저장하고 결과물이 미완성임을 명확히 밝혀라. 프로덕션용인 척 속이지 마라.
클라우드에서는 볼 수 없는 맥락
이 설명은 너한테 넘겨주는 전체 컨텍스트야. 독립적이고 데이터 기반으로 돌아가는 고도(Godot) 워크숍 원칙을 따라. 이 목적에 맞는 새로운 구현 방식과 커스텀 게놈 포맷을 만들고 문서화해.
기반은 C# / .NET 8을 사용하는 표준 고도 .NET 4.5.2로 잡고, 2D 렌더링은 가급적 Compatibility 렌더러를 써. 실제로 쓸 수 있는 도구들을 확인하고, 만약 다른 안정적인 고도 4 .NET 버전이 필요하다면 그 이유를 밝히고 SDK 버전이랑 같이 고정해. 블렌더, 스팀, 웹 서버, AI 서비스 같은 외부 의존성은 싹 다 배제해. 완성된 프로젝트는 윈도우 고도에서 오프라인으로 임포트할 수 있어야 하고, F6/F5나 문서화된 실행 스크립트로 바로 돌릴 수 있어야 해. 개발이랑 테스트는 리눅스 클라우드 환경에서 진행해.
시각적 목표
목표하는 비주얼은 비스듬히 내려다보는 쿼터뷰 시점에서 풀, 나무, 물이 어우러진 알록달록한 배경 위를 활기차게 돌아다니는 픽셀 생명체들이야. 동물들은 몸의 부피감, 주둥이, 눈, 관절이 있는 다리, 발톱, 긴 꼬리가 잘 보여야 하고, 경우에 따라 뿔, 등 가시, 갑옷 같은 것도 있어야 해. 짙은 외곽선, 절제된 명암 단계, 적절한 하이라이트를 써서 입체감을 살려.
배경은 거들 뿐, 생명체가 주인공이야.
매력적인 실루엣, 표정, 무게감이 느껴지는 독창적인 디자인을 뽑아내. 작은 동물부터 거대한 짐승, 괴물, 인간형 생명체, 판타지 생물까지 다양하게 만들어. 전체적인 느낌은 정성 들인 픽셀 아트여야 해. 지저분한 노이즈가 아니라 깔끔한 픽셀 덩어리와 의도된 형태, 절제된 디테일로 승부해.
"완전 절차적(Fully Procedural)"의 실제 의미
전체 파이프라인은 이거야:
시드 + 게놈 + 생성기 버전 → 신체 설계도 → 해부학/리깅 → 포즈 → 픽셀 이미지
몸, 실루엣, 사지, 얼굴, 패턴, 팔레트, 표면 디테일, 움직임까지 전부 알고리즘으로 생성해.
미리 만들어둔 동물 스프라이트, 스프라이트 시트, 외부 캐릭터 모델, AI 생성 이미지, 종별로 미리 그려둔 픽셀 마스크 같은 건 절대 쓰지 마.
공유 파라미터 형태 모듈, 해부학 규칙, 팔레트 규칙, 데이터 기반 신체 설계도 프리셋은 써도 돼. '부모'는 생성 가능하고 수정할 수 있는 게놈 데이터여야 하지, 입력 이미지 파일이 아니야.
시드는 재현 가능해야 해. 명확하게 정의된 난수 알고리즘과 안정적인 시드 도출 방식을 써. 타임스탬프나 프로세스 의존적인 해시값에 기대지 마.
해부학, 색상, 패턴, 움직임은 각각 별도의 난수 스트림을 타야 해. 색깔 바꾼다고 해부학적 구조까지 다시 굴러가면 안 돼.
애니메이션 도중에도 패턴은 몸에 딱 붙어 있어야 하고, 디테일이 바뀌거나 다리 위치가 멋대로 바뀌면 안 돼.
부모의 돌연변이는 가족의 특징을 알아볼 수 있게 유지해야 해. 호환되는 부모끼리는 특징을 물려받을 수 있어야 하고. 말도 안 되는 조합은 명확한 해부학 규칙으로 막아. 호환 안 되는 설계도끼리 억지로 교배시킬 필요는 없어.
신체 구조, 질량 분포, 비율, 사지, 머리, 눈, 주둥이, 꼬리, 부속 기관, 재질감에서 확실한 차이를 보여줘. 색깔만 바꾸거나 원 몇 개 대충 붙여놓은 수준은 인정 안 해.
통합 시스템을 통한 신체 다양성
최소 8가지의 확실하게 구분되는 신체 설계도 패밀리를 구현해:
네 발 달린 포유류와 덩치 큰 짐승.
두 발로 걷는 인간형, 고블린, 트롤, 골렘.
긴 꼬리와 등 쪽 특징이 있는 파충류 및 드래곤류.
다리가 6~8개 달린 절지동물, 마디가 있고 집게가 달린 형태.
날개 구조가 잘 보이고 날갯짓 애니메이션이 있는 비행 생물.
뱀, 벌레 같은 다리 없는 긴 생물.
지느러미가 있고 헤엄치는 동작을 하는 수중 생물.
슬라임 같은 부정형 생물이나 촉수가 달린 말랑말랑한 생물.
식물형 생명체나 다른 판타지 형태들도 같은 확장 지점을 통해 구현할 수 있어야 함. 각 종(Family)은 서로 다른 뼈대(rig)와 이동 모듈을 조합할 수 있어야 하고, 4족 보행 골격 하나만 강요하지 마라. 그렇다고 생성기 8개를 그냥 복붙해서 내놓지는 마라. 형태 구성, 픽셀 래스터화, 팔레트, 유전학, 공유 이동 요소는 중앙에서 통합 관리해야 한다.
종별로 구조적 차이가 확실히 드러나는 저장된 샘플 게놈을 최소 6개씩 제공해라. 이 샘플들은 생성기에서 나온 결과물이어야 하며, 임의의 시드 값을 넣어도 제대로 작동해야 한다.
픽셀 아트 렌더링 및 애니메이션
캐릭터는 대략 64~128 논리 픽셀 정도로 스케일링하고, 크거나 긴 생명체는 바운딩 박스를 적절히 키워라. 네이티브 해상도와 정수 배율을 사용하고, 필터링은 nearest-neighbor 방식을 써라. 생명체와 배경은 픽셀 밀도를 통일해야 하지만, 워크숍 UI는 따로 깔끔하고 읽기 편한 해상도로 돌려도 된다.
생명체 하나당 8~16색 정도의 제한된 팔레트를 사용하고, 재질과 그림자 역할을 논리적으로 구분해라. 흐릿한 경계선, 제멋대로인 디더링, 계속 깜빡이는 1픽셀 노이즈, 눈에 띄게 겹치는 원이나 사각형 도형은 쓰지 마라. 관절 연결부는 매끄러워야 하고, 내부 외곽선이나 앞뒤 팔다리의 깊이 정렬도 정확해야 한다.
공유 뼈대와 결정론적 래스터화를 지원하는 적절한 2D/2.5D 방식을 골라라. 파라메트릭 외곽선, 분절된 부속지, 표면 마스크, 그리고 포즈를 잡은 뒤 저해상도 그리드에 매핑하는 신체 고정형 색상 역할 방식이 가장 기본적이고 탄탄한 해결책이다. 선택한 방식이 시각적 품질과 실행 비용 면에서 왜 좋은지 근거를 대라. 통합 픽셀 그리드에 래스터화해야지, 그냥 미리 만들어둔 픽셀 이미지를 부드럽게 회전시키는 식으로 때우지 마라.
애니메이션은 형태, 상태, 속도, 시간을 기반으로 계산해라. 필수 상태는 다음과 같다.
숨쉬기, 눈 깜빡임, 미세한 부차적 움직임이 포함된 대기(Idle) 상태.
해부학적 구조에 맞춘 느린 이동과 빠른 이동: 걷기, 기어가기, 미끄러지기, 헤엄치기, 날기, 뛰기 등.
물기, 때리기, 포효하기, 낚아채기 같은 표현력 있는 동작.
피격 반응과 부드러운 전환이 가능한 대기/수면 상태.
꼬리, 귀, 날개, 부드러운 부속지의 후속 동작(follow-through); 해부학적으로 가능한 경우 의도적인 스쿼시 앤 스트레치(squash and stretch).
다리는 확실한 디딤과 휘두름 단계, 관절 제한, 안정적인 지면 접촉(예: 간단한 IK 사용)이 필요하다. 발이 미끄러지는 꼴은 보지 않게 해라. 이동 속도, 보폭, 체구는 서로 딱 맞아야 한다. 몸 전체에 단순한 사인파 하나 넣는 걸로는 애니메이션이라고 할 수 없다.
적절한 가림 처리를 포함해 최소 4방향의 정면/이동 방향을 지원해라. 완성된 스프라이트 전체를 돌리는 건 방향성 렌더링의 대체재가 될 수 없다. 시뮬레이션 시간과 픽셀 래스터화는 분리되어야 하며, 렌더링 프레임 레이트가 변해도 움직임이 똑같아야 하고, 일시 정지, 프레임 단위 넘기기, 슬로우 모션도 지원해야 한다. 절차적으로 생성된 프레임 캐시는 허용하지만, 실시간으로 파라미터 조절이 가능한 생성 방식을 대체해서는 안 된다.
사용 가능한 워크숍 및 테스트 환경
실행 가능한 메인 화면에는 다음이 포함되어야 한다.
애니메이션이 적용된 대형 미리보기 창, 중립 및 풍경 배경, 픽셀 줌 컨트롤.
시드 입력 필드, 신체 계획 선택, "새 생명체(New Creature)" 버튼.
해부학, 팔레트, 패턴, 이동 파라미터를 수정할 수 있고 실시간으로 결과가 보여야 하며, 합리적인 값 범위, 실행 취소/다시 실행, 저장된 상태로 초기화 기능.
잠금 기능을 통해 잠기지 않은 부분만 재생성할 수 있게 할 것.
"부모 + 자식 4마리": 애니메이션이 적용된 돌연변이 4마리를 나란히 보여주고, 돌연변이 강도를 조절하며, 자식 중 하나를 새로운 부모로 채택하는 버튼.
호환되는 부모 2마리를 선택해 자식과 비교하는 기능.
애니메이션 상태, 방향, 속도, 일시 정지, 프레임 넘기기, 그리고 선택적으로 뼈대/접촉 지점을 시각화하는 토글.
버전이 관리되는 JSON 프리셋 저장/불러오기 기능은 물론이고, PNG 및 절차적으로 생성된 스프라이트 시트 내보내기 기능도 넣어야 함. 내보낸 메타데이터에는 프레임 크기, 원점, 방향, 상태, 타이밍 정보가 반드시 포함되어야 하고, 부속물이 잘려 나가는 일은 없어야 함.
샘플 게놈 갤러리와 조종 가능한 생명체, 그리고 다른 애니메이션 캐릭터들이 돌아다니는 작은 테스트 구역을 마련할 것.
지형, 그림자, 최소한의 환경 디테일도 절차적으로 생성해. 생명체의 퀄리티와 움직임 구현에 힘을 쏟아. 완성된 게임이나 전투 시스템, 지형 생성기까지 만들 필요는 없음. 버튼 하나하나에 전부 실제 작동하는 로직을 연결해야 함.
아키텍처 및 런타임 성능
게놈/검증, 해부학 구조, 리그/포즈, 픽셀 렌더러, 런타임 액터, 워크숍 인터페이스, 내보내기 기능을 각각 분리해. 프레임워크를 addons/procedural_creatures/와 같이 깔끔하게 분리된 재사용 가능한 모듈로 구성할 것. 워크숍은 이 공개 API를 사용하는 소비자 역할만 하면 됨. 미리보기, 자손 비교, 갤러리, 테스트 씬, 내보내기 기능에서 똑같은 생명체 구현을 사용해야 함. 수정 사항은 어디서든 즉시 반영되어야 함.
프로젝트 상대 경로만 사용하고, 사용자 데이터는 무조건 user://에 저장해. 게놈, 상태, 이동 방향, 속도를 제어할 수 있는 깔끔한 API를 갖춘 인스턴스화 가능한 CreatureActor 씬을 제공해서, 다른 고도(Godot) 프로젝트에 바로 갖다 쓸 수 있게 만들어.
신체 구조, 형태 모듈, 재질/팔레트 규칙, 이동 모듈에 대한 확장 지점을 문서화해. 특정 종을 위한 예외 처리를 코어에 직접 박아넣지 말고, 이 확장 지점을 활용해서 추가적인 생명체군을 구현해 보여줘. 워크숍 의존성 없이 프레임워크를 실행하는 최소한의 통합 예제도 제공할 것.
게놈과 프리셋 형식은 버전을 관리해. 입력을 검증하고, 의미 있는 에러 메시지를 띄우고, 알 수 없는 버전은 명확하게 처리해. 나중에 스키마가 바뀌더라도 마이그레이션 경로가 확실해야 함. 랜덤 생성과 시뮬레이션 시간은 UI나 렌더링 프레임 레이트와 독립적으로 돌아가게 해.
비동기 생성은 취소 가능해야 하고, 슬라이더를 빠르게 조절할 때처럼 결과값이 쓸모없어지면 확실하게 폐기해야 함. 리소스 생성 및 게시 시 고도의 스레딩 제한을 준수해. 액터를 반복적으로 생성, 수정, 삭제하면서 메모리 누수가 없는지 테스트해. 캐시 크기를 제한하고 게놈, 생성기 버전, 렌더링 품질 설정이 변경되면 캐시를 제대로 무효화해.
게놈이 바뀌면 해부학 구조와 불변하는 디테일을 다시 빌드해. 포즈와 필요한 렌더링은 프레임마다 업데이트하고. 게놈 전체를 매번 다시 생성하거나, 캐시를 무한정 늘리거나, 프레임마다 씬을 새로 인스턴스화하는 짓은 하지 마. 픽셀 버퍼, 텍스처 업데이트, 할당, 드로우 콜을 제한하고, 최적화하기 전에 먼저 측정부터 해.
생명체 1마리, 25마리, 100마리가 각각 고유하게 움직이는 환경에서 테스트해. 일반적인 데스크톱 환경에서 수십 마리가 화면에 보여도 60 FPS가 부드럽게 유지되어야 함. 하드웨어, 렌더러, 해상도, 애니메이션 속도를 포함한 실제 측정치를 보고해. 클라우드 환경에서의 소프트웨어 렌더링은 데스크톱 하드웨어에서의 성능을 증명하는 근거가 안 됨.
콜드 생성(cold generation), 웜 캐시(warm caches), 활성 애니메이션, 래스터화, 텍스처 전송을 각각 따로 측정해. 단순히 평균 FPS만 적지 말고, 프레임 타임의 상위 백분위수, 메모리 점유율, 할당량을 보고해. 생명체의 정체성, 실루엣, 고유한 움직임이 유지되고 그 효과가 문서화된다면 품질 단계별 차등 적용이나 가시성 기반 업데이트는 허용함.
클라우드 환경에서의 작업
먼저 리포지토리, OS, 고도 .NET 바이너리, .NET SDK, 사용 가능한 렌더링/이미지 도구를 확인해. 환경이 허용하는 범위 내에서 공식 소스를 통해 누락된 도구를 재현 가능하게 설치해. 로컬 윈도우 경로를 가정하지 마. 버전과 설치 명령어를 문서화해.
지정된 저장소 안에 독립형 프로젝트를 만들어라. 만약 이미 다른 프로젝트가 있다면 전용 하위 디렉토리를 사용해라. project.godot, C# 프로젝트 파일, 메인 씬, 소스 코드, 샘플 데이터, README, 그리고 리눅스와 윈도우용 실행/테스트 스크립트를 전부 포함해서 넘겨라. 필요한 의존성 파일들은 버전을 고정해라. 최종 사용자가 빠진 씬을 일일이 조립하게 만들지 마라.
빌드, 리소스 임포트, 런타임 시작을 검증해라. godot --headless --path . --import 같은 Godot 명령어는 반드시 실제 .NET 바이너리를 사용해서 실행해야 한다. 커스텀 결정론적 테스트 모드를 구현해라. 예를 들어 godot --headless --path . -- --self-test 처럼 실행하면 구조화된 보고서를 반환하고, 실패 시 0이 아닌 종료 코드를 뱉어야 한다. --self-test는 내장 플래그가 아니라 네가 구현할 프로젝트 플래그다.
시각적 이미지 검증을 수행해라. 게임 내 CPU 픽셀 렌더러를 쓰든, 소프트웨어 렌더링이나 가상 디스플레이를 지원하는 Godot을 쓰든 상관없다. 헤드리스 모드로 켜진다고 해서 렌더링이 제대로 된다는 보장은 없다. 기술적으로 가능하다면 실제 Godot 인터페이스 렌더링 결과물과 애니메이션 샘플을 캡처해라. 환경 제약 때문에 테스트하지 못한 부분은 명확히 문서화하고, 로컬에서 직접 검증할 수 있는 단계를 제공해라. 스크린샷, 테스트 성공 기록, 성능 수치를 조작하지 마라.
인수 기준 및 방법론
먼저 게놈, 고품질 캐릭터, 애니메이션, Godot 상호작용을 모두 포함하는 완전한 엔드투엔드 슬라이스를 만들어라. 모든 신체 계열로 확장하기 전에 시각적으로 검사하고 다듬어라. 이 초기 엔드투엔드 슬라이스가 핵심 마일스톤이다. 여기서부터 개발을 계속해서 최종 인수까지 진행해라.
인수 요건은 다음과 같다:
새로 체크아웃한 프로젝트가 문서화된 필수 요건을 통해 빌드되고 실행되어야 한다.
동일한 시드/게놈 + 생성기 버전은 동일한 해부학적 구조를 생성해야 하며, 동일한 상태와 시뮬레이션 타임라인은 동일한 포즈를 재현해야 한다. 일치하는 렌더 파이프라인을 통해 이미지의 결정론적 결과를 검증해라.
최소 8개의 신체 계열과 48개의 샘플 게놈을 포함해야 한다. 추가로 계열당 최소 100개의 시드를 테스트하여 유효한 해부학적 구조, 유한한 값, 안전한 이미지 범위를 확인해라.
저장/불러오기, 매개변수 조정, 기능 잠금, 돌연변이, 유전 기능이 예측 가능한 대로 작동해야 한다.
짧거나 긴 팔다리, 그 외 허용된 극단적인 값에서도 움직임과 방향 전환이 제대로 작동해야 한다.
라벨이 붙은 연락처 개요에 모든 계열과 변형이 비교 가능한 뷰로 표시되어야 하며, 애니메이션 샘플이 다양한 이동 방식을 실제로 보여줘야 한다.
PNG/스프라이트시트 내보내기는 라이브 미리보기와 정확히 동일한 파이프라인에서 생성되어야 하며, 메타데이터에 따라 정확하게 재생되어야 한다.
실루엣, 관절 연결, 가려짐, 발 접지, 깜빡임, 세부 사항, 계열 간 유사성을 시각적으로 검사해라. 구조적 단위 테스트만으로는 고품질 픽셀 아트를 증명할 수 없다.
최종 요약 보고서에는 실행 명령어, 컨트롤, 아키텍처, 확장 포인트, 실행된 테스트, 그리고 실제로 남아있는 한계점이 나열되어야 한다.
독립형 통합 예제는 워크숍 의존성 없이 공개 프레임워크 API를 보여줘야 한다. 확장은 문서화된 인터페이스를 활용한다.
반복적인 생성 및 씬 교체, 취소된 작업, 빠른 매개변수 조정, 유효하지 않은 프리셋을 테스트해라. 충돌 및 지속적인 메모리 증가를 포함하는 재현 가능한 스트레스 테스트를 문서화해라.
품질 보고서는 각 신체 계열의 실루엣, 디자인 내 해부학적 타당성, 픽셀 구현, 표현력, 애니메이션 품질, 전환 효과를 평가한다. 여기에는 엄선된 예제와 함께 수정되지 않은 무작위 시드 샘플이 포함되어야 한다. 눈에 띄는 약점은 승인 전에 반드시 수정해라. 단순히 잘 나온 시드 몇 개만 보여주는 것으로는 생성기의 품질을 입증할 수 없다.
표준 기술 결정은 독립적으로 내리고 독일어로 소통해라. 이전 대화 기록 없이도 작업이 매끄럽게 이어질 수 있도록 저장소 내에 진행 상황과 미해결 과제를 문서화해라. 구현되고 검증된 코드를 넘겨라. 계획이나 자리표시자, 혹은 그럴싸한 데모 하나에서 멈추지 마라.
모든 결정의 핵심 원칙: 우리는 최고 수준의 예술적, 기술적 기준을 충족하는 실무용 절차적 크리처 및 애니메이션 프레임워크를 구축한다. 결과물이 이 작업의 요구 사항을 완벽하게 충족할 때까지 계속해서 다듬고, 테스트하고, 완성도를 높여라.
주요 댓글
r/claudeai
기술적인 성취에 대한 감탄과 AI 생성 예술의 공허함에 대한 비판적 시각이 공존함.
3
웃긴 건... 이 4분짜리 영상에 나오는 크리처 수가 디아블로 4 전체보다 많다는 거임.
1
참고해야겠네 (말하자면, 난 디아블로를 한 번도 안 해봤거든).
-1
맞는 말이지만, 사람이 만든 스프라이트에는 생명력이 느껴짐. 이건 그냥 무작위 크리처 생성기처럼 느껴짐. 전부 다. 만약 게임에 들어간다면 뭔가 어색하고 공허한 느낌이 들 텐데, 정확히 뭐가 문제인지는 아마 모를 거야.
물론 이게 전부 생성된 거라는 걸 알게 되는 순간, 그 게임이 얼마나 공허하고 텅 비어있는지 바로 드러나겠지.
인간이 만든 예술에는 특별한 무언가가 있음. 이건 Claude가 뭘 만들 수 있는지 보여주는 멋진 연습이긴 하지만, 결국 알맹이는 없어.