제작할 때의 공통 규칙, 용도별 규칙, 캐릭터별 설정, 그리고 과거 제작 기록을 분리했습니다.
다음 작품을 만들 때 저 자신과 AI 모두 필요한 부분을 찾아볼 수 있도록 하고 싶었기 때문입니다.
계기는 게임 이미지였는데, 어느새 문제나 스토리, 저장, 리뷰 과정까지 정리하게 되었습니다.
단지 이미지만 모으고 싶었는데 이야기가 꽤 커졌습니다....
그래서 순서대로 작성하겠습니다.
저는 코딩 지식을 배우는 RPG인 "CodeChronicle"을 취미로 만들고 있습니다.
FF6나 SFC 시대의 RPG UI와 UX를 좋아해서, 그런 분위기의 게임으로 만들고 싶습니다.
개발하는 시간은 매일 1시간마다 갖는 5분 휴식 시간입니다.
Orca를 이용해 AI 담당을 나누어 병렬로 작업할 때도 있습니다.
다만, 담당이 바뀔 때마다 이전에 무엇을 결정했는지 설명해야 합니다.
'이전 이미지는 어떻게 만든 거지??'
'저 캐릭터는 대화할 때도 같은 이미지였나??'
이런 것들을 매번 대화 속에서 찾아내는 것은 힘든 일입니다.
다음 5분 동안 개발을 시작하는 저 자신에게도 이해하기 쉽게 해두고 싶습니다.
그런 이야기입니다.
처음에는 샘(泉)과 문(扉)의 이미지가 신경 쓰였습니다.
다른 소재들은 세밀하게 그려져 있는데, 그 부분만 간이적인 SVG로 되어 있었습니다.
같은 게임에 배치되어 있음에도 다른 세계에서 온 것처럼 보였거든요....
미스터리 기사도 마찬가지였습니다.
맵에서는 PNG 형식의 기사가 표시되는데, 대화할 때는 32×40 크기의 간이 SVG가 표시됩니다.
맵에서 본 그 기사는 어디로 갔을까요??
확인해 보니, 맵과 대화에서 다른 렌더링 경로가 남아 있었습니다.
즉, 이미지를 한 장 확인하고 끝낼 수는 없다는 것입니다.
같은 기사라도 어디에 표시되는지까지 확인해야 하는 것이죠....
그리고 PNG로 하면 모든 것이 통일된다는 이야기도 아닙니다.
묘사나 색상, 실제로 게임 내에서 표시될 크기까지 다른 소재와 맞추어야 했습니다.
이미지를 만들 때의 지시사항은 남아 있었습니다.
다만, 남겨진 방식이 '주인공 보행', '기사의 초상'처럼 만든 대상별로 나뉘어 있었습니다.
주인공을 걷게 하기 위해 생각한 것은 다른 인물을 걷게 할 때도 사용하고 싶습니다.
기사의 대화 이미지를 만들기 위해 생각한 것도 다른 캐릭터에 쓰고 싶습니다.
하지만 그대로 사용하면 주인공의 머리색이나 기사의 투구까지 따라옵니다.
그 부분은 계승할 필요가 없습니다....
공통으로 사용할 수 있는 부분과 그 캐릭터만의 특징이 섞여 있었습니다.
그렇다면 '주인공 보행'에서 '보행'의 규칙을 추출하면 될 것 같습니다.
'기사의 대화 이미지'도 '캐릭터 대화용 이미지'로 만듭니다.
여기에 이번에 만들 캐릭터의 특징을 추가하기로 했습니다.
지금은 이런 조합으로 제작 지시를 만듭니다.
모두가 지켜야 할 공통 규칙
＋ 무엇에 사용할 것인지에 대한 규칙
＋ 이번에 만들 대상의 설정
...
예를 들어, 기사의 대화용 이미지라면 이렇습니다.
공통 규칙에는 기존 소재와 그림체나 묘사를 맞추는 것이 포함됩니다.
대화용 이미지 규칙에는 머리나 어깨를 프레임에 담기, 그리고 PC와 스마트폰의 대화 화면에서 확인하는 것 등이 있습니다.
기사의 설정에는 닫힌 투구, 얼굴을 가리는 검은 바이저, 보라색 망토 등이 포함됩니다.
다른 캐릭터를 만든다면, 이 기사의 설정을 대체합니다.
모두에게 투구를 씌우고 싶은 건 아니니까요....
보행 역시 방향을 구분하는 것과 발밑을 맞추는 것은 공통으로 합니다.
주인공의 청흑색 머리나 푸른 의상은 주인공 설정에 둡니다.
다만, 주인공이 4방향 × 3컷이라고 해서 네발 동물이나 날아다니는 생물에게도 같은 형태를 요구하는 것은 아닌 것 같습니다.
모든 것을 똑같이 할 필요가 없는 것이죠.
용도의 규칙은 대화용 이미지, 맵용 이미지, 보행, 공격/전투 표현, 환경 소재, 상태 차이분, 배경의 7가지로 나누었습니다.
NPC를 추가한다면, 이미지만 만들고 끝낼 수 없습니다.
어디에 배치할지, 무엇을 말하게 할지, 언제 등장할지. 저장(보존)은 어떻게 할지 등도 필요합니다.
학습 문제 역시 문제문뿐만이 아니라 채점이나 출제되는 장소, 복습 기록까지 관련됩니다.
이미지로 했던 정리를 앱 전체에서도 하고 싶습니다.
여기부터는 원탁 리뷰(round table review)를 통해 벽을 두드리며 논의했습니다.
긍정파, 중립파, 부정파, 사용자 대변자라는 4가지 시점에서 생각해 보았고, 저 자신도 함께 검토했습니다.
게다가 질문으로 전제를 깊이 파헤치는 grilling 과정을 거치면서, 분류가 충분한지, 공통화했다고 생각하는 부분이 없는지를 점검했습니다.
그 결과, 제작의 진입점을 9개 장르로 나누기로 했습니다.
⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.
| 장르 | 예시 |
|---|
| 세계/장소 | 지형, 건물, 마을, 출입구 |
| ... | |
| 여기서 모든 것을 폴더의 부모-자식 관계(parent-child relationship)로 만드는 것은 포기했습니다. | |
예를 들어 '동굴에 있는 닫힌 문 이미지'.
동굴은 장소이고, 문은 대상이며, 닫혀 있다는 것은 상태이고, 이미지는 매체입니다.
이 모든 것을 한 줄로 나열하려고 하면, 다른 장소의 문과 공통으로 하고 싶은 부분이 눈에 잘 들어오지 않습니다.
그래서 큰 분류는 하나로 두고, 장소나 용도, 상태 등은 분리해서 생각하기로 했습니다.
제작의 진입점(entry point)은 docs/production/index.md에 두었습니다.
여기서부터 각 장르별 안내, 용도의 규칙, 인물 설정을 거쳐 나갈 수 있도록 구성했습니다.
다만, 문서를 늘리게 되면 '같은 내용이 여기저기 반복되는' 문제가 발생합니다.
한쪽만 수정하면 어느 쪽이 맞는 건지 헷갈릴 수 있습니다....
그래서 정보별로 관리하는 장소를 정했습니다.
작업 진행 방식은 Skill입니다.
여기서 말하는 Skill이란, AI에게 반복적으로 전달할 작업 절차나 판단 기준을 정리한 문서입니다.
제작 시의 규칙은 공통 사양(Common Specification)과 용도별 사양(Usage Specification)으로 나눕니다. 캐릭터의 특징은 개별 설정으로 합니다.
실제로 작동하는 값은 코드(Code)로 합니다. 과거에 무엇을 만들었는지는 이력(History)입니다.
예를 들어, 이미지 잘라내기 좌표(cropping coordinates)를 코드와 문서 양쪽에 모두 적어버리면 업데이트가 어긋나게 됩니다.
그래서 문서에는 코드를 참조하는 위치만 두고, 현재의 수치는 코드를 참고하도록 했습니다.
문제 생성에는 원래 question-author라는 Skill이 있기 때문에, 채점이나 입력의 공정성 규칙은 그쪽을 참조합니다.
혹시라도 정리하다가 같은 규칙을 또 만들게 되면 큰일나니까요.
그리고 과거 '주인공의 보행'과 같은 제작 기록은 이름 그대로 남겨두었습니다.
당시 주인공을 위해 만들어진 사실 자체를 바꿀 필요는 없기 때문입니다.
앞으로도 사용할 규칙을 꺼내 쓰는 것과, 과거 기록을 덮어쓰는 것은 별개로 두었습니다.
AI를 위한 진입점으로는 project-guide라는 Skill을 만들었습니다.
무엇을 만들지 확인하고, 필요한 규칙, 개별 설정, 구현할 위치, 확인 방법으로 나아갈 수 있는 절차입니다.
이미지를 만들 거라면 game-art로, 문제를 만들 거라면 question-author로 연결합니다.
모든 것을 읽어보라고 하면 분량 자체가 늘어나기 때문에, 그 작업에 필요한 것만 선택적으로 가져옵니다.
병렬적으로 담당을 나눌 때도, 건드려야 할 파일과 참조해야 할 규칙을 세트로 전달하는 형태입니다.
리뷰(Review) 절차 역시 Skill로 만들었습니다.
구현한 담당자와는 별도의 2개의 에이전트가 각각 동일한 버전을 확인하게 합니다. 첫 결과가 나오면, 서로의 지적 사항을 확인합니다. 상대방의 지적을 지지하는지, 반증할 수 있는지, 아직 미확인인지 등을 근거와 함께 돌려받고, 부모 담당자가 정리합니다. 상호 검토는 최대 2회 왕복입니다.
스스로 만들고 스스로 검토하는 것과, 다른 담당자가 보는 것을 분리하고 싶었기 때문입니다.
이번 정리 역시 독립된 2명의 인원이 확인하며 서로의 지적을 검증했습니다.
파일 목록은 기존 docs/architecture/file-inventory.json를 사용하고, 대상 파일을 총 9개 장르로 분류했습니다.
분류 누락이나 업데이트 누락, 제작 안내와 Skill 간의 링크 끊김(broken link)은 스크립트로 확인하도록 했습니다.
물론 이것만으로 게임의 시각적인 부분까지 확인할 수는 없기 때문에, 이미지는 실제 화면에서, 동작은 관련된 테스트를 통해 확인합니다.
여기까지 정리했지만, 설정을 하나 넣는다고 해서 무엇이든 추가할 수 있는 상태가 된 것은 아닙니다. 주인공의 보행이나 기사(Knight) 표시에는 전용 구현이 남아 있습니다.
소리를 추가하는 확인 절차를 두는 것과, BGM을 재생하는 기능을 만드는 것은 별개입니다.
이번에는 우선 제작 규칙을 정리했습니다.
실행 코드 전체를 재조립하는 것은 다른 단계로 두고, 규칙만 있는지, 설정으로 추가 가능한지, 전용 구현이 필요한지, 미지원(unsupported)인지도 구분하여 작성하고 있습니다.
기존 ID, 이미지 잘라내기 좌표, 채점 방식, 저장 형식 등도 분류를 맞추기 위해 변경하지 않았습니다.
다음번에 무언가를 만들 때는, 진입점에서 필요한 규칙과 설정을 따라가서 어디에 추가해야 하고 무엇을 확인해야 하는지 찾아볼 수 있게 됩니다.
이렇게 공통적인 부분과 개별적인 부분을 나누어 가는 것은 즐겁습니다.
게임을 만들고 싶은데, 만드는 구조를 생각하는 것도 재미있네요....
CodeChronicle은 모험하며 코드를 배울 수 있는 RPG로 키워나가고 싶습니다.
그 다음 이야기를 만들어갈 미래의 자신과 AI에게, 이번에 결정한 것들을 전달할 수 있도록 준비해 두었습니다.
리포지토리: CodeChronicle
![[프로그래밍 학습 X RPG 기획] 제1화 개발을 위해 구조화한 이야기 대표 이미지](/api/thumb?u=https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.1.1%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFwLW5vcnRoZWFzdC0xLmFtYXpvbmF3cy5jb20lMkYwJTJGNDE1NTI4MSUyRnByb2ZpbGUtaW1hZ2VzJTJGMTc4OTEwNzgyMD9peGxpYj1yYi00LjEuMSZhcj0xJTNBMSZmaXQ9Y3JvcCZtYXNrPWVsbGlwc2UmYmc9RkZGRkZGJmZtPXBuZzMyJnM9NzRlZmQzMWVlNmZmNjUwOGVjYmY5YWEwYjFlN2IxMDA%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253Dff30bd1a25b50c9bb694f2bfd72908a2%3Fixlib%3Drb-4.1.1%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjEuMSZ3PTk2MCZoPTMyNCZ0eHQ9JUUzJTgwJTkwJUUzJTgzJTk3JUUzJTgzJUFEJUUzJTgyJUIwJUUzJTgzJUE5JUUzJTgzJTlGJUUzJTgzJUIzJUUzJTgyJUIwJUU1JUFEJUE2JUU3JUJGJTkyeCUyMFJQRyVFOCVBOCU4OCVFNyU5NCVCQiVFMyU4MCU5MSVFNyVBQyVBQyVFNCVCOCU4MCVFOCVBOSVCMSVFMyU4MCU4MCVFOSU5NiU4QiVFNyU5OSVCQSVFMyU4MSVBRSVFMyU4MSU5RiVFMyU4MiU4MSVFMyU4MSVBQiVFNiVBNyU4QiVFOSU4MCVBMCVFNSU4QyU5NiVFMyU4MSU5NyVFMyU4MSU5RiVFOCVBOSVCMSZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMUUyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1wYWQ9MCZzPWZmYzlkZjZlNTI1MWRlYTAyMjQwOWEyMWQwZjliNjc5%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjEuMSZ3PTgzOCZoPTU4JnR4dD0lNDBtZXRhcHBpJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LXBhZD0wJnM9MDBjZTAzNGRmYmY2MWZlMDZiNTNlMjNjYzQxYmY4NWM%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3Dfb610b8bdca501e82af88a0e4ab28ec8&w=640&s=f3v2FnmS7LlBFyAcfIw8bSXs)