1996년에 나온 슈퍼 마리오 64는 3D 플랫포머라는 장르의 기준을 세운 게임이에요. 30년 가까이 지난 지금도 게임 개발자들 사이에서는 “3D 캐릭터 조작감의 교과서”로 불리는데요. 그런데 이 마리오의 움직임과 물리 코드를 통째로 떼어내서, 유니티든 고도(Godot)든 심지어 블렌더에서든 불러다 쓸 수 있는 C 라이브러리로 만든 프로젝트가 있어요. 이름부터 직관적인 libsm64입니다.
어떻게 이게 가능했을까: 디컴파일 프로젝트 이야기
배경에는 슈퍼 마리오 64 디컴파일 프로젝트가 있어요. 디컴파일이 뭐냐면, 게임 카트리지에 들어 있는 기계어 바이너리를 분석해서 사람이 읽을 수 있는 C 소스 코드로 되살리는 작업이에요. 그냥 비슷하게 흉내 내는 게 아니라, 복원한 코드를 다시 컴파일하면 원본과 바이트 단위로 완전히 똑같은 바이너리가 나와야 해요. 전 세계 커뮤니티가 몇 년에 걸쳐 함수 하나하나를 손으로 복원했고, 그 결과 마리오 64의 전체 로직이 읽고 수정할 수 있는 코드로 존재하게 됐죠. libsm64는 여기서 마리오라는 캐릭터의 이동, 물리, 애니메이션 로직만 발라내서 .dll이나 .so 같은 공유 라이브러리로 빌드한 프로젝트예요.
저작권 문제는 어떻게 피했을까
재밌는 건 법적 장치인데요. 라이브러리 자체에는 닌텐도의 에셋, 그러니까 텍스처나 모델, 사운드가 하나도 안 들어 있어요. 대신 초기화할 때 사용자가 직접 소유한 마리오 64 롬 파일을 넘겨주면, 그 안에서 마리오의 텍스처를 런타임에 추출해서 써요. 코드는 디컴파일로 복원한 것이고 에셋은 사용자의 것이니, 배포되는 라이브러리에는 닌텐도의 자산이 포함되지 않는 구조죠.
사용 흐름도 깔끔해요. 롬 파일로 라이브러리를 초기화하고, 내 게임의 지형을 충돌용 메시로 등록한 다음, 매 프레임 조이스틱 입력을 넣고 틱 함수를 호출하면 돼요. 그러면 마리오의 위치와 애니메이션이 적용된 정점(버텍스) 데이터가 돌아오고, 그걸 화면에 그리는 건 호스트 엔진의 몫이에요. 물리 계산은 라이브러리가, 렌더링은 내 엔진이 나눠 맡는 거죠. 실제로 블렌더 애드온으로 아무 3D 씬에나 마리오를 소환해서 뛰어다니게 하는 데모도 있고, 유니티나 고도용 바인딩도 나와 있어요.
왜 하필 마리오의 움직임일까
마리오 64의 조작감은 지금 봐도 정교해요. 걷기에서 달리기로 넘어가는 가속 곡선, 연달아 뛰면 점점 높아지는 3단 점프, 벽차기, 엉덩이 찍기까지, 관성과 가속도가 손맛 나게 설계돼 있거든요. 현대 3D 플랫포머들이 여전히 이 게임을 레퍼런스로 삼는 이유예요. 그런 “정답에 가까운” 캐릭터 컨트롤러를 내 프로젝트에 그대로 꽂아서 굴려볼 수 있다는 게 이 라이브러리의 매력이죠.
업계 맥락: 게임 디컴파일 씬
마리오 64는 시작일 뿐이고, 젤다의 전설 시간의 오카리나나 퍼펙트 다크 같은 고전들도 디컴파일이 끝났어요. 이런 프로젝트 덕분에 원작을 PC에서 네이티브로 돌리는 포트가 나오고, 60프레임이나 와이드스크린 같은 개선도 가능해졌죠. 게임 보존이라는 관점에서 의미가 크지만, 법적으로는 여전히 회색지대예요. 그래서 다들 libsm64처럼 “에셋은 절대 포함하지 않고, 롬은 소유자가 직접 제공한다”는 선을 지키는 방식으로 운영돼요. 닌텐도가 팬 프로젝트에 유독 엄격한 회사라는 걸 생각하면, 이 구조 설계 자체가 일종의 생존 전략인 셈이에요.
한국 개발자에게 주는 시사점
인디 게임을 만들고 있다면 캐릭터 컨트롤러 공부 자료로 이만한 게 없어요. 내가 만든 점프와 30년간 검증된 마리오의 점프를 같은 씬에 나란히 놓고 비교해볼 수 있으니까요. 가속도, 마찰, 공중 제어 같은 값들이 실제 코드에서 어떻게 구현됐는지 뜯어보는 것만으로도 배우는 게 많아요. 게임 개발자가 아니어도, 깔끔한 C API를 다른 언어나 엔진에 바인딩해보는 FFI 연습 소재로도 좋고요.
정리하면, libsm64는 디컴파일 커뮤니티가 만들어낸 “이식 가능한 마리오”예요. 여러분이 이렇게 라이브러리로 떼어내서 내 프로젝트에 꽂아 쓰고 싶은 전설의 게임 메커닉이 있다면 뭔가요?
🔗 출처: Hacker News