게임 캐릭터 아키타입 3종 추가와 선물 시스템 연계 설계
목차
새 아키타입 3종과 각각 2D/실사 스타일을 동시 지원하면서 선물 시스템까지 함께 엮는 작업을 진행했다. 단순해 보이는 에셋 추가지만, 그 뒤에는 게임의 진입 경험과 유저 engagement를 어떻게 설계할지에 대한 여러 의사결정이 있었다.
왜 아키타입 라인업을 확장해야 했는가
게임이나 인터렉티브 미디어에서 '아키타입'은 단순한 캐릭터가 아니다. 플레이어가 누구를 선택하는지, 누구와 상호작용하는지에 따라 전체 게임플레이와 스토리 경험이 달라진다. 초기 라인업이 부족하면 초기 플레이어들이 느끼는 다양성 부족과 선택지 제한이 곧 이탈로 이어진다.
도윤, 재하, 지원 3개의 새 아키타입을 추가한 건 단순히 "종류를 늘렸다"는 뜻이 아니라, 다음을 가능하게 했다는 뜻이다:
- 플레이어 성향 분산: 다양한 외형과 개성을 가진 캐릭터를 만나면, 초기 선택 단계에서 포기할 가능성이 줄어든다.
- 콘텐츠 재시도 유도: 게임을 한 번 클리어한 플레이어도 "이번엔 다른 아키타입으로" 해보려고 돌아온다.
- 팀 내 협업 부담 분산: 개발 초기에 너무 많은 아키타입을 만들려다 보면 QA와 밸런싱에 병목이 생긴다. 단계적 추가가 지속 가능한 속도다.
2D와 실사 스타일을 동시 지원해야 한 이유
여기가 흥미로운 부분이다. 각 캐릭터마다 -2d.jpg와 기본 .jpg 두 개를 병렬로 두는 것은 동일 에셋을 두 배 관리해야 한다는 뜻인데, 왜 그렇게 설계했을까.
| 시나리오 | 2D 스타일 | 실사 스타일 | 용도 |
|---|---|---|---|
| 모바일 대기 화면 | O | — | 밝고 가벼운 UI |
| 인게임 상세보기 | — | O | 몰입감 있는 캐릭터 표현 |
| 선물 상자 열기 | O | — | 빠른 로딩 + 축제 느낌 |
| 프로필/캐릭터 도감 | O | O | 사용자 선택지 |
게임 UI의 맥락마다 최적의 에셋을 쓸 수 있다. 예를 들어:
- 모바일에서 매번 실사 이미지를 로드하면 로딩 시간이 길어지고, 배터리도 빠진다.
- 반대로 중요한 스토리 신에서 2D만 보여주면 몰입감이 떨어진다.
단순히 해상도나 포맷을 다르게 하는 게 아니라, UI 문맥에 따라 최적의 표현 방식을 선택할 수 있는 유연성을 확보한 거다.
선물 시스템과의 연계
"선물 시스템"은 단순히 "이 캐릭터를 얻을 수 있다"는 뜻이 아니라, 아마 이렇게 동작한다:
- 플레이어가 게임 내 성취/결제를 통해 특정 아키타입의 선물을 언락한다.
- 선물 박스 UI가 뜰 때 2D 스타일 이미지가 표시된다 (빠른 로딩, 축제 느낌).
- "확인" 또는 "수집" 버튼을 누르면 실사 버전이 로드되며 상세 정보를 본다.
이건 UX 프로그레션: 가벼운 즐거움 → 깊은 만족감 순서다. 아키타입을 여러 개 확보할수록 선물을 받을 기회도 늘어나고, 자연스럽게 재방문 동기가 생긴다.
에셋 관리와 확장성의 교훈
6개 파일을 추가하는 작업은 작아 보이지만, 실제로는:
- 명명 규칙의 일관성:
{name}-2d.jpg와{name}.jpg패턴을 정확히 지키지 않으면, 이후 새 캐릭터 추가할 때 혼란 발생 - 버전 관리: 아티스트가 이미지를 업데이트할 때마다 두 파일을 동시에 수정해야 한다는 부담
- 로딩 최적화: 코드에서 언제 2D를 쓸지, 언제 실사를 쓸지 플래그를 관리하는 로직도 필요
이런 복잡성 때문에, 다음 아키타입을 추가할 때는:
- 에셋 빌드 파이프라인 자동화 (아티스트가 원본만 제출하면 2D/실사 자동 생성)
- UI 레이어에서 스타일 선택 로직 추상화 (스타일 enum으로 캡슐화)
- 테스트: 모든 조합의 이미지가 정말 로드되는지 확인
같은 콘텐츠를 여러 형태로 제공하는 것은 강력하지만, 관리 부담도 커진다. 그래서 처음부터 구조를 잘 잡는 게 중요하다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.