플레이어 코드 설계하기

튜토리얼 맵을 만드는 과정에서 테스트용으로 간단하게 플레이어 코드를 작성했다. 현재 기능이 많이 구현되어 있지 않은 상태에서 코드의 구조를 정립하는 과정에 대한 글이다.
 
0. 개요
1. 플레이어의 기본 기능
2. 해당 플레이어에 적합한 코드 형식
3. 후기
 
 
 
 
 

0. 개요

바로 코딩하는 것보다 전체적으로 어떤 기능을 가지고 있고, 해당 기능을 바탕으로 유지보수하기 좋은 코드 구조를 미리 고민하는 것이 효율적이어서 생각의 과정을 정리하는 글을 쓰게 되었다.
 
 
 
 

1. 플레이어의 기본 기능

우선 생각한 플레이어의 기능을 정리하면 아래와 같다.
 
<상호작용>
* 카메라가 플레이어를 부드럽게 따라가는 것
* 플레이어 이동(방향키)
* 다양한 물체와 상호작용(닭, 집, 수도꼭지..등등)
 
<플레이어 데이터>
* 해금한 요리 종류
* 플레이어가 조합한 단어 종류를 처음 실행할 때, 해당 부분 순간 캡쳐해서 저장하는 이미지 데이터
* 플레이어가 진행중인 스테이지 데이터 저장
* 플레이어가 찾은 단어 데이터
* 사운드 효과 데이터
 
일단 현재 생각나는 부분은 이와 같다. 이후 추가해야 할 기능이 있으면 추가할 계획이다.
 

2. 해당 플레이어에 적합한 코드 형식

내가 플레이어의 코드를 짤 때의 목표는 아래와 같다.
* 기능 확장 용이
* 유지보수 용이
* 기능별 독립적인 구조

 

 

2.1. Component Pattern

한 클래스는 하나의 책임만 가지는 SRP를 적용해 플레이어의 역할을 클래스별로 나눠서 적용할 것이다.

 

<예시>

* PlayerController

= 플레이어의 전반적인 기능 컨트롤

* PlayerInteraction

= 플레이어와 오브젝트 간 상호작용 처리

* PlayerMovement

= 플레이어의 키 입력 받아 이동 처리

* PlayerMemory

= 플레이어가 찾은 단어, 요리, 조합 기록

* PlayerStageState

= 플레이어의 현재 위치, 스테이지 정보 저장

 

위와 같이 클래스별로 기능을 나눠 코드를 작성한다. 

 

2.2. FSM
플레이어의 상태 별로 발생하는 상호작용이 명확하고, 입력 중에도 조합을 완료해 실행하거나 취소해야 한다. 또한 상호작용 중 또 다른 상호작용이 일어나면 안되므로 현재 상태에 허용되는 행동을 명확히 제어해야 한다. 
그러므로 행동에 따른 상태를 깔끔하게 나눌 수 있는 FSM을 이용하는 게 좋다고 생각한다.
 
나눈 상태는 아래와 같다.
* Idle
= 기본 대기 상태.
= 모든 행동의 출발점
= UI, 입력창 열기 가능
= 오브젝트와 상호작용 가능
 
* Moving
= 플레이어가 이동중
= 오브젝트와 상호작용 가능.
= 카메라 움직임 활성화
= 이동 키를 눌렀을 때 해당 상태 활성화
 
* Interacting
= 오브젝트와 상호작용중
= 이동, 입력, 단어 조합 모두 제한
= 대화, 반응 애니메이션 등 재생 가능.
= raycast로 상호작용 가능 오브젝트 충돌시 활성화
 
* TypingWord
= 플레이어가 단어를 입력하는 중
= 이동과 상호작용을 동시에 하면 컨트롤 충돌 위험
= 단어 입력 UI가 열리고, 커맨드 준비가 완료되었을 때 활성화
 
* ExecutingWordCommand
= 입력한 단어 조합 실행 중(ex : water boils)
= 실행 중에 애니메이션, 사운드 등 작업 발생
= TypingWord가 성공적으로 진행되었을 때
 
* ObersvingData
= 플레이엉 데이터 UI 열람 가능
= 이동, 상호작용 제한
= UI를 확인할 때
 
해당 상태들을 그림으로 나타내면 아래와 같다.

 

 

 

 

 

2.3. Observer Pattern

플레이어 내부 컴포넌트끼리 통신할 때 해당 객체의 상태가 바뀌면 의존 관계에 있는 객체의 값들이 자동으로 갱신되도록 지정해야 한다.

또한, 이벤트를 즉시 호출해 비동기 큐에 넣지 않고 직접 함수의 호출로 처리하기 때문에 즉각적인 반응에 용이하다.

마지막으로 실행 타이밍이 예측이 가능해 유닛 테스트를 실행할 시 효율적이기 때문에 컴포넌트 간 통신할 때 옵저버 패턴을 적용하기로 했다.

 

 

++ 추가로 매니저는 싱글톤/서비스 로케이터, 퍼즐의 작용은 커맨드 패턴을 이용하기로 결정했다. 그리고 플레이어 외부 시스템과의 연결(UI, 사운드 등)은 Event-driven 구조를 사용할 계획이다.

UI에서는 MVP/MVVM 중에서 고민이다..

 

3. 후기

어떻게 구현하는 게 좋을지 고민하면서 디자인 패턴에 대해서도 다시 공부하게 되었고, 내 게임에 더 적합한 구조가 무엇인지 고민하는 계기 또한 되었다. 이제 플레이어 코드를 재정비하고, 튜토리얼 씬부터 구현을 시작해야겠다.