[TIL] 2026-01-07 | [텍스트 콘솔 RPG] '에레보스타워' 프로젝트 회고

게임 개발자를 위한 C++ 문법 팀프로젝트 1

텍스트 콘솔 RPG  '에레보스타워'

⌛기간

• 2025.12.30 ~ 2026.01.07

🏹기능

• 캐릭터 생성 및 성장 시스템
• 파티 결성 및 턴제 전투 시스템
• 인벤토리 및 상점 시스템
• 브렌치 노드 맵 시스템

👩‍💻담당

• 구현 - 배틀 매니저, 몬스터 및 보스 클래스 구조, 배틀 씬 애니메이션 및 로그
• 작업 - 아스키 아트 디자인

 

💻GitHub

https://github.com/SpartChapter2Team10/TextConsoleRPG_Team10

GitHub - SpartChapter2Team10/TextConsoleRPG_Team10: 내일배움캠프 언리얼7기 텍스트 콘솔 RPG 팀 프로젝트 [에

📄Team Notion

https://www.notion.so/teamsparta/10-2c02dc3ef51480b2b172e40b7762b410

자고10조 (자고싶죠) | Notion

📽️Video

https://www.youtube.com/watch?v=Y2zJsQHeVBM

---

KEEP

 

• 전투 시스템 구조화
  • BattleManager와 BattleScene을 분리하여 전투 로직과 UI/출력 책임을 나눠 구현했다.
  • 덕분에 전투 흐름 수정이나 로그 출력 방식 변경 시 영향 범위가 명확했다.
• 턴 기반 전투 흐름의 일관성 유지
  • 플레이어 키 입력 → 턴 처리 → 로그 출력 → 다음 입력이라는 흐름을 유지하여
    텍스트 콘솔임에도 전투 진행이 직관적으로 느껴지도록 했다.
• 전투 로그 시스템 도입
  • 즉시 출력이 아닌 로그를 수집한 뒤 한 번에 출력하는 구조로 설계하여
    전투 상황을 정리된 형태로 보여줄 수 있도록 했다.
  • 색상 로그, 몬스터/플레이어 행동 구분 등 가독성을 고려했다.
• 팀 내 소통
  • 노션, 피그마, 디스코드 등 다양한 협업 툴을 활용하여 프로젝트 진행 중 기획이 자주 변경되었음에도
    변경 사항이 문서로 정리되어 공유되면서 팀원 간 정보 전달이 원활하게 이루어졌다.
  • 깃허브에서는 기능 단위로 개인 작업 브랜치를 분리하고, PR 후 병합하는 방식을 유지하여 코드 충돌을 최소화하였다.

 

 

PROBLEM

1️⃣ 하드코딩 문제

• 문제점
  • 캐릭터 스탯, 전투 관련 수치, 아스키 아트(txt) 경로 등을 CSV 파일로 관리하도록 설계하였으나
    프로젝트 일정과 시간 부족으로 인해 일부 로직에서는 여전히 값과 경로가 코드 내에 하드코딩된 상태로 남아 있다.
  • 이로 인해 데이터 수정 시 코드 변경이 필요, 확장성과 유지보수 측면에서 한계가 존재한다.
• 해결 방안
  • DataManager 클래스를 통해서만 데이터를 읽어오도록 한다.
  • DDD(Data Driven Development)

2️⃣ 로그 수집 시점이 제한적이었던 문제

• 문제점
  • 로그 수집이 특정 함수에서만 이루어져 일부 행동 로그가 누락되는 상황이 발생한다.
• 해결 방안
  • 전투 턴 단위로 로그 Flush 시점을 명확히 정의한다.
  • BattleManager 내부에서 “행동 발생 시 무조건 로그 적재” 규칙을 적용한다.

3️⃣ 헤더 전역 static 랜덤 엔진 문제

• 문제점
  • 랜덤 시드를 생성하는 로직이 GameManager.h에서 클래스 외부 static 변수로 정의되어 있어,
    해당 헤더를 포함하는 각 cpp 파일마다 서로 다른 랜덤 엔진이 생성된다.
  • 이로 인해 전투 결과나 이벤트 처리에서 랜덤 값의 일관성이 보장되지 않고 있다.
• 해결 방안
  • 랜덤 시드 생성 로직을 GameManager 클래스 내부에 선언한다
  • 멤버 변수 및 멤버 함수 호출 방식으로 사용하도록 구조를 개선한다
  • 게임 전체에서 하나의 랜덤 엔진만 사용하도록 통제 > 랜덤 동작의 예측 가능성과 유지보수성을 향상시킨다.

4️⃣ dynamic_cast 사용으로 인한 RTTI 의존 및 성능 저하 문제

• 문제점
  • 다형 객체의 실제 타입을 판별을 위해 dynamic_cast를 사용하면서
    RTTI(Runtime Type Information)가 활성화되고 있다.
  • 객체 크기 증가와 런타임 타입 검사 비용이 발생한다.
• 해결 방안
  • 가상 함수 기반의 다형성 설계 또는 명시적인 역할/상태 enum을 활용한 분기 구조로 개선한다.
  • 이를 통해 RTTI 의존성을 제거, 코드 가독성과 성능을 함께 개선한다.

 

TRY

• 전투 이벤트 기반 구조 도입
  • 전투 행동을 이벤트 단위로 분리한다.
  • 전투 로직과 로그, 애니메이션, 사운드 처리의 결합도를 낮추고
    새로운 연출을 유연하게 확장할 수 있는 구조로 변경한다.
• 콘솔 인터렉션 강화
  • 현재는 전투 씬에서 기본적인 애니메이션과 로그 출력 위주로 구현되어있다.
  • 색상 변경, 텍스트 흔들림, 출력 타이밍 조절 등 다양한 콘솔 인터랙션을 추가한다.
  • 텍스트 기반 전투임에도 시각적·체감적 몰입도를 더욱 높여보고 싶다.

 

FEEL

 

단순한 텍스트 콘솔 게임이었지만, 구조 설계가 프로젝트 전체 완성도에 얼마나 큰 영향을 미치는지를 체감한 경험이었다. 전투 로직과 UI를 분리하는 과정에서 전투 상태를 어떻게 관리하고, 이를 어떤 방식으로 씬으로 전달해야 하는지에 대해 많은 고민을 했다. 또한 제한된 시간 안에 5명이 함께 팀 프로젝트를 진행하며, 개발 중간에 기획이 많이 바뀌었다. 각자의 아이디어를 조율하고 기획을 문서화하여 통일된 정보를 공유하는 과정이 협업에서 얼마나 중요한지를 느끼게 되었다.

프로젝트 초반에는 기본적인 기능을 우선 텍스트 출력 방식으로 구현한 뒤, 이후 화면 렌더링 방식으로 전환했다. 이 과정에서 예상보다 코드 구조가 크게 변경되며 버려지는 코드도 많았고 구현 난이도가 높아졌다. 이러한 경험을 통해 초기 설계 단계에서 출력 방식과 구조를 충분히 고려하는 것이 중요하다는 교훈을 얻었다. 다음 프로젝트에서는 초기 단계부터 상태 관리와 로그 설계를 더욱 탄탄하게 준비하여, 안정적이고 확장 가능한 구조로 만들고 싶다.

---

https://zzageuli.tistory.com/29

[TIL] 2025-12-30 | [텍스트 콘솔 RPG] 팀 프로젝트 1 시작하기

https://zzageuli.tistory.com/30

[TIL] 2025-12-31 | [텍스트 콘솔 RPG] BattleManager, NormalMonster, IMonster 구현

https://zzageuli.tistory.com/31

[TIL] 2026-01-01 | [텍스트 콘솔 RPG] 아스키 아트 작업

https://zzageuli.tistory.com/32

[TIL] 2026-01-02 | [텍스트 콘솔 RPG] 텍스트 로그 기반 진행 → 실시간 UI 렌더링 방식으로 전환

https://zzageuli.tistory.com/33

[TIL] 2026-01-05 | [텍스트 콘솔 RPG] 몬스터 클래스 디테일 높이기, 배틀매니저 로직 새로 짜기

https://zzageuli.tistory.com/34

[TIL] 2026-01-06 | [텍스트 콘솔 RPG] BM → BS 콜백 작업, 디버깅