심시티는 16MHz Intel 386SX에서도 도시 시뮬레이션을 실행했다. 핵심은 교통·화재·전력·범죄 같은 시스템을 매 프레임마다 모두 갱신하지 않고, 작업을 여러 프레임에 나눠 처리한 데 있다. 게임 개발에서도 매 프레임 모든 코드를 실행해야 하는지 따져볼 수 있다.
심시티 원작의 시스템 요구 사양에는 Intel 386SX가 적혀 있다. 이 CPU는 출시 당시 16MHz로 작동했다. 앞선 글에서는 기본형 CPU의 클럭 속도인 12.5MHz로 잘못 적었지만, 386SX의 속도는 16MHz다.
2008년 GPL 라이선스로 공개된 원작 코드는 Micropolis라는 이름으로 볼 수 있다. 상표는 공개되지 않아 코드가 다른 이름을 쓰지만, 내용은 원작 심시티의 코드다. 도시 시뮬레이션의 중심은 s_sim.c 파일의 Simulate() 함수다. 이 함수는 매 프레임 호출되며 범죄, 화재, 세금 등 여러 시스템의 갱신 함수를 부른다.
모든 갱신 함수를 매 프레임 실행하면 당시 CPU에 부담이 된다. 심시티는 대신 mod16 값을 0부터 15까지 순환시키며, 각 프레임에 시뮬레이션의 일부만 처리한다. 그 결과 플레이어의 행동에 대한 반응은 평균 8프레임, 최악의 경우 15프레임 뒤에 나타난다. 슈팅 게임의 입력 지연이라면 문제가 되겠지만, 도시 시뮬레이션에서는 반응이 즉각적이지 않아도 큰 지장이 없을 수 있다는 설명이다.
비슷한 방식은 다른 작업에도 쓰인다. 2014년 레이싱 게임 Assetto Corsa는 반사 표현에 큐브맵을 활용한다. 큐브맵의 여섯 면을 매 프레임 전부 갱신하는 대신, 반사 품질 설정에 따라 일부 면만 갱신한다. 반사 렌더링 방식에 관한 설명은 관련 글에서 확인할 수 있다.
작업을 여러 프레임으로 나누는 방법은 렌더링에만 국한되지 않는다. 글은 언리얼 엔진의 Lumen도 매 프레임 조명을 전부 다시 계산하지 않는다고 설명한다. 다만 반사가 완전히 갱신되지 않은 때에는 결과가 어색해 보일 수 있다. 게임플레이 코드에서도 모든 작업을 매 프레임 실행해야 하는지 검토해볼 만하다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요