클라이언트: 애니메이션·소리·이펙트는 누르는 즉시 시작(선연출), 결과(데미지·보상)만 서버 확정 뒤 표시, 이동·기본 공격은 예측해 바로 반영, 서버의 위치 보정을 받으면 그 위치에서 아직 확인받지 못한 입력을 다시 적용. 서버: 받은 입력으로 이동을 직접 계산해 클라이언트가 예측한 위치와 차이가 기준을 넘을 때만 보정 값 보내기.
수치 감각
반응 시간 ≈ 핑 + 틱 간격의 절반 + 한 프레임. 20틱·핑 150ms면 약 190ms.
그래프에서는
처음부터 늘 높음 · 입력에서 연출 시작까지 걸린 시간, RTT(핑)
확인할 곳
개발 빌드의 클라이언트 로그에 버튼 입력 시각, 첫 애니메이션·소리 시작 시각, 서버 응답 도착 시각을 남기고 게임 안 RTT와 나란히 봄. 엔진의 네트워크 에뮬레이션(Unreal NetEmulation.PktLag)이나 시험 서버의 리눅스 tc netem으로 지연을 넣어 핑을 바꿔 가며 잼
이러면 맞음
연출 시작이 늘 서버 응답 도착과 같은 순간이고 입력에서 연출까지 걸린 시간이 RTT + 틱 대기만큼이며 넣은 지연만큼 그대로 늘어남
이러면 아님
연출은 누르는 즉시 시작하고 데미지 숫자 같은 결과만 늦으면 정상 설계. 핑이 낮은 곳에서도 틱 간격 이상 늦으면 이중 틱 대기나 클라이언트 프레임 문제
확인 수단
게임 서버·클라이언트의 로그·지표가 필요
더 알아보기
턴제, 카드, 방치형처럼 빠른 반응이 필요 없는 게임은 이 방식이 가장 단순하고 안전합니다. 실시간 조작이 있는 게임에서 이동이나 기본 공격까지 이렇게 만들면 문제가 됩니다.