게임 물리 고정 타임스텝을 한 달 적용해봤더니

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

캐릭터가 같은 경사면에서 어떤 날은 미끄러지고 어떤 날은 멈췄습니다. 점프 높이도 모니터 주사율과 프레임 상태에 따라 미세하게 달라졌고, 충돌 판정이 드문 확률로 누락되는 문제는 재현조차 어려웠습니다. 처음에는 물리 엔진의 정밀도나 콜라이더 설정을 의심했지만, 실제 원인은 렌더링 프레임마다 달라지는 시간값을 물리 계산에 그대로 넣은 구조였습니다.

개인 프로젝트의 물리 업데이트를 고정 타임스텝 방식으로 바꾸고 한 달 동안 플레이 테스트와 프로파일링을 진행했습니다. 적용 즉시 모든 문제가 사라진 것은 아니지만, 버그를 재현하고 수치를 조정하는 과정은 확실히 예측 가능해졌습니다. 직접 사용하며 체감한 장단점과 구현 과정에서 놓치기 쉬운 부분을 중심으로 기록합니다.

가변 시간값이 만든 이상한 움직임부터 확인했습니다

프레임 속도에 따라 물리 결과가 달라졌습니다

기존 코드는 매 프레임 측정한 델타 타임을 속도와 위치 계산에 곱하는 단순한 형태였습니다. 평균 60fps에서는 자연스러웠지만 이펙트가 몰려 한 프레임이 40ms 이상 걸리면 캐릭터가 얇은 벽을 통과하거나 스프링 발판의 반발력이 과도하게 적용됐습니다. 반대로 144Hz 환경에서는 입력이 빠르게 반영되는 듯했으나 감쇠 계산이 예상보다 자주 실행되어 물체가 일찍 멈추는 느낌이 났습니다.

특히 문제였던 부분은 평균 프레임이 아니라 프레임 간 시간 편차였습니다. 평균 60fps를 유지해도 8ms와 25ms 프레임이 번갈아 나타나면 적분 오차와 충돌 순서가 달라졌습니다. 여러분도 평소에는 정상인데 화면 녹화, 에셋 로딩 또는 전투 이펙트가 시작될 때만 물체가 튄다면 물리 업데이트 주기를 먼저 기록해볼 만합니다.

확인 과정에서는 플레이 영상보다 로그가 더 유용했습니다. 프레임 번호, 렌더 델타 타임, 실행된 물리 스텝 수, 캐릭터 위치와 속도를 한 줄로 저장하니 문제가 발생하기 직전의 시간 급증이 보였습니다. 큰 개발 행사의 기술 발표에서도 프레임 안정성과 시뮬레이션 사례를 자주 접할 수 있는데, 행사 성격은 GDC 관련 지식백과 설명에서 가볍게 확인할 수 있습니다.

• 점프 테스트: 동일한 입력을 30fps, 60fps, 144fps 제한 상태에서 반복해 최고 높이를 비교했습니다.
• 충돌 테스트: 빠른 투사체를 얇은 벽으로 발사하고 통과 횟수를 기록했습니다.
• 부하 테스트: 의도적으로 한 프레임을 지연시킨 뒤 물체가 얼마나 멀리 이동하는지 확인했습니다.
• 재현 테스트: 입력과 초기 상태를 저장한 후 같은 결과가 반복되는지 좌표 오차를 비교했습니다.

사용 팁: 평균 FPS만 보지 말고 프레임 시간 그래프와 한 프레임에 실행된 물리 스텝 수를 함께 보세요. 드문 물리 버그는 평균값보다 순간적인 시간 급증에 숨어 있었습니다.

60분의 1초로 분리하니 디버깅 기준이 생겼습니다

누산기와 보간을 함께 적용했습니다

제가 선택한 기본 물리 간격은 1/60초였습니다. 렌더링에서 측정한 시간을 누산기에 더하고, 누적 시간이 고정 간격 이상이면 물리 시뮬레이션을 한 단계씩 진행했습니다. 남은 시간은 버리지 않고 다음 프레임으로 넘겼습니다. 이 구조를 적용하자 렌더링은 90fps로 움직여도 물리는 초당 60회의 일정한 기준으로 계산됐습니다.

처음 구현했을 때는 물리 결과가 안정적인 대신 화면이 미세하게 끊겨 보였습니다. 렌더링 프레임이 두 물리 상태 사이에 놓이기 때문이었습니다. 이전 위치와 현재 위치를 저장하고 누산기의 남은 비율로 렌더 좌표를 보간하니 시각적인 떨림이 크게 줄었습니다. 단, 충돌 판정에 사용하는 실제 좌표까지 보간하면 안 됩니다. 보간 좌표는 화면 표시용이고 게임 규칙은 확정된 물리 상태를 기준으로 처리해야 했습니다.

한 달 동안 사용하며 120Hz 물리도 시험해봤습니다. 빠른 액션과 작은 투사체는 조금 더 안정적이었지만 CPU 사용량이 눈에 띄게 늘었고, 제 프로젝트 규모에서는 연속 충돌 감지와 충돌체 두께 조정이 더 효율적이었습니다. 물리 주기는 무조건 높을수록 좋은 설정이 아니라 게임 속도, 객체 수, 목표 플랫폼에 맞춘 비용 선택이었습니다.

1. 렌더링 델타 타임을 누산기에 더합니다.
2. 누산기가 고정 간격보다 크면 입력을 읽고 물리 상태를 한 단계 계산합니다.
3. 계산 전 상태를 이전 상태로 보관하고 고정 간격만큼 누산기에서 뺍니다.
4. 남은 시간 비율로 이전 상태와 현재 상태를 보간해 화면에 표시합니다.
5. 충돌 이벤트와 게임 판정은 보간된 화면 좌표가 아니라 확정된 물리 상태에서 처리합니다.

한 프레임이 지나치게 길어졌을 때 누산된 시간을 끝없이 따라잡게 두지 않았습니다. 프레임당 최대 물리 스텝 수를 제한해야 느려진 게임이 더 많은 계산을 만들며 계속 악화되는 상황을 막을 수 있습니다.

좋아진 재현성과 새로 생긴 비용을 함께 기록했습니다

체감 장점은 숫자보다 작업 흐름에서 컸습니다

가장 큰 장점은 캐릭터 움직임이 부드러워진 것보다 버그 재현 조건이 명확해진 것이었습니다. 초기 상태와 입력 순서를 저장하면 특정 스텝에서 충돌이 발생하는지 반복해서 확인할 수 있었습니다. 이전에는 그래픽 옵션을 바꾸거나 디버거를 붙이는 순간 현상이 사라졌지만, 변경 후에는 1842번째 물리 스텝처럼 구체적인 지점을 기준으로 조사할 수 있었습니다.

게임 기획 수치 조정도 편해졌습니다. 가속도, 마찰, 점프 충격량을 ‘프레임당 얼마’가 아니라 ‘초당 변화량’과 고정 스텝 기준으로 설명할 수 있었기 때문입니다. 개발자와 기획자가 같은 단위를 사용하니 수정 요청도 구체적으로 바뀌었습니다. 역할의 일반적인 범위가 궁금하다면 게임 기획자에 관한 용어 설명도 협업 맥락을 이해하는 데 참고할 만합니다.

물론 단점도 있었습니다. 렌더용 이전 상태를 별도로 보관해야 해서 객체 구조가 복잡해졌고, 순간적인 프레임 정지 뒤 여러 물리 스텝이 몰리면 CPU 사용량이 튀었습니다. 입력 처리 시점도 다시 설계해야 했습니다. 렌더 프레임에서 한 번 눌린 점프 버튼을 여러 물리 스텝이 중복 소비하지 않도록 입력 이벤트를 버퍼에 넣고, 소비 여부를 명시적으로 관리했습니다.

• 좋았던 점: 점프와 마찰 수치가 프레임 제한을 바꿔도 비슷하게 유지됐습니다.
• 아쉬운 점: 카메라와 파티클처럼 물리 밖에서 움직이는 객체는 별도 시간 정책이 필요했습니다.
• 주의할 점: 부동소수점 연산과 실행 순서까지 같아지는 것은 아니므로 완전한 결정론과 동일시하면 안 됩니다.
• 협업 팁: 물리 스텝 번호를 디버그 화면에 표시하니 기획자와 QA가 오류 시점을 전달하기 쉬웠습니다.

프로토타입과 액션 게임에는 다른 기준을 권합니다

게임 규모보다 실패했을 때의 영향을 먼저 봤습니다

모든 프로젝트에 고정 타임스텝이 필요한 것은 아니었습니다. 물리 상호작용이 거의 없는 메뉴형 게임이나 짧게 검증하는 프로토타입에서는 가변 시간값에 최대 델타 타임 제한을 두는 방식이 더 빠르고 실용적이었습니다. 시스템을 일찍 복잡하게 만들면 아이디어 검증보다 기반 코드 관리에 시간을 더 쓰게 될 수도 있습니다.

반면 점프 타이밍, 차량 거동, 다수의 충돌, 리플레이가 핵심인 게임에서는 초반부터 고정 주기를 두는 편이 유리했습니다. 나중에 바꾸면 이동 코드뿐 아니라 애니메이션 이벤트, 카메라 추적, 입력 버퍼, AI 갱신 순서까지 함께 수정해야 했습니다. 저는 작은 테스트 맵에서 먼저 전환한 뒤 CPU 예산을 측정하고 전체 씬으로 확대했습니다. 성능도 자원 배분의 문제이므로 계획예산 제도의 개념처럼 목표와 비용을 연결해 생각하니 우선순위를 잡기 쉬웠습니다.

적용 여부를 판단할 때는 ‘유명 엔진이 어떤 기본값을 쓰는가’보다 프로젝트에서 허용할 실패를 질문하는 편이 낫습니다. 프레임이 흔들려도 카드가 약간 늦게 이동하는 정도라면 단순한 구조가 가치 있습니다. 하지만 한 번의 충돌 누락이 승패를 바꾸고 저장된 리플레이까지 어긋나게 한다면 구현 비용을 감수할 이유가 충분합니다.

1. 목표 플랫폼의 최저 사양에서 물리 한 스텝의 CPU 시간을 측정합니다.
2. 30fps와 고주사율 환경에서 동일 입력의 최종 위치를 비교합니다.
3. 최대 스텝 수를 넘겼을 때 시간을 버릴지, 게임 전체를 느리게 할지 정책을 정합니다.
4. 렌더 보간에서 순간이동과 부활처럼 보간을 끊어야 하는 이벤트를 따로 표시합니다.
5. QA 로그에 고정 스텝 번호와 입력 버퍼 상태를 포함해 재현 경로를 남깁니다.

짧은 프로토타입을 만드는 독자라면 먼저 델타 타임 상한과 간단한 부하 테스트를 적용하고, 물리가 실제 재미의 중심이 된 뒤 구조를 확장하는 선택을 권합니다. 정밀한 액션이나 레이싱 게임을 만드는 독자라면 초기 이동 코드부터 고정 타임스텝과 렌더 보간을 분리하고, 스텝당 성능 예산까지 함께 관리하는 편이 이후의 디버깅 비용을 줄여줍니다.