Ogre Battle 64 재컴파일 프로젝트, 99.05% 달성

AI 요약

Ogre Battle 64: Person of Lordly Caliber(USA, Rev A)를 N64 에뮬레이션 환경이 아닌 네이티브 PC 실행 파일로 빌드하는 프로젝트입니다. N64Recomp(N64Recomp) 툴체인을 이용해 게임의 MIPS 코드를 재컴파일하고, RT64 렌더러로 그래픽을 출력합니다. 저장소에는 저작권이 있는 게임 데이터와 ROM을 넣지 않았으며, 사용자가 자신의 40MB 카트리지 덤프를 준비해야 합니다.

■ 진행 상황과 구성

프로젝트 제목의 99.05%는 아직 재컴파일해야 하는 함수의 수를 기준으로 계산한 수치입니다. 개발자 댓글에 따르면 이미 게임을 플레이할 수 있고 모드도 만들 수 있습니다. 다만 재컴파일된 C 코드와 일부 생성 파일은 저장소에 커밋하지 않습니다. 새로 받은 저장소는 사용자의 ROM에서 코드를 다시 생성하는 make regenerate를 먼저 실행해야 빌드됩니다.

저장소에는 splat 설정과 VRAM 매핑을 담은 config.yaml, N64Recomp 설정인 config.toml, 어셈블리와 빌드 구성을 담은 asm/, N64Recomp 수정 패치, RT64의 SDL 호환성 패치, 프로젝트 계획과 기술 기록을 담은 PLAN.md가 들어 있습니다. make regenerate는 ROM 분석, MIPS 링크, 34개 뱅크 유닛 생성, 메인 코드 재컴파일, RSP 마이크로코드 생성을 정해진 순서로 수행합니다. 이 작업의 대부분은 DeepSeek v4와 v4.1 Flash 모델이 수행했다고 저장소가 밝히고 있습니다.

■ 빌드 절차

macOS에서는 Homebrew로 MIPS binutils와 CMake를 설치한 뒤 Python 가상 환경에 splat64[mips]를 설치합니다. 이어 N64Recomp 저장소를 서브모듈과 함께 내려받고 프로젝트 패치를 적용한 다음 N64RecompCLI를 빌드합니다. USA Rev A ROM을 assets/에 넣고 make regenerate를 실행하면 재컴파일 코드가 생성됩니다. .n64 형식은 제공된 tools/convert_rom.py로 .z64로 바꿀 수 있습니다.

그다음 cmake -S app -B build-app -DCMAKE_BUILD_TYPE=Release와 cmake --build build-app -j로 애플리케이션을 빌드합니다. 실행하면 ROM을 선택하거나 창에 끌어 놓을 수 있는 시작 화면이 나타납니다. ROM은 해시로 검증한 뒤 저장되며, 이후에는 실행 파일 옆에 저장된 ROM을 자동으로 불러옵니다. 배터리 세이브는 saves/ 디렉터리에 기록됩니다.

배포용 빌드는 make dist 또는 make dist-zip으로 만들 수 있습니다. 결과물은 하나의 자체 포함 실행 파일이며, SDL2는 정적으로 링크합니다. Homebrew의 sdl2가 SDL3 기반 호환 계층인 환경을 고려해 배포 과정에서 고정 버전의 실제 SDL2를 내려받아 빌드합니다. 게임 ROM과 추출된 에셋은 배포하지 않습니다.

■ 실행 환경과 문제 해결

Windows 10·11 64비트, Apple Silicon 기반 macOS 11 이상, Vulkan 1.2 드라이버를 제공하는 glibc Linux를 지원합니다. CPU는 SSE4.1을 지원하는 x86-64 프로세서가 필요하며, macOS 빌드는 Apple Silicon이 필요합니다. 메모리는 2GB, 디스크 공간은 애플리케이션 기준 약 150MB가 필요합니다. 에뮬레이트하는 N64 머신은 512MB를 커밋합니다.

Windows에서는 Direct3D 12와 Shader Model 6.0 또는 Vulkan 1.2를 사용하고, Linux는 Vulkan 1.2, macOS는 Metal을 사용합니다. 프로젝트가 제시한 대략적인 최저 GPU는 GeForce GT 630, Radeon HD 7750, Intel HD 510입니다. 키보드만으로 플레이할 수 있고, Windows의 XInput 또는 SDL 컨트롤러를 선택적으로 사용할 수 있습니다. 오디오 장치가 없으면 소리 없이 실행됩니다.

실행 직후 충돌하면 그래픽 드라이버를 먼저 업데이트해야 합니다. 오래된 GPU에서는 OGRE_CONSOLE=1로 부팅 로그 콘솔을 열고, OGRE_GRAPHICS_API=vulkan 또는 OGRE_GRAPHICS_API=d3d12로 렌더링 백엔드를 고정할 수 있습니다. RT64 서브모듈은 특정 커밋에 고정되어 있으며, SDL 2.0.22보다 오래된 환경에서는 SDL_GetWindowSizeInPixels 사용을 위해 별도 패치를 적용해야 합니다.

■ 재컴파일과 법적 쟁점

Hacker News에서는 recomp가 에뮬레이터와 법적으로 어떻게 다른지 논쟁이 이어졌습니다. 한 설명에 따르면 전통적인 에뮬레이터가 실행 중 코드를 인터프리트하거나 JIT 컴파일하는 반면, recomp는 CPU가 실행할 어셈블리를 C로 옮긴 뒤 네이티브 코드로 미리 컴파일합니다. decomp가 사람이 읽을 수 있는 원본에 가까운 소스 코드를 복원하는 작업이라면, recomp는 원본 어셈블리를 C 형태로 옮기는 데 초점을 둔다는 설명입니다.

반대로 저장소에 원본 ROM에서 나온 디스어셈블리와 어셈블리 코드가 포함되어 있다는 지적도 나왔습니다. 일부 참여자는 재컴파일 프로젝트도 원본 프로그램 코드의 파생 저작물로 볼 여지가 있어 에뮬레이터보다 침해 위험이 클 수 있다고 주장했습니다. 다른 참여자는 원본 IP와 ROM을 배포하지 않고 사용자가 자신의 ROM을 제공하는 구조이며, 기계적으로 아키텍처 수준의 변환만 수행하므로 decomp보다 법적 위치가 다소 나을 수 있다고 반박했습니다. N64 SDK인 Libultra가 독점 코드라는 점과 LLM이 학습 과정에서 이를 접했을 가능성까지 언급되며, AI를 사용한 재컴파일이 clean-room 작업인지도 논쟁이 됐습니다.

원문 저장소는 이 프로젝트의 목적을 보존과 상호운용성 연구로 설명하며, Ogre Battle 64의 ROM과 추출 에셋을 배포하지 말라고 명시합니다.

■ Hacker News 반응

• @frozenlettuce — 퍼센트는 아직 재컴파일해야 하는 함수의 수를 기준으로 추정한 값입니다. 이미 플레이할 수 있고 모드도 만들 수 있습니다. 다른 recomp 프로젝트와 마찬가지로 자신의 ROM을 제공해야 합니다.
  • @frozenlettuce — 프로젝트를 시작한 뒤 다음 에이전트가 이어서 작업할 수 있도록 AI 에이전트들에게 인수인계를 작성하게 했습니다. 그래서 프로젝트 전체 과정이 인수인계 문서로 남아 있습니다.
• @Founderarcstone — 좋네요. 몇 년 동안 이 게임을 떠올린 적이 없었습니다.
• @happa — 이런 재컴파일 프로젝트의 법적 지위는 어떻게 되나요? 에뮬레이터보다 회색 지대가 넓나요, 좁나요?
  • @lfarroco — 훨씬 더 많은 관심을 받을 가능성이 있는 Zelda 64 recomp 프로젝트에도 법적 문제가 생겼다는 이야기는 듣지 못했습니다. 특히 Ocarina of Time의 새 버전이 나오는 지금은 닌텐도의 관심을 끌 가능성이 더 큽니다. 제가 보기에는 recomp가 자신의 바이닐 레코드를 재생하려고 턴테이블을 직접 만들고, 음반의 홈을 연구해 소리를 추론하는 일과 비슷합니다. 그러니 에뮬레이터보다 회색 지대가 좁다고 생각합니다.
  • @rafaelvasco — 공식 배포물에 게임 ROM을 포함하지 않는 한 누구도 뭐라고 할 수 없습니다. 이런 recomp는 항상 ROM을 사용자가 제공해야 합니다. ROM을 어디서 구하는지는 또 다른 이야기입니다.
  • @ndiddy — 재컴파일된 코드가 배포되지 않는 한, 기본적으로 에뮬레이션과 같습니다. 이 프로젝트는 제가 알기로 재컴파일된 코드를 배포하지 않습니다. 기능적으로 recomp와 전통적인 콘솔 에뮬레이션의 차이는 CPU가 실행하는 어셈블리를 실행 중에 인터프리트하거나 JIT 컴파일하지 않고 C로 옮긴 뒤 네이티브 코드로 컴파일한다는 점입니다. 예전에는 Sega Genesis 게임을 GBA로 포팅하는 것처럼 에뮬레이션 비용이 너무 큰 플랫폼으로 옮길 때 재컴파일을 주로 사용했습니다. 특정 게임 전용 에뮬레이터를 만드는 상황이라면 인터프리터 비용을 없애기 위해 코드를 재컴파일하는 편이 낫다는 생각입니다. 다만 decomp와는 다릅니다. decomp는 원래 개발자가 작성했을 법한 읽기 쉬운 소스 코드를 만드는 작업입니다. recomp는 어셈블리 코드를 C로 옮길 뿐이며, 결과는 관용적인 C가 아니라 C로 표현한 어셈블리에 가깝습니다.
  • @wgjordan — 에뮬레이터보다 침해 가능성이 큽니다. decomp와 recomp 프로젝트는 원본 프로그램 코드의 파생 저작물로 보는 편이 명확합니다. 완전히 플레이 가능한 결과물을 빌드하는 데 필요한 다른 에셋을 추출하려면 원본 ROM이 필요하더라도 마찬가지입니다. 더 가까운 사례는 팬 번역 패치입니다. 팬 번역 패치도 명백한 저작권 침해 파생물에 가깝지만, 일반적으로 권리자가 묵인합니다. 기업은 상업적이지 않고 자사 공식 제품의 시장 점유율을 충분히 깎지 않는 한 팬 커뮤니티의 창작 파생물을 장려하거나 모른 척하는 경우가 많습니다.
  • @bri3d — 이것은 decomp 프로젝트가 아니라 recomp 프로젝트입니다. 원본 바이너리는 사용자가 제공하고, 아키텍처 수준에서 기계적으로 소스 코드로 옮긴 뒤 패치합니다. 원본 IP는 배포하지 않습니다. decomp 프로젝트가 변형성이 없다는 지적에는 동의하지만, recomp 프로젝트는 조금 다르며 법적으로 훨씬 덜 불안정한 위치에 있을 수 있습니다.
  • @gspr — 설명해줘서 고맙습니다. 저도 부모 댓글 작성자와 똑같이 오해했고, 이 댓글을 읽고서야 바로잡았습니다. 원본 코드가 불법 유출본이었고 LLM이 학습 자료에서 그 코드를 봤다면 법적 쟁점은 아주 흥미로워집니다. 제 비법률가적인 생각으로는 파생 저작물이 되는 게 명백해 보이지만, 세상은 GPL 코드로 LLM을 학습해도 출력물이 파생물로 간주되지 않는다는 쪽으로 가는 것 같습니다. 대체 무슨 일이 벌어지는지 모르겠습니다.
  • @orthoxerox — GPL은 학습 데이터에 포함된 순간 명백히 위반되지만, 헌법은 자살 협약이 아니라는 식의 접근에 가깝다고 생각합니다. 저작권이나 카피레프트 저작물로 학습한 LLM을 파괴하고 새 모델을 학습하라고 요구하거나, 그런 모델이 저작자의 권리보다 인류에게 더 중요하다는 사실을 받아들이는 두 가지 선택지가 있습니다.
  • @gspr — 두 번째 선택지라면 저도 프런티어 연구소 모델로 제 LLM을 학습해도 되는 것 아닌가요? 제 LLM이 GTA 6를 해석하고 재현하게 만들면 어떻게 되나요? 저작권을 이런 식으로 버리기로 했다면 영화 불법 복제는 안 된다고 말하는 이유는 무엇인가요? 현재 기술로 GTA 6의 저작권을 세탁할 수 없다는 점은 알고 있습니다. 대신 베스트셀러 소설을 넣어도 됩니다. 저작권이 정말 사라진다고 결정한다면 그렇게 말하는 법을 먼저 만들어야 합니다. 유용한 새 기술이 나왔으니 일단 허용하되 영화는 해적판으로 보지 말라는 식으로 넘어가서는 안 됩니다.
  • @0points — 저장소 자체에 저작권이 있는 ROM에서 직접 나온 디스어셈블리가 들어 있으므로 독창적인 작업이 아닙니다.
  • @Sesse__ — 원래 프로그램에서 나온 것으로 보이는 수만 줄의 어셈블리 코드가 Git 저장소에 들어 있습니다.
  • @bri3d — 지금 보니 그렇네요. 왜 그 코드를 저장소에 커밋했을까요? 이 접근법의 목적 중 하나는 원본 프로그램 목록에 불과한 어셈블리를 최종 사용자가 쉽게 다시 만들 수 있게 하는 것 아닌가요?
• @onetrickwolf — Ogre Battle 64가 이제 27년 된 게임인데도 이런 일을 걱정해야 한다는 점이 슬픕니다. 1976년 저작권법 이전의 법을 적용했다면 지금쯤 퍼블릭 도메인에 들어갔을 겁니다. 저작권 기간을 이렇게 길게 만든 일은 터무니없고, 보존 활동을 실제로 위협하고 있습니다.
  • @0points — 보존 활동은 다행히 그런 터무니없는 관할권 밖에서도 이뤄집니다. 잘 알려진 작품 대부분은 오래전부터 보존되어 있습니다.
  • @Narann — 제가 알기로 EU에는 프로그램을 다른 플랫폼에서 작동시키는 상호운용성을 보호하는 법이 있습니다. 디컴파일도 상호운용성으로 간주될 것 같습니다.
• @VCFundedGenYer — 이것은 DeepSeek가 작업했으므로 진짜 recomp가 아닙니다. 건드리지 마세요. 모든 AI recomp는 사용해서도 안 되고 진짜 recomp로 간주해서도 안 됩니다. 훔친 코드나 저작권 코드가 들어 있을 가능성이 큽니다.
  • @salomonk_mur — 진짜 recomp란 무엇인가요? 원본처럼 작동한다면 누가 만들었든 재컴파일입니다. 작성자가 대부분 LLM이라는 점이 마음에 들지 않을 수는 있지만, 결과물이 분명히 작동합니다.
  • @ChrisRR — 할머니가 만들던 방식처럼 손으로 정성껏 만든 decomp를 원하는 모양이네요.
  • @jamesnorden — 원본 바이너리와 바이트가 일치하도록 만드는 작업인데 어떻게 훔친 코드가 들어갈 수 있나요?
  • @fzeroracer — N64 SDK인 Libultra는 오래전에 유출됐고 닌텐도 소유의 독점 코드입니다. Portal 64는 닌텐도의 심기를 건드리고 싶지 않았던 Valve가 Libultra 사용을 문제 삼은 일의 일부로 DMCA를 받았습니다. 그런 일이 벌어지는 건 충분히 가능하며, 어떤 LLM이든 학습 데이터에 독점 코드를 흡수했을 가능성이 높습니다. LLM이나 코딩 에이전트의 도움을 받은 decomp는 clean-room 작업이 아닐 수 있습니다. 닌텐도가 특히 강하게 대응한다면 코드베이스가 독점 도구나 지식을 사용했다는 주장을 쉽게 제기할 수 있고, 개발자에게는 대응 수단이 거의 없을 겁니다.
  • @dezgeg — 그 용어는 바이트 일치 decompilation입니다. 이 프로젝트는 그런 프로젝트가 아닙니다.
  • @voidUpdate — “진정한 Scotsman은 LLM을 사용해 재컴파일하지 않는다”는 말이네요.
  • @Keeeeeeeks — 제한된 수명을 가진 숙련 노동자에게 수익화할 수 없는 고도로 전문적인 작업을 시키자고 주장하는 벤처 투자 자본 지원 밀레니얼이라니, 정말 진지하게 받아들이기 어렵습니다.
• @AdmiralAsshat — 좋습니다. N64 시절 이후로 플레이하지 않았습니다. 시스템 최고의 게임 중 하나였고, Matsuno가 참여하지 않았다는 이유로 Tactics Ogre와 Final Fantasy Tactics에 비해 Ogre Battle 64가 과소평가됐다고 생각합니다. 하지만 원작 Ogre Battle보다 훨씬 뛰어나며 Matsuno의 최고작과도 맞설 만합니다. 언젠가 다시 플레이하고 싶습니다. 처음 공략 없이 60시간 넘게 플레이했는데도 최악의 엔딩을 봤습니다. 요새를 해방했는지 정복했는지에 따라 엔딩이 결정된다는, 전혀 설명되지 않은 시스템 때문입니다.
  • @cwnyth — 다음에는 GameFAQs 공략을 사용해 보세요. 학교에서 그 공략을 출력해 밤늦게까지 플레이했습니다. 지금도 제가 가장 좋아하는 RPG입니다. 모든 비밀, 생일 아이템, 캠페인 종료 뒤 특정 마을에만 등장하는 고유 캐릭터를 얻으려면 공략이 필요했습니다. 현대 RPG에서 바라는 건 Ogre Battle 64 같은 게임뿐인데, 지금은 SNES·PS1 버전만 나옵니다. 훌륭한 게임이지만 비교하면 확실히 거칠어요.
• @Tbarlow — 마지막으로 이상한 예외 상황을 디버깅했던 때가 기억나네요. 이 사람들은 N64 게임 전체를 거의 다 왔습니다. 대단한 노력입니다.
• @globular-toast — 이 게임을 처음 들어봤습니다. Wikipedia를 찾아보니 평가는 괜찮지만 아주 뛰어난 수준은 아닌 것 같습니다. 컬트 팬층이 있나요? 아니면 다른 이유로 주목받는 건가요?
  • @ChrisRR — 리뷰 집계 사이트 Metacritic 기준으로 호평을 받았습니다. 일본 Famitsu는 40점 만점에 33점을 줬고, GameSpot의 2000년 시상식에서 최고의 전략 게임을 수상했습니다. “아무도 플레이하지 않은 최고의 게임” 후보에도 올랐지만 Samba de Amigo가 수상했습니다. 판매량은 N64라는 콘솔의 영향으로 낮았습니다. Nintendo Power의 닌텐도 시스템 게임 200선에서는 111위였고, IGN은 Virtual Console 재출시판을 두고 “지금도 여전히 훌륭하다”고 평가했습니다. 2023년에는 Time Extension의 최고의 Nintendo 64 게임 목록에도 올랐습니다. 잘 팔리지는 않았지만 반응은 좋았던 것 같습니다.
  • @frozenlettuce — 여러 면에서 특이한 게임입니다. 퍼블리셔에 문제가 있어 제작된 카피가 많지 않았습니다. 프리렌더링 그래픽은 지금도 잘 낡지 않았고, 작은 팬층이 있습니다. GameFAQs 공략이 콘텐츠와 비밀 요소가 많아서 60쪽이 넘었던 것으로 기억합니다. RPG가 적었던 N64에서 오아시스 같은 게임이었습니다. 스프라이트와 텍스트의 세부 묘사도 뛰어납니다. 예를 들어 게임 중반에 모든 캐릭터를 관계 유형별 색상 선으로 연결한 그래프 화면이 열리고, 진행에 따라 여러 번 갱신됩니다. 요즘에는 이 시리즈의 전략 장르가 대부분 잊혔습니다. 최근에는 “Let Us Cling Together”의 리메이크가 나왔지만 이쪽은 택티컬 장르입니다.
• @nebalee — 이런 재컴파일이 어떻게 작동하는지는 전혀 모르겠습니다. 그런데 왜 그 결과물이 실행되려면 최소 20년은 더 새로운 하드웨어가 필요한가요?
  • @opencl — 하드웨어 요구 사항은 이 프로젝트가 최신 그래픽 API만 지원하기로 결정한 결과입니다. 예를 들어 Ocarina of Time decomp는 OpenGL을 지원하므로 더 오래된 PC 하드웨어에서도 실행되고, Dreamcast로 포팅되기도 했습니다.
• @lizardking — 이런 recomp 프로젝트가 많이 있는 것으로 아는데, 전체 목록을 모으고 진행 상황을 추적하는 사이트가 있나요?
  • @pennomi — N64 전체 타이틀 목록과 각 게임의 완전한 decomp 진행 상황을 기록한 등록부가 생기려면 얼마나 걸릴까요?

원문: GitHub / 커뮤니티: Hacker News / 번역·요약: Trawling