1989년 도스 게임 ‘F-15 스트라이크 이글 2’ 복원 프로젝트, 이제 테스트 파일럿 구함

• 1989년 도스 게임 ‘F-15 Strike Eagle II’를 C 코드로 되살리는 역공학 프로젝트가 꽤 큰 마일스톤을 찍었음

  • 이 프로젝트는 원본 바이너리를 분석해서 당시 게임의 C 소스 코드를 다시 만들어내는 취미 프로젝트임
  • 한 달 전만 해도 두 번째 실행 파일인 egame은 몇 년 더 걸릴 분위기였고, 세 번째 실행 파일인 end는 아직 손도 많이 남은 상태였다고 함
  • 그런데 지금은 모든 실행 파일의 C 코드가 재구성됐고, 데이터도 assembly에서 C 쪽으로 옮겨졌고, assembly-only 코드 대부분도 C로 기능 대체가 끝난 상태임

• 이제 문제는 “코드가 맞냐”보다 “게임이 제대로 돌아가냐”로 넘어갔다는 점임

  • 기존 툴링은 재구성한 코드의 opcode가 원본과 계속 맞는지 확인해줄 수 있음
  • 하지만 데이터 레이아웃 문제처럼 실제 실행 중에만 드러나는 버그는 자동으로 다 잡아주지 못함
  • 그래서 프로젝트가 조용한 정적 검증 단계에서, 진짜 플레이 가능한 게임을 유지해야 하는 단계로 진입한 셈임

• 프로젝트 측은 이제 도스 테스트 파일럿을 모집 중임

  • 최신 릴리스는 v0.9.1이고, 원본 게임 451.03 버전과 데저트 스톰 확장팩 조합에서 동작해야 함
  • 사용법은 새 실행 파일을 원본 게임 폴더에 넣어 기존 실행 파일을 교체하는 방식임
  • 다만 원본 파일은 백업해두는 게 필수고, 기존 f15.com이 새 f15.exe 대신 실행되지 않도록 제거해야 할 수도 있음

• 현재 빌드는 설정 화면으로 들어가지 않고, 기본 환경을 가정하고 바로 동작함

  • 화면은 MCGA/VGA로 가정함
  • 사운드와 조이스틱은 없는 것으로 가정함
  • 그래도 미션 브리핑, 비행, 디브리핑까지 게임의 세 파트는 전부 동작해야 한다고 함

• 테스트에서 찾아줬으면 하는 건 전형적인 “실행해봐야만 보이는” 문제들임

  • 크래시가 나는지
  • 그래픽이 깨지는지
  • 키 입력이 안 먹는지
  • DOSBox에서는 Ctrl+F5로 스크린샷을 찍을 수 있으니, 화면 문제가 있으면 같이 첨부하면 좋다고 함
  • 어떤 행동을 하다가 문제가 났는지까지 적어주면 재현과 수정에 훨씬 도움이 됨

• 흥미로운 포인트는 이게 ‘버그까지 포함한 재구성’이라는 점임

  • 원작에도 3D 오브젝트가 사라지는 문제, 비행기가 뒤집힌 상태에서 연료가 떨어지면 하늘 쪽으로 떨어지는 이상한 동작 같은 버그가 있었다고 함
  • 이런 동작이 원본에도 있으면 지금은 그대로 유지해야 함
  • 그래서 버그를 제보하기 전에는 원본 게임에서도 같은 현상이 나는지 비교해보는 게 좋다고 프로젝트 측이 강조함

• 결국 이 단계는 포팅 프로젝트로 가기 전 마지막 현실 검증에 가까움

  • 코드가 C로 재구성됐다고 끝이 아니라, 실제 게임으로 굴렸을 때 원본과 같은 방식으로 망가지고 같은 방식으로 돌아가야 함
  • 레트로 게임 보존 프로젝트에서 커뮤니티 플레이 테스트가 왜 중요한지 보여주는 사례임

---

기술 맥락

• 이 프로젝트에서 선택한 방식은 새 게임 엔진을 만드는 게 아니라 원본 바이너리를 C 코드로 되살리는 쪽이에요. 왜냐면 목표가 현대식 리메이크가 아니라 1989년 게임의 실제 동작을 보존하는 데 있기 때문이에요.

• opcode 일치 검증은 꽤 강한 안전장치지만, 그걸로 모든 실행 버그를 잡을 수는 없어요. 특히 오래된 C/assembly 코드에서는 구조체 배치나 데이터 정렬 같은 문제가 런타임에서만 이상하게 터질 수 있거든요.

• 그래서 지금 필요한 건 단위 테스트보다 실제 플레이 테스트에 가까워요. 미션 브리핑, 비행, 디브리핑처럼 게임 흐름 전체를 사람이 타고 지나가야 입력, 그래픽, 상태 전환 문제가 드러나기 때문이에요.

• ‘버그까지 보존한다’는 조건도 중요해요. 원작에도 있던 버그를 새 코드에서 고쳐버리면 겉으로는 좋아 보여도, 복원 정확도 관점에서는 오히려 원본에서 멀어진 거거든요.