2. Tutorial 시스템 리팩터링 일지 (1)

---

2. Tutorial 시스템 리팩터링 일지 (1)

 

어쩌다보니까 이 카테고리에는 정말 오랜만에 글을 작성하게 됐다. 뭐든지 꾸준함이 좋은 것은 알지만 제대로 실천하기가 힘들다. 

 

이번 게시글은 이전에 작성하겠다는 내용이 아니라, 튜토리얼 씬을 리팩터링 하면서 생겼던 이슈에 관해서 게시글을 작성해볼까 한다.

 

튜토리얼 시스템을 왜 리팩터링 하는가?

지금 팀에 합류 당시에는 Shader를 개발하는 그래픽 프로그래머 직군으로 팀에 합류 했었으나, 여러 사정으로 인해서 클라이언트 프로그래밍도 담당하게 되었다. 기존에 이미 프로그래머가 3명이나 있었기에 내가 크게 필요로 하지는 않았으나 변동이 일어나면서 작업 할당량이 늘기 시작했다.

 

졸업 작품 팀에서 프로그래머 파트장을 담당하게 되면서, 이전 편에 작성했던 것 처럼 여러 내용들을 정리했고 작업 분배에 있어서는 기존 작업자의 시스템을 가져가는 것이 아니라, 신규로 기획하고 있는 시스템들을 구현하기로 했다. 우리 팀은 플레이어 담당자, 몬스터 담당자, 기타 담당자, 기타 담당자로 나눌 수 있었는데 이 중에서 기타 담당자의 포지션이 내 역할이었다.

 

기타 담당자가 2번  쓰인 것은 오탈자가 아니라, 같은 역할을 하는 인원이 있었기 때문인데 UI 프로그래밍이 진행되지 않은 상황이라서 해당 작업자에게 UI 프로그래밍을 맡기면서  기타 담당자가 1명으로 줄었다.

 

위의 모든 일들이 1학기 기말 발표 2주 전까지 일어났던 일이었는데, 기말 발표를 1주 정도 앞두고 팀에서 연출을 게임에 추가하고 싶다고 이야기가 들어왔다. 기한이 촉박한 상황이었고 UI를 담당하던 인원이 게임 연출을 진행하기로 했으나, 최종 마감을 지나도록 구현이 불가했고, 작업이 진행된 내용이 있어서 신규 인원이 재개발을 진행하는 것 보다는 기존 인원이 담당하는 것이 효율적이라 판단했다.

 

일정 관리에 어려움이 있는 것으로 파악을 하고 해당 담당 인원과 학교 내부에 있는 졸업 작품 실습실에서 4박 5일 정도를 같이 지내면서 게임 연출을 진행했다.

 

마감 기한이 촉박하고, 다급하게 진행이 되다보니 코드의 품질이 좋을 순 없었고 그 중에서 튜토리얼 시스템이 있었다. 방학 동안에 풀어나가야 할 과제였고 2학기 전까지 해결할 문제였으나, 여러 상황이 겹치면서 지금까지 오게 됐다.

 

구조를 고민하는 것은 힘들다.

노션에 작성한 업무 목록이다. 튜토리얼 시스템에는 크게 Perform(유저의 적응을 돕기 위한 온보딩 퀘스트) 시스템과 Dialog 시스템이 사용된다. 이 중에서 Dialog 시스템은 튜토리얼 뿐만 아니라, 게임 내부에서 지속적으로 사용되는 시스템이다. 그렇기 때문에 더한 고민이 필요로 했다.

 

Perform의 경우에는 단순하게 플레이어의 행동에 따라서 결정이 되기 때문에, 플레이어 담당자에게 플레이어 캐릭터의 행동에 따라서 Enum 값으로 빼내줄 것을 요청했다. 

 

UML에는 조예가 없는지라, 간단하게 PPT를 통해서 제작했다. 위 사진과 같은 구조를 통해서 진행이 된다. 이전에 블로그에 작성했었던 MVP 패턴을 참고했고 UIPerformBoardHandler에서는 Player 행동이 반환되는 Player Input Data를 가지게 된다.

 

이는 동작의 변경이 있을 때 마다, 수행이 된다. UIPerformBoardHandler에서는 UIPerformBoard를 관리하고 있으며, 현재 실행중인 Board는 Current Board로 가지고 있다. 동작 변경이 있으면 UpdateAction 메서드를 통해서 현재 진행중인 Current Board에 데이터를 넘겨준다.

 

UIPerformBoard에서는 데이터를 전달 받게 된다면, 동작에 해당하는 Action이 있는지 확인과 수행이 완료되었는가를 확인한다. Action이 존재하고, 수행이 완료되지 않았다면 해당하는 Action을 보여주고 있는 Sprite를 Normal Sprite에서 Clear Sprite로 변경해주고 isComplate를 True로 변경한다.

 

현재 Current Board에서 모든 동작이 수행됬다면, UIPerformBoardHandler에서 다음 Board로 변경해주는 작업을 한다.

 

해당 시스템을 구현하면서 고민이었던 점은 결속력 문제였다.

 

어떻게 결속하는 것이 좋을까.

팀 노션에 정리한 내용인데, 다시 한 번 블로그에서 설명해본다. Perform Board에는 수행 Action들을 유저에게 알려주기 위해서 Sprite를 통해서 안내해주고 있는데, 구조 설계 단계에서 SRP 요소를 고민했다. Sprite를 변경한다면 Sprite에도 스크립트를 달아줘서 관리하는게 올바르지 않은가?라는 고민이었는데, 기획자가 나중에 행동을 변경할 때, 한눈에 확인할 수 있도록 UIPerformBoard 스크립트에서 모든 Action을 관리하게끔 구현했다.

 

이렇게 구현을 실행하니까, Data와 Data에 따라서 상태가 변경되어야 하는 Sprite가 서로 이어지지 않은 문제가 있었다. Dictionary를 통해서 관리를 하고 있었는데, Key 값으로는 Player Input Data를 받고, Value로는 ActionData를 사용중에 있었다.

 

ActionData에는 Sprite의 인스턴스를 담고 있지 않기에, 별도의 기능이 필요했고, 위 사진에 있는 내용을 고민하다가 Object와 ActionData를 가지고 있는 PerfromActionDataGroup 클래스를 만들어 줌으로서 해결했다.

 

생각보다 내용이 길어져서 다음 편에서 Dialog System을 구현하면서 생긴 고민을 작성해야겠다.