Quick Flow

서버 tick은 월드 상태를 한 번 전진시키는 기준 단위입니다. 한 tick에서 입력을 소비하고, 규칙과 충돌을 적용하고, 확정 상태를 기록한 뒤 필요한 클라이언트에 snapshot을 보냅니다. tick rate와 snapshot 전송 rate는 같은 값일 필요가 없습니다.

수신 callback: command를 session queue에 넣음
      -> tick: queue에서 이번 tick의 command를 꺼냄
      -> tick: movement·combat·cooldown·spawn을 순서대로 적용
      -> tick: authoritative state와 tick 번호를 확정
      -> 전송 주기: 관심 있는 상태만 snapshot 또는 event로 전송

tick 안의 처리 순서

실시간 서버의 일반적인 순서는 입력 소비 -> 규칙 적용 -> 상태 확정 -> 결과 전송입니다. 같은 tick에 이동과 공격이 모두 들어올 수 있으므로, 어느 규칙이 먼저 평가되는지는 게임 규칙으로 정해야 합니다. 예를 들어 이동 후 사격을 판정할지, tick 시작 위치에서 사격을 판정할지는 hit 판정과 플레이 감각을 바꿉니다.

네트워크 callback에서 즉시 world.move()를 호출하면 수신 타이밍이 simulation 순서를 결정합니다. callback은 session별 queue에 command와 sequence를 기록하고, tick이 정한 시점에 읽습니다. 늦게 도착한 command를 어느 tick까지 허용할지, 과거 tick을 다시 돌릴지, 다음 tick으로 미룰지도 protocol 계약에 넣습니다.

tick 번호는 시간 측정만을 위한 값이 아닙니다. snapshot이 어느 상태 뒤에 생성됐는지, 클라이언트가 어느 입력까지 서버가 처리했는지, 로그에서 같은 상황을 재현할 수 있는지를 연결합니다. 시계의 wall clock timestamp만으로 순서를 정하면 서버·클라이언트 시계 차이와 지연을 구분하기 어렵습니다.

tick rate와 전송 주기

tick rate를 올리면 입력과 규칙을 더 자주 평가할 수 있지만 CPU 비용이 선형으로만 늘지 않을 수 있습니다. 한 tick에 모든 플레이어의 AI, 충돌, 시야, persistence 작업이 몰리면 계산 시간이 tick 간격을 넘고 queue가 밀립니다. 반대로 낮은 tick은 대역폭을 줄여도 빠른 이동·사격의 판정 오차와 입력 반응성을 해칠 수 있습니다.

snapshot은 모든 tick에 전체 월드를 보낼 필요가 없습니다. 클라이언트가 이미 아는 상태와 달라진 entity, 현재 플레이어와 가까운 entity, 신뢰성 있게 남겨야 하는 event를 나누어 보냅니다. 다른 플레이어의 위치는 snapshot 보간과 외삽으로 부드럽게 그릴 수 있으므로, simulation frequency와 화면 update frequency를 분리할 수 있습니다.

밀린 tick을 숨기지 않기

처리 시간이 tick 간격보다 길어지면 다음 tick이 시작되지 못하고 입력 지연이 쌓입니다. 이때 무한히 catch-up하면 CPU 사용량이 더 올라가며, 임의로 tick을 건너뛰면 이동 거리와 쿨다운이 달라질 수 있습니다. 서버는 tick duration, queue 길이, command drop 또는 late 처리 수, 각 시스템의 처리 시간을 함께 기록해야 합니다.

물리·게임 규칙·랜덤 값이 같은 tick 입력에 항상 같은 결과를 내는지는 별도 문제입니다. 고정 tick만으로 cross-platform determinism이나 replay가 자동으로 보장되지는 않습니다. rollback이나 replay가 필요한 게임은 random seed, floating-point 정책, snapshot 복원, versioned simulation rule을 추가로 설계합니다.