GPG 보내기
[역자의 말: 3개월 만에 새로운 번역글로 돌아왔습니다. 1부와 2부에 이어 마찬가지로 3개월 만에 올라온 워크래프트 제작기 3부입니다 :~) 워크래프트의 프로듀서이자 리드 프로그래머였던 패트릭 와이엇이 첫 번째 멀티플레이어 게임의 '공포'를 비롯 지난 번 이상으로 더 흥미롭고 새겨볼만한 이야기를 펼칩니다.]
패트릭 와이엇 | 2012년 11월 12일 | 원문보기
사상 최초의 《워크래프트》 멀티플레이어 게임은 압도적인 승리이자 비참한 패배, 동시에 무승부였다. 아, 그게 어떻게 가능한지 궁금한가? 지금부터 이야기해보자. 이 이야기는 쓰는 도중에 게임 AI와 게임 사업의 경제, 전장의 안개 등을 포함하면서 긴 이야기가 되었다. 시간이 많이 있다면 계속 읽어보시라!
1993년 9월에 개발을 시작하고 6개월 뒤, 워크래프트 시리즈의 첫 게임으로 계획된 《워크래프트: 오크 대 인간》이 드디어 기술 데모의 연장에서 하나의 게임으로 변해갔다.
몇 개월 동안 프로젝트에 나 혼자 풀타임으로 참여한 만큼 개발 속도에는 제약이 있었다. 디자인 작업을 해준 론 밀라와 스튜 로즈 등을 포함해 다른 직원들의 도움을 받을 수 있어 복이었다. 그리고 여러 아티스트도 다른 프로젝트의 마일스톤 사이에 시간이 나면 프로토타입의 아트윅을 그려주었다.
회사의 금고가 그리 크지 않았던 데다 인터플레이와 선소프트 같은 퍼블리셔들을 위해 타이틀을 개발해 받은 수입으로 개발 자금을 충당하고 있던 터라 팀의 충원은 느렸다.
우리는 당시 네 개의 16비트 콘솔 타이틀을 개발하고 있었다. 호평을 받았지만 적게 팔린 횡스크롤 액션 퍼즐 게임 《로스트 바이킹 2》(Lost Vikings 2), 주인공이 샷건을 들고 뛰어다니는 횡스크롤 액션 게임 《블랙쏜》(Blackthorne), DC 코믹스 세계를 바탕으로 하는 스트리트 파이터 모방작 《저스티스 리그 태스크 포스》(Justice League Task Force), 슈퍼맨을 바탕으로 한 횡스크롤 액션 게임 《슈퍼맨의 죽음과 귀환》(Death and Return of Superman)이었다.
그 게임들의 개발과 여러 가지 일을 해서 받은 돈으로 회사는 《워크래프트》의 초기 개발 비용을 낼 수 있었다.
게임 개발의 경제
게임 역사 대부분에서 독립 게임 개발 스튜디오(소매 게임 퍼블리셔에 속하지 않은 스튜디오)는 일반적으로 퍼블리싱 회사와 계약해서 프로젝트에 필요한 자금을 얻었다. 퍼블리셔는 프로젝트 개발에 필요한 돈을 개발사에 ‘선지급’해준다. 개발비 융통에 더해 퍼블리셔는 홍보와 마케팅, 제조, 소매상 배급, 고객 지원 등도 맡는다.
90년대 초에는 지금보다 더 많은 게임 퍼블리셔가 존재했지만, 게임 개발 비용, 특히 퍼블리싱 비용의 증가에 따른 파산과 인수가 업계의 대통합으로 이어졌다. 그래서 오늘날 소매 게임 퍼블리셔 하면 20년 전에 존재했던 무수한 중간 규모 회사들이 아닌 액티비전 블리자드나 EA, 유비소프트가 떠오를 것이다.
모든 산업에서 그렇듯이 계약 조항은 돈을 가진 사람들에 상당히 유리하게 만들어진다. “돈 가진 자가 규칙을 만든다”는 황금률이다. 원론적으로는 게임이 잘 팔릴 때 게임 개발사가 보상받도록 계약이 짜여야 하지만, 과거의 기록과 영화 산업이 보여주듯 이익 대부분은 퍼블리셔의 손에 들어가고 개발사는 ‘운이 좋다면’ 이후 다른 계약이 가능하도록 생존할 만큼만 돈을 받는다.
앞서 퍼블리셔가 ‘선지급’으로 돈을 준다고 이야기했는데, 더 정확히 말하면 ‘로열티를 대신한 선지급’이다. 개발사는 사실상 관대한 대출금을 받아 게임 판매 로열티로 갚는 셈이다. 게임을 개발하고 한 장 팔릴 때마다 돈을 받는다니, 듣기에는 괜찮다. 하지만 대다수 게임은 선지급으로 받은 돈을 메울 만큼 돈을 벌지 못한다. 개발 스튜디오는 흔히 타이틀과 후속작에 대한 권리를 포기할 수밖에 없으므로 이런 계약은 고용 계약이나 다름없다.
개발 스튜디오가 더 나은 계약 조건을 노리고자 흔히 채용한 전략은 자사 자금으로 초기 프로토타입을 만들어서 개발 계약을 퍼블리셔에 제안할 때 활용하는 것이었다. 개발사가 직접 돈을 대서 게임을 만드는 기간이 길수록 계약 조건도 더 나아졌다.
이 전략의 가장 좋은 예는 밸브 소프트웨어일 것이다. 게이브 뉴웰은 자신이 마이크로소프트에서 번 돈으로 《하프라이프》(Half-Life)의 개발 자금을 충당했고 그에 따라 게임 출시 일정을 상당 부분 통제할 수 있었다. 퍼블리셔인 시에라 엔터테인먼트가 바라는 분기 매출 목표에 맞추려고 급하게 만들어지는 대신 높은 품질의 제품이 되면 출시하도록 한 것이다. 더 중요한 것은 (이후에 회사가 막대한 성공을 거둔) 디지털 다운로드가 게임 판매에 가시적인 전략으로 다가올 때 게이브의 자금 덕에 밸브가 《하프라이프》의 온라인 배급권을 소유할 수 있었다는 점이다.
직접 자금을 대서 만드는 프로토타입의 단점은 프로젝트를 계약하지 못했을 때 개발사가 그대로 안아야 위험이다. 이는 흔히 스튜디오의 종말로 이어진다.
실리콘 앤 시냅스는 《워크래프트》와 함께 ‘게임즈 피플 플레이’(Games People Play)라는 프로젝트의 개발 자금도 스스로 충당했다. 공항 서점에 배치되어 고립된 여행객에게 즐길 거리를 주는 십자말풀이와 보글 등 낱말 게임을 모은 프로젝트였다.
회사 오너들은 대상이 크게 다른 두 개의 게임을 개발함으로써 회사의 미래를 코어 엔터테인먼트 시장(그러니까, 나와 당신 같은 하드코어 게이머들)에 전부 거는 경우보다는 경제적으로 더 안정될 수 있도록 매출원을 다양화하려고 했다.
물론 각색의 장르에 투자를 분산하면 자기 청중의 욕구에 맞지 않는 제품을 만듦으로써 회사 브랜드가 희석될 위험이 있다. 오늘날 블리자드 브랜드의 가장 큰 강점은 사용자들이 회사의 비전과 명성을 믿으므로 앞뒤 안 보고 게임을 산다는 점이다. 저예산 캐주얼 타이틀과 고예산 대작 게임을 함께 출시하는 회사로서는 이루기 어려운 명성이다. 예를 들어 시에라 엔터테인먼트는 여러 차례 자기 청중을 찾는 데 어려움을 겪었고 지금은 사업을 하지 않는다.
어쨌든 간에 ‘게임즈 피플 플레이’ 프로젝트는 잘못된 판단으로 결론이 났다. 리드 프로그래머가 캐주얼 게임을 개발할 의욕이 없어서 프로젝트가 제대로 발전하지 못한 채 취소되었기 때문이다. 어쩌면 실수가 아니었을지도 모른다. 당시 두 번째로 큰 교육용 소프트웨어 회사였던 데이비드슨 앤 어소시에이트가 실리콘 앤 시냅스 인수를 확신한 것은 《워크래프트》와 ‘게임즈 피플 플레이’의 조합이었기 때문이었다.
새로운 군주
잰 데이비드슨이 시작하여 이후 그의 남편 밥이 합류한 회사 데이비드슨 앤 어소시에이트는 갖가지 교육용 소프트웨어를 출시해왔고, 《매스 블라스터》라는 게임의 성공으로 성장이 예견된 회사였다. 플레이어가 수학 문제를 풀어서 다가오는 소행성을 파괴하는 게임 《매스 블라스터》는 교육과 엔터테인먼트의 영리한 결합이었고 회사는 그 성공으로 막대한 돈을 벌어들였다.
곁들이자면, 《매스 블라스터》는 교육용 타이틀로써 적절하게 활용된다면 가치가 있을지도 모르겠지만, 난 그 어리석은 활용 사례를 목격한 적이 있다. 고등학생 시절 내가 들었던 저널리즘 수업에서는 보충수업을 하는 반과 컴퓨터실을 나눠 쓰면서 학교 신문에 나갈 기사를 썼다. 당시 같은 수업을 듣던 친구와 나는 3학년 학생들이 계산기를 써서 《매스 블라스터》를 하는 모습을 공포 속에 지켜보았다. “3 + 5″와 “2 * 3″ 같은 수식이 들어있는 소행성이 다가오면 학생들은 재빠르게 수식을 계산기로 계산해 나온 값을 입력해 소행성을 파괴했다. 교사들보다 한 수 위로 생각했다는 점에선 뭔가 배웠다 할 수도 있었지만, 취업 전선이 빠르게 다가오는 상황에서 시간을 제대로 활용한 건지는 잘 모르겠다.
성실함과 공격적인 리더십을 갖춘 데이비드슨 앤 어소시에이트는 게임 제조(상자의 제작과 포장)와 배급(상자를 소매상과 중개업자들에게 배송), 학교에 직접 교재를 배급하는 일까지 사업을 확장했다. 그들은 성장하는 엔터테인먼트 분야에도 사업을 확장할 기회를 보았다. 초기에 내부에서 게임 제작을 시도해본 그들은 검과 마법보다는 조기 교육을 더 잘 아는 직원들이 게임을 만드는 대신 경험 있는 게임 개발 스튜디오를 인수하는 게 낫다고 판단하게 된다.
그리고 《워크래프트》 개발팀의 성장을 막았던 자금 문제는 회사의 인수로 단번에 해결되었다. 데이비드슨 앤 어소시에이트의 커다란 지갑이 뒷받침해주자 실리콘 앤 시냅스(매각 이후 ‘블리자드’로 명칭이 바뀌었다)는 다른 퍼블리셔들로부터 티끌만 한 이익이 나는 계약을 따내려는 노력을 개발에 집중할 수 있었다. 그 티끌이란 정말 티끌이었다. 우리는 1993년 최고의 게임을 두 개나 만들었지만 “올해의 닌텐도 개발사”라는 이름뿐이었지 어떤 로열티도 못 받았다.
인수를 통해 얻은 돈더미로 새 직원을 고용하고 기존 직원은 프로젝트에 완전히 탑승하게 되면서 《워크래프트》의 개발은 극적으로 가속되었다.
디자인 “과정”
블리자드 초기에 게임을 디자인하고 구축하는 과정은 ‘유기적’이었다는 말로 가장 잘 설명할 수 있다. 그 혼란스러운 과정은 형식적인 디자인 회의에서도 일어났지만 복도나 식당에서 즉흥적으로 모이는 식으로 더 자주 일어났다.
어떤 기능은 디자인 문서에서 온 반면 어떤 기능은 프로그래머 개개인이 변덕으로 집어넣었다. 어떤 게임 아트는 계획하고 일정을 잡아서 체계적으로 제작된 반면 어떤 아트는 늦은 밤에 아티스트가 굉장한 아이디어가 떠올랐거나 그냥 다른 걸 해보고 싶었다는 이유로 만들어졌다. 다른 요소들도 비슷하게 즉석에서 나왔다. 《워크래프트》의 이야기와 배경은 출시 몇 개월 전에야 정리되었다.
과정은 예측하기 어려웠어도 그 결과는 찬란했다. 개발팀 구성원들이 컴퓨터 게임광들이었기 때문에 우리 게임은 개발이 진행되면서 게이머들이 플레이하고 또 플레이하고 또 플레이하고 싶어하는 것으로 발전해나갔다. 우리가 IBM PC로 처음 만든 오리지널 게임이었던 《워크래프트》는 그 과정을 가장 잘 (가끔은 가장 나쁘게) 실증했고, 결과적으로 (적어도 당시에는) 모범이 되는 게임을 탄생시켰다.
유닛 생산 시스템의 탄생
생물 진화의 과정에는 계보의 가지 전체가 멸종하게 되는 잘못된 시작이란 게 있다. 《워크래프트》의 개발 중에도 그런 게 있었다. 우리는 척도가 되어줄 명세가 없었으므로 실험해보고 잘 안 되는 건 골라내는 방식으로 진행했다. 모든 것은 측정하고 의식한 과정이었다 말하고 싶지만 많은 부분이 사고와 논쟁, 개인 간의 충돌에서 나타났다.
특히 내가 잘 기억하는 것이 게임 유닛 생산과 관련된 사건이다. 개발 초기에는 유닛을 생산할 별다른 인터페이스 장치가 없었기 때문에 콘솔에 ‘치트’ 명령어를 입력해서 유닛을 불러냈다. 최선의 유닛 생산 방식을 생각하기 시작하면서 다양한 아이디어가 제안되었다.
초기 블리자드에서 많은 게임의 구상과 디자인을 했던 아티스트 론 밀라는 《파퓰러스》(Populous)처럼 플레이어가 농장을 건설하고 그 농장에서 기본 일꾼 유닛이 주기적으로 소환되는 방식을 제안했다. 플레이어는 일꾼 유닛을 사용해서 금광과 목재 채취, 건설을 할 수 있지만 일꾼이 전투 유닛만큼 좋지는 않다.
다른 활동에 참여하지 않는 일꾼을 병영에서 군사 훈련에 참여하도록 지시하면 잠시 지도에서 사라졌다가 능숙한 전투원이 되어 나타난다. 다른 훈련 지역에서는 투석기와 마법사 같은 더 고급 유닛을 생산할 수 있게 한다.
완전히 살이 붙은 아이디어는 아니었다. 구현 방향을 서술하는 형식성의 부족은 우리 디자인 과정에서 흔히 나타나는 결함 중 하나였다. 아이디어를 생각했다가 비정규 디자인 팀 (즉, 사원 대부분) 사이에서 논쟁한 이후에 코딩으로 구현되는 식이었다.
우리가 유닛 생산 코드를 작업하기 전, 론은 사장 앨런 애드햄과 함께 전시회 (아마도 겨울 CES) 참석차 자리를 비웠다. 그가 없는 동안 워크래프트 시리즈 전체의 방향을 정한 사건이 일어났다. 나는 그 사건을 “워크래프트 디자인 쿠데타”라고 부른다.
초기에 회사에 합류한 (아마 여섯 번째 직원) 또 다른 아티스트/디자이너 스튜 로즈가 어느 늦은 오후 내 사무실에 나타나 다른 방식을 주장했다. 스튜는 론이 제안한 유닛 생산 과정에는 해결하지 못한 구현상의 복잡성이 너무 많은 데다가 실시간 전략 (RTS) 게임에서 제공해야 하는 조작 방식을 거스른다고 생각했다.
새롭게 나타난 장르인 RTS는 다른 장르보다 플레이어에게 요구하는 게 많다. 빌드 계획과 업그레이드, 경제 활동, 유닛 생산, 건물 배치, 지도 정찰, 전투 감독, 개별 유닛 스킬의 조작 등 서로 대립하는 요구가 있어 플레이어의 주의가 한곳에 오래 집중될 수 없다. RTS에서 가장 한정적인 자원은 플레이어의 주의력이다. 간접적인 유닛 생산 구조로 인지 부담을 늘린다면 주의력을 소모하고 게임의 난이도는 높아진다.
아무것도 안 하거나 가장 우선순위가 낮은 일을 하는 일꾼을 모아서 훈련해야 기본 전투 유닛인 보병을 생산할 수 있다면 게임의 난이도를 (스튜가 보기에) 불필요하게 높인다.
나 역시 비슷한 (하지만 그만큼 생각을 정리하지 않은) 걱정을 했고 유닛 생산이 대담한 변화를 가할 필요가 있는 부분으로 느껴지지 않았던지라 그의 제안을 받아들일 준비가 되어있었다. 《워크래프트》의 디자인이 비롯된 《듄 2》(Dune 2)는 건설 인터페이스 패널에서 버튼을 클릭하면 짧은 시간 뒤에 유닛이 나오는 훨씬 단순한 생산 구조를 지니고 있었다. 참신하지는 않았어도 (더 이전의 게임에서 가져온 아이디어다) 잘 작동했다.
스튜는 우리가 《듄 2》의 방식을 써야 한다면서 논쟁하지 말고 그냥 바로 만들자고 주장했다. 그래서 나는 뒤이은 며칠 밤낮 동안 유닛 생산 구현에 필요한 인터페이스 코드를 급히 작성했고 그 디자인 결정은 기정사실이 되었다. 적 컴퓨터 AI가 완성되려면 수개월 남았던 점만 제외하면 론과 앨런이 돌아왔을 때는 가까스로 싱글 플레이어 모드를 플레이할 수 있는 상태가 되었다.
이제 《워크래프트》는 플레이하기 간단하고 (무엇보다 중요하게) 재미있는 진짜 게임이 되었다. 우리는 뒤돌아보지 않았다.
첫 멀티플레이어 게임
1994년 6월, 10개월의 개발 이후 게임 엔진은 멀티플레이어를 돌릴 준비가 거의 되어 있었다. 처음으로 《워크래프트》 멀티플레이어 게임을 플레이할 수 있게 해줄 코드 변경을 통합하면서 흥분은 커졌다. 내가 핵심 게임 논리(이벤트 루프, 유닛 디스패처, 길 찾기, 전술적 유닛 AI, 상태 막대, 게임 내 인터페이스, 고수준 네트워크 코드)를 구축하느라 바빴던 동안 다른 프로그래머들은 멀티플레이어 게임을 만드는 데 필요한 구성 요소를 작업하고 있었다.
칼텍 졸업생 제시 맥레이놀즈는 IPX 패킷을 근거리 통신망에 보내는 저수준 네트워크 라이브러리 코딩을 마쳤다. 그 코드는 당시 이드 소프트웨어의 존 카맥이 나중에 오픈 소스로 공개한 《둠》(Doom)의 코드에서 주워 모은 지식을 바탕으로 작성되었다. IPX 상호작용 레이어는 단 몇 백 줄의 C 코드였지만, 한 게임 클라이언트에서 생성된 메시지를 다른 플레이어로 전송하기 위해 네트워크 카드 드라이버와 연결되는 코드의 일부였다.
그리고 캘리포니아 주립대학교 풀러튼에서 석사학위를 받은 밥 피치는 플레이어가 멀티플레이어 게임을 만들고 참여할 수 있는 화면을 개발했다. 밥의 게임 생성/참여 논리와 내 게임 이벤트 루프가 통합되도록 밀접하게 협력해야 했기 때문에 내 사무실이 밥의 자리 바로 옆이어서 굉장히 편리했다.
변경점을 통합하고 게임 클라이언트를 컴파일한 뒤 네트워크 드라이브에 복사하자 밥은 자기 사무실로 뛰어 돌아가 게임에 참여했다. 작은 기적과 함께 우리가 쓴 코드는 실제로 작동했고 이제 《워크래프트》 사상 최초의 멀티플레이어 게임을 시작할 수 있었다.
게임을 시작하면서 나는 그 어떤 게임을 플레이할 때보다 커다란 흥분을 느꼈다. 그 일부는 내가 이 코드를 쓰는 데 참여했다는 데서 왔지만, 그보다 더했던 것은 두 가지 요인이 만들어낸 공포였다. 컴퓨터 AI 대신 인간을 상대로 플레이한다는 것, 그리고 특히 전장의 안개 때문에 그 상대가 뭘 하는지 알 수 없다는 것이었다.
전장의 안개
플레이어의 시야에서 상대하는 적 유닛을 감추는 것은 예전 게임에서 끌어온 아이디어 중 하나였다. 아군 유닛이 탐색하지 않는 한 게임 지도의 숨겨진 지역은 검은 그래픽으로 뒤덮인다. 이것은 실제 전투에서 장군이 아는 적의 작전과 부대 이동에 대한 정보가 불완전함을 흉내 낸 디자인이었다.
거의 17년 전에 월터 브라이트(D 프로그래밍 언어의 창시자)가 쓴 멀티플레이어 턴제 전략 게임 《엠파이어》(Empire)는 같은 목적으로 전장의 안개를 사용했다. 지도의 한 지역이 ‘발견’되면 그 이후에는 계속 보이는 채로 남기 때문에, 게임 초반에 충분히 지도를 탐색해서 중요 시설이나 경제력이 습격으로 해를 입기 전에 적 부대의 활동을 미리 아는 게 중요했다.
적이 뭘 하는지 알 수 없다는 데서 오는 심리적 공포는 역사 속 수많은 장군의 최후를 가져왔고, 이 요소를 RTS 장르에 넣는 것은 흥분(과 공포)의 수준을 높이는 훌륭한 방법이다. 월터와 《듄 2》를 만든 웨스트우드 사람들에게 감사한다!
컴퓨터 AI
많은 게이머가 알겠지만 전략 게임에서 컴퓨터가 제어하는 ‘인공지능’(AI) 플레이어는 대체로 약하다. 인간 플레이어가 컴퓨터 AI의 취약점을 발견해 별 어려움 없이 AI를 저지하는 일은 흔하다. 그래서 컴퓨터 AI는 일반적으로 수적 우위나 위치상의 이득, ‘비대칭 규칙’에 의존해서 플레이어에게 도전을 제공한다.
《워크래프트》의 미션 대부분에서는 적 컴퓨터 플레이어들이 처음부터 도시와 군대를 부여받아 인간 플레이어를 상대한다. 그리고 대부분 플레이어들이 속임수라고 부를지도 모르겠지만, AI 플레이어가 더 경쟁하기 쉽도록 몇 가지 비대칭 규칙을 적용했다.
컴퓨터 AI를 도우려고 만든 규칙 하나는 금광이 고갈되지 않도록 사라지는 금의 양을 줄인 것이었다. 인간 플레이어의 일꾼이 금광에서 나올 때 일꾼은 광산에서 100단위의 광물을 제거하고 그대로 플레이어의 마을회관에 전달한다. 일꾼들이 오다니면서 금광은 결국 고갈된다. 하지만 AI가 제어하는 일꾼이 광산에서 나올 때는 8단위의 광물만 제거되고 마을회관에는 100단위를 전달한다.
이런 비대칭 규칙은 두 가지 측면에서 실제로 게임을 더 재미있게 만든다. 먼저 플레이어가 난공불락의 방어를 구축해 우월한 전략적 기술로 컴퓨터 AI를 능가하는 ‘틀어박히기’(turtling)를 막는다. 플레이어의 금광이 컴퓨터보다 훨씬 전에 마르기 때문에 틀어박히기는 망하는 전략이다.
두 번째로, 인간 플레이어가 컴퓨터의 기지를 파괴했을 때 플레이어가 채취할 금광이 여전히 남아있다. 덕분에 게임의 속도가 빨라지고 제한된 자원으로 힘겹게 승리하는 것보다 더 재미있다.
많은 플레이어가 공정 경쟁을 심각하게 위반한다고 생각하는 규칙은 컴퓨터 AI가 전장의 안개를 뚫어 볼 수 있다는 점이다. AI는 매 순간 플레이어가 무얼 하는지 정확히 안다. 이 규칙은 실제로 컴퓨터에 커다란 이득은 아니었고 단지 너무 멍청해 보이는 걸 막을 뿐이었다.
흥미롭게도 《스타크래프트》(StarCraft)의 오랜 인기(출시된 지 14년이 넘었는데도 여전히 플레이 된다)와 함께, 일군의 AI 프로그래머들이 속임수를 쓰지 않는 AI를 만드는 도전을 했다. 이 프로그래머들은 BWAPI라는 라이브러리의 도움을 받아서 《스타크래프트》 엔진에 직접 명령을 입력해 게임을 플레이하는 코드를 썼다. 프로그래머들은 각자 자신이 만든 AI를 경쟁하게 해서 승자를 가렸다. BWAPI AI 플레이어들이 게임을 잘하긴 했지만 그중 최고도 숙련된 인간 상대에게는 손쉽게 깨졌다.
인간을 상대로 한 플레이
《워크래프트》 이전에 많은 (정말 많은) 전략 게임을 플레이해본 나는 당시 컴퓨터 AI의 한계를 잘 알고 있었다. 나는 많은 컴퓨터 AI와 싸우면서 때로는 지고 대체로 이겼지만 절대 AI의 지능에 겁먹은 적이 없었다. 심지어 친구의 아타리 800으로 게임이 담긴 카세트테이프(!)가 낡아서 읽히지 않게 될 때까지 플레이한 크리스 크로포드의 게임 《동부 전선》(Eastern Front)에서 끔찍한 러시아인에 맞설 때도 그랬다.
그 게임들은 재미있고 신이 났고 분명히 도전적이었지만, 무섭지는 않았다. 그러나 내가 처음 플레이한 《워크래프트》의 멀티플레이어 게임은 뭔가 달랐다.
솜씨와 전략뿐 아니라 명령을 내리는 속도에서도 유능한 인간 플레이어를 상대로 경쟁하는데 전장의 안개 때문에 행동을 볼 수 없다는 점은 전율과 동시에 공포였다. 내 전체 경력 중 《워크래프트》를 처음 플레이하면서 이기는지 지는지 알 수 없었던 때처럼 흥분을 느껴본 적이 없다.
대량의 아드레날린이 혈류에 주입되면서 나는 효율적으로 금과 목재를 채취하고 농장과 병영을 짓고 공격 병력을 전개하고 지도를 탐색하고, 무엇보다 내 군대가 짓밟히기 전에 밥의 군대를 짓밟으려고 전력을 기울였다.
이것은 엔진의 기능을 검증하려고 시험 삼아 하는 게임이 아니었다. 밥도 나처럼 사상 최초의 《워크래프트》 멀티플레이어 게임에서 승리했다는 업적을 거머쥘 욕망이 있었음을 안다. 더구나 회사에서 《둠》을 함께 플레이했을 때 자신을 몇 번이고 로켓 런처로 죽이자 화가 난 밥이 다시는 나랑 게임을 하지 않겠다고 맹세한 적이 있었다. 밥은 분명 복수를 노리고 있을 터였다.
양측 군대가 전투에 돌입하자 나와 밥 모두 유닛 생산을 배로 늘려 전투에 내보냈다. 밥의 기지를 발견해서 공격하고 나니 희망이 생겼다. 밥의 전략은 무질서해 보였고 내 병력으로 무너뜨릴 수 있을 것으로 보였다. 하지만 일말의 여지도 남기고 싶지 않았기에 나는 광란의 속도로 밥의 유닛과 건물을 계속 공격했다.
그리고…다운되었다.
프로그래머라면 모두 알겠지만 새로운 코드가 처음부터 적절하게 동작할 가망은 제로에 가깝다. 그래서 게임이 다운되었다고 놀랄 일은 아니었다. 게임 그래픽이 화면 위로 스크롤 되면서 당시 윈도 이전 세대의 게이머들이라면 아주 친숙할 DOS4GW 크래쉬 화면이 나왔다. 지금은 플레이어가 오류 내용을 보낼 수 있는 더 정교한 오류 보고 화면이 뜨지만 이따금 ‘죽음의 블루 스크린’을 본 적이 있을 것이다. 이건 그것과 비슷하다.
게임이 다운되자 나는 자리에서 벌떡 일어나 밥의 사무실로 달려가 소리쳤다. “그거 끝내줬다아아아아아아!” 그리고 덧붙였다. “내가 널 짓밟아줬지!” 그래서 즉시 반박하는 밥의 말에 나는 놀랐다. 밥은 반대로 나를 무너뜨리고 있었다고 했다.
흥분을 가라앉히고 평상심으로 돌아가는 데는 몇 분 걸리지 않았다. 우리는 곧 다운을 일으킨 버그만이 아니라 게임 상태 동기화 문제도 있다고 판단했다. 나는 그것을 ‘동기화 버그’라 이름 붙였다. 두 컴퓨터가 처음에는 같이 시작하지만 두 개의 완벽히 다른 세계로 갈라지면서 완벽히 다른 전투 양상을 보여주는 문제였다.
네트워크 코드를 프로그래밍해보지 않은 사람들은 게임을 플레이할 때 두 개의 게임 클라이언트가 게임 상태 전체를 주고받는다고 생각할지도 모른다. 즉 두 컴퓨터가 차례마다 모든 게임 유닛의 위치와 행동을 보낸다는 것이다. 체스나 체커처럼 위치가 얼마 되지 않고 속도가 느린 게임이라면 분명 가능하지만, 《워크래프트》처럼 최대 600개 유닛이 한 번에 행동하는 게임에서는 그만한 정보를 네트워크로 보낼 수 없었다.
우리는 많은 게이머가 2400 보드(초당 전송 비트) 모뎀으로 《워크래프트》를 플레이하리라 예상했고 그 정도면 초당 수백 개의 캐릭터만 전송할 수 있었다. 모뎀을 사용해본 적이 없는 젊은 게이머라면 봉화나 돌 두드리기보다 조금 발전한 이 기술을 이해하는 데 조사가 필요할 것이다. 기억하라. 이것은 아마존도 구글도 넷플릭스도 없던 암흑시대의 이야기다.
이전에 《배틀 체스》를 DOS에서 윈도로 ‘이식’했던 경험이 있던 나는 멀티플레이어 게임에서 모뎀을 사용해 통신하는 방식에 친숙했다. 모뎀의 대역폭이 제한적이라 게임 전체 상태를 네트워크로 보내는 건 불가능하다고 알고 있었기 때문에, 각 플레이어가 내리는 명령만 보내고 두 플레이어가 동시에 그 명령을 실행하도록 했다.
컴퓨터는 하라는 대로 정확히 하는 데 능하므로 나는 이 해법이 통할 것으로 생각했다. 불행하게도 프로그래밍을 하는 인간은 해야 할 일을 컴퓨터에 정확히 말하는 데 능하지 않다. 그것이 대부분 버그의 원인이다. 두 컴퓨터가 같은 것을 해야 하는데 버그 때문에 불일치가 발생하는 게 문제였다.
동기화 버그는 게임을 시뮬레이션하는 두 컴퓨터가 동일한 질문에 각자 다른 답변을 선택하면서 나타났고, 이 분기는 시간을 거치면서 더욱더 커졌다. 《백 투 더 퓨처》 같은 시간여행 영화처럼 시간 여행자가 과거에 있는 동안 만든 작은 변화가 완벽하게 다른 미래로 이어진 셈이다. 《워크래프트》에서도 그와 비슷한 분기가 발생했다. 내 컴퓨터에서 엘프 궁수는 오크 일꾼을 보고 공격하지만, 상대 컴퓨터에서는 일꾼이 공격을 인지하지 못하고 목재를 채취하러 갔다. 이런 유형의 불일치를 발견하거나 정정할 장치가 없다면 둘은 금방 완벽하게 다른 게임을 하게 될 것이었다.
따라서 첫 《워크래프트》 멀티플레이어 게임은 무승부였다. 하지만 동시에 개발팀에게는 커다란 승리였다. 끝내주게 재미있었으니까! 사무실의 다른 팀원들도 이후 곧 멀티플레이어를 플레이하면서 손대면 돌이킬 수 없는 마약을 맛보았다. 《워크래프트》의 멀티플레이어를 한 번 맛본 사람은 다른 게임으로 돌아갈 수 없었다. 주기적으로 게임이 다운되었지만 우리는 뭔가 굉장한 순간에 도달했음을 알고 있었다.
이제 필요한 것은 게임의 완성이었다.
비극적이게도 곧 우리는 더 고약한 사실을 발견했다. 동기화 버그가 무척 많을 뿐 아니라 그 원인도 다양했다는 점이다. 만약 모든 동기화 버그가 비슷한 이유였다면 그 하나의 근본을 찾아서 고쳐볼 수 있었다. 하지만 수없이 많은 유형의 문제가 있어서 각자 서로 다른 유형의 동기화 버그를 일으켰고 따라서 각기 다른 해법이 필요했다.
동기화 버그의 원인
나는 《워크래프트》를 개발하면서 각 플레이어가 내린 명령(“유닛 5 선택”, “650, 1225로 이동”, “유닛 53 공격”)만을 보냄으로써 네트워크로 전송되는 데이터의 양을 최소화하는 해법을 설계했다. 많은 프로그래머들이 나와는 별개로 이 같은 시스템을 설계했다. 차례마다 게임 상태 전체를 보내지 않으면서 두 컴퓨터를 동기화하는 문제에 이것은 누가 봐도 분명한 해법이었다.
잠깐 곁다리로 빠지자면, 요즘 이 방식에 대해 소급해서 공을 주장하려는 특허가 몇 개 있는 것 같다. 나는 소프트웨어가 특허로 등록되면 안 된다고 믿는다. 소프트웨어에 들어가는 아이디어 대부분은 어느 정도 숙련된 프로그래머라면 고안할 수 있다. 특허는 누가 봐도 명확하지 않은 것에 한정되어야 한다. 곁다리는 여기까지.
아직 두 컴퓨터 간의 동기화를 검증할 장치를 구현하지 않은 상태였기 때문에, 두 컴퓨터가 다른 선택을 내리게 하는 모든 버그가 게임에 분기를 불러올 수 있었다. 즉, 계속 통신은 하지만 시간이 지나면 더 빠르게 갈라져 느슨하게 연결된 두 세계로 나누어져 버린다.
게임을 출시하기 전에 해야 할 많은 일 중에서 탈동기 문제를 검출할 시스템을 설계하는 게 다음 일이 되었다.
긴 여행에 앞서
여러분은 이 이야기의 결말을 안다. 《워크래프트》는 결국 단 5개월 뒤에 출시된다. 매일 많은 시간을 일하면서 많은 장애물을 맞닥뜨리고 많은 난제를 극복하고 우리가 좋아하는 것을 열정적으로 만들었던 우리에게는 영원 같았다. 그 5개월은 앞으로 글에서 계속 다루겠다. 이번에는 한 번에 너무 많은 이야기를 담은 만큼 안 그래도 긴 글에 그 기억까지 다 집어넣기는 불가능하다!
저자: 패트릭 와이엇
게임 개발자로서 22년 이상을 업계에서 일하며 여러 작은 회사들이 크게 성장하는 데 도움을 줬고(블리자드의 부사장, 아레나넷의 창립자, 엔 매스 엔터테인먼트의 COO), 베스트 셀러 게임 시리즈의 디자인과 개발을 이끌었으며(워크래프트, 디아블로, 스타크래프트, 길드 워), 사실상 게임의 거의 모든 측면의 코드를 써봤고(네트워크, 그래픽, AI, 길 찾기, 사운드, 툴, 인스톨러, 서버, 데이터베이스, 전자상거래, 분석 도구, 암호화, 개발 운용 등), 개발한 게임의 많은 부분을 디자인했고, 플랫폼 서비스 팀을 운영했으며(데이터센터 운영, 고객 지원, 결제/계정, 보안, 분석), 대작 게임 퍼블리싱 사업에서 경쟁하는 데 필요한 첨단 기술들을 개발했다.
이 글은 저자의 허락 하에 번역하고 게시하였습니다. 저자의 블로그에서 원문을 확인할 수 있습니다. 오영욱님이 번역을 감수해주셨습니다.
This article is translated and republished by permission of the author.
댓글 없음:
댓글 쓰기