Code Complete

프로그래밍을 하다보면 기존의 상태를 유지한 상태에서 이벤트 Scene나 서브 게임 Scene으로 전환해서 플레이하다가 처음의 메인게임 Scene으로 돌아가야하는 경우가 있다. 

이런 경우 각각의 Scene을 클래스화하고 관리자에 키워드와 함께 등록해서 사용하면 편리한데 각각의 Scene을 상황에 따라 2차원이나 3차원으로 쌓을 수 있다.

그림에는 프로젝트에서 사용했던 관리자 클래스와 개념도만 나와있지만 관리자에 Scene 클래스가 포함되며, 팩토리를 이용해 생성하거나 등록하게 꾸밀 수 있다.

이런 식으로 Scene 관리를 꾸미면 데빌 메이 크라이3 에서처럼 캐릭터를 컨트롤하는 와중에 이벤트 데모를 플레이해주고 데모가 끝났을 때 데모 플레이 직전의 상태로 돌아가는 구조를 간단

하게 구현 할 수 있다. 

우선 Blood Summoner 프로젝트에서 사용된 Network SyncFSM을 간단히 살펴보겠다.

간단히 설명하면  실시간으로 발생하는 내부 이벤트나 유저 컨트롤, 패킷등을 이벤트 메니저가 관리를 하고 있다가

 EventProgress 인터페이스에서 이벤트를 일괄처리하는 부분이 있는데, 이 이벤트 처리 코드가 switch - case를 사용하고 있다.

자 ~ 우선 switch - case 사용이 무엇이 문제인가. 본인이 생각하는 단점들을 나열해 보겠다.

첫째, switch - case 는 if - else 구문과 같기 때문에 이벤트가 많아지면 결과 도출까지의 비용이 커진다.

둘째, 별로 C++스럽지 못하다.

셋째, 함수가 엄청 길어질 수 있다.. 최악의 경우 몇천에서 만단위까지 

넷째, 스택 이용 메모리가 굉장히 커질 수 있다.

그러면 어떻게하면 비용을 줄이면서 더욱 C++ 스럽게 할 수 있을까?

각각의 이벤트를 클래스로 정의하고 C++의 다형성을 이용하면 깔끔하게 해결된다.

단점 

- CASE 무지하게 많아지면 결국은 이것도 객체를 찾는게 일이다.

- 일반적으로 SWITCH_CASE 보다 느리다.

- 컴파일러가 발전하면서 점프테이블을 잘 만들어준다. (관리하지 않은 switch case 문제 중 하나 해결)

다른 방법 링크 : 함수 포인터 이용

풀에서 Free 객체를 얻고 ID를 할당 후 빌더를 통해 객체의 최종 동작 형태를 결정한다.

Blood Summoner 프로젝트 처음 제작한 RTS인데 제작 기간은 7개월을 초과하면 안되는 상황이었다.

아키텍처를 설계하는 입장에서 제작의 편의성과 함께 속도를 생각하지 않을 수 없는 상황이었는데 결국은 리소스 풀과 함께 Actor 객체 풀도 사용하기로 결정했다.

POOL을 사용하기로 결정한 후엔 POOL의 스팩과 역활을 결정하는 일이 남았는데 메모리 블록화 방지와 참조국소성을 좋게하기 위해 스테이지 로딩 시점에 해당 스테이지에서 최대 한도를 초과하지 않는 객체를 미리 할당하기로 했다.

실직적인 객체들은 배열의 형태로 생성되어 있으며 Pool 인터페이스를 통해 인스턴스를 얻으면 Actor를 가리킬 수 있는 포인터에 주소를 얻고 ID를 부여한 후 빌드를 해서 사용한다.