고정 간격으로 진행하는 게임 서버가 잠깐 멈췄습니다. 밀린 틱을 모두 실행하면 따라잡을 수 있나요?

고정 틱 서버가 잠깐 멈췄다고 밀린 틱을 무제한 실행하면 회복보다 더 큰 지연을 만들 수 있습니다. 예를 들어 50ms 틱 서버가 500ms 멈추면 열 틱이 쌓이지만, 한 틱 계산이 50ms를 넘는 상태에서 열 틱을 처리하면 벽시계는 계속 앞서고 새 틱도 추가됩니다. 이 악순환을 나선형 지연(spiral of death)이라고 부릅니다. 따라서 따라잡기 상한, 핵심 규칙의 보존, 저중요도 작업의 생략·지연 정책을 함께 정해야 합니다.

시뮬레이션 시간과 실제 시간

고정 틱은 모든 서버 계산이 일정한 dt를 사용하므로 물리·재사용 대기·피해 판정의 결과를 재현하고 서버 간 비교하기 쉽습니다. 하지만 실제 시간과 시뮬레이션 시간이 같다고 자동으로 보장하지는 않습니다. 한 번의 큰 delta로 500ms를 계산하면 열 번의 작은 틱과 물리 충돌·쿨다운·입력 순서가 달라질 수 있으므로 핵심 규칙을 큰 간격으로 합치지 않겠습니다. 반대로 누적된 시간을 버리면 세계가 실제보다 느리게 진행될 수 있습니다. 벽시계 기반 세션 만료와 틱 기반 게임 시간을 섞으면 플레이어마다 쿨다운이 다르게 느껴질 수 있어 각 타이머의 기준을 명확히 합니다.

따라잡기 정책

한 프레임 또는 루프에서 처리할 최대 틱 수와 최대 CPU 시간을 둡니다. 상한 안에서 핵심 이동·충돌·전투 규칙은 순서대로 처리하고, 통계·장식 애니메이션·저우선 AI 재평가는 다음 틱으로 미루거나 빈도를 줄일 수 있습니다. 다만 피해 판정과 자원 차감처럼 결과를 바꾸는 규칙을 조용히 건너뛰면 공정성이 깨지므로, 부하 시 입력을 거절하거나 방을 일시 정지하는 명시적 정책이 필요합니다. 지속 과부하라면 틱 주기를 늘리는 것보다 작업 프로파일링, 공간·에이전트 단위 분산, 계산 상한, 서버 용량 증설로 처리 능력 부족을 해결하겠습니다. 밀린 틱을 버릴 때는 어떤 게임 시간을 잃었는지 이벤트 로그와 사용자 표시를 남기고, 서버 간 결정적 재생이 필요하면 입력·난수·틱 번호를 기록합니다. 서버가 일시 정지된 동안 도착한 입력을 어느 틱에 넣을지, 너무 오래된 입력을 폐기할지 또한 입력 계약으로 정합니다.

따라잡기 중 클라이언트가 보는 위치와 서버 확정 위치가 벌어지면 보정이 필요하지만, 보정으로 과거 전투 결과를 임의로 바꾸지는 않겠습니다. 테스트는 순간 500ms 정지와 지속적인 틱 예산 초과를 분리하고 입력 지연, 누적 틱, 복구 시간, 핵심 이벤트 누락, CPU p99를 봅니다. “고정 틱을 사용한다”는 구현 선택보다 따라잡기 예산과 과부하 모드(catch-up and overload policy)를 먼저 명시해야 결정성과 사용자 경험을 함께 지킬 수 있습니다. 따라잡기 상한은 숨은 시간 손실을 만드는 값이므로 누적 지연·처리 틱·폐기 틱·틱별 CPU p99를 기록하고, 폐기된 시간 동안 생략한 이벤트를 상태와 함께 남깁니다. 입력을 단순히 오래됐다는 이유로 버리면 정상 사용자와 공격자의 결과가 달라질 수 있어 입력 연령·세션 상태·게임 단계에 따른 폐기 규칙을 적용하겠습니다.

지속 과부하에서는 방 단위로 시뮬레이션 품질을 낮추거나 인스턴스를 분리할 수 있지만, 저빈도 AI를 줄이는 것과 핵심 판정을 줄이는 것은 다릅니다. 작업마다 허용 지연과 생략 가능 여부를 관리하고, 복구 후 한꺼번에 보정하지 않고 상태 스냅샷 기준으로 클라이언트가 점진적으로 수렴하게 하겠습니다.