HOUSE DUCK · KOREAN ORIGINAL
프롬프트로 게임 캐릭터 디자인 하기 | House Duck 바이브코딩
AI에게 게임 캐릭터를 만들어달라고 하면
그럴듯한 그림 한 장은 꽤 빨리 나온다.
문제는 그다음이었다.
같은 인물을 다시 그려달라고 했는데 얼굴이 바뀌고,
표정을 바꾸니 옷까지 달라지고,
게임 화면에 줄여 넣으니 눈과 입이 한 덩어리가 됐다.
한 장만 보면 마음에 드는데
여러 장을 나란히 놓으면 같은 게임처럼 보이지 않는 일도 많았다.
예쁜 이미지를 뽑는 것과
게임 캐릭터를 만드는 것은 다른 일이었다.
프롬프트 한 번으로 마음에 드는 그림이 나와도
그 그림이 게임 안에서 계속 살아남는지는 별개의 문제였다.
Project K, Quirky Ball,
그리고 아직 게임명도 정하지 않은
차기작을 만들면서 배웠다.
한 장 잘 나온 그림이 가장 위험했다.
Project K의 초기 인물 그림은
지금 보면 생성형 이미지의 흔적이 아주 선명하다.

그림 한 장만 보면 캐릭터가 있어 보였다.
하지만 세계관의 특징을 빨리 보여주고 싶어서
비슷한 외형 조건을 반복해서 넣다 보니
지도자 후보들이 전부 비슷한 나이와 체형으로 모였다.

표정은 많아졌는데
이름을 가리면 누가 누구인지 바로 구분하기 어려웠다.
그래서 인물 수를 늘리는 대신
얼굴형, 체형, 머리 모양과 복장 실루엣을
먼저 벌리는 쪽으로 바꿨다.

자동 검사도 많이 통과했고
이미지 크기와 파일 규격도 맞았다.
그런데 실제 모바일 화면에 넣어보니
머리카락과 옷 주름, 광택 같은 잔묘사가 남았고
게임의 픽셀 화면과 따로 노는 느낌이 났다.

파일이 정상이라고 그림까지 좋은 것은 아니었다.
결국 Project K는 픽셀 필터를 더 세게 거는 방향도 버리고
한 명의 3D 원본을 먼저 제대로 만든 뒤
그 원본에서 초상, 프로필과 카드 이미지를 뽑는 쪽으로 다시 잡았다.

위 그림도 최종 게임 에셋은 아니다.
현재 승인된 인물 방향판에 가깝고
실제 게임에 넣을 3D 원본은 아직 만드는 중이다.
마음에 드는 방향을 찾았다고
완성된 것처럼 말하지 않는 것도 꽤 중요했다.
프롬프트를 감상평이 아니라 제작 지시서처럼 바꿨다.
처음에는 멋진, 고급스러운, 영화 같은 식의
형용사를 많이 넣으면 좋아질 거라고 생각했다.
지금은 반대로 쓴다.
이 캐릭터가 무슨 역할인지,
화면에서 어느 크기로 보이는지,
무엇이 바뀌면 안 되는지를 먼저 적는다.
역할: 모바일 화면에서 바로 읽히는 지도자
구분: 얼굴형·체형·머리·긴 코트 실루엣
고정: 같은 인물의 정면·측면·후면, 같은 복장과 대표색
명암: 기본색과 그림자 중심의 2~3단 셀 명암
금지: 실존 인물 닮은꼴, 피부 노이즈, 미세 주름, 글자와 워터마크
검수: 실제 게임 크기로 줄여도 눈·코·입과 역할이 읽힐 것
이건 당시 사용했던 프롬프트 원문은 아니다.
여러 번 실패한 뒤 지금 남긴 제작 조건을
프롬프트 형식으로 다시 정리한 것이다.
그리고 한 번에 수십 명을 만들지 않는다.
대표 캐릭터 몇 명만 먼저 뽑고
실제 UI와 게임 화면에 넣어본 뒤 다음 묶음으로 넘어간다.
생성 횟수를 늘리는 것보다 반려 기준을 먼저 만드는 편이 빨랐다.
Quirky Ball은 오히려 덜 그려서 캐릭터가 됐다.
Quirky Ball도 처음부터 지금 얼굴이었던 것은 아니다.
한때는 일반 구슬에도 얼굴을 붙이려고 했고
빨간 육각형 쿼키는 큰 이빨 웃음을 짓고 있었다.

화면 안의 모든 것이 캐릭터처럼 보이면
정작 주인공이 누구인지 흐려졌다.
그래서 일반 구슬의 얼굴은 걷어내고
쿼키만 사백안과 굵은 눈썹,
한쪽이 올라간 입꼬리를 가진 캐릭터로 남겼다.

표정만 고친다고 끝나지도 않았다.
이름을 알려주고, 왜 연구소에 갇혔는지 말하고,
플레이 상황에 따라 깜빡이고 웃고 걱정하고 도발해야
그제야 빨간 도형이 캐릭터로 읽히기 시작했다.
컷신도 비슷한 과정을 거쳤다.
초기에는 과학자와 기계를 단순 도형으로 그렸다.

이후 생성형 이미지로 과학자와 장비의 초안을 얻었지만
그 결과물을 그대로 게임에 넣지는 않았다.
색상을 다섯 개로 줄이고, 흰 배경을 지우고,
크기와 픽셀 배율을 고정해 한 장의 아틀라스로 다시 묶었다.

같은 규격으로 잘라둔 뒤에야
장면이 바뀌어도 과학자의 얼굴과 기계의 크기가 흔들리지 않았다.

좋은 프롬프트보다 후처리 규칙이 더 오래 살아남았다.
게임명 미정 차기작에서는 최종 캐릭터를 일부러 안 만들었다.
차기작의 초기 프로토타입은
캐릭터조차 없는 타이밍 게임에 가까웠다.

리부트하면서 오리, 거위와 비둘기를 넣었지만
지금 보이는 새들은 코드로 만든 저폴리 그레이박스다.
최종 캐릭터 디자인이 아니다.

대신 먼저 정한 것은 역할이었다.
오리는 지휘와 균형,
거위는 방어와 무게,
비둘기는 경로를 만드는 캐릭터로 나눴다.
모델이 예쁘지는 않아도
끌기, 충돌, 엄폐와 보상이 제대로 읽히는지부터 본다.

아직 외부 플레이어의 재미 검증도 통과하지 않았다.
그래서 최종 셀 3D 캐릭터를 먼저 잔뜩 만들지 않고
오리 한 종의 원본만 검수한 뒤 확장하는 계획으로 멈춰두었다.
재미가 없는 게임에 예쁜 캐릭터를 열 명 더 넣어도
재미있는 게임이 되는 것은 아니기 때문이다.
에셋이 마음에 든다고 게임이 완성된 것은 아니다.
캐릭터 이미지가 잘 나오면
프로젝트가 갑자기 많이 완성된 것처럼 느껴진다.
나도 새 그림을 화면에 넣을 때마다
게임이 꽤 그럴듯해졌다고 착각했다.
하지만 플레이어가 다시 실행할 만큼 재미있는지,
저장과 로그인, 결제가 망가지지 않을 만큼 소프트웨어가 완성됐는지,
처음 보는 사람도 이해할 만큼 UI가 분명한지,
버튼을 눌렀을 때 즉시 반응할 만큼 상호작용이 기민한지,
그리고 게임의 존재를 알릴 마케팅까지 이어지는지는
캐릭터 원화 한 장으로 해결되지 않는다.
오히려 에셋이 좋아질수록
플레이어가 게임에 기대하는 기준도 같이 올라간다.
에셋은 출발선을 보기 좋게 만들어준다.
하지만 결국 게임을 움직이는 것은
재미와 완성도다.
프롬프트가 잘 먹혀서 마음에 드는 캐릭터가 나오면
기뻐해도 된다.
다만 그날 하루 프로젝트가 잘 풀린 것이지
게임이 성공한 것은 아니다.
다음 날에는 다시 플레이하고, 고치고,
버튼 하나의 반응과 첫 10분의 재미를 확인해야 한다.
일희일비하기에는 게임을 완성하는 일이 아직 너무 많이 남아 있다.

