롤러코스터 타이쿤이 1999년 하드웨어로 수천 명 시뮬레이션 가능했던 이유 (진짜 레전드 최적화)

• Chris Sawyer가 거의 혼자 Assembly로 작성 → 1999년 기준 이미 사장된 방식인데 혼자 끝까지 밀어붙임 ㄷㄷ
• 돈 값 저장 시 변수마다 자료형 크기를 다르게 설정 (1바이트~4바이트), 현대 CPU에선 의미 없어서 OpenRCT2에선 전부 8바이트로 통일
• 비트 시프트(bit shifting)로 곱셈/나눗셈 대체 → 게임 내 공식 자체를 2의 제곱수 기반으로 설계한 거 미쳤는데
• 손님 길찾기(pathfinding) 알고리즘을 아예 안 씀 → 대신 손님이 무작위로 걷다가 우연히 탈거리 발견하는 구조로 설계
• 손님들끼리 충돌 판정 없음 → 같은 타일에 수천 명 겹쳐도 되고, 대신 근처 인파 수치로 행복도에만 영향 줌

---

상세 내용

Assembly로 쓴 마지막 대형 게임

롤러코스터 타이쿤(RollerCoaster Tycoon, RCT)은 개발자 Chris Sawyer가 거의 전부 어셈블리(Assembly)로 작성한 게임임. 당시엔 이미 Doom(1993)도 대부분 C로 작성했을 정도로 어셈블리 개발은 사실상 사장된 분위기였는데, 얘는 혼자 끝까지 어셈블리로 밀어붙임. RCT가 이 방식으로 개발된 마지막 대형 게임일 가능성이 높음.

어셈블리 사용의 성능 이점은 당시엔 상당했지만, 현재는 컴파일러 최적화가 워낙 좋아져서 예전만큼 큰 차이가 나진 않음.

소스 코드 없어도 OpenRCT2로 역공학 가능

RCT의 소스 코드는 공개된 적 없지만, 팬들이 만든 오픈소스 재구현 프로젝트 OpenRCT2가 수년간의 리버스 엔지니어링을 통해 원작을 100% 재현함. 덕분에 내부 코드 구조를 분석할 수 있었고, 이 글에서 소개하는 최적화 사례들도 여기서 확인 가능.

자료형도 절약: 상황별 바이트 수 다르게

돈 값 저장 방식이 인상적인데, 전체 공원 가치처럼 큰 수는 4바이트, 상점 아이템 가격처럼 작은 수는 1바이트만 사용함. 쓸 데 없이 큰 자료형 쓰지 않겠다는 거임. OpenRCT2에선 현대 CPU에서 성능 차이가 없다는 이유로 전부 8바이트로 통일했음.

비트 시프트로 곱셈/나눗셈 대체

value << 2 같은 비트 시프트(bit shifting) 연산을 곱셈/나눗셈 대신 씀.

• x << 2 = x * 4
• x >> 1 = x / 2

2진수 시스템에서 비트를 한 칸 왼쪽으로 밀면 값이 두 배가 되는 원리임. 10진수에서 숫자 뒤에 0 붙이면 10배 되는 것과 같은 원리.

더 놀라운 건 이게 그냥 코드 트릭이 아니라 게임 설계 자체를 2의 제곱수 기반으로 맞췄다는 점임. 게임 내 공식에서 9.5 대신 8을 쓰도록 디자인한 거임. 프로그래머가 게임 디자이너한테 "CPU가 좋아하는 숫자로 공식 바꿔주세요"라고 요청하는 건 보통 불가능한 일인데, RCT에선 Chris Sawyer가 둘 다였기 때문에 가능했음.

길찾기를 버린 길찾기 설계

일반적인 공원 게임이라면 손님이 타고 싶은 놀이기구를 정하고 → 경로를 계산해서 → 거기까지 이동하는 구조를 쓸 거임. 근데 이건 수천 명 NPC에게 동시에 **A* 길찾기(pathfinding)**를 돌리는 거라 현대 컴퓨터도 벅찬 작업임.

RCT의 손님들은 사실상 맹목적으로 랜덤하게 걸어다님. 탈 거리를 목적지로 정하는 게 아니라, 걷다가 우연히 흥미로운 놀이기구를 발견하면 탑승하는 구조. 갈림길에서는 거의 랜덤으로 방향을 선택하고, 막힌 길만 피하는 아주 단순한 규칙만 사용함.

게임 내에서도 이 "한계"를 실제로 목격할 수 있음. 손님이 배고프다고 불평하면서도 음식 가판대를 찾아가는 게 아니라 그냥 계속 걷다가 우연히 지나치길 기다림 ㅋㅋ

전통적인 길찾기가 필요한 경우(정비사가 고장난 기구 찾아가거나, 손님이 출구 찾을 때)에는 별도로 사용하되, 탐색 깊이 제한을 걸어둠:

• 일반 손님: 최대 5개 교차점까지만 탐색
• 지도를 구매한 손님: 7개까지 탐색 (지도가 실제로 길찾기 성능을 올려주는 거임 ㄹㅇ)
• 정비사: 더 중요한 NPC라서 8개까지 탐색

탐색 한계에 부딪히면 손님이 "출구를 못 찾겠어요"라고 불평하는데, 이건 사실 게임이 "성능을 위해 탐색을 포기했다"는 신호임. 기술적 제약을 게임플레이 피드백으로 승화시킨 거 개인상받아야 함.

충돌 판정도 없앰, 대신 행복도로 우회

수천 명의 NPC가 서로 충돌 회피 연산을 한다? 그건 프레임레이트 킬러임. RCT 손님들은 서로 충돌 판정 자체가 없음. 같은 타일에 수천 명이 겹쳐도 게임은 멀쩡하게 돌아감.

대신 주변에 다른 손님이 너무 많으면 행복도(happiness)가 떨어지고 불만이 쌓이는 방식으로 혼잡도를 간접적으로 처리함. 플레이어 입장에선 여전히 공원 레이아웃을 잘 설계해야 하고, 연산 비용은 비교도 안 되게 낮아짐.

결론: 코더 = 게임 디자이너일 때만 가능한 최적화

RCT의 최적화 중 상당수는 프로그래머와 게임 디자이너가 같은 사람이었기 때문에 가능했음. 현대 게임 개발에선 이 두 역할이 완전히 분리되어 있어서 이런 식의 협업은 거의 불가능에 가까움. 다만 교훈은 여전히 유효함 — 더 많은 대화, 그리고 때로는 기술적 도전에 "안 돼"라고 말하는 용기.