dotgimon 제작기 06. 몬스터 아트 교체 범위와 제작 기준

표기 날짜는 작업 순서에 맞춰 배치한 날짜다. 실제 작업일은 확인되지 않으며, 관련 변경은 9월 30일에 저장소에 한꺼번에 남았다.

dotgimon의 초기 몬스터는 16×16 문자열 도트맵이었다. #과 공백으로 그린 그림을 두 배로 확대해 LCD에 올렸다. 많은 종을 같은 방식으로 만들 수 있었지만 작은 눈과 입, 팔다리의 특징을 구분할 수 있는 칸은 적었다.

기존 외형을 전부 새로 만드는 것으로 범위를 정했다. 그렇다고 종 ID나 진화 조건까지 바꾸는 작업은 아니었다. 이미 게임에 연결된 자리는 유지하고, 그 자리를 차지하는 그림을 다시 만드는 쪽이었다.

그림을 바꾸면 저장 데이터까지 흔들릴 수 있었다

몬스터 한 종에는 이미지 외에도 이름과 ID, 단계와 속성, 진화 연결, 합체 조합이 붙어 있었다. 도감과 생애 기록도 종 ID를 저장했다. 그림을 그리다가 ID를 바꾸면 저장 파서가 옛 ID를 모르는 종으로 거부할 수 있었다.

진화 연결을 그림에 맞춰 바꾸면 게임 기획도 달라졌다. 속성과 상성은 대전 결과에 쓰이므로 외형 작업 중에 손댈 값이 아니었다. 기존 87종의 자리에 새 외형을 연결하되, 이름과 단계, 여섯 시작 버전, 일반 진화 연결과 합체 페어를 유지하는 기준을 세웠다.

교체 전에 작업물은 프로젝트 밖의 복구용 폴더에 보관했다. 저장소에서는 옛 GIF와 16px 원본, 실험용 리소스와 생성 스크립트를 정리하되 복구 경로를 카탈로그에 남겼다. 새 방식으로 옮기는 동안 옛 원본까지 함께 잃지 않기 위한 순서였다.

게임 규칙과 아트 목록을 같은 원본으로 취급하지 않았다

아트 카탈로그에는 종 ID와 단계, 속성, 계통, 진화 연결을 복사했다. 제작할 그림을 정리하려면 이런 정보가 필요했다. 하지만 실제 게임 규칙의 원본은 dex.ts와 link.ts에 두었다.

카탈로그에 복사된 값만 보고 게임 데이터를 바꾸지 않도록 역할을 나눴다. 빌드할 때는 카탈로그의 종 ID 집합과 단계·속성을 실제 도감과 비교했다. 새 그림이 잘 만들어져도 다른 종의 자리에 들어가면 실패로 처리했다.

규칙 파일 다섯 개의 SHA-256도 카탈로그에 기록했다. 해시는 파일 내용이 바뀌었는지 비교할 수 있는 값이지만, 이를 자동으로 비교하는 검사는 없었다. 9월 30일 저장소에서 dex.ts·link.ts·constants.ts는 기록된 해시와 같았고, engine.ts·useGame.ts는 달랐다. 해시를 남긴 것만으로 모든 규칙 파일이 그대로라고 볼 수는 없었다.

원화에는 진화 전후의 공통 특징을 남겼다

새 외형은 종별로 독립된 원화부터 만들었다. 화염·공룡, 냉기·야수 같은 계통을 구별하고 진화 단계가 오를수록 몸의 특징을 더하는 방향이었다. 한 계통이라는 이유로 실루엣이 모두 같아지는 것도 피하려 했다.

예를 들어 Fangcub은 냉기·야수 계통의 어린 몬스터였다. 원화 지시에는 넓은 초승달 모양의 얼음 목깃과 곧게 선 꼬리를 주요 특징으로 적었다. 길쭉한 여우나 성체 늑대, 갑옷 기사처럼 바뀌지 않게 제외할 형태도 함께 적었다.

참고 시안에는 A~I 같은 기호를 붙였지만, 이 기호를 새 전투 속성이나 시작 버전으로 사용하지는 않았다. 외형을 고르는 기준과 게임의 속성 분류가 섞이지 않도록 했다. 종별 프롬프트에도 어떤 시안의 방향을 이어받는지 남겼다.

생성한 원화는 종별 폴더의 concept.png에 두고 실제 프롬프트도 같은 리비전 폴더에 보관했다. 그림만 남으면 왜 그 형태가 나왔는지 다시 확인하기 어려웠다. 재시도할 때도 원래 지시와 바꾼 지시를 구별할 수 있게 했다.

자동 변환 결과를 완성본으로 부르지 않았다

원화를 32×32 흑백 도트로 바꾸고 필요한 부분을 손으로 고치는 두 단계를 나눴다. 자동 변환은 초안을 만드는 역할이었다. 형태가 맞는지와 LCD에서 읽히는지는 별도로 판단했다.

수동 보정본은 재생성할 때도 덮어쓰지 않았다. 종 폴더에 pixels.txt가 있으면 자동 변환보다 우선하도록 정했다. 같은 원화를 다시 빌드해도 사람이 고친 눈이나 테두리가 사라지지 않는 구조였다.

생성 성공과 사용자 승인도 다른 상태로 두었다. 이미지가 파일로 생겼다는 것만으로 화면에서 보기 좋다는 뜻은 아니었다. 자동 검사 통과, 도트 보정 파일의 존재, 실제 화면 검수는 각각 다른 사실이었다.

생성 실패도 종별로 남겼다

이미지 생성은 모든 요청에서 성공하지 않았다. 출력 단계의 안전 필터에 막힌 경우에는 프롬프트를 단순하게 바꿔 다시 시도했다. 단순 도형이나 평면적인 형태를 강조한 지시도 별도 파일에 남겼다.

실패 응답은 attempts 아래 JSON으로 보관했다. 원화가 없는 종을 집계할 때는 실패한 요청 횟수를 그대로 더하지 않았다. 한 종에서 여러 번 실패해도 미완성 종은 하나이고, 재시도에 성공하면 실패 목록에서 빠지는 방식이었다.

진행 집계는 실제 concept.png의 존재를 우선했다. 이미지가 있으면 성공, 없고 마지막 결과가 실패면 실패, 그 밖에는 미제작으로 분류했다. 요청은 성공했다고 나왔는데 정작 파일이 없는 경우를 제작 완료로 세지 않으려 했다.

교체 완료의 기준을 파일 생성과 분리했다

완료 기준에는 원화와 32px 도트, 알 이미지가 모두 있는지와 옛 원본 참조가 남지 않았는지를 넣었다. 누락된 에셋이 있으면 엄격한 빌드 검사에서 실패하게 하고, 타입과 게임 회귀 테스트도 따로 확인하도록 했다. 그림을 바꿔도 종을 읽거나 진화시키는 코드가 그대로 작동하는지 보기 위해서였다.

육안 검수는 그 검사들과 분리했다. 파일이 있고 크기와 색상이 맞아도 몬스터끼리 구별되지 않을 수 있었다. 자동으로 만들 수 있는 것은 도트 초안까지로 두고, 화면에서 형태를 판단하는 단계를 완료와 섞지 않았다.

이 교체에서는 종 ID를 유지했으므로 그림 때문에 저장 데이터와 도감 기록을 옮기는 작업은 만들지 않았다. 외형은 새로 만들되 게임 규칙의 원본은 그대로 두고, 아트 목록은 그 규칙을 따라가는 사본으로 정리했다.