1. 오늘 작업 내용
이번 팀 프로젝트의 전체 게임 기획을 정리하고, 내가 담당하게 된 Map / Spawn / WaveManager 파트의 구현 방향을 구체화했다.
게임의 전체적인 컨셉은 **「Dream Protector」**이다.
아이가 잠든 밤, 장난감이 깨어나 아이의 꿈을 지키고 악몽을 해결하는 게임.
현실에 나타난 악몽으로부터 아이를 보호하고, 이후 꿈속으로 직접 들어가 악몽의 근원을 제거하는 싱글 플레이 TPS PVE 게임을 목표로 한다.
2. 게임의 핵심 컨셉
게임은 크게 두 가지 플레이 경험으로 구성된다.
Stage 1 — 아이의 방
아이를 악몽으로부터 보호하는 디펜스 플레이
- 아이의 침대 주변을 방어
- 여러 방향에서 악몽이 등장
- 웨이브가 진행될수록 SpawnVolume이 증가
- 등장하는 몬스터의 종류와 수가 증가
- 플레이어의 행동에 따라 아이의 Stress가 감소
즉, 단순히 몬스터를 많이 잡는 것이 아니라 아이를 보호하면서 전장을 관리하는 플레이를 목표로 한다.
Stage 2 — 꿈속 / 장난감의 성
악몽의 근원을 직접 찾아 제거하는 섬멸전
- 꿈속으로 진입
- 웨이브 단위로 몬스터와 전투
- 웨이브가 진행될수록 몬스터 종류와 스폰량 증가
- 마지막 웨이브에서는 보스전 진행
- 플레이어가 사망하면 실패
- 제한 시간 안에 모든 적을 처치하면 웨이브 성공
3. 게임의 차별성
이번 프로젝트에서 생각한 차별점은 인간의 수면 주기인 REM 수면을 게임의 진행 구조에 활용하는 것이다.
단순히 계속 전투가 이어지는 방식이 아니라,
REM 수면 → 악몽 출현 → 전투 → 비 REM 상태 → 탐색 / 준비
와 같은 흐름을 만든다.
REM 수면을 악몽이 등장하는 전투 시간으로 활용하고, 전투가 아닌 시간에는
- 맵 탐색
- 아이템 루팅
- 제작
- 다음 전투 준비
등을 할 수 있도록 설계한다.
이를 통해 전투만 반복하는 구조가 아니라 전투와 준비가 반복되는 게임의 리듬을 만드는 것을 목표로 했다.
4. Stage 1 규칙
Stage 1은 아이의 방에서 진행되는 방어전이다.
아이의 침대 주변에는 일정한 거리를 기준으로 방어 구역을 설정한다.
특히 플레이어가 침대 바로 옆에서 계속 공격하는 것을 방지하기 위해,
침대 주변 일정 거리 안에서 공격하면 아이의 Stress가 증가하도록 설계
했다.
따라서 플레이어는 단순히 아이 근처에 붙어서 싸우는 것이 아니라 적의 접근을 막으면서 적절한 위치에서 전투해야 한다.
Spawn 구조
맵의 여러 방향에 SpawnVolume을 배치하고 웨이브가 진행될수록 활성화되는 SpawnVolume의 수를 증가시킨다.
예시:
Wave 1
↓
SpawnVolume 2개 활성화
Wave 2
↓
SpawnVolume 3개 활성화
Wave 3
↓
SpawnVolume 4개 활성화또한 웨이브가 진행될수록 등장하는 몬스터의 종류도 증가시켜 난이도를 높인다.
실패 조건
- 아이의 Stress가 한계치에 도달하면 게임 실패
성공 조건
- 모든 웨이브에서 아이를 보호
5. Stage 2 규칙
Stage 2에서는 아이의 꿈속으로 들어가 악몽과 직접 전투한다.
Stage 1과 달리 플레이어의 생존 자체가 중요한 요소가 된다.
웨이브 구조
Wave 1
↓
기본 악몽 몬스터
Wave 2
↓
강화된 몬스터 + 장난감 로봇 등
Wave 3
↓
장난감 기사 + 대형 몬스터
↓
Boss Battle웨이브마다 제한된 시간이 존재하며,
제한 시간 안에 모든 몬스터를 처치하면 웨이브 성공
으로 설계했다.
웨이브 성공 / 실패에 따른 보상과 패널티
웨이브를 성공하면 중앙 맵 양쪽의 지역 문이 해금되고, 해당 지역에서 버프 아이템을 획득할 수 있도록 한다.
반대로 웨이브 처치에 실패하면 다음 웨이브에 추가로 처치해야 할 몬스터가 증가하는 등의 디메리트를 부여한다.
웨이브 성공
↓
지역 해금
↓
버프 획득
↓
다음 REM 전투
웨이브 실패
↓
다음 웨이브 디메리트
↓
난이도 증가또한 다음 REM 주기가 시작되기 전에는 다음 전투 구역으로 이동할 수 없도록 하여 플레이어의 진행 속도를 통제한다.
6. 내가 맡은 파트
팀의 전체적인 파트 분배는 다음과 같이 진행했다.
- GameManager
- UIManager
- Character / WeaponManager
- Monster / CombatManager
- Map / Spawn / WaveManager ← 내가 담당
- Story
- ItemManager
내가 담당한 부분에서는 크게 다음 세 가지를 구현하게 된다.
Map
- 전투 맵 구성
- Spawn 위치 구성
- 플레이어 이동 동선 구성
- 주요 전투 구역 배치
Spawn
- SpawnVolume 배치
- Spawn 위치 관리
- 몬스터 생성 위치 랜덤화
- 웨이브별 SpawnVolume 활성화
Wave
- 웨이브 시작 / 종료
- 웨이브별 몬스터 구성
- 웨이브별 Spawn 수량 관리
- 제한 시간 관리
- 웨이브 성공 / 실패 처리
- 다음 웨이브 진행
7. Spawn 시스템 설계
Spawn 시스템은 SpawnVolume을 중심으로 구성할 예정이다.
기본적인 흐름은 다음과 같다.
Wave 시작
↓
SpawnVolume 위치 선택
↓
랜덤 Spawn 위치 생성
↓
지정된 수량만큼 Enemy 생성
↓
모든 Enemy 처치 확인
↓
Wave 종료
↓
다음 Wave 시작이를 위해 사용할 클래스로는 다음과 같이 생각하고 있다.
ASpawnVolume
AWaveManager
AEnemy
AIController
AI Behavior TreeSpawnVolume은 단순히 적을 생성하는 것뿐만 아니라 어떤 위치에서 적을 생성할 것인지 관리하는 역할을 담당한다.
8. 웨이브 구성 예시
현재 기획한 기본적인 웨이브 구성은 다음과 같다.
| 1 | 붉은 슬라임 / 비행형 가오리 | 하단 입구 → 중앙 | 기본 패턴, 소수 |
| 2 | 람머스 슬라임 / 쁘띠 뮤탈 | 양쪽 측면 → 중앙 | 중간 난이도, 더 빠른 이동속도 |
| 3 | 해골 사신 인형 / 대형 몬스터 | 성탑 + 중앙 | 보스급 전투, 강한 패턴 |
실제 수량과 타이밍은 구현 후 플레이 테스트를 진행하면서 조정할 예정이다.
따라서 처음부터 수치를 완벽하게 결정하기보다는 시스템을 먼저 구현하고 실제 플레이를 통해 밸런스를 조정하는 방향으로 생각했다.
9. 에셋 병합 과정에서 발생한 문제
오늘은 시스템 기획뿐만 아니라 팀원들이 작업한 에셋을 머지하는 과정에서도 문제를 하나 발견했다.
탄환으로 사용할 구미베어 젤리 에셋이 4개가 하나의 메쉬로 묶여 있는 상태였다.
게임에서는 각각의 젤리를 개별적으로 사용해야 했기 때문에 메쉬를 분리할 필요가 있었다.
10. 메쉬 분리 방법
언리얼 에디터에서 해당 에셋을 열고 모델링 모드를 이용해 메쉬를 분리했다.
내가 사용한 과정은 다음과 같다.
에셋 선택
↓
좌측 상단 Select Mode
↓
Modeling Mode로 변경
↓
XForm
↓
Split그리고 Split 옵션을 다음과 같이 변경했다.
Output Type
DynamicSplit Method
By Poly Groups이렇게 설정한 뒤 Split을 실행하니 하나로 묶여 있던 4개의 젤리 메쉬를 각각 분리할 수 있었다.
11. 이번 작업에서 배운 점
이번 작업을 통해 단순히 에셋을 가져와 사용하는 것뿐만 아니라 가져온 에셋의 구조를 확인하고 게임에 맞게 수정하는 과정도 필요하다는 것을 알게 되었다.
특히 같은 에셋이라도
여러 개의 Mesh가 각각 존재하는 경우와
하나의 Mesh 안에 여러 개의 오브젝트가 묶여 있는 경우는 수정 방법이 다를 수 있다는 것을 알게 되었다.
이번에 사용한 Split → By Poly Groups 방식은 메쉬가 폴리곤 그룹 단위로 구성되어 있는 경우 분리할 수 있는 방법으로 이해했다.
따라서 앞으로 다른 에셋에서도 무조건 같은 방법이 적용된다고 생각하기보다는, 해당 에셋의 Mesh 구조와 Polygon Group 구성을 먼저 확인해야 한다.
12. 오늘의 핵심 정리
이번 작업에서 가장 크게 정리된 부분은 게임의 기획을 실제 시스템 구조로 연결하는 것이다.
처음에는
"웨이브 방식으로 몬스터가 나온다."
정도로 생각했다면, 이번에는 이를 구체적으로
Map
↓
SpawnVolume
↓
Spawn 위치
↓
WaveManager
↓
Enemy Spawn
↓
Enemy 처치 확인
↓
Wave 종료
↓
다음 Wave라는 시스템 구조로 생각할 수 있게 되었다.
또한 REM 수면이라는 기획 요소도 단순한 스토리 설정으로 끝나는 것이 아니라,
REM
↓
전투
↓
웨이브 종료
↓
탐색 / 루팅 / 준비
↓
다음 REM이라는 실제 게임 플레이 사이클로 연결할 수 있다는 점을 정리했다.
🔥 한 줄 회고
오늘은 Dream Protector의 전체 게임 구조와 내가 담당할 Map / Spawn / WaveManager의 역할을 구체화하고, 실제 에셋 작업 과정에서는 하나로 묶여 있던 메쉬를 Modeling Mode → XForm → Split → By Poly Groups를 통해 분리하는 방법을 익혔다.