📘 TIL – Farmer's Defender - 감자마을 지키기! (Team Project)
프로젝트 개요
| 항목 | 내용 |
|---|---|
| 게임 이름 | Farmer's Defender - 감자마을 지키기! |
| 장르 | TPS(3인칭 슈팅) + 디펜스 |
| 사용 엔진 | Unreal Engine 5.6 |
| 개발 인원 | 4명 |
| 개발 기간 | 2026.02.03 ~ 2026.03.05 |
| GitHub | https://github.com/NbcampUnreal/7th-Team5-CH3-Project |
게임 분위기
| 요소 | 설명 |
|---|---|
| 밝고 유쾌한 분위기 | 긴장감은 있지만 무겁지 않은 톤 |
| 약간의 코믹함 | 예상치 못한 조합과 과장된 연출 |
| 비폭력적 연출 | 피 대신 몬스터가 가루/먼지처럼 사라짐 |
| 정겨운 농촌 배경 | 따뜻하고 평화로운 마을 환경 |
프로젝트 회고 (KPT)
Keep — 잘 작동했던 판단과 구조
1. 기획 문서화를 의사결정 기준으로 활용
프로젝트 초기에 컨셉 / 시스템 / UI / 밸런스 / 레벨 디자인 / 사운드 / 클래스 구조까지 전 영역을 문서화했다.
개발 중 기능 변경이 발생하면 즉시 문서에 반영했고, 문서는 단순 참고 자료가 아니라 구현 기준으로 사용되었다.
그 결과
- “이 기능 어떻게 하기로 했지?” 같은 논의가 줄어들었고
- 구현 중 되돌아가는 상황이 크게 줄었다.
2. Data-Driven + Event-Driven 혼합 구조
| 설계 영역 | 방식 | 역할 |
|---|---|---|
| 밸런스 데이터 | DataTable / DataAsset | 무기 스탯, 몬스터 프리셋, 웨이브 보상 |
| 게임 흐름 | Delegate 기반 이벤트 | 웨이브 시작/종료, 낮밤 전환 |
이 구조의 핵심 원칙
데이터는 테이블이 제어하고, 흐름은 이벤트가 제어한다
장점
- 기획자가 수치를 수정할 때 코드 수정이 필요 없음
- 시스템을 추가해도 기존 로직과의 결합도가 낮음
- 게임 흐름을 이벤트 중심으로 관리 가능
3. 시스템 역할 분담을 기획 단계에서 명확히 정의
| 시스템 | 설계 내용 |
|---|---|
| 무기 시스템 | 4종 무기의 역할 차별화 |
| 자원 시스템 | 4종 자원의 순환 구조 |
| 생산 시스템 | 건물 → NPC → 동물 생산 체인 |
또한
- 산탄 관통 여부
- 무기 밸런스
- 생산 효율
같은 설계 요소는 유사 장르 레퍼런스를 조사한 뒤 결정하였다.
이 과정 덕분에 구현 단계에서 모호함이 줄어들었다.
Problem — 가장 비용이 컸던 문제
1. 에셋 파이프라인 검증 부족
사용하려던 동물 에셋이 Unity 기반 에셋이었기 때문에 다음 과정이 필요했다.
| 단계 | 작업 |
|---|---|
| 1 | Unity 에셋 추출 |
| 2 | Blender로 변환 |
| 3 | FBX로 Export |
| 4 | Unreal Import |
이 과정에서 발생한 문제
- FBX 애니메이션 누락
- Blender NLA 미등록
- 프레임 범위 0 문제
- IK Retargeter가 휴머노이드 중심 구조
특히 4족 동물 리타겟팅이 매우 어려웠다.
결과적으로 에셋 관련 작업이 예상보다 큰 병목이 되었다.
근본 원인
에셋 도입 전에 엔진 호환성 검증을 하지 않았다.
2. 기획 변경의 연쇄 비용
다음 변경이 동시에 발생했다.
| 변경 사항 |
|---|
| 조준 시스템 삭제 |
| 밤 건설 불가 |
| 수리 기능 삭제 |
| 재시작 정책 변경 |
문제는
하나의 변경이 기획서 전체에서 여러 섹션 수정으로 이어졌다는 것
예시
| 변경 | 수정 필요한 영역 |
|---|---|
| 조준 시스템 삭제 | 입력 / 무기 / UI / 클래스 다이어그램 등 |
기획서가 상세할수록 수정 범위도 넓어지는 문제를 경험했다.
3. 프로토타입 검증 전 밸런스 설계
다음 핵심 밸런스 요소들이 실제 플레이 검증 없이 설계되었다.
- 자원 수급 구조
- 건물 스탯
- 무기 DPS
- 웨이브 난이도
기획서 구조는 있었지만
실제 플레이 기반 수치 검증이 부족한 상태에서 개발이 진행되었다.
Try — 다음 프로젝트 개선 계획
1. 에셋 호환성 체크리스트 도입
앞으로는 에셋 도입 전에 다음 검증을 진행할 계획이다.
| 단계 | 체크 |
|---|---|
| 1 | FBX 애니메이션 포함 여부 |
| 2 | DCC 툴(Blender 등)에서 원본 상태 확인 |
| 3 | 테스트 Export |
| 4 | 엔진 Import 검증 |
이 과정을 1시간 이내 테스트로 진행할 예정이다.
특히
- 타 엔진 에셋
- 엔진 비종속 에셋
은 반드시 검증한다.
2. 기획 변경 영향 매트릭스
시스템 의존 관계를 매트릭스로 정리
예시
| 변경 시스템 | 영향 영역 |
|---|---|
| 조준 시스템 | 입력 / 무기 / UI / 클래스 구조 |
| 낮밤 시스템 | 몬스터 / 웨이브 / 생산 시스템 |
이렇게 하면
변경 발생 시 수정 범위를 즉시 파악할 수 있다.
3. 밸런스 시뮬레이션 조기 도입
플레이 테스트 이전에도 스프레드시트 기반 시뮬레이션을 활용할 계획이다.
예시
| 조건 | 결과 |
|---|---|
| 낮 5분 | 밭 2개 + 벌목장 1개 |
| 생산 | 농작물 30 / 나무 5 |
| 결과 | 감자탄 30발 생산 |
검증 질문
감자탄 30발로 1웨이브 25마리를 처리할 수 있는가?
이런 방식으로 기획 단계에서 수치 검증을 진행한다.
4. Event-Driven 디버깅 환경 구축
Delegate 기반 이벤트 구조는 결합도가 낮지만 다음 문제가 있다.
- 어떤 이벤트가 발생했는지
- 누가 수신했는지
- 언제 호출되었는지
추적이 어렵다.
그래서 다음을 구축할 예정이다.
| 도구 | 목적 |
|---|---|
| 이벤트 로깅 유틸 | Delegate 호출 기록 |
| 이벤트 디버그 UI | 흐름 시각화 |
초기 단계에서 구축하면 통합 이후 디버깅 시간을 크게 줄일 수 있다.
기술적으로 어려웠던 부분
| 담당 | 어려웠던 점 |
|---|---|
| 공통 | Collision Channel 설정이 코드보다 에디터 설정에 크게 의존해서 시행착오가 많았음 |
| 임영택 | 기능 구현 위주로 개발하다 보니 코드 규모가 커지면서 구조 수정이 어려웠음 |
| 정보원 | 수학 기반 로직을 직접 설계하는 경험이 부족해 구현 과정에서 어려움이 있었음 |
| 이희원 | 컴포넌트 분리 구조 설계가 미숙해 클래스가 비대해지는 문제를 경험 |
| 장유진 | 명확한 설계 기준 없이 감각적으로 개발하다가 유지보수 문제를 체감 |
팀원 후기
| 이름 | 후기 |
|---|---|
| 임영택 | 다들 열심히 해줘서 좋은 결과가 나왔다. 팀원들에게 감사하다. |
| 장유진 | 더 좋은 구조가 무엇인지 고민하면서 많이 배울 수 있었다. |
| 정보원 | 팀 프로젝트가 매우 즐거웠고 열정적인 팀원 덕분에 좋은 게임이 완성됐다. |
| 이희원 | 팀원들이 모두 열심히 참여해 좋은 결과물을 만들어 뿌듯하다. |
