KPT 회고
1️⃣ Keep - 현재 만족하고 있는 부분
- 언리얼 스타일 구조 도입
- AActor()와 UObject와 같은 언리얼 엔진에서 다루는 구조를 구현
- BeginPlay(), Tick() [AActor()]을 분리해 프로그램 라이프사이클을 제어하는 구조는 정~말 좋죠??
- UObjectBase 기반 구조화
- Run() → BeginPlay() → Tick()으로 이어지는 프로그램 흐름을 통일 시킴
- 향후 EnemyAI, CutsceneSystem 같은 시스템도 동일 인터페이스로 확장 가능
- 몬스터 JSON 정의 및 드록 테이블 처리
- Data-Driven Design을 통해서 객체 생성을 용이하고 몬스터 추가 및 수정을 코드 없이 확장 가능.
- MonsterDefinition을 JSON으로 외부 분리하여 정의 - 구현 - 구조체 설계식으로 이후 한 로직 수정으로만 유지보수 용이.
- 게임 저장/불러오기 기능
- JSON 데이터 사용으로 현재 유지한 보조 기억을 주 기억으로 쉽게 남겨서 데이터 처리 원활
- 기존 데이터 수정으로 원하는 테스트 및 기능 구현 가능
- 플레이어에게 선택지를 주는 메뉴 기능 구성
- 콘솔 UI 환경에서 게임 루프가 명확하고 사용자 행동 기반 흐름이 깔끔.
- 메뉴 번호 기반 입력으로 플레이어 입장에서 UX상 직관적 플레이 가능
- 팀원 깃전략 활용
- Mster - Dev - Release로 관리하여 Git Conflict에 대해 예방 가능
- 깃 브런치 전략을 통해 팀원의 코드를 merge 후 통합하여 테스트 및 main으로 관리하여 형상관리에 능통했다.
2️⃣ Problem - 불편하게 느끼는 부분
- 초기 기획 구성 아쉬움
- 초기에 게임 환경 구축 미숙 (IDE 통일 실패로 인한 팀원 전반적인 빌드 과정 어려움)
- 게임 개념과 방향과 틀, 아키텍쳐 설계 (개발계획, 데이터 규격) 없이 직접 먼저 개발 시도
→ 이후 자유로운 코드 수정 및 시도할 수 있는 코드 제한적
- 플랫폼 호환성
- 플랫폼 종속적 코드 (Windows 전용)
- windows.h, Sleep(), SetConsoleOutputCp() 등은 Windows 전용
→ Linux/Mac에서 빌드 불가
- 소통의 부재 팀원 간 프로젝트 능동적 미참여
3️⃣ Try - Problem에 대한 해결책, 당장 실행 가능한 것
- 초기화와 리소스 처리 혼합
- BeginPlay()에서 캐릭터 생성, 저장 목록 불러오기, 로그 출력 등 너무 많은 역할 수행
- UI, 세이브로드, 던전 입장 및 분기, 캐릭터생성, 배틀시스템 호출 등 너무 많은게 들어있음
→ OOP / SOLID 원칙 준수 필요
→ 단일 책임 원칙 (Single Responsibility Principle - SRP) 미비
→ 클래스는 하나의 책임을 지게 하여 컴포넌트화 필요!
- 소스 원천 통합 필요
- 각 클래스의 멤버 변수의 값들을 다른 클래스 로직에서 이용하여 변경에는 열려있고 확장에는 닫혀 있어, 유지 보수 측면에서 불편함.
→ OOP / SOLID 원칙 준수 필요
→ 개방-폐쇄 원칙 (Open/Closed Principle - OCP) 미비
→ 개발 초기부터 확실한 아키텍쳐 설계 및 개발 구상도 필요.
- GameManager* GManager = new GameManager(); [main.cpp]
- 직접 new/delete를 사용하면 예외 발생 시 메모리 누수 위
→ std::unique_trp GManger =- std::make_unique();
스마트 포인터로 메모리 관리 효율 증가
- 에러 처리 부족
- 코드 진행 시 각 컴포넌트에서 예외처리 미숙으로 게임 크래시 발생 가능성 높음
→ 에러가 충분히 터질만한 구간을 try - catch로 감싸 사용자에게 오류 메시지 제공
→ 헬퍼 함수 및 Util을 작성해서 중복으로 사용되는 코드를 컴포넌트로 묶어 재사용
→ 에러 발생 예상 구간에 throw를 던져 코드 안정성 확보
- TDD 개발 설계 필요
- 깃전략을 사용했지만 Test 없이 사용한 코드를 통합 시 에러 방어 실패.
- 각자 따로 작성된 코드들을 합칠 때마다 에러 발생
- TDD 개발 방식으로 자신의 코드에 대한 신뢰성 증가 필요
- 발표준비 미흡
- 팀 프로젝트 후 발표 준비와 팀원 간 소통이 미흡하여
- 팀 프로젝트에 대한 장점과 단점 그리고 트러블 슈팅 미작성
