UDangTangTang 개발기 #3 — 프로젝트 기록
시작은 이랬습니다
팀 인원은 4명이었습니다. 저희는 게임 개발 부트캠프를 수강하며 알게 된 사이였습니다.
팀 프로젝트를 진행하기 이전에, 각자 개인 프로젝트로 2주간 게임을 개발해본 경험이 있었습니다. 개인 프로젝트를 진행하면서 “혼자가 아니라 여러 명이라면 더 완성도 높고 재미있는 게임을 만들 수 있지 않을까”라는 생각이 들었습니다. 그래서 부트캠프에서 배운 것을 바탕으로, 4명이서 하나의 온전한 게임을 만들어보자는 마음으로 이 프로젝트를 시작하게 되었습니다.
왜 뱀파이어 서바이벌류였을까
UDangTangTang은 “탕탕특공대”라는 게임을 참고해서 만든 게임입니다. 저희 4명 모두 탕탕특공대를 재미있게 플레이했던 경험이 있었고, 뱀파이어 서바이벌류 장르 자체가 주는 재미와 몰입도가 개발 난이도에 비해 매우 높다고 생각했기 때문에 이 장르를 선택하게 되었습니다.
이 장르를 선택한 이유를 조금 더 정리하면 이렇습니다.
- 핵심 루프가 단순해서 처음 팀 프로젝트로 만들기 좋다: 이동 + 자동 공격 + 성장이라는 단순한 구조라, 처음부터 복잡한 조작/전투 시스템을 설계할 필요가 없었습니다.
- 콘텐츠 확장이 명확하다: 무기·패시브·진화 조합처럼, 데이터만 추가하면 콘텐츠가 늘어나는 구조라 팀원별로 작업을 나누기 좋았습니다.
- 레퍼런스가 명확하다: 뱀파이어 서바이벌, 브로드소드 등 장르를 정립한 게임들이 있어서, 기획 방향을 잡을 때 참고하기 쉬웠습니다.
초기 기획: 무기 7종 + 진화 시스템
프로젝트 초반에 잡은 핵심 설계는 다음과 같았습니다.
- 무기 7종: 회전도끼, 단검, 쌍검, 메이스, 랜스, 삼지창, 지팡이 — 각각 궤도 회전, 직선 발사, 근접 휘두르기 등 서로 다른 공격 패턴으로 설계
- 패시브(강화서) 7종: 각 무기와 1:1로 대응되는 강화 아이템
- 무기 + 전용 강화서 → 진화: “무기 최대 레벨 + 대응 강화서 보유” 조건으로 진화하는 구조
이 “무기-강화서 1:1 매칭” 구조를 기획 초반에 확정한 이유는, 플레이어 입장에서 진화에 필요한 요소를 직관적으로 학습할 수 있게 하고 싶었기 때문입니다. “이 무기를 키우려면 이 강화서를 모으면 된다”는 규칙이 명확하면, 플레이어가 별도의 학습 없이도 진화 조건을 자연스럽게 파악하고 스스로 빌드를 계획할 수 있습니다.
아키텍처를 처음부터 데이터 중심으로 설계한 이유
저는 백엔드/서버 개발 경험이 있어서, 게임 데이터를 관리하는 방식에 특히 신경을 썼습니다. 처음부터 ScriptableObject + Registry 패턴으로 스탯/웨이브/스킬 데이터를 코드와 분리하는 구조를 제안했고, 팀에서도 이 방향으로 진행하기로 했습니다.
이렇게 설계한 이유는:
- 기획자와 개발자의 작업 분리: 밸런스 수치를 코드 재컴파일 없이 데이터 파일만으로 조정할 수 있게 하고 싶었습니다.
- 백엔드에서 익숙했던 패턴: 서버 개발에서 설정값을 코드와 분리해서 관리하던 습관을 게임 개발에도 그대로 적용해봤습니다.
- 나중에 CSV → SO 변환기(
Assets/Script/Editor/CSV_SO_Converter.cs)까지 만들어서, 스프레드시트에서 수치를 조정하고 바로 임포트하는 워크플로를 갖췄습니다.
팀 내 역할 분담
4명이 각자 다른 영역을 맡아 진행했습니다.
- 저: 적 AI, 몬스터 스폰, 보스 패턴 구현
- 팀원 A: 플레이어 이동 및 공격, 스킬과 패시브의 조합·진화 시스템 구현
- 팀원 B: 맵과 UI, 데이터 관리
- 팀원 C: 기획·설계, QA 및 밸런싱
역할이 명확히 나뉘어 있었던 덕분에, 각자 담당 영역에서 깊이 있게 파고들 수 있었습니다.
개발 기간과 진행 방식
실제 개발 기간은 5주였습니다. 진행 방식은 매일 아침 화상 채팅으로 서로의 진행 상황과 오늘의 목표를 공유하는 짧은 회의를 거의 매일 진행했습니다. 정식으로 스크럼 방법론을 따랐다고 할 수 있을지는 모르겠지만, 결과적으로 매일 진행 상황을 공유하고 blocker를 빠르게 파악하는 방식이 5주라는 짧은 기간 안에 프로젝트를 완성하는 데 큰 도움이 됐습니다.
지금 돌아보면
5주라는 기간 동안 정말 게임 개발에 몰두하며 지냈던 것 같습니다. 팀원들과 매일 만나 대화하고 문제를 해결하며 조금씩 게임을 완성시켜 가는 과정이 정말 즐거웠습니다.
음악과 아트 같은 부분에서는 항상 부족하고 아쉬웠지만, 그런 와중에도 꽤나 완성도 있는 게임을 만들었다고 생각합니다. 다시 한번 그렇게 게임 개발에 몰두하며 팀원들과 하나의 완성도 높은 게임을 만드는 경험을 하고 싶습니다.
다음 글부터는 이 프로젝트를 만들면서 실제로 마주친 기술적 문제들(빌드 에러, 데이터 버그 등)과 설계 결정들을 하나씩 자세히 다뤄보겠습니다.
이 시리즈의 이전 글: [Unity Standalone 빌드 컴파일 에러 원인 찾기], [보스 HP 데이터가 뒤바뀐 걸 발견한 과정]