GPG 보내기
패트릭 와이엇 | 2012년 7월 25일 | 원문보기
[역자의 말: 워크래프트의 프로듀서이자 리드 프로그래머였던 패트릭 와이엇이 1990년대 중반으로 돌아가 워크래프트를 만든 과정을 이야기합니다. 패트릭 와이엇은 워크래프트 외에도 블리자드에서 디아블로와 스타크래프트, 그리고 이후 창립한 아레나넷에서 길드 워의 개발을 이끌었으며, 현재 엔 매스 엔터테인먼트에서 COO를 역임하고 있습니다.]
옛날 옛적에, 그러니까 PC 게임이 DOS 운영체제용으로 만들어졌던 시절, 나는 《워크래프트》(Warcraft)라는 게임을 만들기 시작했다.
프로젝트를 이끌게 되다!
나는 몇 개의 PC 게임과 두 개의 매킨토시 게임, 슈퍼 닌텐도와 세가 제네시스용으로 일곱 개의 콘솔 타이틀을 개발했지만, 그 프로젝트들에선 모두 보조역을 맡았거나 프로젝트 자체가 독자적인 개발보다는 ‘이식’이었다. ‘이식’이란 어떤 플랫폼으로 나온 게임의 코드와 디자인, 아트웍 등을 변환하여 다른 플랫폼에서 동작하도록 옮기는 과정이다.
내 역할은 두 가지로 압축되었다. 프로듀서(프로젝트 관리자, 디자이너, 전도사, 고양이 돌봄이를 의미하는 게임 업계 용어)로서 팀을 이끄는 일과 리드 프로그래머로서 게임 코드의 대부분을 쓰는 일이다. 당시에는 이런 겸임이 그다지 벅찬 일이 아니었다. 오늘날 개발팀은 2백 명을 넘나드는데 당시에는 하나의 프로젝트에 열 명 정도의 개발자만 고용되었다.
《워크래프트》의 근원
내가 일했던 스타트업 회사(당시에는 ‘실리콘 앤 시냅스’란 이름이었고 이후 우리의 눈보라 같은 개발 방법론을 빗대어 ‘블리자드’라 이름 붙였다)의 개발자들은 자유 시간에 대단히 많은 게임을 플레이했다. 그리고 그런 게임플레이 경험에서 《워크래프트》를 만들 아이디어가 나타났다.
우리가 《워크래프트》를 만들 생각을 하게 된 것은 웨스트우드 스튜디오가 만든 《듄 2》(Dune 2)라는 게임을 플레이(하고 또 플레이하고 또 플레이)하고 난 뒤였다. 논쟁의 여지가 있지만 《듄 2》는 스크롤 되는 지도, 유닛의 실시간 생산과 이동, 개별 유닛의 전투 행위가 있는 현대적인 실시간 전략(real-time strategy, RTS) 게임의 시초였다. 《듄 2》는 규모와 그래픽 품질을 제외하고 디자인 면에서 《스타크래프트 2》 같은 최근의 RTS와 크게 다르지 않다.
그 전작인 《듄 1》은 그 자체로 가치가 있고 어느 정도 후속작과 공유하는 요소가 있지만, 어드벤처 게임 속에 반실시간 전투가 들어간 형태였다. 《듄 2》는 플레이어가 게임 세계 속에 캐릭터로 나타난다는 전작의 관념을 버리고, 자원을 채취하고 기지를 건설하고 다시 자원을 채취하고 군대를 구성해서 적을 찾아 정복하는 현대 RTS의 장치에 집중했다.
블리자드의 다른 사람들처럼 나도 점심시간과 업무 이후에 《듄 2》를 속속들이 플레이했다. 세 종족을 모두 플레이하며 각각의 강점과 약점을 파악하고, 이후에는 사무실의 다른 사람들과 플레이 스타일, 전략, 전술을 비교했다.
《듄 2》는 굉장히 재미있었지만 고쳐 달라고 하고 싶은 (아니, 비명을 지르고 싶은) 뚜렷한 결점들이 있었다. 가장 두드러지는 것은 친구들과 게임을 하는 방법이 컴퓨터를 상대하는 것밖에 없었던 점이다. 모든 상대가 유닛 이동 명령을 내릴 때까지 기다려야 하는 턴제 게임과 달리 실시간 게임은 모든 플레이어가 동시에 명령을 내리게 할 수 있으니 장기적이고 진 빠지는 전략 계획보다는 기민하고 단호한 전술적 움직임에 이득을 주었다.
그 목표 하나를 마음에 담고, 진지하게 디자인을 계획하거나 기술 사양을 판단하거나 일정을 잡거나 필요한 예산을 짜는 일도 없이 게임 개발이 시작되었다. 냅킨에 적은 메모조차도 없었다. 당시 블리자드에서 우리는 이것을 “그날의 사업 계획”이라 불렀고 그게 우리의 표준적인 운영 방식이었다.
초기 개발
프로젝트 유일의 개발자였던 나는 아티스트를 확보할 수 있을 만큼 작업이 진전되기 전까지는 《듄 2》의 그래픽을 캡처해서 사용했다. 아티스트들은 온갖 긴급한 마감에 맞춰 일하고 있었기 때문에 이 시점에서 그 사람들을 방해할 이유는 없었다. 우리는 언제나 시간에 쫓기고 있었다.
내 초기 프로그래밍 작업은 타일 기반 맵 스크롤 렌더러, 유닛과 그 외의 이미지를 그리는 스프라이트 렌더러, 게임 유닛의 애니메이션을 처리하는 스프라이트 시퀀싱 엔진, 마우스와 키보드 이벤트를 전하는 이벤트 디스패처, 유닛 행동을 제어하는 게임 디스패처, 애플리케이션 작동을 제어하는 상당량의 유저 인터페이스 코드 등이 포함된 게임 엔진의 개발이었다. 이 부분은 처음 몇 주 만에 완료되어 싱글 플레이어 게임을 ‘플레이’할 수 있는 상태가 되었다. 다만 유닛 생산은 구현하지 않았기 때문에 명령어를 타이핑해서 유닛을 화면에 띄워야 했다.
매일 나는 유기적인 방식으로 이전의 작업 위에 새로운 것을 쌓아나갔다. 정해진 일정도 프로젝트에 영향을 주는 외부 요인도 없었기 때문에 나는 어떤 기능을 만들지 직접 선택할 수 있는 부러움을 받을만한 자리에 있었고, 그것이 굉장한 동기 유발이 되었다. 나는 벌써 게임 개발을 즐기고 있었고 이런 제약 없는 프로그래밍은 마치 마약과도 같았다. 게임 업계에 들어온 22년이 지난 지금도 나는 프로그래밍의 창조적 측면을 좋아한다.
첫 번째 고유 기능: 다수 유닛 선택
내가 특히 자랑스러웠던 기능 중 하나가 유닛 선택이었다. 《듄 2》는 한 번에 하나의 유닛만 선택할 수 있어서 유닛들이 공동으로 전투를 하려면 광란의 클릭질이 필요했다. 플레이어가 하나 이상의 유닛을 선택할 수 있게 한다면 병력 파견의 속도가 높아지고 전투가 극적으로 개선될 것임이 분명했다.
게임 업계에 들어오기 전 나는 아버지의 와인 저장고 사업을 도우면서 와인 저장고를 설계하는 데 맥드로나 맥드래프트 같은 범용 CAD 프로그램을 많이 사용했었다. 그래서 명령을 내릴 유닛들을 모아서 선택하는 데 드래그해서 그린 사각형을 사용하는 은유가 자연스러워 보였다.
나는 《워크래프트》가 이 사용자 인터페이스 은유를 사용한 최초의 게임이라고 믿는다. 처음 이 기능을 구현했을 때는 한 번에 상당수의 유닛을 선택해 조작할 수 있었다. 선택할 수 있는 유닛의 수에 상한선이 없었다.
한 번에 백 개의 유닛을 선택하고 제어하면 내가 구현한 단순한 길 찾기 알고리듬의 취약성이 드러나긴 했지만, 작동하는 기본 알고리듬이 나오자 코드는 더 안 쓰고 유닛을 선택하고 목적지로 파견하는 일에 많은 시간을 보냈다. 내 프로그래밍 경력에서 그 당시까지 만든 것 중 가장 끝내주는 기능이었다.
이후 개발 과정에서 팀멤버들과 게임 디자인을 논의한 뒤에는 한 번에 네 개의 유닛만 선택할 수 있게 하도록 결정했다. 사용자들이 단순히 무리를 모아서 한 번에 싸움에 보내기보다는 전술적 배치에 더 주의를 기울이게 해야 한다는 생각이었다. 이후 《워크래프트 2》에서는 이 숫자를 아홉으로 늘렸다. 《듄 2》의 정신적 후속작인 《커맨드 앤 컨커》에서는 선택할 수 있는 유닛의 상한선이 없었다. 이런 차이에 대해서는 또 따로 글을 쓰는 것도 가치가 있을 것이다.
이 시기의 《워크래프트》는 유닛 다수를 한 번에 조작할 수 있는 기능을 빼면 《듄 2》가 단순화된 모양과 별다를 게 없었다. 나는 《워크래프트》가 《듄 2》에서 영감을 얻긴 했어도 우리 미니맵은 화면 왼쪽 위에 있고 《듄 2》는 오른쪽 아래에 있으니 하늘과 땅 차이라는 방어적인 농담을 할 정도였다.
연대의 구성
1994년 초를 기해 도움을 줄 인원을 확보할 수 있을 만큼 충분히 프로젝트가 진행되었다. 론 밀라와 샘 디디에, 스튜 로즈, 밥 피치, 제시 맥레이놀즈, 마이크 모하임, 미키 닐슨 등이 나와 함께 했다. 이들 중 다수는 1994년 2월 우리 회사가 데이비드슨 앤 어소시에이트에 인수된 뒤부터 게임에 참여하기 시작했다.
긴 금발에 체격이 좋은 론 밀라는 바이킹 전사의 후예임이 분명했다. 그는 원래 버진 게임즈에서 게임보이 게임들의 아트윅을 만든 솜씨에 아티스트로 고용되었지만, 놀라운 창조성과 디자인 감각으로 많은 블리자드 프로젝트에서 디자인 역을 맡았고 워크래프트 프로젝트에도 비슷한 역할로 들어왔다.
강인하고 다부지며 건장하여 곰이 인간의 모습을 했다고밖에 볼 수 없는 샘 디디에가 그린 영웅다운 인물들과 웅대한 그림들은 이제 블리자드 게임을 규정하는 아트 스타일이 되었다. 그는 16비트 콘솔 게임들로 컴퓨터 그림 솜씨를 연마했으나 회의 도중이나 다른 남는 시간에 판타지 아트윅을 그리길 좋아하는 취향이 워크래프트의 아트 디렉션을 이끌 능력을 보여주었다.
일러스트레이터로서 오늘날 사용되는 블리자드 로고를 디자인했던 스튜 로즈는 처음에는 배경 타일맵을 그리는 데 참여했으나 이후 《워크래프트》의 디자인에 결정적인 역할을 하게 된다. 스튜가 인간 일꾼 역을 맡아 억압당하는 노역자를 연출한 목소리 연기는 인상적이고 천재적이었다.
밥 피치는 프로그래머로 일을 시작했고 내가 《워크래프트》의 개발을 시작함과 동시에 다른 타이틀의 프로젝트를 이끌었다. 블리자드의 사장 앨런 애드햄은 밥에게 온갖 단어 게임을 모아 놓은 ‘Games People Play’라는 게임의 제작 임무를 맡겼었다. 밥은 이 프로젝트에 대한 열정이 없었기 때문에 수개월 동안 별 진전을 보이지 못했다. 《워크래프트》가 모습을 드러내자 밥은 나를 도울 수 있게 해방되었고 그의 게임에 대한 열정은 프로젝트가 더 빠르게 전진할 수 있게 도와주었다.
캘리포니아 공대 졸업생인 제시는 게임을 근거리 통신망(LAN)으로 플레이할 수 있도록 IPX 네트워크 프로토콜의 네트워크 드라이버를 구축하는 일을 시작했다. 블리자드의 두 창립자 중 한 명인 마이크 모하임은 이후 ‘혼합 모드’의 모뎀 드라이버를 쓰는 더 어려운 일을 맡았다. 《워크래프트》는 DOS ‘보호 모드’ 게임이었으나, DOS 운영체제와 그것이 실행되는 80386 칩 아키텍처의 변덕 때문에 모뎀 드라이버는 보호 모드와 실제 모드에서 모두 불러올 수 있었다. 그래서 모하임이 자기 사무실에서 진단용 숫자로 가득한 화면을 응시하며 재진입 코드와 관련된 복잡한 타이밍 문제를 풀어가는 모습을 자주 볼 수 있었다. 결국에 모뎀 코드는 튼튼하게 완성되었고 이것은 당시의 원시적 도구들을 고려하면 상당한 성과였다.
《워크래프트》의 아트
앨런 애드햄은 워해머 라이선스를 얻어서 브랜드 인지도로 판매량을 늘릴 수 있길 바랐다. 워해머는 《워크래프트》의 아트 스타일에 커다란 영감을 주었지만, 사업적 측면의 견인 부족과 사실상 개발팀의 모두(나 포함)가 직접 세계를 만들고 싶어했던 뜨거운 욕망이 그런 계약의 가능성을 없애버렸다. 우리는 이미 《슈퍼맨의 죽음과 귀환》과 《저스티스 리그 태스크 포스》로 DC 코믹스와 일하면서 끔찍한 경험을 했고 누구도 새로운 게임에서 그런 문제를 겪고 싶지 않았다.
블리자드가 워크래프트 세계의 지적재산권을 소유하지 않았다면 무슨 일이 일어났을지 지금 생각해보면 놀랍다. 아마 블리자드가 오늘날처럼 게임 업계의 유력 주자가 되는 일은 없었을 것이다.
《워크래프트》의 출시 수년 뒤, 아시아 여행에서 돌아온 아버지는 나에게 스켈레톤 마부 모습의 워해머 미니어처를 선물로 주면서 말했다. “여행하면서 이 멋진 장난감들을 보고 네가 만든 게임이 떠올랐단다. 너네 게임을 베낀 것 같은데 회사 법률팀한테 이야기해줘야 하는 거 아니냐?” 으으음!
개발의 장애물
개발 초기 과정에서 재미있었던 사실 하나는 모뎀이나 근거리 통신망으로 플레이할 수 있는 게임을 만들면서도 회사에는 LAN이 구축되어 있지 않았다는 점이다. 있었으면 확실히 백업 만들기가 단순해졌겠지만 우리는 플로피 디스크의 용량에 쉽게 들어가는 콘솔 게임들을 만들어왔기 때문에 별 필요가 없었던 것이다.
그래서 다른 아티스트와 프로그래머들과 협업을 하기 시작했을 때 우리는 ‘스니커 네트워크’를 사용했다. 플로피 디스크를 사무실 여기저기로 옮기면서 소스 코드 개정과 아트윅을 통합하는 것이었다.
밥 피치는 프로젝트의 두 번째 프로그래머였고 우리 둘은 정기적으로 파일과 코드 변경 점을 복사해서 주고받았다. 주기적으로 통합 과정에서 실수가 일어났고 고쳤던 버그가 다시 나타났다. 우리는 변경 점을 통합하려고 파일을 복사하는 도중에 우발적으로 고친 버그를 덮어썼음을 발견했고, 그 뒤부터는 이전에 어떻게 고쳤는지 일일이 기억해야만 했다.
개발 속도가 빨라지고 어떤 파일을 작업했는지 ‘기억’하는 것 외에 코드 통합을 다룰 과정이 없었기 때문에 이런 사고는 몇 번 더 일어났다. 내 컴퓨터가 모든 통합 작업을 수행하는 마스터 시스템이었다는 면에서 나는 그나마 운이 좋았다고 할 수 있다. 오늘날에는 소스 컨트롤을 통해 그런 멍청한 일을 피하지만 당시 우리는 그게 뭔지도 몰랐다!
더 많은 프로그래머와 디자이너, 아티스트가 타이틀에 참여하게 되면서 진행 속도는 크게 빨라졌지만 커다란 장애물 역시 발견되었다. 게임은 원래 운영체제를 위한 120K를 뺀 640K의 메모리만 사용할 수 있는 DOS의 ‘실제 모드’로 개발 중이었다. 당시의 얼마나 똥 컴퓨터를 사용했는지 믿을 수 있겠는가!?!
아트 팀이 유닛과 배경, 인터페이스 아트윅을 만들기 시작하면서 금세 메모리를 전부 채워버렸고 대안을 찾기 시작했다. 첫 시도는 EMS로 ‘페이징된 메모리’를 사용해 640K의 메모리 한계를 ‘넘는’ 아트 자원을 저장하는 것이었다.
프로그래머들의 EMS 메모리 이야기는 노인들이 눈 속에서 맨발로 고갯길을 넘어 학교에 다녔다는 이야기와 비슷하다. 두 가지가 다른데, EMS 쪽이 더 끔찍한 이야기고, 이건 정말로 사실이라는 점이다.
다행히 어떤 경우에도 EMS 해법은 통하지 않았고 결국에는 더 나은 해법이 나오게 되었다. 왓콤이라는 회사가 ‘보호 모드’에서 선형 32비트 메모리에 접근하는 프로그램을 쓸 수 있는 DOS 모드 ‘익스텐더’를 포함한 C 컴파일러를 출시한 것이다. 오늘날은 모든 프로그래머가 32비트(심지어 64비트)를 당연하게 사용한다. 새 컴파일러를 적용하려면 이틀 정도 소스 코드를 갱신해야 했지만, DOS 모드 익스텐더는 완벽하게 작동했고 이제 훨씬 더 많은 메모리에 접근하면서 작업할 수 있었다.
끝이 아닙니다
다음 글에서는 스튜 로즈와 디자인 쿠데타, 《워크래프트》의 첫 멀티플레이어 게임, 멀티플레이어를 거의 끝장낼 뻔한 버그, 빌 로퍼가 《워크래프트》를 멋지게 만든 사연, 플로피 디스크 용량에 게임을 맞춘 방법, 우리 게임을 본 웨스트우드 스튜디오의 반응 등 나와 개발팀의 일원들이 18년(!) 전에 만들었던 게임에서 파헤쳐낼 수 있는 만큼 재밌는 이야기를 파헤쳐 보겠다.
저자: 패트릭 와이엇
게임 개발자로서 22년 이상을 업계에서 일하며 여러 작은 회사들이 크게 성장하는 데 도움을 줬고(블리자드의 부사장, 아레나넷의 창립자, 엔 매스 엔터테인먼트의 COO), 베스트 셀러 게임 시리즈의 디자인과 개발을 이끌었으며(워크래프트, 디아블로, 스타크래프트, 길드 워), 사실상 게임의 거의 모든 측면의 코드를 써봤고(네트워크, 그래픽, AI, 길 찾기, 사운드, 툴, 인스톨러, 서버, 데이터베이스, 전자상거래, 분석 도구, 암호화, 개발 운용 등), 개발한 게임의 많은 부분을 디자인했고, 플랫폼 서비스 팀을 운영했으며(데이터센터 운영, 고객 지원, 결제/계정, 보안, 분석), 대작 게임 퍼블리싱 사업에서 경쟁하는 데 필요한 첨단 기술들을 개발했다.
이 글은 저자의 허락 하에 번역하고 게시하였습니다. 저자의 블로그에서 원문을 확인할 수 있습니다. 오영욱님이 번역을 감수해주셨습니다.
This article is translated and republished by permission of the author.
댓글 없음:
댓글 쓰기