현재 사용하고 있는 엔진은 오픈소스 게임엔진인 Ogre3D 이지만 전체 시스템을 구성하기 위하여 database, script, statechart, management factor 를 추가로 구현하였다. 아래는 그간 구성하면서 느꼈던 점과 개선안을 정리한 개인적인 문서이다.
1. 에디터를 위한 UI 는 database 와 자동으로 연결이 되어있어야 한다. 즉, 어떤 기능을 만들고 table 을 만들어 수정가능하도록 구현하였다면, 새로운 기능의 table 을 수정하기 위한 에디터가 필요하게 되는데 이 작업이 매우 번거롭다. 최종 사용자가 아닌 내부 개발자 혹은 디자이너, 기획자가 사용할 에디터이므로 더더욱 미적 감각보다는 database 를 자동으로 반영하여 에디터를 자동으로 생성해 내는 쪽이 편리할 것 같다. 두번 이상의 반복은 죄악이다.
2. script, state, database 는 게임 안에서 바로 수정가능해야 한다. 윈도우로 나갈 필요도 없다. 직접 구현을 해보고 적용을 해보니 이 컨셉이 생각보다 유용하다. 좀 더 강력하게 보완해야 할 것 같다.
3. database 는 boost seriallizer 여 연동하여 xml 파일 시스템을 사용하고 있는데, 정의와 버전관리가 번거롭다. 새로운 테이블은 언제든지 수정되거나 추가/삭제 될 수 있으며 이는 기존 데이터의 무결성에 영향을 주어서는 안되며 컴파일 없이 이루어져야 편리하다. 마찬가지로, boost 를 적극적으로 사용하다 보니 성능은 우수하지만 컴파일 타임이 늦어지고 serializer, statechart 등이 빌드에 종속적이라는 것이 매우 큰 단점이 되었다. 성능적인 우수함을 손해보더라도 database 와 state 는 동적으로 제어 가능한 것이 좋을 것 같다.
4. 모든 모듈은 언제든지 붙였다가 땔 수 있어야 한다. 특히 게임상에서 listener 와 같은 녀석들을 효과적으로 제어할 수 있는 기능은 개발의 국제화(외국 프로그래머 및 외주에서 작업)에도 도움이 된다. 이는 모듈화를 더욱 잘게 쪼갠 개념인데 어떤 라이브러리 및 기능단위로 나뉘는 것보다 더 작은 규모인, "작업" 단위의 모듈을 말하는 것이다. 이렇게 잘게 쪼게어진 모듈은 자체가 단위 테스트가 될 수도 있다.
5. 이번 엔진을 설계할 때, 큰 줄기를 statechart, script, database, listener 로 삼았는데 개념적 확장이 필요할 것 같다. 기본 개념은 statechart 는 상태 진입/종료 시 script 를 호출하고 스스로는 자신의 상태와 어떤 상태로 전이 될 수 있는 지 등의 기본 개념만 알고 있다. script 는 누가 자신을 실행했는지, 현재가 어떤 상황인지는 모르고 그저 일하라고 하면 자신을 일만 하면 된다. database 는 말 그대로 database 로써 script 및 listener 에서 상수로써 접근하여 사용한다. listener 는 "작업" 단위로써 랜더 루프에 언제든지 꼽거나 뽑을수 있는 형태로 구현하였다.
6. UI 는 역시 flash 다! flash 를 사용할 경우 가장 큰 이득은, 개발자가 UI 를 "완전"하게 무시할 수 있다는 데 있다.
