Quick Comparison
rollback networking은 remote input이 늦게 도착해도 local player가 기다리지 않도록, 예측한 input으로 먼저 simulation을 진행한 뒤 실제 input이 다르면 과거 frame부터 다시 실행하는 방식입니다. 대전 격투처럼 적은 참여자가 같은 frame 판정에 민감할 때 유용하지만, 모든 온라인 게임의 기본 해법은 아닙니다.
| 방식 | 먼저 선택할 상황 | 핵심 비용 |
|---|---|---|
| server snapshot 보정 | authoritative world와 다수 entity를 다룸 | 위치가 보정될 때 시각적 흔들림 |
| 입력 지연 | 판정 일관성이 최우선이고 지연을 감수 가능 | 모든 입력이 늦게 반응 |
| rollback | 소수 인원, frame 기반 대전, 결정론 simulation | snapshot 보관·재시뮬레이션·side effect 제어 |
rollback을 쓰려면 같은 초기 state와 같은 frame input이 같은 결과를 만드는 결정론(determinism)이 필요합니다. platform마다 다른 floating-point 결과, 벽시계 시간, 난수 호출 순서, 비결정적인 physics engine 결과가 섞이면 되감은 frame이 원래 결과와 달라집니다.
되감기 흐름
각 simulation frame의 state snapshot과 player별 input을 보관합니다. remote input이 비어 있으면 마지막 input 또는 neutral input으로 예측합니다. 나중에 실제 input이 도착했는데 예측과 다르면, 가장 이른 불일치 frame으로 state를 복원하고 현재 frame까지 다시 simulation합니다.
function onRemoteInput(frame: number, input: Input) {
inputs.remote.set(frame, input);
if (predictedRemote.get(frame)?.equals(input)) return;
const rewindFrom = frame;
const base = snapshots.get(rewindFrom - 1) ?? initialState;
state = base.clone();
for (let f = rewindFrom; f <= currentFrame; f++) {
state = simulate(state, inputs.local.get(f), inputs.remote.get(f));
snapshots.set(f, state.clone());
}
}실제 구현은 snapshot을 매 frame 전체 복사할지, delta·checkpoint를 둘지 정해야 합니다. rollback window가 8 frame이면 늦은 9번째 input은 현재 match 규칙상 처리하지 않거나 동기화 오류로 다뤄야 합니다. window를 무한히 키우면 memory와 재시뮬레이션 시간이 늘고, 화면은 자주 과거 결과로 바뀝니다.
simulation 밖으로 새지 않게 하기
재시뮬레이션 안에서 사운드 재생, particle 생성, analytics 전송, 보상 저장을 곧바로 실행하면 같은 frame이 여러 번 재생됩니다. simulation은 state 변화만 계산하고, 확정된 frame에서만 외부 side effect를 내보내거나, frame + eventId로 effect를 중복 제거합니다.
server authoritative 구조에서도 rollback은 쓸 수 있지만, 누가 어떤 input을 확정하는지와 치트 검증은 여전히 server 책임입니다. peer-to-peer rollback을 도입하면 host migration, NAT, 부정 input 검증이 별도 문제가 됩니다. 먼저 클라이언트 예측과 서버 보정으로 충분한지 확인하고, frame 단위 판정 요구가 분명할 때 선택합니다.
도입 전 확인
simulation을 headless test에서 frame별 hash로 비교해 같은 input log가 같은 state hash를 만드는지 검사합니다. OS, CPU architecture, build 설정을 바꾼 test도 필요합니다. 이런 test가 없으면 rollback 불일치가 network bug처럼 보이지만 실제로는 simulation bug인 경우를 구분하기 어렵습니다.
또한 예측하지 못한 remote input을 어떤 방식으로 채울지 게임 규칙으로 결정해야 합니다. 마지막 방향 입력을 유지할지 neutral로 둘지에 따라 체감과 공정성이 달라집니다. network code가 임의로 정할 기본값이 아닙니다.
참고 링크
2 sources