게임 렉 백서 › 동기화 설계
낮은 스냅샷 전송률 Low snapshot / update rate
원인 ID sy-low-send-rate · 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
그림과 실험이 있는 원본 카드로 열기 →
서버가 위치 업데이트(스냅샷)를 1초에 몇 번만 보내면 보간 버퍼를 그만큼 길게 잡아야 해서, 다른 캐릭터를 더 먼 과거로 봅니다.
왜 전송량을 아끼려고 위치 업데이트를 1초에 5~10번만 보냄 → 그러면 매끄럽게 그리려면 버퍼를 패킷 간격의 2배(200~400ms)로 잡아야 하고, 짧게 잡으면 패킷 하나만 놓쳐도 멈춤 → 화면에서는 상대의 방향 전환이 늦게 보이고 판정과 어긋남. 버퍼가 짧으면 뚝뚝 끊기고 손실 때 순간이동
증상 뚝뚝 끊김 , 순간이동 , 씹힘·롤백 요인 지연, 손실
누가 겪나 서버 전체
언제 항상
담당 주 담당 게임개발팀·서버 개발 · 함께 게임개발팀·클라이언트 개발
게임개발팀 할 일 서버: 가깝거나 전투 중인 대상은 자주, 먼 대상은 드물게 보내기, 바뀐 부분만 보내(델타 압축) 한 번의 크기를 줄이고 주기를 올리기. 클라이언트: 보간 버퍼 길이를 패킷 간격에 맞춰 자동 조절.
수치 감각 1초에 10번이면 패킷 간격 100ms, 버퍼 200ms. 핑 150ms의 한쪽 지연 75ms를 더하면 상대를 약 0.3초 과거로 봅니다.
그래프에서는 확인할 곳 서버 쪽 패킷 캡처에서 한 유저에게 가는 흐름만 걸러 Wireshark의 I/O Graphs로 초당 패킷 수와 간격을 봄. 게임 쪽 로그가 있으면 개체별 업데이트 간격과 클라이언트 보간 버퍼 여유(다음 스냅샷이 올 때까지 남은 시간)를 함께 봄 이러면 맞음 위치 업데이트가 초당 5~10번(간격 100~200ms)으로 늘 드물고 보간 버퍼를 200ms 넘게 잡고 있거나 버퍼 여유가 자주 0이 됨 이러면 아님 업데이트는 촘촘히 나가는데 도착 간격만 흔들리면 지터·손실 쪽. 사람이 붐빌 때 먼 개체만 드물게 받으면 연결별 전송 예산·우선순위 확인 수단 인프라 도구로 확인(게임 코드 불필요)
출처 Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve 초당 10회 업데이트면 보간 200ms로 한 번의 누락을 견딤. Half-Life 기본은 초당 20회·보간 100ms Snapshot Interpolation Gaffer On Games 초당 10개면 두 개 연속 손실까지 견디려 350ms 지연이 필요, 초당 30개면 150ms로 줄어듦 State Synchronization Gaffer On Games 우선순위 누적으로 중요한 개체를 더 자주 보내고 대역폭 한도 안에서 나머지를 돌아가며 전송 8.8. The “I/O Graphs” Window Wireshark 표시 필터에 맞는 패킷 수·바이트를 시간 구간별 그래프로 그림 함께 보면 좋은 원인
같은 층: 동기화 설계
같은 증상(뚝뚝 끊김)의 다른 층 원인
그림과 실험이 있는 원본 카드 보기