물리학을 통한 멀티 플레이어 네트워킹


12

물리학을 이용한 멀티 플레이어 네트워킹이 레이싱 게임에서 어떻게 구현되는지 궁금합니다. 우리는 다른 사람들에 의해 제어되는 여러 가지 빠르게 움직이는 차량이있는 실제 세계를 가지고 있습니다. 차량에 무기가 있고 서로 쏠 수 있다고 가정 해 봅시다 (Twisted Metal, Vigilante v8)

타격과 충돌이 걱정됩니다. 권위있는 서버 또는 더 나은 대안?

답변:


5

일반적으로 서버는 클라이언트와 주기적으로 공유되는 "진실"상태를 저장합니다. 충돌은 클라이언트와 서버에서 독립적으로 발생하며 클라이언트 상태는 일반적으로 Dead Reckoning 과 비슷한 프로세스를 사용하여 이전 상태에서 추정됩니다 . 서버 상태가 클라이언트에 도달 할 때 차이점이 있으면 클라이언트는 현재 상태에서 대부분 보간을 통해 방금 수신 한 상태로 전환합니다.

그러나 많은 객체 충돌로 인해 실제 문제가 발생할 수 있으므로 일반적으로 수행되는 작업은 클라이언트의 시뮬레이션 시간을 서버의 시뮬레이션 시간보다 약간 더 유지하여 다양한 추가 유연성을 허용하는 것입니다. Valve의 소스 엔진 넷 코드에 대한이 기사 는 상당히 설명이되어 있습니다. 또한 어떤 네트워킹 미들웨어 / 라이브러리를 사용할지 아직 결정되지 않았다면 RakNet과 "ReplicaManager3"컴포넌트 를 살펴 보는 것이 좋습니다 .


2

당신이 할 수있는 몇 가지가 있습니다.

  1. 서버의 모든 물리 객체를 중앙 집중화하고 모든 클라이언트의 플레이어 객체와 동기화 할 수 있습니다. 이것은 가장 쉽고 결함이없이 작동하지만 많은 리소스를 사용하며 많은 대역폭이 필요합니다. 특정 반경 내에있는 다른 플레이어의 플레이어에게만 값을 보내 대역폭 사용을 최적화 할 수 있습니다.

  2. Neenster가 언급 한대로 서버와 클라이언트가 물리를 시뮬레이션하도록 할 수 있습니다. 서버는 종종 클라이언트를 수정합니다. 즉, 모든 클라이언트가 모든 플레이어에 대해 자체 물리를 계산하고 서버에서 키 누르기 이벤트를 동기화하여 모든 클라이언트에서 각 플레이어의 궤적을 제공합니다. 서버가 물리 시뮬레이션을 브로드 캐스트하고 5 초마다 모든 클라이언트가 변경 사항을 수락한다고 가정 해 봅시다. 이것은 대부분 눈에 띄지 않는 약간의 오프셋을 만들 수 있지만 네트워크 지연 및 패킷 손실 (높은 트래픽 UDP로 불가피) 중에는 플레이어 및 / 또는 다른 플레이어가 화면 주위에서 반짝이고 위치가 빠르고 행복하게 변하는 것을 알 수 있습니다. 워드?).

  3. 각 클라이언트가 자체 물리를 계산하고 좌표를 동기화하도록 할 수 있습니다. 이로 인해 클라이언트간에 공유되는 객체의 물리를 시뮬레이션하기가 어렵습니다. 특정 객체가 반드시 클라이언트에 속할 필요가 없기 때문에 멋진 작업을 수행하려는 경우 구현하기가 매우 복잡한 개념입니다.

첫 번째는 가장 쉬운 방법 일 것입니다. 각 경기마다 자체 서버가 있어야합니다. 당신이 LAN 경기를하고 있다면 이것은 갈 길입니다.

두 번째는 아마도 가장 실용적이지만 구현하기가 어려울 수 있습니다. 서버에서 물리 시뮬레이션을 실행하는 것도 상당히 유익합니다. 중앙 집중식 서버를 사용하는 경우 여러 컴퓨터에로드 밸런싱을해야 할 수도 있습니다. 10 개의 서버 일치를 허용하고 가장 일치하는 서버를 사용하여 서버에 새로운 일치를로드하십시오.

세 번째는 서버에서 스트레스가 가장 적으며 피어 투 피어 네트워크 체계를 수행하는 경우 아마도 최상의 솔루션 일 것입니다. 앞서 언급했듯이 플레이어 객체 이외의 객체는 다른 클라이언트에서도 변경할 수 있기 때문에 동기화하기가 어려울 수 있습니다.

게임이 어떻게 작동하는지 모르겠 기 때문에 어느 것을 사용해야하는지 말할 수 없습니다. 내가 할 수있는 것은 사실을 알려주는 것입니다. 더 궁금한 점이 있으면 언제든지 의견을 남겨주십시오.


클라이언트가 물리를 수행하게하는 것은 수용 가능한 해결책이지만, 부정 행위와는 관련이 없습니다.
cubuspl42

@ cubuspl42 주제를 유지하기 위해 세부 사항을 생략했습니다. OP가 부정 행위를 완화 할 수있는 잠재적 인 방법을 탐색하기 위해 솔루션을 더 탐색 할 수 있다는 것이 적절하다고 생각합니다.
tsturzl

그러한 방법 중 하나는 각 클라이언트가 제공하는 것의 편차를 임계 값으로 제한하는 것입니다. 예를 들어, 대부분의 고객은 주어진 객체가 5,8 또는 6,9 위치에 있지만 한 사람이 12,19를 좌표로보고하는데, 이는 다른 고객과 얼마나 차이가 있는지에 비해 임계 값에서 벗어날 수 있습니다. 이것은 부분적인 해결책 일 뿐이지 만 대부분의 게임은 부정 행위에 대한 부분적인 해결책 만 제공하므로 왜 그런지 계속됩니다. 이 솔루션은 부정 행위를 의미하지는 않지만 위치를 수정해야하며 지연된 것으로 나타납니다.
tsturzl

글쎄, 나는 약간 동의하지 않는다. 일부 유형의 치트는 수정이 가능하고 일부는 그렇지 않습니다. 예를 들어, 경쟁 온라인 사수를 위해 속임수를 만들 수 있다면 게임 디자인이 좋지 않습니다. 또는 신 모드와 무한 탄약으로지도 주위를 날 수있는 미친 해킹 (Crysis 1에서 발생했다고 생각합니다). 이것들은 수정 가능하며 게임을 올바르게 디자인하십시오. wallhack과 같은 것들은 거의 고칠 수 없습니다 (서버에서 엄청난 자원이 필요할 것입니다). Aimbot은 사실상 고칠 수 없습니다. 솔루션 # 3은 이러한 최악의 치트의 위험을 증가시킵니다.
cubuspl42

@ cubuspl42 예제가 무엇인지 잘 모른다고 생각합니다. 옵션 3은 당신이 말하는 문제를 정확히 막을 수 있습니다. 일반적으로 속도를 공유하는 TCP가 있으며 클라이언트 간의 속도를 쉽게 확인하고 합의를 형성 할 수 있습니다. 클라이언트가 동기화 된 시계 (HW 시계에서 연결시 설정 가능).
tsturzl
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.