99% 어셈블리는 제작자의 설명입니다
Chris Sawyer 공식 FAQ는 첫 RollerCoaster Tycoon의 99%를 x86 어셈블리·기계어로 쓰고 Windows·DirectX 연결에 일부 C를 사용했다고 밝힙니다. 이것만으로 게임의 모든 성능 특성을 설명할 수는 없습니다.
2024년 인터뷰에서 제작자는 프레임률을 유지하면서도 놀이기구·열차·손님을 충분히 많이, 넓은 화면에 표현하는 일을 중요하게 여겼다고 말합니다. 목표로 한 경험과 계산·표시 비용을 함께 고려한 선택으로 읽을 수 있지만, 그 회고를 현대 시스템의 벤치마크로 삼을 수는 없습니다.
OpenRCT2 코드가 원작의 구현을 모두 보여 주지는 않습니다
OpenRCT2는 RCT2의 공개 재구현입니다. 이번에는 커밋 20fbc093의 GuestPathfinding.cpp를 읽었습니다. 이 코드의 현재 개선 사항이나 상수를 1999년 첫 작품을 직접 보여 주는 증거로 볼 수는 없습니다.
해당 코드 주석은 제한된 깊이 우선 탐색과 휴리스틱 점수로 경로를 평가하는 구조를 설명합니다. 항상 전역 최단 경로를 찾도록 보장하는 구조는 아니며, 손님이 모두 목적지 없이 무작위로만 걷는다는 설명도 맞지 않습니다.
교차점 한도는 상태에 따라 다릅니다
| PeepPathfindGetMaxNumberJunctions의 분기 | 반환 상수 |
|---|---|
| 직원 | 8 |
| 일반 손님 | 5 |
| 지도 소지 손님 | 7 |
| 공원을 떠나는 손님 | 7 |
| 떠나는 상태이고 guestIsLostCountdown < 90 | 8 |
떠나는 상태 분기는 지도 소지 검사보다 먼저 적용됩니다. 표의 숫자는 이 함수가 고르는 교차점 탐색 한도이며 전체 경로 길이·방문 타일 수·성공률과 같지 않습니다. 앞선 범용 설명의 5/7/8만 나열하면 상태별 예외를 빠뜨릴 수 있습니다.
탐색 예산은 속도와 결과 품질을 함께 바꿉니다
탐색 상한을 두면 한 요청의 작업량을 제한할 수 있지만 우회 경로를 놓칠 수 있습니다. 반대로 한도를 늘렸다는 이유만으로 전체 게임이 좋아졌다고 말할 수는 없습니다. 실제 손님 수·공원 구조에서 frame time 분포와 경로 실패를 함께 비교해야 합니다.
자료형 최적화에도 같은 원칙이 적용됩니다. 다시 공유된 자료에 나오는 특정 필드의 1바이트·4바이트 주장이나, 모든 수식이 2의 거듭제곱에 맞춰졌다는 설명은 원작의 정의를 확인하지 못했으므로 여기서는 사실로 받아들이지 않습니다. 범위·정밀도·메모리 비용과 측정 결과를 먼저 봅니다.
코드 읽기와 실행 측정의 경계
기존 원고를 제작자 FAQ·인터뷰, 특정 커밋의 OpenRCT2 파일과 대조했습니다. 원작 역어셈블·성능 측정이나 OpenRCT2 빌드·게임 실행은 하지 않았습니다. 게임 화면과 원작 코드는 싣지 않았습니다. 이 글은 특정 언어 하나로 성능이 보장된다고 주장하지 않습니다.
English summary. Sawyer's assembly-language account and the current OpenRCT2 implementation are different evidence. The pinned pathfinder uses state-dependent junction limits, including leaving-park cases. These limits are not path length or success guarantees; no game or performance test was run.