플로피 한 장 1.44MB 안에 게임 만들기 대회

한국의 한 단체가 플로피 디스크를 기리는 게임 개발 대회를 연다고 함. 조건이 1.44MB임. 리소스, 엔진, 라이브러리까지 파일 전체를 그 안에 넣어야 함. 감이 안 오는 사람을 위해 이런 댓글이 있었음. 폰 꺼내서 사진 한 장 찍어 봐라, 그걸로 이미 끝났다는 거임. 포맷하고 나면 1.38MB밖에 안 남았던 걸로 기억한다는 댓글도 있었고. 제약이 창의력을 만든다는 말도 나왔음. 1.44MB 아래로 맞추려면 게임을 어떻게 짤지 진짜 머리를 써야 한다는 얘기였음.

제일 추천 많이 받은 댓글은 위키백과 링크 하나였음. .kkrieger 같은 게 또 나왔으면 좋겠다는 거임. 2004년에 나온 무료 3D FPS인데 용량이 96KB임. 에셋을 전부 절차적 생성으로 만들었다고 함. 절차적 생성은 데이터를 저장하는 대신 만드는 방법만 코드에 넣어 두고 실행할 때 뽑아내는 방식임. 텍스처를 저장하는 게 아니라 텍스처 만드는 방법을 저장했고, 모델은 절반만 넣고 나머지는 거울처럼 뒤집어 썼다는 설명이 붙었음. 이런 잔재주가 잔뜩 들어갔다는 거임. 실제로 메모리에 올라간 게임은 300MB쯤 된다고 함. 압축이라고 부르는 그 압축은 아니지만, 96KB 코드를 300MB로 펼치는 건 정보이론에서 말하는 알고리즘 압축에 들어맞는다는 댓글도 있었음. 대신 에셋 만드는 난이도는 어마어마하게 올라간다는 단서도 붙었고. 20년 지난 지금 기술로 다시 하면 뭐가 나올지 궁금하다는 반응도 나왔음.

이런 걸 직접 해 봤다는 사람 글이 추천을 꽤 받았음. 코드를 빡빡하게 조이면 결과는 놀라운데 한참 하다 보면 머리가 아파 온다고 함. 그래도 만족스럽다는 말은 붙였고. 마지막에 몇 바이트라도 더 깎으려고 변수 이름 자체를 절차적으로 만들어서 거기에 생성한 리소스를 붙였다고 함. 정신 붙잡고 있지 않으면 자기가 뭘 했는지 잃어버린다는 거임. 코드로 만든 루브 골드버그 장치 같다고 표현했음. 나도 똑같은 데서 당해 봤다는 답글이 달렸음. 여기엔 반박도 붙었음. 바이너리를 줄이는 게 목적이면 그냥 심볼을 떼면 되는 거 아니냐는 거임. 그럴 거면 왜 변수 이름을 생성하냐, 그냥 한 글자로 쓰면 되지 않냐는 질문도 나왔음. 한 글자로 가면 금방 바닥나서 그렇다는 답, 런타임에 만들 리소스는 몇 개일지도 모르니 그게 오히려 흔한 방식이라는 답이 각각 붙었음.

이런 대회 기준으로 보면 1.44MB는 사실 많은 편이라는 댓글이 376을 받았음. 마음먹고 만들면 20시간짜리 3D RPG도 들어간다는 거임. 그 정도 공간을 절차적 생성 하는 사람들한테 주면 3D 오픈월드 RPG가 나올 것 같다는 답글이 붙었고. 아주 작은 저장 형식이라는 원문 표현에는 64K 데모신이 할 말 있다는 지적이 나왔음. 자바스크립트 쪽에도 13KB로 만드는 js13kgames, 1KB로 만드는 js1k 같은 전통이 있다는 소개도 있었음. 게임보이 카트리지는 32KB에서 시작해 마지막쯤 4MB까지 갔으니 1.44MB면 충분하다는 계산도 나왔음. 제일 크고 제일 돈 많이 들인 NES 게임이 1MB였다는 댓글도 있었고. 그럼 NES 게임 만들어서 PC로 컴파일하면 된다는 농담도 나왔음. Pico-8 게임은 PNG 메타데이터에 들어갈 만큼 작아서 1.44MB에 여러 개 넣을 수 있다는 말도 붙었음.

옛날 얘기가 줄줄이 나왔음. 우리가 플로피 쓰던 시절엔 대부분의 게임이 한 장에 안 들어갔다는 댓글이 646을 받았음. 자기 둠은 플로피 서너 장이었다고 함. 둠 첫 챕터는 한 장에 들어갔다는 정정이 붙었고. 그럼 둠만큼 큰 걸 안 만들면 되는 거 아니냐, 게임잼이 원래 그런 걸 만드는 자리가 아니라는 답도 나왔음. 배틀 체스는 한 장에 들어갔다는 기억, Another World는 한 장에 들어간 공학적 기적이라는 평도 있었음. 운영체제도 없이 그 디스크 하나로 부팅되던 게임이 생각난다는 댓글도 있었고. 학교 컴퓨터실에서 그거 엄청 했다는 추억담, IPX 네트워크를 통째로 죽여 놓기도 했다는 얘기가 붙었음. 360KB에서 720KB짜리 플로피로 게임하며 자란 입장에서는 1.44MB도 사치스럽게 느껴진다는 댓글, 첫 컴퓨터였던 TRS-80 컬러 컴퓨터가 32KB였다는 댓글도 있었음. 대체 80년대를 어떻게 버틴 거냐는 반응으로 이 줄기가 끝났음.

데모신이라는 걸 찾아보라는 댓글도 있었음. 예전엔 로더라고 불렀다는 설명이 붙었고. 유럽 유명 스튜디오 상당수가 그 데모 파티에서 시작했다는 얘기가 나왔음. 레메디, 스타브리즈, IO, 하우스마크가 그렇다고 함. 리딕 다크 판타지의 메인 메뉴 큐브가 딱 데모신 감성이었다는 기억도 붙었음. 그때 그룹 릴리스에 딸려 오던 와레즈 인트로랑 키젠도 그립다는 말이었음. 인터넷 문화가 참 많이 바뀌었다고 했음. .kkrieger를 만든 팀 farbrausch도 Werkkzeug라는 자체 도구로 그런 식의 개발을 했다는 댓글이 붙었음. 독일어로 도구라는 뜻이고 옛 버전은 깃허브에 공개돼 있다고 함. 더 작은 FPS를 만든 뒤에 콘텐츠 제작 파이프라인까지 통째로 만들어 버린 QUOD라는 사례를 가져온 사람도 있었음.

요즘 개발자들이 게을러졌다는 쪽으로 얘기가 튀기도 했음. 게임이 80GB에서 200GB나 될 이유가 없다는 거임. 여기엔 반박이 길게 달렸음. 게을렀다는 말은 이상하다는 거임. 크런치라는 단어까지 따로 만들어 낸 업계라고 했음. 빠르고 큰 저장장치가 아주 싸던 시대가 이제 막 끝났을 뿐이고, 속도와 용량은 거의 항상 맞바꾸는 관계라는 설명이었음. 실행 중에 압축을 풀거나 에셋을 만들어 내는 데는 시간이 들어서, 겉보기에 낭비 같아도 이유가 있다는 얘기였음. 4K 텍스처를 원하면 최소 40GB는 잡아야 한다는 댓글도 붙었음. .kkrieger 결과물도 4K는커녕 당시 기준에도 못 미쳤고 어디까지나 데모라는 지적, 현대 게임 텍스처를 절차적 생성으로 뽑으려면 계산에 한참 걸린다는 지적도 나왔음. 사이버펑크처럼 세계를 보여 주는 걸로 이야기를 하는 게임은 절차적 생성이랑 정반대라는 말도 있었음. 반대로 요즘은 아무도 용량 아끼려고 코드를 다듬지 않고 편한 도구로 대충 붙이거나 AI한테 다 맡긴다는 냉소도 있었음. 부팅할 때마다 AI가 랜덤 시드로 코드를 다시 짜는 로그라이크가 새 장르라는 농담이 그 옆에 달렸음.