회고를 바탕으로, 다음 스텝으로 나아가보세요.

실제로 많은 회사들이 프로젝트가 종료될 때마다 회고를 진행하고, KPT회고 방법론을 아주 많이 적용한답니다!

공부한 것, 배운 것 보다는 "협업"을 하며 느낀 점, 앞으로 더 잘 하고 싶은 점과 관련된 이야기를 많이 나누어주시면 좋겠습니다.

• KPT회고 방법 참고하기

Keep - 현재 만족하고 있는 부분

1. 언리얼 스타일 구조 도입

   • AActor()와 UObject와 같은 언리얼 엔진에서 다루는 구조를 구현
   • BeginPlay(), Tick() [AActor()]을 분리해 프로그램 라이프사이클을 제어하는 구조는 정~말 좋죠??

2. UObjectBase 기반 구조화

   • Run() → BeginPlay() → Tick()으로 이어지는 프로그램 흐름을 통일 시킴
   • 향후 EnemyAI, CutsceneSystem 같은 시스템도 동일 인터페이스로 확장 가능

3. 몬스터 JSON 정의 및 드록 테이블 처리

   • Data-Driven Design을 통해서 객체 생성을 용이하고 몬스터 추가 및 수정을 코드 없이 확장 가능.
   • MonsterDefinition을 JSON으로 외부 분리하여 정의 - 구현 - 구조체 설계식으로 이후 한 로직 수정으로만 유지보수 용이.

4. 게임 저장/불러오기 기능

   • JSON 데이터 사용으로 현재 유지한 보조 기억을 주 기억으로 쉽게 남겨서 데이터 처리 원활
   • 기존 데이터 수정으로 원하는 테스트 및 기능 구현 가능

5. 플레이어에게 선택지를 주는 메뉴 기능 구성

   • 콘솔 UI 환경에서 게임 루프가 명확하고 사용자 행동 기반 흐름이 깔끔.
   • 메뉴 번호 기반 입력으로 플레이어 입장에서 UX상 직관적 플레이 가능

6. 팀원 깃전략 활용

   • Mster - Dev - Release로 관리하여 Git Conflict에 대해 예방 가능
   • 깃 브런치 전략을 통해 팀원의 코드를 merge 후 통합하여 테스트 및 main으로 관리하여 형상관리에 능통했다.

Problem - 불편하게 느끼는 부분

1. 초기 기획 구성 아쉬움

   • 초기에 게임 환경 구축 미숙 (IDE 통일 실패로 인한 팀원 전반적인 빌드 과정 어려움)

   • 게임 개념과 방향과 틀, 아키텍쳐 설계 (개발계획, 데이터 규격) 없이 직접 먼저 개발 시도

     → 이후 자유로운 코드 수정 및 시도할 수 있는 코드 제한적

2. 플랫폼 호환성

   • 플랫폼 종속적 코드 (Windows 전용)

   • windows.h, Sleep(), SetConsoleOutputCp() 등은 Windows 전용

     → Linux/Mac에서 빌드 불가