게임을 개발하는 과정에서 인하우스 툴을 많이 만들게 된다. 개발팀의 문화나 개발하는 게임의 특성에 따라 차이는 있겠지만, MMORPG처럼 컨텐츠 분량이 매우 많은 게임은 손으로 모든 컨텐츠를 만들어 넣기 어려우므로 툴에 의존하게 된다. 그런데, 한 번 게임을 만들고 비슷비슷한 후속작을 계속 내거나 만들고자 하는 장르에 딱 맞는 엔진을 구매하지 않는 한, 개발팀에서 적절한 툴을 만들어 사용해야 한다.
툴의 품질은 컨텐츠의 품질과 툴 사용자의 작업 효율에 큰 영향을 미친다. 직접 유저에게 서비스되는 코드가 아니라고 가볍게 생각하면 안 된다. 디버거 없이 메모장으로만 코딩한다고 상상해 보자… 회사 다니기 싫어지지 않는가?
좋은 툴을 만들기 위해 고려해봄직한 주제등을 정리해 보았다. 쓰다 보니 데이터를 만들어내는 데 전용 툴을 쓰는 경우와 텍스트를 직접 편집하는 경우를 구분하지 않게 되었다. 적절히 가려 읽어주기 바란다.
툴의 사용자는 사람이다. 사람은 실수한다. 어디서 실수했는지, 왜 잘못된 건지 알려주자. 데이터를 읽어들이는 코드를 짜다 보면 데이터를 해석하고 적재하는 코드보다 에러 검사하는 코드가 더 길어지기도 하지만, 당연한 것으로 받아들이자. 어차피 버그를 잡는 건 프로그래머의 몫이니, 데이터의 에러 검사에 미리 시간을 투자하자.
잘 알려진 툴과 인터페이스가 비슷하면 좋다. 3dmax나 포토샵이 제공하는 모든 기능을 만들 순 없겠지만 이왕 만드는 기능이면 단축키를 똑같이 하자. 배우기 쉬우면 좋지만, 그보다 더 중요한 건 익숙해졌을 때의 작업 효율이다. 실수를 하기 어렵거나, 했더라도 쉽게 알아볼 수 있도록 해라.
크래시 덤프 수집 기능을 넣어서 툴의 버그를 잡아라. 아마 대부분의 게임개발자들이 열악한 현실에 익숙해진 나머지 툴이 죽더라도 일단 담배를 한 대 태운 후 한숨을 쉬며 툴을 다시 띄울 것이다. 툴의 버그를 적극적으로 리포트하도록 독려해라. 그리고, 리포트한 사람에게 친절해라.
툴이 안 죽어야 되는 것은 기본이다. 죽더라도 오토세이브가 있으면 좋지 않을까 싶다(적용해보진 않았다). 여러 사람이 동시에 편집할 가능성을 고려해서 여러 파일로 분산해라. 모든 몬스터의 스킬 이펙트를 한 파일로 몰아넣는다거나 하면 두 사람이 동시에 몬스터의 스킬 이펙트를 편집할 수 없게 된다.
미리보기 가능한 것은 미리보기할 수 있게 만들어라. 하지만 미리보기가 실제 게임에 들어갔을 때와 다르게 보이면 절대로 안된다. 가급적 서버를 작업자의 개인 컴퓨터에서 띄워볼 수 있거나, 데이터를 커밋했을 때 팀 공용 테스트 서버가 그 데이터를 다시 읽을 수 있게 만들자(솔직히, 하기 힘든 일이긴 하다). 일찍 에러내라. 데이터가 실제로 사용될 시점에 에러내기보다는 서버나 클라이언트가 뜰 때 모든 데이터를 검사하고 에러를 알려줘라. 뜰 때 검사하기 어렵다면, 그런 에러에 대해서는 게임을 죽이지 말고 가벼운 경고를 띄우고 넘어가라.
캐릭터 레벨 세팅은 기본이고, 캐릭터를 무적 상태로 만들거나 퀘스트 상태를 변경하는 등 다양한 치트가 필요하다.
표 형태로 나타내기 적절한 데이터는 엑셀에 넣게 하자. 경험상 엑셀 파일에 적절한 패턴으로 데이터를 뽑아낼 범위를 명시하고, 게임이 데이터를 읽을 시점에 엑셀 파일을 직접 읽어서 텍스트를 뽑아내는 게 가장 좋았다. 우리는 C#으로 COM Interop을 이용해서, xls 파일을 읽고 txt 파일을 토해내는 일종의 컴파일러를 짜고, C++ 게임 코드에서 xls 파일과 txt 파일의 날짜를 비교해서 갱신이 필요한 경우 컴파일러를 실행하게 했다.
단, 과도하면 좋지 않다. 엑셀 테이블에 열이 너무 많아지는 경향이 보이면 외부 파일로 빼내거나 포맷을 수정할 것을 고려해 보자.
변환된 데이터를 직접 수정하게 하면 나중에 원본 데이터가 수정되었을 때 자동으로 최종 결과물에 반영할 수가 없다. 수정은 항상 원본에서만 하게 하자.
형상관리 시스템(svn같은)에 친화적이고 데이터 검색도 쉽다. 에디터를 안 만들어도 된다! 대신 에디트플러스 구문강조 문법 파일 정도는 어렵지 않으니 만들어서 보급하도록 하자. 주석도 쓸 수 있으면 좋다. 문제가 생겼을 때 데이터 문제인지 프로그램 문제인지 빠르게 파악할 수 있다. 물론 플레인텍스트는 읽고쓰기가 바이너리보다 느리다. 어디서 쓰고 어디서 쓰지 말아야 할지 적절한 타협점을 찾도록 하자. 속도가 정말 중요한 경우와 확장성이 정말 중요한 경우는 거의 겹치지 않을 거다.
해석기parser를 짜는 부담이 훨씬 줄어든다. XML이 대표적인 예고 루아도 답이 될 수 있다. 우리는 처음에 XML 비슷한 바이너리 포맷을 만들었다가 텍스트로 확장했고 엑셀->텍스트 변환기와 DTD 비슷한 것도 만들었다.
뭐가 됐든 생각도 못했던 기능을 추가하게 된다. 자기서술적인 데이터 포맷을 쓴다면 사소한 기능 추가에 유연하게 대응할 수 있다. 덤으로 디버깅하기도 쉽다. 버전 정보를 남기면 포맷이 업그레이드되었을 때 과거 포맷을 읽을 수 있게 할 수도 있고, 최소한 과거 포맷을 새 프로그램이 읽다가 죽어버리는 건 피할 수 있다.
사용자와 이야기를 많이 해라. 단, 사용자의 성격에 주의해라. 분명히 생산성을 개선할 여지가 있는데 그냥 적응해버리거나 얘기를 안 하고 넘어가기도 한다. 단순작업, 반복작업은 기계가 하게 해라. 그리고, 반드시, 직접 사용해 봐라.
초기에 툴을 대충 만들고 방치할 경우, 팀의 병목으로 작용하고 있는데도 모르고 지나칠 수 있으니 주의하자.
사실 인하우스 툴의 생산성을 개선하는 작업은 프로그래머의 시간으로 다른 직군의 시간을 사는 것이기 때문에, 프로그래머들의 시간이 부족하면 좀처럼 하기 어렵다. 출시 날짜가 다가오면서 야근야근 열매를 월화수목금금금 먹고 있는데 툴을 사용하는 사람이 칼퇴근하고 있으면 툴의 문제가 눈에 들어오지 않을 뿐더러 문제를 알아도 고치고 싶지 않을 거다. 이쯤 되면 프로그래머를 비난할 수는 없고, 직군을 초월한 매니저급의 의사결정이 필요한 부분이다. 하지만 프로젝트 초기에는 아무래도 시간이 널럴할 테니 툴을 만들 때 이런저런 고민을 많이 해보기를 권한다. 툴의 품질에 투자하는 만큼 팀 동료의 효율이 올라가서 멋진 컨텐츠를 슴풍슴풍 뽑아내는 것을 보면 꽤 재미나고 보람차다.
여기까지 써놓고 짜식는 소리를 하는 것일 수도 있지만, 너무 일찍 툴을 만드는 것은 안 좋을 수도 있다. 어떤 게임을 만들지 확실히 결정하기 전에 툴부터 만들면 좀더 다양한 게임성을 탐색할 여지를 억제할 수 있다. 기존에 검증된 게임성을 가져다 쓸거면 모르겠으나, 툴보다는 프로토타입이 먼저다.