한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

게임 렉 백서 › 동기화 설계

선연출 뒤 서버 거절 Client-side feedback rejected by server

원인 ID sy-optimistic-reject · 주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발

그림과 실험이 있는 원본 카드로 열기 →

내 화면에서 먼저 보여 준 타격·스킬을 서버가 나중에 인정하지 않으면, 분명히 본 결과가 없던 일이 됩니다.

왜 타격 이펙트·스킬 모션을 서버 확인 전에 먼저 재생(선연출) → 그러면 서버가 사거리·대상 위치·쿨다운·자원을 다시 따져 보고 거절 → 화면에서는 피가 튀었는데 데미지 없음, 스킬 모션만 나가고 효과 없음, 쿨다운만 돎

증상
씹힘·롤백, 고무줄
요인
지연
누가 겪나
나만, 특정 기능만
언제
특정 행동을 할 때
담당
주 담당 게임개발팀·클라이언트 개발 · 함께 게임개발팀·서버 개발
게임개발팀 할 일
클라이언트: 데미지 숫자·사망·보상처럼 확정이 필요한 부분만 서버 결과로 표시, 흔한 거절 사유는 먼저 검사, 거절되면 쿨다운·자원을 되돌리고 이유를 보여 주기. 서버: 사거리·대상 위치 검사에 핑만큼 여유 두기, 거절 응답에 사유를 담아 보내기, 스킬별 거절 비율을 지표로 모으기.
수치 감각
거절 응답은 누른 뒤 핑 + 틱 대기만큼 늦게 옵니다. 핑 150ms면 약 0.2초 동안 “맞힌 줄” 압니다.
그래프에서는
일부만 높음 · 스킬별 서버 거절 비율(핑 구간별)
확인할 곳
서버에서 스킬별 거절 비율과 거절 사유(사거리, 대상 위치, 쿨다운, 자원)를 모으고 유저 RTT 구간별로 나눔. 클라이언트에는 선연출한 행동이 거절된 횟수를 기록
이러면 맞음
거절이 특정 스킬과 사거리·대상 위치 사유에 몰리고 핑이 높을수록 거절 비율이 오름
이러면 아님
거절 사유가 쿨다운·자원이고 핑과 상관없으면 클라이언트와 서버의 데이터 값(쿨다운, 비용)이 다른지 봄. 거절은 없고 연출이 서버 응답 뒤에야 시작되면 서버 응답 후에만 연출(요청-응답 방식)
확인 수단
게임 서버·클라이언트의 로그·지표가 필요
더 알아보기
선연출은 핑을 가리는 가장 좋은 방법입니다. 다만 클라이언트와 서버가 판단에 쓰는 정보(상대 위치, 남은 자원)가 다를수록 거절이 잦아집니다. 스킬별 거절 비율을 지표로 모아 두면 판정이 어긋나는 곳을 찾기 쉽습니다.

출처

  1. Using Gameplay Abilities in Unreal Engine Epic Games
    Local Predicted 능력은 클라이언트에서 즉시 실행하지만 서버가 최종 결정하고 결과를 뒤집을 수 있음
  2. Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization (Yahn W. Bernier, GDC 2001) Valve
    무기 발사를 클라이언트에서 예측해 효과를 먼저 재생하고 서버 결과로 예측 오차를 바로잡음

함께 보면 좋은 원인

같은 층: 동기화 설계

같은 증상(씹힘·롤백)의 다른 층 원인

그림과 실험이 있는 원본 카드 보기