Anoa의 모든 글

감독이 되다 2

지난 글(링크)에서 이야기 한 것 처럼 다소 즉흥적으로 일을 벌여 이벤트 신을 만들게 되었다. 그리고 이벤트 신 감독(직접 이름 붙였다)에 취임하였다고 이야길 하였다. 이 이야기는 자신의 방망이를 만족하지 못하고 계속 깎고 있는 노인의 현재 진행형 실화 이야기이다…

아미 앤 스트레티지:십자군(이하 AnS)은 기본적인 게임의 시스템을 완성했다. 요컨데 사람과 컴퓨터가 같은 테이블에 둘러앉아 사용 할 기본 규칙을 완성한 것인데, 거기에 세력 별 시나리오를 가미하여 RPG의 느낌을 추가 하기로 결정하였다.

이야기를 이어 나가는데에는 이벤트 신 만큼 좋은 것이 없다. 기획자 아이린은 기본적인  시나리오와 캐릭터, 그리고 캐릭터의 성격, 그리고 대사를 작성했고, 늘 그렇듯 나는 난장을 피웠다. 처음 만드는 시스템은 항상 돌발 변수가 생기기 때문에 만들어 보기 전까지는 문제를 알 수 없었기 때문에 만들어가면서 이것 저것 내 맘대로 바꿔버렸다. 본인이 노력한 모든 것을 부정당하고도 크게 개의치 않아했던 기획의 인내심에 박수를 보낸다.

이벤트 신은 시나리오 진행에 따라 턴마다 나오거나, 퀘스트를 해결 할 때 나오거나, 특정 국가를 멸망 시켰을 때 나오는 등. 중간중간 불쑥불쑥 나와야했다. 그렇기 때문에 분량은 짧아야 했고, 긴 대사를 넣을 수 없었다. 그리고 당연히 내용을 신경쓰지 않거나, 읽기도 전에 넘어갈 수 도 있기 때문에, 이벤트 신을 보지 않고서도 플레이를 할 수 있도록 배려 해야 한다.

위와 같은 제약으로 인해 작업을 하다보니 여러가지 규칙을 추가하게 되었다. 규칙은 아래와 같다.

이벤트 씬의 길이는 10~20초 내외여야 한다.

물론 빨리 감기도 지원.

“내가 만든 씬은 돈도 많이 쓰고 정말 죽여 준다구. 그러니까 스킵없이 끝까지 봐” 라고 하는 게임들을 본인은 정말 싫어한다(보고있나 xxx판타지?).

이벤트 내용으로 인해 생기는 결과들을 마지막에 한번 더 정리해서 보여준다.

내용을 보지 않더라도 결과는 알 수 있어야한다

직위 등 힘의 우위가 있는 경우, 더 센 쪽을 오른쪽, 그리고 조금 더 높은 곳에 둔다.

게임에 나오는 모든 플레이어 혹은 플레이어 국가는, 항상 왼쪽에서 오른쪽을 바라보도록 위치한다.

자연스럽게 누가 나인지 확인할 수 있다.

캐릭터의 성격은 단순하고 극단적인 인물로 설정한다.

대사가 짧고, 출연횟수가 적기 때문에 성격은 알기 쉬워야한다.

조직이나 특정 그룹의 사람들은 반복되는 구호 및 행동들로 특징짓는다.

항상 반복되는 동작으로 케릭터 성을 부여하는 것이 좋다.

캐릭터에 주위에 있는 실제 인물의 성격을 과장되게 부여한다.

100% 상상 보다는 대사가 더 잘 써진다(감정 이입도 됨).

시작 시 이야기의 배경이 되는 날짜와 장소를 보여주고 시작한다.

이것은 시나리오용 이벤트로, 일반적으로 여러 곳에서 뜨는 이벤트 신과는 다르게 봐줘야함을 의미한다.

플레이어의 커맨드에 의한 이벤트는 대상만 이야기하도록 한다.

대출이라거나 고용 등 어느 왕국을 선택하든 사용하는 시스템들은 주인공의 말투나 성격을 일일이 넣어줄 수 없기 때문에 대상만 이야기 하도록 한다.

시행착오를 거쳐가며 위와 같은 연출 규칙을 하나씩 추가하였다. 만들다 보니 지정된 캐릭터의 얼굴을 보아가며 성격을 만들게도 되고, 캐릭터를 성격을 잡아가며 작성하다보니, 해당 캐릭터는 시나리오 대로 갈 성격이 아닌지라 시나리오를 바꾸는 경우도 생기더라.

그리하야 아래와 같은 영상이 완성되었다. 아래는 이벤트 신.

아이튠즈 팟캐스트에서 라디오 방송 등을 받으면 ‘새 것’, ‘듣다가 멈췄음’, ‘다 들음’의 표시가  동그란 원 반원 그리고 없는 것 으로 구분이 된다. 재미 있는 부분은, 끝에서 몇 초 남았을때 끊어도 반원은 없어 진다는 것이다. 일반적인 라디오 방송이나 그런 것들은 마지막에 노래 혹은 cm등이 나오기 때문에 다들 끝까지 듣지 않고 넘기게 되는데, 그렇기 떄문에 끝 부분 쯔음 에서 멈추면 모두 들은 것으로 간주해 준다. 저런 수 많은 작은 편의 기능들이 모여 x플 제품이 사용감이 좋다 라는 걸 만들어 주고 있진 않을까? 그들도 수많은 방망이 깎기에서 저 결과가 나오지 않았을까? 물론 윈도우즈용 아이튠즈는 정말 x이다.

이런 수 많은 방망이 깎기 도전과제를 모두 해제해도 우리가 GOTY(Game Of The Year)의 보상을 받을 수 없다는 건, 잘 알 고 있다. 다만 우리를 기대해 주시는 많은 분들이 있기 때문에, 대충 내서 결과를 보자. 식이 아닌 정말 진지하게 개발 하고 있고, 그런 것들을  “이런 것 까지 신경썼네?” 하고 눈치채어 준다면 정말 기쁠 것 이라는거. 그냥 그 정도의 생각으로 일 하고 있다.

시간이 간다. 누군가는 코드를 짜면서 보내고. 누군가는 그림을 그리면서… 그리고 누군가는 일반적인 회사에 다니고 있다면 해보지 못했을 경험을 하면서… 프로그래머에게는 필요없는 경험 일 수도, 한국에서 가장 강력한 이념인 먹고사니즘에 따르면 전혀 쓸모없는 그런 것을 하면서 시간을 보내는 것 일 수도 있지만, 적어도 인디 개발자가 되니 해볼 수 있었던 경험이고, 그래서 나에게는 시간이 즐겁게 흘러간다.

감독이 되다

인디 게임의 정의는 여러가지가 있겠지만, 나는 가장 쉬운 분류법으로 60 달러(USD) 게임에 들지 못하는 게임은 인디 게임이다. 라고 생각한다. 1~30 명 내외의 소규모 인원으로 게임을 만드는 것. 대형 퍼블리셔(EA 나 Ubi 같은)에게 돈을 받지 않고 개발하는 것, 그런 것 말이다. 킥스타터같은 곳에서 펀딩받는 인디 게임이나, 스팀에 올라온 인디 게임들을 보면 ‘어떻게 이런게 인디지?’ 라는 생각이 들때도 있지만, 또 ‘그게 인디지 뭐’ 하게되는. 자우림도 있지만 눈뜨고 코베인도 있는 인디 씬 처럼(물론 자우림에 대해선 논란이 있을수도 있다) 그런 느슨한 끈으로 묶여있는, 그런게 인디 게임의 정의 라고 생각한다.

이렇게 생각 한다면 요즘은 ‘국내 게임 개발자들 대다수가 인디 개발자인 시대’ 인 것 같다. 야구를 좋아하는 분이라던가, 일본에 상장 하여 큰 부자가 된 분 등, 업계를 휘어잡고 있는 분들이 큰 그림을 그린 이후, 큰 회사들은 변신 로봇마냥 이리저리 합체가 되었다. 그에 따라 많은 개발자들이 자의 반, 타의 반으로 소속된 회사에서 나오게 되었다. 수 년전 온라인 게임 붐 때는 신규 프로젝트에 몇 십억 또는 몇 백억씩 투자를 해 줄 여력이 있던 시기지만 지금은 아니기에, 다들 스마트 폰 게임이나 소셜 게임쪽으로 창업을 하고 있는 추세고, 그들이 만드는 게임은 위에서 내가 이야기하는 인디게임의 범주를 넘어서는 것 처럼 보이진 않는다. 바야흐로 ‘대 인디 시대’ 혹은 ‘대 창업 시대’의 개막이다.

파이드 파이퍼스는 시작부터 인디 개발팀 이였다. 느슨하게 ‘게임을 만들고 스마트 폰으로 대충 내면 어떻게 수익을 낼 수 있지 않을까?’, ‘빡 새 같은거 나도 한 달이면 만드는데 그런거 만들면 부자 되는거 아냐?’ 같은 생각과는 전혀 다르게, 게임 프로토타이핑을 길게하고, 만들고 싶은 게임을 다듬고 싶을 때 까지 다듬는 것을 목표로 시작했다. 시작할 때는 팀 내에 그래픽 디자이너가 없어서, 웹상에서 리소스를 조달 해 개발했고, 팀 내부에 출퇴근하는 그래픽 디자이너가 없는 것을 감안하여 최대한 리소스를 적게 쓰는 게임을 선택 하고, 하나의 리소스를 여러곳에 중복으로 사용할 수 있도록 UI를 고안하였다(프로젝트 시작 후 13개월이 지나서야  ‘아미 앤 스트레테지: 십자군’은 100% 자체 리소스로 채워졌다).

아래는 우리가 이벤트 씬이라고 부르는 것이다. 짧은 컷 씬인데 인 게임의 여러부분에 붙여 넣어 게임의 이야기를 이끌어 나가고 분위기를 살리는데 사용 하고 있다.

사실 이런 이벤트 신은 어릴적 즐기던 게임들에서 영향을 받았다. 나는 아직도 영웅전설 3 에서 밤에 잠이 오지 않아 침대에서 뒤척이던 이벤트 신을 기억한다. 그저 걷는 모습을 좌우로 번갈아서 찍었을 뿐이지만 이 단순한 효과가지고도 이야기에 흠뻑 빠져들게 하기엔 충분했다. 당시 게임들은 용량을 줄이고 작업량을 줄이기 위해서 그런 방법을 많이 사용했다. 혼란에 빠지면 4방향으로 캐릭터를 뱅글뱅글 돌리거나, 놀랄 경우 살짝 위로 올렸다가 내리거나 등. 세밀한 텍스쳐, 사실적인 애니메이션, 엄청난 모델링과는 거리가 멀었던 시절이라 지금에서 보면 ‘뭐 그런게 좋나?’ 싶겠지만 그 거리의 간극을 상상력이 체워주고 있었기 때문에 감정 이입이 되던 시절이였다.

그 시절 개발자들이 당면한 조건과 우리가 제약 조건이 비슷하기에 우리는 그들의 방법을 차용하기로 했다. 원래의 기획안은 이미지를 한장 띄우고 그 아래에 장문의 문장으로 서술하는 고전적인 방식이였는데, 무책임 하게도 위의 이벤트 신으로 만들자는 결정을 IGF China 2012 용 릴리즈 두 달 전에 결정해 버렸다. 생각보다 많은 시간이 소모 되었지만 원안보다는 확실하게 게임의 분위기를 살릴 수 있었다고 자부한다.

기존의 십자군 역사 관련 글들을 보면 등장했던 카드 형태의 캐릭터, 전체 맵과 외교에서 사용하던 깃발과 문양 등 이미 게임의 다른 부분을 위해 만들어 놓은 물건을 최대한 사용했다. 프로토타입 때에는 ‘던전 앤 파이터’의 배경과 ‘사무라이 스피리츠’의 배경을 가져다 놓고, 그 위에 장수 얼굴을 올렸으며, 간단한 기본 대화가 전부였지만, 심볼과 깃발을 넣고. 그 깃발을 장수가 들고 다니도록 하고, 얼굴 표정을 적용하고, 몇 종류의 대화창을 추가한 후, 분노 점프와 같은 에니메이션을 추가 했다. 상대와 나와의 관계 점수나 종교 관계 등을 기준으로 상황마다 다른 대사가 나오도록 작성하였고, 랜덤으로 텍스트를 출력하거나, 군중 씬 등에서는 위치를 랜덤하게 적용하거나 하는 프로그래머 다운 노가다도 수행했다. 이팩트도 간단히 넣고, 효과음도 sfxr로 만들어서 넣었다.

(길게 이야기 했지만) 정리하자면, 계획없이 즉흥적으로 필요할 때마다 아무거나 만들어서 넣었다는 이야기이다.

누구나 자신이 만든 무언가를 남에게 보여주고 칭찬 받고 싶어하는 마음이 있다고 생각한다. 어린 아이들 보면 부모의 칭찬을 받기 위해 하는 행동처럼. 내 손으로 만든 것을 보여주고 싶었지만 박명수 옹 처럼 한글 철자도 자꾸 틀리는 마당에 소설같은건 무리고, 디자인을 보는 눈은 부족하며, 그렇다고 노래를 잘하거나 악기를 다룰 수 있는 것도 아니고. :-(

하지만 (프로그래머로서) 이벤트 신 작업은 감당 할 수 있었다. 짧은 대사와 서술만 필요하기 때문에 글쓰는 능력은 상관 없었고(그나마도 기획자 감수를 거쳤다) 이미 디자인된 물건 들을 적용만 하면 되기에 디자인 센스도 필요 없고, 레트로한 물건! 이라고 정한 탓에 효과음도 직접 만들어 넣을 수 있을 만한 수준이면 충분했다. 자신감이 생긴 탓에 생각보다 많은 부분에 생각보다 많은 신을 만들어 내었다. 이벤트 신을 작성하는 나는, 내용을 구상하고, 이미 있는 물건들을 적절히 배치해서 찍어내는 감독이 되었다.

프로그래머는 프로그램에 대한 제한을 긋고 의견을 제시할 수 있을 뿐 전적으로 해당 작업자가 일을 잘 할 수 있도록 도와주는 역할에 머물러야 한다고, 주변 사람들에게 항상 이야기 하고 다녔고, 십 여년 간 그렇게 일을 해왔다. 그래도 나도 프로그래머 이전에 게임 개발자이기 때문에. 노트의 가장 뒷장부터 게임에 대한 생각을 채워 나간 기억이 있으니까. 시스템을 주도해서 만들고, 그것을 보여줄 수 있다는게 정말 행복했다. 확실히 개발에 대한 만족스러움이 있기에 어딜 가던 누구와 만나던, 요즘 일은 어떻냐? 라는 질문에 서슴없이 이렇게 대답을 한다.

“내 인생에서 지금이 가장 충실히 사는것 같다. 지금이 가장 행복하다.”

얼마 안되었지만 나의 개발 인생은 지금이 가장 충실하며, 행복하다. 여러분의 게임 개발도 항상 그러길 빈다. :-)

자체 엔진의 변

항상 예전부터 자체 엔진에 대해서 글을 쓰고 싶었다. 우리는 왜 자체 엔진을 써서 작업하는가? 뭐 그런 것에 대해서 말이다. 하지만 쉽사리 맘에 드는 글이 써지지 않아서, 몇번을 지우고 쓰고, 지우고 쓰고 반복하다 결국 이 변명같은 글을 하나 던져본다.

나는 올드한 개발자다. 정통성이 있다거나 오래했다거나 하는 자랑 섞인 이야기가 아니다. 그저 오래전 습성을 변경하지 못한다는 뜻이다. 코드 스타일은 요즘 많이들 쓰는 오픈소스 스타일이 아니라, 오래전 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톤 트럭도 오토로 나오는 세상에서, 아직도 수동 차량을 좋아하는 사람도 있고, 수동 차량이 더 적합한 도로 상황도 있는 법이다. 적어도 수동타면 급발진은 없잖아?