기본적으로 물리 기반 샌드 박스 / 활동 게임 인 2D 게임을 만들고 싶습니다. 내가 정말로 이해하지 못하는 것이 있습니다. 연구 결과 서버의 업데이트는 약 100ms마다되어야합니다. 플레이어가 물리를 동시에 시뮬레이션하고 보간을 통해 지연 보상을 수행 할 수 있기 때문에 이것이 어떻게 작동하는지 알 수 있습니다.
내가 이해하지 못하는 것은 이것이 다른 플레이어의 업데이트에 어떻게 작동하는지입니다. 고객이 100ms마다 플레이어 위치에 대해서만 알림을 받으면 100ms에 많은 일이 발생할 수 있기 때문에 어떻게 작동하는지 알 수 없습니다. 그 당시 플레이어는 방향을 두 번 정도 변경했을 수 있습니다. 누구 든지이 문제에 대한 통찰력이 있는지 궁금합니다.
기본적으로이 기능은 촬영 및 이와 유사한 방식으로 작동합니까?
감사
답변:
긴 답변을 좋아하지 않는 사람들을위한 요약 ...
가능하지만 대기 시간이 있으면 완벽한 멀티 플레이어 물리학 을 수행하는 것은 불가능합니다 . 대기 시간이 물리에 영향을 미치는 이유에 대해 설명하고 물리 시뮬레이션에서 대기 시간이 미치는 영향을 줄이기위한 팁이 제공됩니다.
멀티 플레이어 물리 게임을 만드는 것은 위험에 처할 수 있습니다. "완벽한"온라인 멀티 플레이어 물리 경험을 만드는 것은 불가능합니다. 더 잘하기 위해 할 수있는 일이 있지만 대기 시간을 가정하여 완벽한 물리학을 만들 수있는 방법은 없습니다.
문제는 물리가 현실적이되기 위해서는 빠르고 반응이 좋아야하지만, 동시에 모든 요소의 결합 된 행동, 즉 모든 플레이어의 결합 된 행동을 기반으로 계산되어야한다는 것입니다. 대기 시간이 있으면 실시간으로 수행 할 수 없습니다.
다양한 요소를 제어 할 수 있는지 여부를 결정하고 지연 시간이 너무 길면 플레이어의 경험이 저하 될 것임을 이해하는 것은 개발자의 책임입니다. 당신이 그걸로 살 수 있고 (그리고 플레이어가 할 수 있다면) 가십시오. 작업을 더 매끄럽게 유지하는 방법에 대한 참고 사항은이 게시물의 끝 부분을 참조하십시오.
일이 엉망이되는 방법을 보여주는 예
두 명의 플레이어 (클라이언트)가 서버에 연결된 게임을 상상해보십시오. 메시지가 클라이언트에서 서버로 인터넷을 통과하는 데 100 밀리 초 (1/10 초)가 걸립니다. 플레이어가 무언가를하면 서버에 자신의 행동을 알리는 메시지가 전송됩니다. 그런 다음 서버는 메시지를 다른 플레이어에게 브로드 캐스트하여 연기하는 플레이어의 역할을 모두 알 수 있습니다.
이제 두 명의 플레이어가 물리 객체 인 상자를 가지고있는 시나리오를 만듭니다. 플레이어 A가 한쪽에 부딪쳐 어떤 방향으로 움직입니다. 그러나 동시에 플레이어 B는 다른쪽에 부딪쳐 다른 방향으로 보냅니다.
이것을 처리하는 다른 방법과 결과가 무엇인지 살펴 보겠습니다.
물리가 서버에서만 계산되면 어떻게됩니까?
물리가 서버에서만 계산되었다고 가정합니다. 플레이어 A는 1/10 초 후 서버에 메시지를 수신하여 "이 방법으로 상자에 충돌했습니다"메시지를 서버에 보냅니다. 플레이어 B는 "다른 방법으로 상자를 쳤다"메시지를 보낸다. 서버는 두 동작의 조합으로 물리 변화를 계산하고 두 플레이어에게 "이것처럼 움직입니다."라는 메시지를 보냅니다. 완벽한 물리학은 두 선수의 행동을 결합하여 수행됩니다.
그러나 문제는 플레이어가 상자가 반응하는 것을보기까지 2 초의 2/10이 될 것입니다. 두 플레이어의 메시지는 서버에 도달하는 데 1/10 초가 걸리고 서버 계산 결과가 두 플레이어 모두에게 전송되는 데 1/10 초가 더 걸립니다.
결론, 게으른 게임 플레이.
물리학이 클라이언트에서 방금 계산되면 어떻게됩니까?
클라이언트에서만 물리학을 계산했다고 가정 해 봅시다. 플레이어 A의 관점에서 살펴 보겠습니다. 플레이어 A가 상자에 부딪 히고 즉시 방향을 옮깁니다. 플레이어 A가 한 일을 알리는 메시지도 서버에 전송됩니다.
동시에, B는 명중을했고 상자 가 방향을 따라가는 것을 보았고 서버에 그들이 한 일에 대한 메시지를 보냈습니다.
1 초 후 2/10 일에 서버에서 클라이언트로 메시지가 도착합니다. A는 B가 한 일을 말하고 B는 A가 한 일을 말합니다. 문제는 두 클라이언트가 말한다. "X 플레이어가이 지점에서 명중을했을 수도 있지만 더 이상 그 위치에 상자가 없기 때문에 그들의 명중은 아무 것도하지 않았다."
결론은 두 게임이 동기화되지 않고 공유 경험이없는 플레이어입니다. 둘 다 다른 것을 본다면 멀티 플레이어의 요점은 무엇입니까?
물리학이 클라이언트와 서버 모두에서 계산되면 어떻게됩니까?
이 경우 클라이언트에서 물리가 계산되므로 플레이어는 즉각적인 지연없는 반응을 볼 수 있지만 서버에서도 계산되므로 모든 플레이어에 대해 "올바른"것입니다.
두 선수 모두 각자의 방향으로 상자를 쳤으며, 각각의 상자는 적중만으로 상자가 움직이는 것을 봅니다. 그러나 2 초 후 2/10이 지나자 서버는 "실제로 당신은 둘 다 틀 렸습니다. 상자는 이런 식으로 갔다"고 말합니다. 갑자기 두 선수 모두 상자가 방향을 획기적으로 바꾸고 새로운 위치로 결함을 보게됩니다.
결론은 결함 게임입니다.
결론
기본적으로 어떤 종류의 대기 시간이 존재하는 경우 여러 플레이어와 완벽한 물리 게임 을 만들 수있는 방법이 없습니다 . 꽤 좋은 게임을 만들 수는 있지만, 일부 플레이어에게는 대기 시간이 너무 길어질 수 있습니다. 그러나 좋은 게임 경험을 유지하기 위해 할 수있는 일이 있습니다.
멀티 플레이어 게임을 잘 운영하기 위해 할 수있는 일
간단한 충돌 볼륨을 사용하십시오. 간단한 큐브 모양이 수행 될 때 물리학을 사용하여 모양의 모든 세부 사항을 모델링하지 않아도됩니다. 스파이크 볼은 물리학을 위해 스파이크 볼로 모델링 할 필요는 없습니다. 대신 구체로 모델링하십시오.
작고 중요하지 않은 객체를 클라이언트 전용 항목으로 만듭니다. 깨진 유리창에서 깨진 유리 조각을 예로들 수 있습니다. 각 클라이언트가 자체적으로 시뮬레이션하도록 할 수 있으며 실제로 다른지 중요하지 않습니다.
활성 물리 오브젝트 수를 낮게 유지하기 위해 물리 오브젝트 여야하는 경우에만 오브젝트 물리 오브젝트를 만드십시오.
멀티 플레이어 물리학을 할 때 게임을 슬로우 모션으로 실행하십시오. "글 머리 기호 시간"을 생각하십시오. 슬로우 모션 게임은 대기 시간을 보상하고 여러 플레이어가 물리와 함께 상호 작용할 수 있도록합니다.
플레이어가 어떤 종류의 상황을 함께 설정할 수 있도록 한 다음, 어떤 큐에서는 물리가 두 플레이어 모두에 대해 시뮬레이션되며 둘 다 결합 된 동작의 결과를 감시합니다. 플레이어는 시퀀스가 완료 될 때까지 시퀀스를 방해 할 수 없습니다.
서로 방해하지 않도록 플레이어의 물리학을 분리하십시오. 한 번에 한 명의 플레이어 만 제어 할 수있는 볼링 또는 수영장과 같은 게임이나 각 플레이어마다 볼링 레인과 같은 "샌드 박스"가 있습니다.
당신이 그들을 이길 수 없다면, 그들을 가입시키고 물리 지연을 게임의 일부로 만드십시오. 물리 법칙이 깨지거나 결함이있는 결함이있는 우주에 관한 이야기를 상상해보십시오. :)
부록 : 슈팅 게임이 다루는 방법
슈팅 게임은 지나치게 복잡한 물리학을 수행하지 않으면 서 처리합니다. 그들은 클라이언트 부작용을 사용하여 플레이어가 물건을 빨리 볼 수 있지만 서버는 발생한 일을 최종적으로 호출합니다.
플레이어 A가 플레이어 B를 쏘는 시나리오를 상상해보십시오. 일반적인 슈팅 게임은 다음과 같이 작동합니다.
A가 B를 때리는 것처럼 보였을 때 어떻게해야합니까? B가 이동했을 수 있지만 서버가 아직 "B move to here"메시지를 클라이언트에게 보내지 않았기 때문에 A가 아직 보지 못했습니다.
Valve는 이것에 대해 그들의 사이트에 글을 잘 작성했습니다. http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking을 참조 하십시오
나는 여기에 주제에 대한 일련의 기사를 썼습니다 : http://www.gabrielgambetta.com/fpm1.html
처음 세 기사에서는 주제 소개, 클라이언트 측 예측, 서버 조정 및 엔터티 보간 (이는 특정 질문에 대한 답변)입니다. 네 번째 기사 (곧 제공 될 예정)는 "촬영 항목"을 다룰 것입니다. :)
Tim Holt의 대답은 거의 같습니다. 내 기사에는 진행 상황을 이해하는 데 도움이되는 몇 가지 다이어그램이 있지만 Tim과 나는 기본적으로 같은 말을하고 있습니다.
응답 성을 위해 자신의 캐릭터를 완전히 예측하고 일관성을 위해 다른 캐릭터를 100ms 지연시키는 것은 무리가 없습니다. 이것이 나빠 보인다면, 자신의 캐릭터가 약간 지연되어 동기화되도록하십시오. 어느 쪽이든 지연 스파이크가 발생하는 경우 잘못된 예측을 완화하기 위해 여전히 수정 메커니즘이 필요하며 해당 시스템은 사용자가 설명하는 것과 같은 상황을 처리합니다. 대기 시간이 100ms인지 1ms인지는 중요하지 않습니다. 클라이언트는 항상 어떤 의미에서 '지연'하므로 오래된 데이터를 처리하고 보간과 같은 장식적인 효과를 적용하여 합리적인 것처럼 보이도록 항상 행동해야합니다.
결국 사용 가능한 네트워크 리소스를 사용하여 모든 작업을 수행해야합니다. 이상적으로 우리는 대기 시간이없는 세계에 살고 모든 것이 완벽하게 동기화 될 수 있습니다. 실제로는 100, 200, 300ms마다 클라이언트를 업데이트하고 클라이언트에는 발생한 상황을 매끄럽게 보이도록 논리가 있어야합니다. "부드러움"은 매우 중요합니다. 결국 게임은 백엔드에서 클라이언트와 서버간에 혼란스러운 동기화가 발생하더라도 원활하게 느껴 져야합니다.
좋은 게시물과 더 나은 답변을 찾을 수 있습니다.
문제는 실제로 지연 시간이 아닙니다. 문제의 원인을 숨기도록 보상하고 예측할 수 있습니다. 패킷 손실도 문제가되지 않습니다. 네트워킹 시스템은 패킷 손실에 견딜 수 있고 견고해야합니다. 그러나 문제는 지연 스파이크와 예측할 수없는 대기 시간입니다. 패킷이 동기화되지 않은 상태로 도착하는 경우 지연 시간 변동으로 인해 일부만 삭제되고 지연 시간 변동으로 인해 예측 및 보간 할 수없는 경우 등