80년대의 게임
1970년에 기술을 기반으로 80년대에 여러 게임 기기가 등장하였고 여러 명작 디지털 게임이 등장하였다.
근데 이 게임 기기의 스펙을 보면 램이 고작 4KB이고 하드디스크나 다른 기능은 하나도 없었다.
현재로 4KB는 크기가 매우 작은 이미지 한 장에 불과한 용량이다.
과거에는 게임 기기 하나당 게임 한 개이거나 게임팩을 통해 한 게임 기기로 여러 게임을 즐길 수 있었다.
그렇다면 예전 프로그래머들은 어떻게 이런 적은 용량에 게임을 만들었을까?
슈퍼마리오
대표적으로 슈퍼마리오의 게임팩 용량은 고작 40KB이다.
정확히는 소스코드는 32KB, 그래픽 에셋은 8KB 밖에 되지 않았다.
이 8KB 용량 안에 8개의 월드와 각 월드 당 최소 4개의 스테이지, 배경과 오브젝트, 주인공과 몹까지 전부 들어가야 한다.
이러한 악조건에서 어떻게 게임을 제작하였을까?
용량 줄이기
배경 에셋 줄이기
슈퍼 마리오를 플레이할 수 있었던 NES의 화면 사이즈가 256px * 240px이었다.
그럼 배경 하나를 저장하는 데 드는 용량은 256px * 240px * 3byte로 대략 180KB이다.
그러면 배경 하나를 만들려면 180KB가 필요한 게 정상인데 근데 게임팩 하나엔 그래픽 에셋을 8KB까지만 저장할 수 있었다.
심지어 게임은 32개의 레벨을 가지고 있었고 각 레벨마다 이제 배경과 사물을 이렇게 꽉 채워서 보여주고 있다.
하지만 그때 당시 게임 개발자들은 상남자였기 때문에 8KB 정도면 충분했다.
잘 생각해 보면 배경을 하나의 큰 이미지로 만들어둘 필요는 없고
자주 쓰는 패턴을 타일 형태로 미리 만들어두고 타일을 조합해서 배치하는 식으로
배경을 만들면 훨씬 적은 용량으로 많은 배경을 만들 수 있다.
그래서 배경용 타일을 총 256개 정도 만들어두고 요걸 이렇게 원하는 곳에 배치해서 배경들을 만들어냈다.
근데 위 이미지도 보시면 한 128px * 128px 정도의 픽셀이 들어있기 때문에 용량이 좀 클 것 같지만
잘 보면 4가지 색상 밖에 쓰지 않았기 때문에 1픽셀에 2비트의 용량만 필요하다.
그래서 계산해 보시면 위 배경용 이미지 하나는 4KB만 차지한다.
사물 에셋 줄이기
근데 게임이면 배경 말고 움직이는 사물들도 만들어야 된다.
다행히 NES에선 이제 레이어 2개를 동시에 출력해 줄 수가 있었는데
하나인 배경을 넣고 하나인 사물을 넣어서 출력해 준 다음에 이거를 겹쳐버리면 게임이 완성이 된다.
그래서 캐릭터랑 사물을 위한 타일 셋도 필요하다.
이 이미지도 4KB밖에 차지하지 않기 때문에 총 8KB의 그래픽 에셋으로 만들 수 있었다.
이미지 압축
'굼바'라는 몬스터가 있다.
이 몬스터를 만들고 싶으면 4개의 타일이 필요하다.
근데 굼바에다가 걷는 애니메이션도 넣어주고 싶다면 위 그림처럼 총 12개의 타일이 필요하다.
그러나 이를 획기적으로 줄일 수 있는 방법이 있다.
중복되는 타일은 재사용을 하면 되기 때문에 중복된 타일은 중복해서 저장을 할 필요가 없다.
그리고 용량을 더 줄이고 싶으면 캐릭터 디자인을 그냥 좌우 대칭으로 만들어버리면 된다.
왜냐면 캐릭터나 사물용 타일은 화면에 집어넣을 때 뒤집어서 넣을 수도 있기 때문이다.
그러면 움직이는 군 바를 만들고 싶으면 12개의 타일이 아니라 이렇게 최소 3개의 타일만 필요하게 된다.
하지만 사물 말고 이제 배경 타일은 뒤집기가 불가능했다.
그래서 배경 같은 경우엔 타일을 그대로 재활용한 흔적을 많이 발견할 수 있다.
예를 들어, 구름과 수풀은 모양은 같고 색깔이 다른 에셋임을 알 수 있다.
코드 줄이기
슈퍼마리오 소스코드가 궁금하면 누가 비슷하게 재현해서 깃헙에 올려놓은 게 있다.
그리고 이걸 분석한 책 "I AM ERROR"라는 책이 있다.
그 책에 따르면 소스코드에서 상당 부분 차지하던 게 레벨 디자인이다.
레벨이 32개였으니까 32개의 레벨마다 어떤 배경 타일이 어디에 위치할지도 코드로 기록을 해야 한다.
블록 위치를 기재할 때 픽셀로 집어넣었으면 아마 256가지의 숫자를 2개나 기록해 둬야 되기 때문에 2바이트가 필요했을 것이다.
근데 슈퍼마리오는 타일을 기반으로 배치하기 때문에 16 곱하기 16개의 좌표로 이렇게 기록을 해두었기에
최대 1바이트만 사용하면 되기 때문에 그만큼의 램 용량과 소스코드 양을 줄일 수 있다.
그리고 반복적으로 등장하는 타일을 배치할 때 "한 번에 4개씩 배치해주세요"라고 코드를 짤 수 있게 구현해놨기 때문에 코드 양 자체를 몇백 바이트만큼 이렇게 줄일 수 있었다.
성능절약
NES 하드웨어 자체의 한계도 있었다.
문제는 바로 한 줄에 최대 8개의 사물/캐릭터만 넣을 수 있는 것이다.
만약 그 이상 집어넣으면 사라진다.
만약 굼바를 집어넣고 싶어도 굼바가 2자리를 차지하기에 한 화면에 4개까지만 이렇게 집어넣을 수 있었다.
근데 마리오도 항상 이렇게 존재해야 되니까 굼바는 최대 3개까지밖에 못 넣는다.
그래서 이걸 해결하고 싶은 개발자들은 플리커링("Flickering")이라는 테크닉을 썼는다.
플리커링은 예를 들어서 블록을 10개나 집어넣고 싶다면 NES에서는 2개는 안 보이게 된다.
그럼 8개만 보여주고 그다음에 1 프레임마다 다음 블록을 보여주고 반대편에 있는 타일을 감춘다.
그러면 약간씩 깜빡일 수는 있으나 총 10개의 스프라이트를 한 번에 이렇게 보여줄 수 있다.
그래서 옛날 게임들 하다 보시면 가끔 번쩍번쩍거리는 게임들이 있는 이유이다.
예를 들어서 버블버블이라는 게임이 있는데 이거 거품 타일이 가로로 너무 많아지면 깜빡이는 현상이 있었다.
근데 그때 당시에는 CRT 모니터를 썼었는데, 그때 당시 모니터는 잔상이 많이 남았기 때문에 블리커링이 일어나도 별로 티가 안 났다.
주섬주섬
1980년에 나온 슈퍼마리오의 첫 작품은 어셈블리어로 만들어진 것이다.
어셈블리어를 건축으로 예를 들면, 망치만 들고 집 한채를 짓는 짓이다.
현대에는 고급 언어와 좋은 게임 엔진으로 게임 제작에 편해졌다.
그럼에도 이러한 역사와 과거 기술을 아는 것은 간간히 기술 최적화에 쓰이기 좋다.
참고
Game Boy / Color Architecture | A Practical Analysis
An in-depth analysis that explains how this console works internally
www.copetti.org
NES Starter Kit
Quickstart guide for making NES games from scratch in C.
nes-starter-kit.nes.science
댓글