게임 개발은 쉽지 않다.
실제로 개발자가 의도한 모든 것을 있는 그대로 재현하려면 시간과 예산이 잔뜩 들 뿐더러, 게임이 무거워져 사양을 많이 잡아먹게 된다.
그래서 게임 개발자들은 언제나 꼼수를 쓴다.
쇼벨 나이트는 사실 2D 도트 그래픽으로 진행되는 게임이 아니라, 3D로 진행되는 게임이다. 눈속임을 썼을 뿐.
삽질기사가 정말 있는 그대로의 2D 도트 게임이었다면 엄청난 도트노가다와 물리법칙 적용에 훨씬 긴 개발기간이 필요했을 것이다.
이처럼 2D 게임처럼 보였던 게 알고보니 3D 게임이라는 경우는 꽤 흔하다. 엔터 더 건전도 이런 경우다.
3차원이라 해도 시점을 고정한다면 화면상에는 2차원으로 보이니 꽤 그럴듯하다.
그럼 반대의 경우는 어떨까?
3D 게임으로 보였던 게 사실 2D 게임이었다면?
말이 안될 것 같지만 놀랍게도 있다.
초창기 FPS의 대표격 게임들인 이드 소프트웨어의 울펜슈타인 3D(1992)와 둠(1993)은 사실 3D 게임이 아니다.
"아니, 명백히 3D 공간을 걸어다니는데 이게 3D 게임이 아니라고? 지랄하고 자빠졌네"
라는 생각이 들 테지만 정말로 3D가 아니다!
전부 교묘한 눈속임이다.
울펜슈타인과 둠이 출시될 당시의 가정용 게임기들은 실시간으로 삼차원 게임환경을 렌더링할 정도로 성능이 좋지 못했다.
그래서 실제 Z축을 게임에 집어넣을 수 없으니 당시의 게임들은 모두 꼼수를 썼다.
비슷한 시기에 슈퍼패미콤으로 나온 젤다의 전설: 신들의 트라이포스(1991)를 예로 들어 설명해보자.
짤에서 링크는 절벽에서 뛰어내려 우물 속으로 빨려들어간다.
하지만 실제 작동하는 게임 메모리 상에서 절벽은 없다.
절벽에서 뛰어내리는 모션도 있고, 진짜 절벽처럼 보이게 음영도 져있지만 모두 같은 높이에 있는 타일이다.
절벽 부분이 아래로만 내려갈 수 있게 프로그래밍 된 타일일 뿐.
링크가 절벽 '아래'에서 절벽 타일로 걸어올라가려 하면 게임은 링크를 막고,
절벽 '위'에서 아래로 내려가려 하면 뛰어내리는 모션을 재생하면서 아래로 내려보내는 것이다.
따라서 플레이어는 '절벽 위에서 뛰어내렸다'라고 생각하는 상황이
사실 게임기 내부에서는 '평면상에서 아래쪽 위치로 이동했다'고 처리된다.
이러한 눈속임으로 플레이어는 실제 높낮이가 있는 공간으로 착각하게 되지만,
게임 속 공간은 전부 평면일 뿐이다.
슈퍼패미콤 성능의 한계를 고려한 현명한 최적화인 셈이다.
똑같이 슈퍼패미콤으로 출시된 울펜슈타인 3D도 마찬가지다.
게임기의 메모리 내에서 게임의 모든 공간은 평면으로 처리된다.
그리고 이 평면 공간에 입체감을 부여하고자 꼼수를 쓰는데,
플레이어가 서 있는 위치(초록 화살표)를 기준으로,
매 순간 순간 게임은 직선으로 플레이어의 시야 내에 보이는 타일들과 플레이어의 거리를 스캔한다.
그리고 그 거리의 길고 짧음에 따라, 플레이어의 화면에 비춰지는 타일들의 크고 작음을 결정한다.
이 과정이 순식간에 이루어져,
그 결과물로 플레이어의 눈에는 깊이감 있는 화면이 보이게 되는 것이다.
일명 레이캐스팅(Raycasting)이라 불리는 렌더링 기법이다.
매 순간순간 플레이어를 기준으로 쏜 직선이 닿는 부분만을 화면에 나타냄으로써, 렌더링 하는 데 드는 메모리를 획기적으로 줄일 수 있다.
지금처럼 주변의 모든 공간을 3차원 렌더링 하려고 했다가는 슈퍼패미콤이 버티지 못했을 것이다.
결국 플레이어가 깊이감이 있는 삼차원 공간을 탐험한다고 생각할 때,
실제 게임기의 메모리상에서는 화면과는 상관 없이 평면 상의 공간을 프로세싱하고 있는 것이다.
3차원 공간처럼 보여도 Z축이 없는 2차원 공간이기에, 모든 벽들의 높이가 같고 게임 상의 높낮이 변화가 전혀 없다.
계단도, 2층도 없다.
그렇다면 둠은?
둠은 울펜슈타인 3D보다 훨씬 진보된 모습을 보여준다.
적들이 높은 곳, 낮은 곳에서 보이고 계단도 있다!
아무리 봐도 3차원 공간으로 보인다.
하지만 이것도 3차원이 아니다.
플레이어가 분명히 적의 머리 너머를 쏘고 있는데,
아무 문제 없이 총알이 적에게 맞는 것이 보이는가?
이것 역시 실제 높낮이의 구분 없이 눈속임을 이용하기에 벌어지는 현상이다.
둠은 울펜슈타인의 레이캐스팅보다 진보된 렌더링 기법으로 이진 공간 분할법(Binary Space Partitioning)을 사용한다.
개발자가 2차원 맵을 디자인하면
둠 엔진은 이 공간을 잘게 잘게 쪼개서
데이터 트리를 형성한다.
간단한 작은 공간을 예로 설명해보자.
이런 네모난 공간을 디자인했다고 해보자.
게임 엔진은 이 공간을 둘로 나누고,
또 그 둘을 다시 둘로 나누고, 계속 나눠서 게임 엔진이 수용할 수 있는 작은 공간들의 집합으로 만든다.
그리고 이 각각의 공간들을 데이터 트리로 만든다.
공간을 둘로 나누고 그 둘을 또 둘로 나눈다고 했던 것에서 볼 수 있듯, 이렇게 하면 서로 제일 가까운 공간들이 자연히 제일 가까운 가지에 배열된다.
플레이어가 이 공간에 들어섰을 때, 프로세서는 그 공간만큼을 렌더링하고 저장한다.
그리고 트리의 가장 가까운 다음 가지로 이동해서, 또 그 공간만큼을 렌더링하고 저장한다.
이렇게 렌더링하고 저장하기를 반복하다가,
한 가지가 차지하는 공간이 앞에 가로막혀 화면상에 보이지 않으면 그 공간은 렌더링하지 않고 넘어간다.
이 절차를 플레이어의 시야 안에 들어오는 공간을 완벽하게 렌더링할 때까지 반복한다.
이것도 게임에 들어가는 연산을 최대한 줄여 최적화하기 위한 수단이었다.
따로 물체의 위치를 삼차원 정렬하거나 하는 추가적 연산 과정 없이, 데이터 트리를 올바른 순서로 지나는 것 만으로 공간을 정확하게 렌더링할 수 있다.
뭔소린지 모르겠으면 그냥 꼼수 써서 효율적으로 화면을 그렸구나 하고 생각하면 된다.
레이캐스팅 기법을 쓰던 울펜슈타인은 단순한 2차원 게임 시스템을 벗어날 수 없었다.
화면은 말 그대로 단순한 2D 타일들을 이어붙인 것 뿐이었기에
모든 벽들의 크기가 똑같아야 했으며, 어색한 네모를 기워붙인 형상에서 벗어날 수 없었고, 벽들의 각도가 일정해야만 했다.
다른 각도로 배치된 벽을 렌더링하려면 훨씬 많은 연산이 필요했을 것이기 때문이다.
이와 달리, 둠의 이진 공간 분할법, 일명 BSP 기법은 이러한 제약으로부터 게임을 해방시켜주었다.
레이캐스팅처럼 벽의 픽셀들을 일일이 따라 계산하는 대신, 작게 분할된 각각의 공간들을 데이터 트리를 따라 렌더링함으로써
프로세서에게 무리를 주지 않고도 벽의 크기와 각도 등을 자유롭게 만들 수 있게 되었고,
바닥과 천장을 각기 다른 높이에 배치해 더 다양하고 몰입감 있는 경험을 제공할 수 있게 되었다.
혁신적이지만, 아직 3차원에는 도달하지 못했다.
깊이감 있는 천장과 바닥으로 보이는 것은 사실 플레이어 시점에서 깊이감 있어보이도록
프로세서에게 평소보다 더 멀리 있는 것처럼 렌더링하라고 지정된 타일들일 뿐이고,
실제 메모리 상에서는 전부 2차원 평면이다.
둠이 정말 게임을 3차원 공간으로 연산하고 있었다면 공간을 공간 위에 올릴 수 있었을 것이다.
하지만 둠을 처음부터 끝까지 플레이해봐도, 플레이어가 그 아래 설 수 있는 2층 공간 같은 건 없다.
2층 공간같은 게 있었다면 연산이 꼬였을테니까 말이다.
이것이 둠가이가 높낮이에 상관없이 적을 맞출 수 있는 이유다. 적들이 실제로 높은 곳에 있는 게 아니라, 그렇게 보이도록 만들어졌을 뿐이기 때문이다.
그리고 시점을 위아래로 올리거나 내릴 수 없는 이유이기도 하다. 진짜 3차원 게임이 아니라 3차원으로 보이도록 만들어진 2차원 게임이기 때문이다.
우리가 알고 있는 지금 형태의 완전한 3D 게임은 퀘이크(1996)가 나올 때 쯤에야 구현되었다.
둠에서 최초로 적용된 BSP 기법은 둠 이후에도 수많은 게임들에 활용되었으며, 아직까지도 가끔 활용되고 있다.
지금 와서 보면 어설픈 가짜 3D 그래픽이지만, 당시에는 조악한 하드웨어로 3차원의 화면을 구현해낸 혁신 그 자체였다.
아마 둠이 없었다면 지금 중붕이들이 즐기는 3D 게임들이 수 년 뒤에나 나왔을 것이다.
그리고 이 혁신의 뒷편에는 조금이라도 더 재밌는 게임을 만들고자 머리를 싸매 가면서 수없이 고민하던 개발자들의 노고가 있었으리라.
앞으로 게임 할 때에는 중붕이들도 게임 개발자들에게 감사하는 마음을 갖도록 하자.
요즘 게임 말고
제거
신림동 빨래방 만취 여중생ㄷㄷㄷ.jpg ;){kind=link}