오늘 할 일
- 맵 빨리 유기하기
- 피격 처리
- 사망처리
- 가드 상태(플레이어 액션 상태) 저장
- 공격 강도, 방향 전달용 구조체 만들기
- 코드리뷰
문제점
플레이어 쪽은 ActionComponent 적 쪽은 CombatComponent를 사용 중
ActionComponent는 액션 자체에 대한 구조화가 잘 돼있는 반면 전투 관련 처리는 미비(충돌 처리 등) CombatComponent는 충돌 처리가 잘 돼있지만 다분히 Enemy향으로 설계돼있음
따져봤을 때 ActionComponent로 통합하고 전투 로직을 ActionComponent에 추가하는게 이상적이나 시간이 부족하므로 전투 로직은 CombatComponent를 사용하고 현재까지 구현돼있는 회피, 전력질주, 가드는 ActionComponent를 사용하기로 함
그런데 이 타협의 가장 큰 문제는 상태가 파편화돼있다는 점임. ActionComponent에서 액션의 상태를 관리해야하지만 CombatComponent에서 전투관련 상태를 따로 관리함. 이를 통합한 통합상태가 PlayerCharacter에 생길 수밖에 없음.
이 구조의 문제점:
- 아무리 잘 관리한다 해도 결국에 상태 동기화를 놓칠 여지가 큼
- 상태가 여러개여서 복잡도가 매우 높아짐
지금 생각해보니 ActionComponent가 게임에서 일어나는 모든 액션을 관리하겠다는 역할인데 너무 과한 설계였나 싶다. 데이터 드리븐 개발방식에서 데이터 → 액션컴포넌트로 진입점이 단일화되는 확실한 장점은 있지만 그만큼 블랙홀처럼 모든 기능들이 이 설계 위에 올라가야하는 강제성이 생기게 된다.
액션 컴포넌트에서 액션 데이터를 파싱해 게임에서 쓰기 좋게 정리하는 부분을 서브시스템 게임인스턴스로 이관하고 액션 컴포넌트와 액션 애니메이션 컴포넌트를 하나로 합쳐야 했나? Vertical Slice가 아닌 Horizontal Slice를 만들거면 컴포넌트보다 서브시스템 레벨로 격상시키는게 좋을 뻔 했다. 컴포넌트는 결국엔 쓸지말지 선택할 수 있는 여지가 있기 때문에, 혼자 개발하거나 작업의 순차성이 완벽히 보장되는 환경이 아니라면 다소 현실성이 없을 수 있다.