GameMook

나는 이렇게 게임 프로그래머가 되었다 -1-
나는 이렇게 게임 프로그래머가 되었다 -2-

게임을 만들고 싶다고 해도, 우리나라의 학생들은 반드시 공부를 해야만 합니다. 우리나라는 일단 대학을 안나오면 제대로된 대접을 받기 힘든 사회이기 때문이죠. 부조리한 건 맞지만, 내가 속한 사회가 그러하다면 어쩌겠습니까. 공부를 해야죠.

그런데 학교 공부가 마냥 게임 제작과 관련이 없는 것만은 아니더군요.

앞에서 썼듯이, 저는 원래 비행시뮬레이션 등의 3D환경을 구현한 게임을 좋아했습니다. 그리고 제 고등학교 시절은 매년 DirectX의 새 버전이 나와서 새로운 기능을 가진 Direct3D를 쓰면 3D환경을 아주 쉽게 구현할 수 있다고 MS가 뭇 사람들을 현혹하던 시기였습니다. 그런데 당시에 Direct3D를 설명했던 책이나 잡지 기사를 보면 일단 '아주 쉽게'란 말은 사실과 아주 거리가 먼 표현이었습니다. 어떤 과정을 거쳐 이미지가 완성된다는 식으로 설명을 잔뜩 해놨는데, 솔직히 그때에는 하나도 이해를 못했습니다.

학교에서 진도를 나가면서 관련 내용이 나오자 아주 반가웠죠. 고등학교에서 수학 진도를 절반쯤 나갔을 때 벡터를 배운 것 같습니다. 벡터를 배우고, 도형을 벡터방정식으로 표현하는 것을 알자 3D 프로그래밍을 설명할 때 봤던 듯한 내용들이 쏟아져 나오는 것이었죠. 너무 마음에 들었습니다. 세상에 저렇게 간결하고 일관성있는 식이 있을 수가. 원래부터 이렇게 하는 것이 올바른 방식이었던 것처럼 느껴졌죠. 이렇게 간단한 방식을 더 일찍 가르쳐 주지 않는 학교 교육 과정이 오히려 불합리하게 느껴질 지경이었습니다.

그리고 수학을 웬만큼 배우고 나자 물리에선 모호한 표현으로 가르쳤던 것들이 사실은 그냥 단순하고 기초적인 벡터연산이었다는 점이 분명해졌습니다. 이를테면, 물리과목에서는 플레밍의 왼손법칙/오른손법칙 등으로 그냥 외웠던 물리현상들이 알고보면 간단한 벡터의 외적에 불과하다는 사실이나, '물체의 운동방향으로 작용한 힘'이라는 모호한 표현 대신 '물체의 변위와 힘의 내적'이라는 명료한 표현으로 쓸 수 있다는 점 등이 물리와 수학이 사실은 연결되어 있다는 깨달음을 주었죠.

물론, 이런 정신적 감흥을 느끼는 사람은 매우 적다는 건 저도 알고 있습니다. 하지만, 이런 감동의 순간 순간이 결국엔 도움이 되었죠. 지금 게임계의 가장 큰 화두는 바로 수학과 물리니까요. 어렸을 때 흥미와 감동을 느꼈으니 예습은 제대로 한 셈이죠.

다음에 계속
필자 : Uhm

경력 6년차의 게임 프로그래머. geek의 화신이며 포스를 수련한다는 소문도 있습니다.
홈월드나 토탈어나힐레이션, COH 같은 RTS와 FPS를 좋아하지만 요즘은 아내와 함께 기타히어로를 하는 가정적인 남편이기도 합니다.

언제나 후배들에게  포스의 어두운면에 대한 주의를 설파하는 뼛속까지 프로그래머.

나는 이렇게 게임 프로그래머가 되었다 -1-

게임을 만들기 위해 공부할 것은 지나치다 싶을 정도로 많습니다. 진심입니다. 진심으로 공부할게 너무 많습니다. 아마 단일 소프트웨어로는 운영체제, DBMS 다음으로 복잡한 물건이 아닌가 싶을 정도입니다. 아마 모두 다 공부하려고 책을 쌓아놓는다면 미리 포기부터하게 될 겁니다. 따라서 흥미가 있는 부분을 하나씩 파헤쳐보는 점진적인 과정이 중요하죠.

옛날 얘기를 좀 해보지요.

제가 게임 프로그래밍을 본격적으로 공부한 것은 94년부터입니다. 그때부터는 게임 프로그래밍에 필요한 것이 뭔지 닥치는 대로 찾아봤죠. 우선 대부분의 게임을 C로 만든다기에 C언어 부터 공부했습니다. 한동안 (한 반년쯤?) 포인터에서 딱 막혀서 탱자탱자 (게임하며) 놀던 기간도 있었지만 대개는 책 보면서 닥치는 대로 짜 봤습니다. 포인터의 개념을 터득한 후에는 책에 나온 도서관리 프로그램 따위의 예제를 짜봤죠.

C로 기본적인 것들을 대충 익히고서는 본격적인 게임에서 많이 쓰이던 그래픽을 어떻게 구현하는지가 궁금했죠. 당시 대부분의 게임이 320*200*8bpp^[각주:1], 혹은 640*480*4bpp의 그래픽 품질로 구현되고 있었고, 일부 고사양게임들은 640*480*8bpp의 그래픽 품질을 보여주던 시절이었습니다. 그리고 그중에서도 극히 고사양을 요구하는 (윙커맨더^[각주:2]와 같은) 게임들은 640*480*8bpp에서 3D 렌더링을 구현하고 있었습니다. 당연히 이러한 그래픽을 어떻게 구현하는지가 궁금했죠. 그때까지 쓰던 터보 C++ 2.0 에서 제공하는 그래픽 라이브러리(BGI)에서는 저런걸 할 수 없었기 때문이죠. 하더라도 끔찍하게 느린 속도를 감수해야 했죠. 게임에서 쓰던 방식은 아니란 걸 알았습니다.

그 답은 PC통신의 프로그래밍/게임제작 동호회 등을 뒤져가며 인터럽트란 것에 대한 개념을 주워들으면서 얻을 수 있었죠. 하드웨어에 인터럽트를 날리면 하드웨어에서 특정한 동작을 수행하며, 그래픽스 하드웨어에 인터럽트를 날리면 그래픽에 관한 원하는 동작을 수행할 수 있다는 것 정도가 파악되었습니다. 그때부터 여기저기서 찾아본 정보로 (지금도 업데이트되고 있는) Ralph Brown's Interrupt List 라는 것의 존재를 파악했습니다. 거의 모든 하드웨어의 인터럽트 펑션에대한 자세한 정보가 기술되어 있는 리스트였죠. 당시에 조금이라도 프로그래밍을 한다 싶은 사람들은 저마다 하나같이 RalphBrown's Interrupt List가 중요한 참고자료 중 하나였을 겁니다. 저도 DOS에서 그래픽스 라이브러리를 구현해 보는 데에 RBIL이 매우 좋은 참고자료가 되었습니다.

옛날 DOS게임을 할 때 궁금했던 것 중 하나는 게임을 실행하면 (DOOM같은 것들) 프롬프트에 스크롤되어 올라가던 다음과 같은 문구였습니다.
약간 설명을 하자면, 당시 640*480*8bpp 이상의 그래픽 품질을 구현하고자 했을 때 가장 걸림돌이 되었던 것은 16비트 운영체제였던 DOS의 64kb 세그먼트^[각주:3] 제한이었습니다. 단순 산술계산으로도 640 * 480 * 8bpp = 2457600bit = 300kb 이기 때문에, 5개의 세그먼트를 오가며 메모리에 접근해야 했죠. 비디오 메모리의 접근 세그먼트를 변경하는 것도 비디오 하드웨어의 인터럽트 펑션중 하나였습니다. 저는 당시 게임에 많이들 쓰고 있던 DOS/4GW의 정체가 이러한 제약과 관련이 있다는 것을 알아낼 수 있었습니다. 이러한 제약은 DOS가 인텔계열 CPU의 리얼모드만을 이용하는 OS이기 때문이며, 이를 보호모드로 전환하면 주소공간이 32비트로 확장되어 최대 4gb에 이르는 메모리를 세그먼트전환 없이 사용할 수 있게 되는 구조였죠. 즉, DOS에서 보호모드를 사용할 수 있게 해주는 실행환경이 바로 DOS/4GW였던 것입니다. DOS/4GW는 당시 최적화가 잘 되기로 소문이 나 있던 Watcom C++과 함께 배포되어 WC의 기본 프로젝트 세팅중 하나로 선택할 수 있었죠. 저는 '세그먼트 전환이 없는 그래픽 라이브러리'를 목표로 어렵사리 (당당하지는 못한 방법이었지만) Watcom C++ 의 한 카피를 구해서 구현 해보았죠.

위의 이야기들은 옛날 이야기고, 지금에 와서는 전혀 쓸 일이 없는 기술들이고, 제가 왜 아직까지 이런 것들을 기억하고 있는지가 신기할 지경인 일들입니다. 하지만 남은 것도 좀 있지요. 인터럽트와 보호모드는 모두 현대 CPU와 OS의 구조를 이해하는데에 결정적인 키워드입니다. 인터럽트 리스트를 뒤져가며 그래픽 라이브러리를 구현해본 것도, 개발툴 매뉴얼을 보며 보호모드 전환을 해본 것도, 모두 현대 컴퓨터의 구조를 이해하는 데에 매우 큰 도움이 된 것 같습니다.
물론, 위의 과정을 거치면서 얻은 가장 큰 소득은, 앞으로 프로그래밍이란 작업을 어떻게 해야 하는 지를 몸으로 익혔다는 점입니다. 바로, "한가지씩 해본다"는 철학이죠.


다음에 계속
나는 이렇게 게임 프로그래머가 되었다 -3-
필자 : Uhm

경력 6년차의 게임 프로그래머. geek의 화신이며 포스를 수련한다는 소문도 있습니다.
홈월드나 토탈어나힐레이션, COH 같은 RTS와 FPS를 좋아하지만 요즘은 아내와 함께 기타히어로를 하는 가정적인 남편이기도 합니다.

언제나 후배들에게  포스의 어두운면에 대한 주의를 설파하는 뼛속까지 프로그래머.

욕망.
게임을 만들기 위해서 가장 중요한 덕목입니다. 게임을 만들고 싶은 욕망이 없는 사람은 게임을 만들 수가 없죠. 저는 현재 31살의 게임프로그래머로서, (웬만한 게이머들은 이름을 대면 알 거 같은 느낌이 드는 게임의) 프로그램팀장을 하고 있습니다. 저 역시 게임을 만들고 싶은 욕망 때문에 일을 시작했죠.

게임을 접하고 좋아하는 거야 아주 어렸을 때 일이지만, 본격적으로 게임을 만들어야 겠다는 생각이 든 것은 고1때의 일입니다. 중3때 접한 듄2^[각주:1]를 보고, 나중에 저런 게임을 만들면 정말 멋진 사람이 될거 같은 느낌이 들었죠. 이리저리 PC통신으로 (93년 당시) 알아본 결과, 요즘 게임은 보통 C로 만든다는 것을 알아냈고, 서점에서 찾아볼 수 있었던 책 중에서 가장 얇은 C언어 입문서를 사들고 왔습니다. 그게 94년, 고1때의 일이죠.

물론, 그 전, 초등학교(저는 국민학교를 다녔습니다만) 때 다들 하듯이 GW-BASIC^[각주:2]등으로 기본적인 프로그래밍은 익혔죠. 컴퓨터학원 다니면서 심심풀이로 테트리스나 15-퍼즐이나 오목같은 간단한 게임을 만들면서 지내곤 했습니다. 하지만, 거기까지가 전부였죠. 베이직의 파일입출력을 끝끝내 이해할 수 없었기에 그보다 대규모의 프로그램은 만들 수가 없었습니다. (지금 생각해도 베이직의 파일입출력 라이브러리는 괴악하기 그지없습니다) 베이직으로는 고등학교때 컴퓨터동아리에서 '땡겨^[각주:3]'내기 테트리스 짜기나, Dragon Curve^[각주:4](쥬라기 공원의 각 장 앞부분에 나온 그 드래곤 커브)를 Q베이직^[각주:5]으로 구현하며 논 것이 거의 마지막이었습니다.

베이직의 한계를 느낄 무렵, C라는 언어의 존재를 알게 되면서 C언어 책을 고를 때, 가장 중요한 기준은 (위에서도 썼지만) '얇은 책'이었습니다. 저는 나름 독서광이었고, 새로운 것을 접할 때는 간략하게 개괄적으로 설명한 책이 더 나에게 적합하다는 것을 알고 있었으니까요. 자신에게 무엇이 가장 적합한지를 아는 것이 중요했던 것 같습니다. 만약 C언어의 모든 면을 자세히 설명한 TCPL^[각주:6]같은 책을 골랐더라면 인내심이 한없이 0에 가까운 저는 이내 포기하고 말았겠죠.

제 인내심은 욕망을 지지할 정도로 견고하지는 못하다는 점을 알고 있었습니다. 게임 제작을 하고 싶다고 하더라도, 자신의 특성을 파악해야 했던 것이죠.

(다음에 계속)
나는 이렇게 프로그래머가 되었다 -2-


필자 : Uhm

경력 6년차의 게임 프로그래머. geek의 화신이며 포스를 수련한다는 소문도 있습니다.
홈월드나 토탈어나힐레이션, COH 같은 RTS와 FPS를 좋아하지만 요즘은 기묘하게도 와우를 하는 시간이 더 많은 게이머입니다.

언제나 후배들에게  포스의 어두운면에 대한 주의를 설파하는 뼛속까지 프로그래머.