Skip to content

Quake:SourceReview

Quake게임 소스코드 구조를 설명한다.

Intro

  • botlib: 인공지능 플레이어인 Bot의 인공지능에 관한 라이브러리. aas라는 자체 bot을 위한 데이타 파일을 읽고 장애물을 피해가는 최단경로나 채팅에 관한 내용들이 담겨져있다.
  • cgame: 퀘이크3 게임에 관한 클라이언트측 모드 소스. 총이나 로켓을 쏠때 어떻게 이펙트를 보여줄것인가 등 패킷에 담겨져 있는 정보를 어떻게 표현할것인가에 대한 내용이 담겨져있다.
  • game: 퀘이크3 게임에 관한 서버측 모드 소스. 총이나 로켓을 쏴서 상대가 맞으면 헬쓰가 얼마나 깍이고, 죽으면 스코어가 어떻게 되고 등 서버측에서 어떻게 처리할것인가에 내용이 담겨져있다.
  • q3_ui: 퀘이크3 게임에 관한 ui 모드 소스. 메인 메뉴나 ingame메뉴에 대한 처리 부분.
  • renderer: 퀘이크3 엔진에서 렌더러부분. 렌더러 부분은 따로 스태틱 라이브러리로 만들 수 있는데, 이것은 렌더러부분을 자체제작한 다른 툴에서도 이용하기 위함이다.(Shader툴이나 텍스쳐둘이나 등등) 렌더러의 인터페이스만 얻으면 외부에서도 쉽게 렌더러를 이용 할 수 있다.
  • quake3: 퀘이크3 엔진 코어. 사운드 매니저, 메모리 매니저, 클라이언트와 서버측 엔진처리, vm, 파일 매니저, cvar 매니저, 충돌처리, 윈도우나 리눅스에 대한 코드 등등이 담겨져 있다.
  • splines: 다른 툴에서 스플라인을 만들때 쓰는 라이브러리 인듯.
  • ui: 퀘이크3 팀아레나에 관한 ui 모드 소스.

엔진과 virtual machine

퀘이크3 엔진은 게임을 실행할려면 virtual machine이 필요하다. virtual machine, 약자로 VM이라고 하는데, 쉽게 말하면 게임을 실행할때 필요한 모드소스부분이라고 할수있다. 즉 퀘이크3 게임을 하기위해서 cgame.dll game.dll ui.dll(혹은 .qvm) 이 3개의 vm이 있어야 하고 모드소스가 배포되었을때는 이 3개의 vm들의 소스가 배포된 것이다.

vm은 dll버전과 qvm버전 둘 중 아무거로 컴파일을 할 수가 있는데, qvm은 quake1 시절부터 유래된 quake c로 컴파일한 일종의 바이너리파일인데 엔진에서 이 파일을 읽어서 실행시킬수가 있다. (사실 나도 아직 qvm에 관한 자세한것은 모른다. q3에서 처음 배포된거라서)

vm에서 엔진의 기능을 호출할때는 trap_으로시작하는 syscall로 호출하고, 엔진에서 vm에 관해 호출할때는 vmMain을 호출한다. 특징적인것은 vm에서 호출하는 syscall이나 엔진에서 호출하는 vmMain이나 파라미터로 포인터를 넘겨주지 않고, 모두 integer로만 넘겨줘야한다. 이것은 엔진차원에서 안정성을 확보하는것이기도 하고, 모드개발자에게 실수를 방지해주는 것이기도 하지만, 모든 엔진이 포인터보다는 핸들을 주고받는 구조적 일관성을 유지시켜주는데도 일조를 한다.

따라서 모드개발자는 syscall로만 엔진의 기능을 이용할수가 있고, syscall의 종류와 갯수가 이 엔진이 좋고 안좋고를 결정하는것이다.

메모리 관리

엔진은 zone과 hunk라는 두개의 메모리 관리자를 사용한다. zone 메모리 관리자는 처음에 큰 메모리(com_zoneMegs에 지정된만큼)를 malloc한다음 double linked list를 사용하여 메모리 요청이 있을때마다 쪼개어 쓰는데, 리스트를 검색하는데 약간의 시간이 걸리므로 일반적인 용도에서만 쓰인다. 한편 hunk 메모리 관리자는 처음에 큰 메모리(com_hunkMegs에 지정된만큼)를 malloc하는것은 같지만, 주로 맵을 로딩하거나 렌더러를 초기할때처럼 한번에 같이 리셋되는 것들이 순차적으로 요청을 할때 사용한다. hunk는 리스트로 메모리를 관리하는게 아니고 메모리 position으로 관리하기때문에 속도가 무척빠르고 clear하는것도 빠르다(position을 초기위치로만 변경하면 되기때문에). 메모리관리자는 메모리가 overflow되는것을 검사하는것뿐만 아니라, 콘솔에서 meminfo만 치면 상세하게 메모리 상황이 리포트된다.

한편 vm들은 기본적으로 엔진의 메모리관리자를 이용하지 않는데(메모리를 엔진에 요청해서 리턴받는 메모리 주소로 악의적으로 엔진을 망치게 할수 있기때문이다), 신기하게도 모두 static으로 해결을 한다. 모든 entity리스트나 정보등을 static으로 사용하며, clear할때는 memset으로 가뿐히 해결한다. 굳이 동적메모리 할당을 흉내낸것이 game안에 g_mem.c인데, 이것역시 스태틱으로 메모리 풀을 만들어놓은다음 요청이 있을때마다 나누어준다. 어찌했거나 vm들은 동적메모리를 하나도 이용하지 않기때문에 메모리 누수 걱정을 할 필요가 없다.

콘솔 (Console)

엔진에는 게임내의 콘솔, 시스템 콘솔 두 가지의 콘솔이 존재한다.

게임내 콘솔은 게임클라이언트가 활성화되었을때 콘솔키를 누르면 나타나고, 시스템 콘솔은 엔진이 시동할때에 만들어지지만 클라이언트가 활성화되면 보통 hide된다. 게임내 콘솔과 시스템 콘솔은 서로 동기화되지만 게임콘솔은 주로 유저들을 위해 많이 쓰이는 한편, 시스템 콘솔은 주로 개발자들에게 유용하다. 시스템 콘솔은 윈도우 버전에서는 윈도우로 만들어졌지만, 리눅스버전에서는 콘솔로만 보여지는 등 플랫폼에 따라 형태가 달라질수 있지만, 게임내 콘솔은 어느 플랫폼이나 동일하게 보여진다. 시스템 콘솔은 엔진 개발 초기부터 유용하게 쓰이는데, 각종 로그를 한눈에 볼수 있을 뿐아니라 로그를 클립보드로 복사를 할수있고, developer변수를 1로 셋팅하면 개발자용 로그도 출력되어 더욱 자세하게 상황을 파악할수가 있다. 특히 퀘이크3를 dedicated 서버로 실행하면 클라이언트가 사라지고, 이 시스템 콘솔창이 활성화 되는데, 서버가 동작하는 상황을 관찰하는 용도로도 쓰인다. 엔진내에 fatal 에러가 발생하면 모든 기능이 소멸되고, 시스템콘솔창이 깜박깜박 거리며 활성화되어 에러검출에도 도움이 많이 된다.

콘솔은 로깅하는 속도가 느리지 않아서 렌더링 디버깅에서 매프레임당 로그를 출력해도 느리지 않고, logfile을 1로 셋팅하면 모든 로그내용이 파일로도 저장되어 로그를 손실할 걱정도 없다.

시네마틱 (Cinematic)

cinematic이라하면 영화기법이지만 id게임에서는 동영상을 플레이를 하는 기능을 말한다. 콘솔에서도 cinematic intro.roq이런식으로 입력하면 바로 볼수도 있는데, 퀘이크3에서는 확장자가 roq인 파일이 cinematic파일이다.

보통 다른 게임에서는(d3d를 이용한 게임은) dshow를 이용하거나 blink 라이브러리를 사서하거나 하지만 퀘이크3에서는 엔진이 오픈지엘기반이다보니 id가 독자적으로 개발을 한것같다. (실은 그런기능을 가진 라이브러리가 있다해도 id는 새로 깔끔하게 속도빠르게 자기네들이 직접개발하기를 좋아한다.)

퀘이크3의 이 cinematic은 게임디자이너인 graeme devine이 짠걸로 알려지는데, 그는 1995년도에 출시한 The 11th Hour에서 동영상 플레이부분을 코딩한적이 있는, 게임계 경력이 18년차인 베테랑이다.

roq는 스크린은 vector quantisation(벡터 양자화)라고 부르는 jpeg에 쓰이는 기술로 화면을 압축했고, 오디오는 dpcm으로 압축을 하였다. 이 코덱을 몇년전에 Tim Ferguson교수가 분석해서 unofficial 포맷을 공개한적이 있다. 이 코덱은 여타 dshow나 blink보다 디코딩속도가 빠른것으로 알려져있고, 대신 파일사이즈가 큰 경향이 있다.

roq는 속도가 빨라서 ui에서도 오버레이 레이어로 쓰이기도 하는데, 그 좋은예가 'Return to castle wolfenstein'의 멋진 ui이다. 퀘이크3 팀아레나에서는 맵내의 TV에서도 roq가 쓰이고, 둠3에서도 TV효과는 다 roq를 쓰고 있다.

사운드 (Sound)

엔진의 사운드 시스템은 꽤 기본에 충실하다.

dsound등을 쓸수 없기때문에(멀티플랫폼으로 만들어야하니까) 믹서을 손수 구현을 하였다. 최대 96채널을 동시에 믹싱할 수 있는데, 3d 위치에 따라 좌우볼륨을 조절하여 렌더링하여 3차원 공간에서의 소리도 제대로 구현이 된다. 그리고 도플러효과도 있고, s_show를 1로 하면 사운드 시스템이 동작하는것도 한눈에 보여진다.

사운드 시스템의 소스를 분석하고 나면 게임내 사운드는 어떻게 동작한다는것을 쉽게 이해할 수 있을것이다.

See also

Favorite site