게임개발의 숨은 기둥 인하우스툴

오영욱 (게임개발자)

krucef@gmail.com 


 

아타리가 <퐁>으로 술집 한켠에서 기계가 고장 날 정도로 동전을 벌어들인 것이 반올림하면 반세기 전의 일이다. 한국에서 당시 PC게임을 하던 사람이라면 대부분 추억하고, 2016년에 4탄이 나왔으며, 2018년에 모바일 게임으로도 나온 <창세기전> 시리즈는 출시된 지 24년이 지났다. <울티마> 시리즈의 아버지로 널리 알려진 리처드 개리엇은 혼자서 <Akalabeth>의 개발을 시작하였다. 이후 애플2 버전에 참여한 개발자는 두 명이었다. 또한 한국 게임산업 극초기에 나온 <신검의 전설>은 당시 고등학생이던 남인환이 혼자 개발하기도 했다. 그러나 컴퓨터게임의 역사가 흐르는 동안 게임 개발의 모습은 크게 변했다. ‘AAA게임’이라 불리는 블록버스터급 대형 게임의 경우 개발에 투입되는 인원이 수 백명이 되었다. <어쌔신 크리드> 프랜차이즈 중 <오리진>은 900명의 개발자가 참여하였고, 신작 <오디세이>는 1000명이 넘는 인원이 개발에 참여한 것으로 알려져 있다.

그렇다면 게임들은 어떤 방식으로 만들어졌고 지금은 어떻게 만들어지는가. 90년대 초, 주로 일본에서 들어온 게임 잡지나 개발 서적을 통해 찾아볼 수 있는 개발 방법론은 이렇다. 게임디자이너가 기획서를 작성하고, (지금은 주로 “아티스트” 직군으로 불리는) 그래픽 에셋 작업자가 기획을 기초로 그림을 그리고, 프로그래머가 코드를 작성한 이후, 음향 제작자가 준비한 음향을 입혀 게임을 구현한다. 그렇게 완성한 게임을 테스터, 혹은 QA(Quality Assurance, 품질보증)라는 직군이 버그 등을 테스트하고, 이후 게임을 출시한다.

현대의 게임 개발은 이 방법론을 그대로 적용할 수 없다. 하지만 게임 디자이너, 아티스트, 프로그래머, 사운드, QA라는 직군의 구분은 거의 그대로 유지되는 편이며, 이는 게임의 끝에 나오는 크레딧(만든사람들)에서 쉽게 확인할 수 있다. 다만 실제 개발 과정은 개발 팀마다 다른 편이며, 세부 직군이나 그 업무에서 차이가 나는 경우도 많고, 이전과 달리 테크니컬 아티스트 같은 복합적인 직군이 새롭게 생겨나기도 했다.

흔히 게임을 종합예술이라고 칭하는데, 이는 게임이 그림과 음악, 프로그램 코드 등을 종합한 결과물이기 때문이다. 게임 개발의 핵심은 결국 여러 작업물을 한데 모아 합치는 것이다. 하지만 초창기의 게임은 이런 식으로 개별 작업물을 코드나 리소스 파일을 통해 합치는 방식이 아니었다. 초기의 게임은 단일한 반도체 회로만으로 구성되었으며, 게임디자이너가 게임의 회로까지 모두 디자인한 것이다. 앞서 언급한 아타리의 <퐁> 역시 개발자 알 알콘이 게임의 전자회로를 설계했다.

프로그램 코드가 동작하는 CPU는 나중에야 사용되었다. 개발자의 숫자가 극적으로 늘어나진 않았다. 당시의 게임디자이너들은 대부분 프로그래머이기도 했기 때문이다. 당시의 게임은 지금처럼 이미지나 사운드가 다른 파일로 분리되지 않고 모두 게임코드에 삽입되었다. 또한 음을 합성하여 실제 악기와 비슷한 소리를 내는 미디(MIDI)가 등장하지 전까지는 삑삑 소리밖에 내지 못하는 컴퓨터 스피커의 주파수 대역을 지정해서 효과음을 만들어내기도 하였다.

 

 

그림 1  코드에 입력된 ET의 모습[1] 그림 2 실제 게임플레이에 등장한 E.T 

 

게임 개발 점점 복잡해지고 커지면서, 프로그래머 더이상 그림을 직접 그리지 않게 되었다. 초기의 그래픽 디자이너들은 컴퓨터 화면의 픽셀에 대응하기 위하여 모눈종이를 활용하기도 했다. 

Figure3_슈퍼마리오개발화면

그림 3 1985년의 슈퍼마리오 개발영상 중[2]

 

게임제작에 간단한 도형 이상의 그래픽이 필요해지면서, 게임에 사용할 이미지를 만드는 작업이 본격적으로 분리되기 시작했다. 이 과정에서 모눈종이에 그린 이미지를 디지털로 옮기는 작업을 위한 소프트웨어가 만들어지기 시작했다. 이러한 소프트웨어 덕분에 프로그래밍에 익숙하지 않은 사람도 게임 개발에 참여할 수 있게 되었으며, 프로그래머는 게임의 소스코드에만 신경 쓸 수 있게 되었다. 게임 개발에서 직군이 본격적으로 분리된 것도 이러한 소프트웨어 덕분에 프로그래머가 모든 일을 다 할 필요가 없어졌기 때문이다.

이러한 소프트웨어는 회사 안에서만 사용되었기 때문에 ‘인하우스툴’ 이라 불렸다.  인하우스툴과 게임개발 직군의 다양화 모두 게임 개발의 초기에 발생했다는 것을 생각하면 인하우스툴의 등장과 게임개발 직군의 분화는 많은 사람이 게임 개발에 참여할 수 있게 하며, 복잡한 게임을 개발할 수 있는 밑바탕이 되었다고 볼 수 있다. 이러한 인하우스툴은 이미지 변환 외에도 게임개발에서 사용되는 사운드나 폰트 등의 리소스를 제작하거나, 게임의 콘텐츠(예컨대 레벨이나 스테이지)를 쉽게 늘리도록 도와주는 기능을 가지고 있었다.

많은 인하우스툴이 일회용으로만 사용되고 버려졌으며, 여러 번 사용되더라도 외부에 공개되지는 않았다. 인하우스툴은 제작단계의 필요 때문에 만들어진 소프트웨어였기 때문에 필요한 기능만 가지고 있었고, 버그가 있어도 우회하면서 그냥 사용하는 경우가 많았다. 치명적인 버그가 아닌 이상 내부에서만 사용할 소프트웨어를 유지·보수하기 보다는 제품이 될 소프트웨어에 개발력을 집중하는 것이 나았기 때문이다. 그렇다 보니 인하우스툴의 품질은 외부에 유통되기까지는 부족한 경우가 대부분이었다. 덕분에 게임에 대한 관심이 매우 크지 않는 이상 인하우스툴을 아는 경우는 거의 없다. 게임 개발을 공부했더라도 현업에 들어온 이후에 자기 조직에서 쓰는 툴로 인하우스툴을 알게 되는 경우가 많다.

물론 인하우스툴 중에서는 그 편리함 덕분에 제품화로 이어진 경우도 있다. 일례로 1990년대에 게임을 개발하던 사람들에게 익숙한 <디럭스페인트>는 포토샵이 대중화되기 전까지 게임회사에서 가장 흔히 쓰이는 그림 저작도구 중 하나였다. 이 툴은 일렉트로닉아츠가 게임 저작용으로 만든 툴로, 상당히 많은 게임 개발자들의 손을 거쳐 갔다.

Figure4_디럭스페인트

그림 4 MS-DOS 용 디럭스페인스크린샷 

 

게임디자이너들을 위한 소프트웨어도 개발되었다. 80년대 등장한 <로드런너>는 게임 안에서 스테이지(레벨)을 만들수 있는 개발툴을 가지고 있었다. 이렇게 이용자에게까지 개발툴이 공개된 경우도 있지만, 보통 게임 안의 스테이지를 디자인하기 위한 툴은 게임과 따로 개발되었다. 게임디자이너들은 이런 툴을 이용하여 게임의 콘텐츠를 쉽게 늘려갈 수 있었다. 이러한 툴은 아티스트 직군을 위한 툴에서 시작하기도 하였는데, 먼저 3D가 대중화되기 전의 게임 개발에 대한 설명이 필요하다. 90년대 이전에는 대부분 용량이나 효율성을 이유로 게임에 사용할 이미지들을 타일로 잘게 쪼개서 배치하였다. 이런 방식으로 이미지들을 재활용할 수도 있고, 게임의 용량을 줄일 수도 있었다. 이렇게 배치하는 것을 돕기 위한 소프트웨어를 흔히 맵에디터, 타일에디터 등의 이름으로 불렀는데, 90년대 게임 개발 서적에서는 쉽게 찾아볼 수 있다. 초기에는 게임에서 사용할 이미지를 만드는 데 사용되었지만 게임 안 스테이지에서 사용할 정보도 툴에서 다루게 되면서 자연스럽게 게임디자이너들이 사용하는 툴이 갈라져 나왔다.

1990년대를 풍미한 상징적인 게임인 <둠>의 제작사인 이드소프트웨어는 이러한 인하우스툴을 활용했다. 이드소프트웨어의 초기작들은 대부분 TED(타일에디터)라는 인하우스툴을 통해 개발되었다. 이드소프트웨어는 TED를 이용하여 인기작인 <커맨더킨>의 초반 시리즈 세 작품을 세 달 만에 개발하기도 하였으며, 2D 액션 게임 뿐만 아니라 <울펜슈타인3D> 같은 초기 FPS 게임의 레벨을 만드는 데도 사용하였다.

Figure5_TED

그림 5 TED5 스크린샷

 

TED의 제작자인 존 로메로는 이외에도 <울펜슈타인 3D> 제작에서 사용된 사운드 저작툴이나, 존 카멕과 함께 개발한 <둠>의 레벨 에디터 <DoomED>를 개발하기도 했다. 톰 홀과 존 로메로는 이 툴 덕분에 훌륭한 레벨을 빠르게 디자인할 수 있었다. 존 로메로는 뛰어난 레벨 디자이너로 알려졌지만, 그가 직접 도구까지 만들었다는 사실 역시 주목받아야 한다.

실제로 존 로메로는 2016년 게임 개발자 콘퍼런스 유럽에서 진행된 ‘이드소프트웨어의 초기’ 발표에서 “좋은 툴이 좋은 게임을 만든다. 최대한 툴에 많은 시간을 할애하라[3]“라는 말을 통해 툴의 중요성을 언급하기도 하였다. 한편 다른 회사들이 이드소프트웨어의 엔진과 툴을 가져다 후속작이나 비슷한 게임 제작에 사용할 수 있게 하였다. 초기의 게임엔진 사업이었다.

통합 툴이란 이름으로 인하우스툴이 공개되는 경우도 있었다. 이 경우 각 회사마다 공개된 툴을 고쳐 쓰거나, 새로운 기능이 필요한 경우 만들어 쓰는 경우가 대부분이었다. 예를 들어 게임 안에서 애니메이션을 보여주기 위한 이미지를 자를 수 있는 스프라이트 툴이 있었고, 충돌처리영역 에디터는 스프라이트 툴에서 액션 게임에서 충돌할 영역을 지정하는 기능을 추가한 툴이었다. 이미지만 배치하는 타일 에디터에서 자신들의 게임에 필요한 기능들을 설정할 수 있게 발전시킨 레벨 에디터를 만들기도 하였다. 한글 폰트가 등장하기 전에는 폰트 에디터 역시 게임 개발에 빼놓을 수 없는 도구였다. 이러한 도구들의 등장과 더불어 게임 엔진과 그림이나 사운드 같이 에셋 파일들이 프로그래밍 코드에서 분리된 덕분에 작업자들은 코드에 접근하지 않아도 자신의 작업물을 확인할 수 있게 되어, 많은 사람들이 자신의 영역에 집중할 수 있게 되었다. 이렇게 만들어진 에셋을 통합시킬 때 사용하는 통합툴 역시 중요한 소프트웨어였다.

다만 국내에서는 몇몇 개발 서적이 이를 한데 모아 통합 툴이란 이름으로 소개한 경우 외에는 인하우스툴의 흔적이나 자료를 찾기가 힘들다. 컨퍼런스를 통해 공개된 경우가 종종 있어 이를 정리할 필요가 있다. 북미에서는 이러한 인하우스툴 소프트웨어를 이용하여 개발 기간을 단축하거나, 게임의 재미를 효과적으로 구현하였다는 발제를 쉽게 찾아볼 수 있으며, 최근에는 이러한 <고전 툴 회고> 시리즈가 미국의 게임개발 전문 뉴스 커뮤니티 사이트인 가마수트라[4]에 연재되고 있다.

오늘날에는 ‘언리얼 엔진’이나 ‘유니티’ 등의 상용 게임 엔진을 많이 사용하게 되면서 일반적으로 사용하던 게임의 인하우스툴들은 대부분 게임 엔진이 흡수하였고, 아트직군이 사용하는 도구들은 포토샵이나 3DSMax 등의 소프트웨어에서 수요를 흡수하였다. 덕분에 새로운 툴을 개발할 필요 없이, 게임 개발자들은 엔진에서 제공하는 툴을 사용하여 게임 개발에만 집중할 수 있게 되었다. 하지만 게임 엔진이 반복 업무를 줄이거나 필요한 정보를 충분히 제공하지 못하는 경우도 발생했다. 그래서 상용 게임엔진 언리얼 엔진의 경우 에디터의 소스코드까지 공개하였고, 유니티는 C# 스크립트를 통해 필요한 기능을 추가할 수 있게 하였다. 이런 기능은 각 회사가 운영하는 상점에서 판매되기도 한다.

그럼에도 불구하고 인하우스툴이 게임 개발에 사용되는 경우는 여전히 존재하는데, 게임의 규모가 커지거나 독특한 게임을 개발하기 위해서이다. 풍부한 이야기를 담은 롤플레잉 게임인 <위쳐3>은 이야기와 이야기의 분기가 많고 스토리를 전달하기 위해 영화처럼 보이는 캐릭터간의 대화, 일명 시네마틱이 매우 많았다. 이 대화 콘텐츠만 상당한 양이라 개발사는 스토리 작업자들이 조금이라도 쉽게, 그리고 애니메이터의 도움 없이도 자신들이 원하는 장면을 연출할 수 있도록 툴을 연출 전용 툴을 만들었다. 2017년 샌프란시스코에서 전세계의 게임개발자들이 모여 지식을 나누는 행사인 게임 개발자 콘퍼런스(GDC)에서 이 툴에 대해 발표하였다.

한편 기존 엔진으로 만족하지 못해 태어난 특이한 툴도 있다. ‘스파인’은 이미지를 뼈대로 이어붙인 후, 그 뼈대를 움직여서 동작을 구현하는, 일명 스켈레탈 애니메이션 툴의 한 종류이다. 스켈레탈 애니메이션은 어도비 플래시를 통해 많이 구현하였으나, 플래시의 이용이 줄며 게임 개발을 위한 전용 툴의 수요가 생겨나기 시작했다. 스파인은 제작사인 이소테릭 소프트웨어가 자기 회사의 게임 개발을 위해 제작하였고, 툴의 가능성을 보고 2013년 킥스타터로 자금을 모아 개발한 툴이다. 이후 현재는 수많은 게임이 스파인을 이용하여 제작되고 있으며, 출시 초기보다 많은 19가지의 게임 툴킷과 7개의 프로그래밍 언어를 지원한다.

 

Figure6_Spine

그림 6 스파인 툴

 

비슷한 예로 일본의 ‘Live2D’라는 소프트웨어가 있다. Live2D는 2차원 이미지를 3차원 애니메이션처럼 움직이기 위해 만들어진 소프트웨어로, 웹과 유니티 등의 게임 엔진에서 지원하고 있다. 국내에서도 <데스티니차일드> 같은 모바일 게임이 Live2D를 사용하여 화제가 되기도 하였다.

하지만 이런 경우들과 달리 많은 인하우스툴 소프트웨어가 여전히 일회용으로 간단하게 만들어져 소수의 인원 사이에서만 사용되는 경우가 많으며, 심지어 여력이 없어 툴 개발 대신 사람들의 반복작업으로 개발이 진행되는 경우도 많다. 예컨대 인하우스툴을 만들어 작업자들의 편의를 도모하는 대신 복잡하지 않은 프로그래밍을 작업자에게 가르쳐 개발 효율을 올려보자는 방법론도 존재한다. 특히 게임 안에서 소스코드로 구현되는 게임의 규칙을 다루는 게임디자인의 영역에서는 LUA 등의 스크립트 언어를 사용하여 게임 안의 콘텐츠를 게임디자이너들이 직접 작성해야 하며, 이를 통해 프로그래밍을 못 하는 게임기획자는 살아남지 못할 것이라는 과격한 주장이 나오기도 했다. 이는 게임엔진의 수정이 필요 없고, 인하우스툴에 제한받지 않는 개발이 가능하다는 장점이 있지만, 게임디자이너들이 스크립트 언어에 익숙해지는 시간이 많이 필요하며, 디버깅과 오류 가능성이 커지기 때문에 호불호가 갈리기도 한다

그러나 결국 문제는 인하우스툴의 사용이냐 스크립트 언어를 통한 개발이냐가 아니라, 내부에서 개발 과정을 관리하는데 얼마나 충분한 자원을 할애하는가에 달려있다. 반복작업이 늘어지고 시간이 오래 걸리면 실제 콘텐츠를 작성하는 작업자에게는 과중한 업무가 몰리기 마련이다. 잠깐 사용할 목적으로 만들어진 툴이 주변에 퍼지고, 정작 만든 이는 사용법을 잊어 문제가 되는 경우도 있다. 요컨대 툴이 개발에서 걸림돌이 되는 게 모두 개발자의 악의나 실수 때문은 아니다. 심지어 툴을 작성한 개발자가 퇴사하여 해당 툴을 분석하지 못해 업데이트가 안 되는 경우도 흔하다.

몇 차례 사용하지 않을 기능을 굳이 툴로 만들 필요는 없을 것이다. 쉽지 않겠지만 툴을 만드는데 드는 비용과 툴을 만들어서 절약할 수 있는 비용을 추산하는 것이 중요할 것이다. 하지만 국내에서는 툴의 중요함에 비해 툴 개발이 상대적으로 경시되고 있다. 툴이 생산성에 주는 영향을 고려한다면 툴의 중요성은 더 인정받아야 하지 않을까.

인하우스툴은 오픈소스 문화와 시너지를 내기도 한다. 오픈소스 문화는 프로젝트와 코드를 공개하여 여러 사람이 프로젝트에 참여할 수 있도록 만드는 문화이다. 이전과 다르게 코드를 공개하는 개발자 덕분에 인하우스툴까지 오픈소스로 공개되는 경우가 많아졌다. 이러한 툴들을 자신들의 상황에 맞추어 쓰던가, 작업하면서 수정한 버그들이나 새로운 기능들을 원래의 프로젝트에 추가하여 다른 사람들도 사용할 수 있게 하는 경우도 많다. 작은 툴이더라도 오픈소스로 공개하는 문화가 생긴다면 서로의 시간을 절약하고, 여러 사람의 참여를 통해 툴이 발전하는 기회가 될지도 모른다.

인하우스툴은 게임 개발을 효율적으로 만드는 중요한 요소임에도, 이에 대한 연구나 기록을 찾기는 힘들다. 국내 게임 프로그래머 커뮤니티가 적어지고, 게임엔진의 성능이 향상됨에 따라 그것을 어떻게 효율적으로 활용할 것인지에 논의가 집중되면서, 인하우스툴의 개발과 사용에 대한 논의는 과거보다 더 보기 힘들어졌고, 이것이 실제 개발로 피드백되는 경우는 더욱 찾기 힘들어졌다. 인하우스툴에 대한 관심이 커져 더 많은 개발 사례와 활용으로 이익을 얻은 사례가 외부로 알려지길 바란다. 이러한 시도들이 모여 게임개발자들이 더욱더 생산적으로 창의적인 게임을 만드는 데 도움이 될 것이라 확신한다. 그것을 위해서라도 인하우스툴의 개발자들이 더 조망 받았으면 한다

 


읽을거리

 

“The Early Days of id Software” 

게임개발자콘퍼런스 유럽에서 id Software의 핵심멤버인 존 로메로가 id Software의 초기와 자신들이 성공했던 비결들을 이야기하는 영상이며 당시의 증언을 생생하게 들어볼  있다. 

 

읽을거리2

클래식 툴 회고 : 존로메로가 30이 넘는 게임을 출시한 타일에디터 TED의 개발에 대해 이야기합니다.

(Gamasutra, https://www.gamasutra.com/blogs/DavidLightbown/20170223/289955/Classic_Tools_Retrospective_John_Romero_talks_about_creating_TEd_the_tile_editor_that_shipped_over_30_games.php)

게임 개발툴의 사용자경험을 디자인하기를 저술하고, 게임 개발자들에게 개발툴 제작을 가르치는 게임개발자인 David Lightbown 이 미국의 게임개발 웹진인 Gamasutra에 연재중인 클래식 툴 회고 시리즈의 첫번째 작. 2편은 팀스위니와 첫번째 버전의 언리얼 에디터, 3편은 크리스노던의 Deus Ex 개발툴에 대한 이야기이다. 현재 3편까지 나왔으며 당시 개발자들이 직접 툴에 대해 이야기하는 것을 볼 수 있는 흔치 않은 기회이기도 하다.  


[1]: “Atari 2600 ET sourcecode 1982”, https://gist.github.com/tluyben/f8b19965eaab6d236f9b

[2]: “Super Mario Bros. 30th Anniversary Special Interview,” https://youtu.be/DLoRd6_a1Cl

[3]: The Early Days of id Software”, https://youtu.be/E2MIpi8pIvY?t=797

[4]: www.gamasutra.com

 

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중

WordPress.com 제공.

위로 ↑

%d 블로거가 이것을 좋아합니다: