답변:
일반적으로 서버는 클라이언트와 주기적으로 공유되는 "진실"상태를 저장합니다. 충돌은 클라이언트와 서버에서 독립적으로 발생하며 클라이언트 상태는 일반적으로 Dead Reckoning 과 비슷한 프로세스를 사용하여 이전 상태에서 추정됩니다 . 서버 상태가 클라이언트에 도달 할 때 차이점이 있으면 클라이언트는 현재 상태에서 대부분 보간을 통해 방금 수신 한 상태로 전환합니다.
그러나 많은 객체 충돌로 인해 실제 문제가 발생할 수 있으므로 일반적으로 수행되는 작업은 클라이언트의 시뮬레이션 시간을 서버의 시뮬레이션 시간보다 약간 더 유지하여 다양한 추가 유연성을 허용하는 것입니다. Valve의 소스 엔진 넷 코드에 대한이 기사 는 상당히 설명이되어 있습니다. 또한 어떤 네트워킹 미들웨어 / 라이브러리를 사용할지 아직 결정되지 않았다면 RakNet과 "ReplicaManager3"컴포넌트 를 살펴 보는 것이 좋습니다 .
당신이 할 수있는 몇 가지가 있습니다.
서버의 모든 물리 객체를 중앙 집중화하고 모든 클라이언트의 플레이어 객체와 동기화 할 수 있습니다. 이것은 가장 쉽고 결함이없이 작동하지만 많은 리소스를 사용하며 많은 대역폭이 필요합니다. 특정 반경 내에있는 다른 플레이어의 플레이어에게만 값을 보내 대역폭 사용을 최적화 할 수 있습니다.
Neenster가 언급 한대로 서버와 클라이언트가 물리를 시뮬레이션하도록 할 수 있습니다. 서버는 종종 클라이언트를 수정합니다. 즉, 모든 클라이언트가 모든 플레이어에 대해 자체 물리를 계산하고 서버에서 키 누르기 이벤트를 동기화하여 모든 클라이언트에서 각 플레이어의 궤적을 제공합니다. 서버가 물리 시뮬레이션을 브로드 캐스트하고 5 초마다 모든 클라이언트가 변경 사항을 수락한다고 가정 해 봅시다. 이것은 대부분 눈에 띄지 않는 약간의 오프셋을 만들 수 있지만 네트워크 지연 및 패킷 손실 (높은 트래픽 UDP로 불가피) 중에는 플레이어 및 / 또는 다른 플레이어가 화면 주위에서 반짝이고 위치가 빠르고 행복하게 변하는 것을 알 수 있습니다. 워드?).
각 클라이언트가 자체 물리를 계산하고 좌표를 동기화하도록 할 수 있습니다. 이로 인해 클라이언트간에 공유되는 객체의 물리를 시뮬레이션하기가 어렵습니다. 특정 객체가 반드시 클라이언트에 속할 필요가 없기 때문에 멋진 작업을 수행하려는 경우 구현하기가 매우 복잡한 개념입니다.
첫 번째는 가장 쉬운 방법 일 것입니다. 각 경기마다 자체 서버가 있어야합니다. 당신이 LAN 경기를하고 있다면 이것은 갈 길입니다.
두 번째는 아마도 가장 실용적이지만 구현하기가 어려울 수 있습니다. 서버에서 물리 시뮬레이션을 실행하는 것도 상당히 유익합니다. 중앙 집중식 서버를 사용하는 경우 여러 컴퓨터에로드 밸런싱을해야 할 수도 있습니다. 10 개의 서버 일치를 허용하고 가장 일치하는 서버를 사용하여 서버에 새로운 일치를로드하십시오.
세 번째는 서버에서 스트레스가 가장 적으며 피어 투 피어 네트워크 체계를 수행하는 경우 아마도 최상의 솔루션 일 것입니다. 앞서 언급했듯이 플레이어 객체 이외의 객체는 다른 클라이언트에서도 변경할 수 있기 때문에 동기화하기가 어려울 수 있습니다.
게임이 어떻게 작동하는지 모르겠 기 때문에 어느 것을 사용해야하는지 말할 수 없습니다. 내가 할 수있는 것은 사실을 알려주는 것입니다. 더 궁금한 점이 있으면 언제든지 의견을 남겨주십시오.