항상 예전부터 자체 엔진에 대해서 글을 쓰고 싶었다. 우리는 왜 자체 엔진을 써서 작업하는가? 뭐 그런 것에 대해서 말이다. 하지만 쉽사리 맘에 드는 글이 써지지 않아서, 몇번을 지우고 쓰고, 지우고 쓰고 반복하다 결국 이 변명같은 글을 하나 던져본다.
나는 올드한 개발자다. 정통성이 있다거나 오래했다거나 하는 자랑 섞인 이야기가 아니다. 그저 오래전 습성을 변경하지 못한다는 뜻이다. 코드 스타일은 요즘 많이들 쓰는 오픈소스 스타일이 아니라, 오래전 PC 통신에서 유행하던 코리안 스타일을 사용 중이다. 도스 편집기의 사용 기억 때문에 복사는 Ctrl+Insert, 붙여넣기는 Shift + Insert, 잘라내기는 Shift + Delete를 사용한다. 그래서 해당 단축키가 먹지 않는 편집기는 사용 하질 못한다(플래시 코드 편집기나 랜더몽키 따위…).
심지어 도스에서 윈도우로 넘어가는 과도기 시절에도 C++를 사용해서 윈도우 프로그래밍을 하는게 아니라. MS Quick-Basic으로 도스 게임 만들기에 여념없었다. 윈도우 프로그래밍으로 넘어 와서도 VC를 사용하여 게임을 만들기 보단, 이제는 아는 사람도 거의 없을 다크 베이직 같은걸 잠시간 파보기도 했었다. 베이직으로 무언가 해보겠다는 신념보다는 그저 베이직이 익숙하기에 다른걸 쓰기 싫었던 것이였다.
그 당시엔 X모드라 불리던 320×200의 256컬러 모드를 사용하기 위해, 인터럽트 13h를 호출하고, 단순히 점을 찍기 위해 메모리상에 이짓저짓을 한다. 그리고 그 점찍는 루틴을 확장하거나 속도를 위해 몇 가지 트릭을 써서 선, 사각형, 그리고 이미지를 직접 디코딩해서 한 줄씩 복사해 넣어서 스프라이트를 만든다. 모든 일은 점을 찍는 일의 연장이고, 단순히 화면에 그림 한장을 그리기 위해서는 아주 많은 코드량과 지식이 필요했다(감이 잘 안온다면 회사에 10년은 더 일한 늙으스레한 프로그래머, 혹은 코딩따위는 안한지 10년쯤 된 관리자 아저씨나 혹은 사무실 앞 치킨집 사장님에게 물어보면 눈을 반짝이며 무용담을 늘어 놓을 것이다).
그 시절도 라이브러리는 꽤 많았다. 개개인들이 공개한 여러 라이브러리들이 있었고, 그 라이브러리들을 모아서 하나의 엔진처럼 사용했다. 여러 라이브러리를 전전하다 그래픽 라이브러리는 토우켄 라이브러리라는걸 사용했던 기억이 난다(개발자는 N사의 고양이 마크를 사용하는 팀의 그 실장님으로 기억한다). 게임을 만들다 보니 베이직으로 짠 코드는 너무 느려서, 결국 어셈으로 간단한 코드를 짜고 베이직에서 불러와 사용하면서 라이브러리도 직접 만들어 쓰게 되었다. 나에게는 그 그래픽 엔진이 OpenGL이였고 DX였였다, 그 사운드 라이브러리도 OpenAL이나 DS같은 것이였다. 그러한 여러 라이브러리들을 모아 게임을 만들었었다.
필드에 나와서 여러 회사를 거치면서 여러 게임을 만들었고, 그러면서 상용 엔진도 몇 종 써보고, 검토도 해봤지만 거의 대부분 자체 엔진을 선택했다. 어릴때부터 해왔던 관성도 있고, 비싸서 구매 승인이 떨어지지 않은 경우도 있지만, 가장 큰 요인은 그때 개발하던 게임이 그런 엔진을 구매할 정도의 규모가 되지 않는 경우가 많았다. 개인적인 욕심이라면 그냥 사달라고 조를 수 도 있겠지만, 대부분 게임은 그러한 엔진이 필요한 게임이 아니였다. 게다가 해당 게임에 적합한 엔진도 없었다. 게임마다 필요한 기능이 다르기 때문에, 어차피 엔진을 사와도 우리 게임에 특화된 부분을 만들어야하며, 최악의 경우에는 해당 엔진에 맞춰서 게임을 변경하는, 그런 억지로 우겨넣는 일도 생길 수 있기 때문이였다.
엔진을 게임에 맞춰 수정할 일이 뭐가 있겠냐 싶지만 코딩을 하다보면 상당히 많았다. 오래 전 PSP의 예를 들어보자. 해당 기기의 경우 시스템 메모리와 비디오 메모리의 구분이 없이 32메가 였다. 물론 그 안에 OS가 뺏어먹는 용량과 프로그램 실행파일의 용량, 실행 시 스택의 용량까지 모조리 다 넣어야 했다. 또 사용되는 미디어인 UMD는 CD와 마찬가지의 기능을 갖고 있기 때문에 파일의 위치가 연속이 아닐경우 Seeking 타임 만으로도 시간을 엄청나게 잡아 먹을 수 있는, 함수를 호출하면 언제 리턴이 될지 예측할 수 없는 뭐 그딴 기기 였다. PC 게임에서 사용하는 방식으로 리소스 및 시스템을 구현해서 첫 게임을 돌려보았을 때 첫 스테이지는 로딩만 50초가 걸렸다. 남코 놈들이 왜 로딩에 미니게임을 넣었는지 알 수 있었다.
그래서 이런 방식을 사용했다. 하나의 스테이지에서 사용하는 데이터는 하나의 팩 파일로 무조껀 모아 넣는다. 그로서 파일 파편화 문제에서 자유로와 졌으며, 덤으로 디자이너분께 사용가능한 용량의 제약을 정확히 알려 줄 수 있었다(데이터 폴더에서 배치파일을 실행시킨후 나온 파일이 5메가가 넘으면 안됩니다. 같은 식의…). 팩파일에서 파일을 가져와 가공 할 수 있는 메모리 자체가 부족했기에 메모리에 올린 팩 파일에서 메모리 주소를 따와 이미지를 찍을 수 있게 뜯어 고쳤다. (위에서 이야기 했듯이 시스템 메모리와 비디오 메모리의 구분이 없기때문에 가능한 방식이였다.) 포인터 주소를 4의 배수를 맞춰줘야하는 CPU의 제약 덕택에 팩파일은 아에 파일의 시작 주소 위치가 4의 배수가 될 수 있도록 정렬해 넣었다. 위에 언급한 몇 가지 최적화로 로딩을 10초 안쪽으로 떨어 뜨렸다. 남의 엔진을 사용했다면? 아마도 게임의 몇몇 부분을 삭제하지 않았을까?
어쨌든 그러한 연유로 계속, 계속 자체 엔진으로만 달려왔다. 필요한 공개 라이브러리들을 모아서 해당 게임을 만들기 위해 필요한 엔진을 만들어낸다. 신규 플렛폼에 들어갈 때는 게임의 코드와 엔진의 인터페이스까지 같은 걸 쓰고, 꼭 PC에서 게임이 돌아가도록 크로스 플랫폼으로 짠다. 엔진의 단위보단 코드의 모듈 단위로 재사용을 하는 쪽이 훨씬 쉽다.
이러한 방법으로 경쟁사들이 신규 플랫폼에 들어가며 몇 개월씩 허비 할 때, 좀 더 일정을 앞당길 수 있었다. 또 이러한 방법으로 경쟁사들이 범용적인 엔진에 게임을 우겨넣어서 30프레임짜리 게임을 만들때, 우리는 최대한 가볍게 만들어 60프레임을 유지할 수 있었다. 그리고 한 번더 강조하지만 이 글을 읽는 대다수의 사람들이 만드는 게임은 엔진의 구매가 필요한 수준의 게임을 만들지 않는다. 시장에 나오는 70~80%의 게임은 그렇게 비싸고 무거운 엔진이 필요한 게임이 아니다.
위에서 열심히 변명을 해보았지만, 요즘처럼 훌륭한 공개 엔진도 많고, 상용 엔진도 싸게 파는 시기에 자체 엔진은 어떻게 보면 참 궁상맞은 짓인 것 만은 맞는 것 같다. 그래도 1톤 트럭도 오토로 나오는 세상에서, 아직도 수동 차량을 좋아하는 사람도 있고, 수동 차량이 더 적합한 도로 상황도 있는 법이다. 적어도 수동타면 급발진은 없잖아?