멀티 플레이어 게임에서 위치 보간

멀티 플레이어 게임 에서 대역폭을 절약하기 위해 모든 서버 틱마다 모든 객체를 업데이트하지는 않지만 각 객체에는 updateRate가 있어이 객체가 X 서버 틱마다 업데이트 될 것으로 게임에 알려줍니다.

객체에 대한 업데이트 메시지를 받으면 다음 업데이트가 올 것으로 예상되는 시간을 계산합니다.

origin = serverCurrentPosition
diff = serverNextPosition - origin
arriveTime = now + timeBetweenTicks * updateRate

객체를 그릴 때 다음 업데이트까지 남은 시간을 계산하고 그에 따라 위치를 보간합니다.

step = 100 / timeBetweenTicks * updateRate
delta = 1 - step * ((arriveTime - now) / 100)
position = origin + diff * delta

작동하지만 ... 그림에는 여전히 약간의 지터가 있지만, 내 이론에서는 스케일링이 약간 의 지연 을 처리해야하기 때문에 모든 것이 잘 작동 해야합니까?

여기서 질문은 이것이 최선의 접근입니까? 계산에 실제 지연을 두어야합니까? 그렇다면 어떻게해야합니까? 나는 약간의 experiements를했지만 지터가 악화되었습니다.

지연이 끊임없이 변하기 때문에 지터가 있습니다. 이는 서버가 모든 timeBetweenTicks틱을 정확하게 업데이트하는 동안 일정 시간이 지나면 클라이언트가 업데이트를 수신 한다는 것을 의미합니다 . 그 시간은 아마도 timeBetweenTicks좋은 연결에 가깝지 만 정확히 같지는 않습니다 (또한 서버 지연과 서버 및 클라이언트에서 다른 클럭 속도를 가질 수 있습니다).

따라서 지정된 시간에 정확하게 업데이트를받는 경우 실제 업데이트 전후에 대상에 지속적으로 도착합니다. 따라서 지터.

지터를 줄이기위한 간단한 접근 방식은 "고무 밴딩"을 사용하는 것입니다. 이는 Martin이 다른 답변에서 제안한 것입니다. 기본적으로 업데이트를받을 때 개체의 위치를 ​​즉시 변경하지는 않습니다. 대신 클라이언트 위치와 서버 위치가 약간만 다른 경우 클라이언트 위치 보간을 시작하여 지정된 시간 (예 : 다음 업데이트의 중간) 후에 클라이언트와 서버 위치가 수렴됩니다.

설정에서 지터를 줄이는 또 다른 아이디어 : "현재"좌표와 "다음"좌표를 모두 전송하므로 객체의 속도를 계산할 수 있습니다. 그런 다음 업데이트가 지연되면 대상을 대상 (즉, "다음"위치)에서 멈추지 말고 동일한 속도로 계속 이동하십시오. 객체가 갑자기 속도를 변경하지 않으면 클라이언트의 모션 부드러움이 실제로 향상됩니다.

나는 "네트워크 그림자 (network shadows)"라 부르는 접근법으로 약간의 성공으로이 문제를 해결했다. 이것이 다른 사람들이하는 일인지 모르겠지만 항상 나를 위해 일했습니다.

네트워크를 통해 동기화되는 각 엔티티에는 보이지 않는 네트워크 섀도우 엔티티가 있습니다. 네트워크에서 업데이트가 발생하면 네트워크가 있어야 할 위치로 그림자를 직접 텔레포트 한 다음 시간이 지남에 따라 로컬 가시적 엔티티를 그림자쪽으로 천천히 보간합니다.

이전 답변 에이 접근법에 대한 자세한 내용을 여기 에 포함 시켰 습니다.

약간 다른 접근 방식을 자세히 설명하는 기사를 작성했으며 매우 부드러운 결과를 얻습니다. http://www.gabrielgambetta.com/fpm3.html