클라이언트 / 서버 실시간 비디오 게임에서 더 빠른 컴퓨터를 처리하는 방법

socket.io를 사용하여 첫 온라인 게임을 만들고 있는데 agar.io 또는 diep.io와 같은 실시간 멀티 플레이어 게임이되고 싶습니다.

그러나 모든 컴퓨터를 같은 속도로 작동시키는 방법을 알아 내려는 문제가 발생했습니다.

모델에 대한 세 가지 아이디어가 있지만 그중 어느 것도 옳지 않은 것처럼 보이며 일반적인 비디오 게임이 어떻게 작동하는지 궁금합니다. (당신은 내 아이디어를 읽는 것을 건너 뛸 수 있습니다. 그들은 단지 내가 겪고있는 문제를 볼 수있는 방법을 제공합니다.)

1. 서버는 클라이언트가 스스로 실행하고 업데이트를 서버에 전달한 다음 나머지 클라이언트에게 브로드 캐스트합니다. 이로 인해 일부 컴퓨터는 다른 컴퓨터보다 더 빠르게 실행되어 더 빠르게 업데이트하고 화면을 더 빠르게 이동할 수 있습니다.

2. 서버가 클라이언트에게 업데이트시기를 알려주도록합니다. 그런 다음 마지막 클라이언트가 응답 할 때까지 (한 사람이 느린 컴퓨터를 가지고있는 경우 끔찍한 아이디어) 기다릴 수 있습니다. 첫 번째 클라이언트가 응답 할 때까지 (다시 말하면 각 프레임 전에 통신을 기다립니다) 가능한 한 빨리 보내십시오 ( 1)과 같은 문제가 발생하는 것 같습니다.

3. 게임을 시작할 때 서버가 클라이언트에게 업데이트 방법을 알려주도록합니다. 이는 고객이 해당 기간 사이의 이동을 제한 할 책임이 있음을 의미합니다. 예를 들어, 누군가가 그 기간 내에 어떻게 든 버튼을 두 번 누르면 관리인은 단 하나의 버튼 누름 이벤트 만 보냅니다. 이로 인해 일부 작업 (예 : 이중 버튼 누름)이 무시되고 상호 작용이 클라이언트의 시계에 의존하므로 서버의 시계와 일치하지 않을 수 있습니다. 그런 다음 서버는 각 클라이언트를 추적하고 업데이트가 올바른 시간에 제출되는지 확인해야합니다.

나는 약간의 연구 를했지만, 내가 읽은 기사는 클라이언트가 다른 클라이언트보다 빠르게 업데이트를 보내는 경우 수행해야 할 작업을 구체적으로 다루지 않는 것 같습니다.

필자의 경우에는 키보드 속도가 빠른 사람들을 상대하고 있습니다 (컴퓨터는 다른 컴퓨터보다 더 많은 키보드 업데이트를 보낼 것입니다).

프로그래머는 일반적으로 이것을 어떻게 처리합니까?

세 번째 아이디어는 내가 이런 종류의 문제에 대한 산업 솔루션으로 생각한 것에 가장 가까운 것 같습니다.

설명하는 것을 일반적으로 Ticks 라고합니다 . 각 틱마다 일련의 각 클라이언트에 대해 고정 된 수의 작업이 처리됩니다. 종종 게임 서버는 가능한 경우 병렬 작업을 수행하지만 훨씬 더 복잡한 문제입니다.

틱은 1 / N 초 형식 일 것입니다. N은 초당 틱 수 또는 Tickrate입니다. 이 사용률은 사용 사례에 따라 매우 자주 또는 매우 드물게 나타날 수 있습니다. 내 개인적인 제안은 더 많은 것이 필요하지 않은 한 초당 60 틱 이상의 진드기를 피하는 것입니다. 당신은 아마하지 않습니다 :)

조치는 원 자성이어야합니다. 예를 들어, slither.io에서 적중 한 플레이어가 이미 움직이지 않는 한 이동과 같은 동작은 체인을 깨는 것과 같은 것을 즉시 처리해서는 안됩니다. 이것은 픽셀 수준의 무언가에는 사소한 것처럼 보일 수 있지만 타일 기반 이동을 처리하는 경우 훨씬 분명 해지고 공정성을 보장합니다. 플레이어 A가 타일 X, Y로 이동하고 플레이어 B가 현재 해당 타일에있는 경우, 틱이 끝날 때까지 플레이어 B가 해당 타일에 남아 있는지 확인해야합니다.

또한 서버 측에서 독립적으로 수행하지 않는 한 클라이언트 측에서 계산을 수행하지 마십시오. 이것은 물리학으로 복잡하고 비싸집니다 (많은 게임은 이것으로 인해 많은 다른 동작 및 이벤트보다 물리에 대한 틱 속도가 낮습니다)

참고로, 게임 서버 및 멀티 플레이어 네트워킹에 대한 이해를 돕기 위한 좋은 링크 가 있습니다.

마지막으로, 공정성이 서버를 망칠 수는 없습니다. 게임이 불공평하게 만드는 익스플로잇이 있으면 수정하십시오. 더 나은 컴퓨터가 약간의 이점을 갖는 문제라면 큰 문제는 아닐 것입니다.

다음 시스템은 모든 클라이언트와 서버가 언제든지 거의 동일한 게임 상태를 공유하도록합니다.

클라이언트와 서버 모두에서 게임 상태를 유지하십시오.

클라이언트가 명령 (마우스, 키보드 등의 다른 입력)을 사용하려고 할 때 게임 상태가 유효한지 확인하십시오.

이 경우 송신 클라이언트에서 명령을 실행하지 않고 서버로 명령을 보내십시오.

서버가 명령을 받으면 게임 상태가 유효한지 확인하십시오.

이 경우, 서버에서 실행이 완료된 후 정확한 미래 날짜와 함께 모든 클라이언트에 명령을 다시 전송 한 다음, 명령을 클라이언트에 보내는 최소 시간과 같은 지연 후에 명령이 요청한 조치를 실행하십시오. . 날짜를 기록하면 향후 예측에 도움이됩니다. 시간이 너무 많은 경우 게임 시스템을보다 결정적인 시간으로 만드십시오.

클라이언트가 서버로부터 명령을받을 때 게임 상태가 유효한지 확인하면 명령이 요청한 동작을 즉시 실행 한 다음 현재 날짜를보고받은 날짜 예측과 비교하십시오. 유효하지 않으면 클라이언트가 동기화되지 않은 것입니다. (연결이 비슷한 모든 클라이언트가 동시에 수신)

날짜가 이전 인 경우 이전 단계에서 문제가 발생한 경우 수정하십시오. 날짜가 약간 지나간 후에도 아무 것도하지 않으면 날짜가 너무 길면 클라이언트가 동기화되지 않은 것입니다. 즉, 클라이언트가 너무 뒤쳐집니다.

클라이언트가 동기화되지 않은 경우 서버의 전체 게임 상태 사본을 요청하고 사용하십시오. 너무 자주 발생하면 명령을 보내는 것보다 비용이 많이 들기 때문에 수정하십시오.

클라이언트에서 다른 작업이 없을 때만 화면에 물건을 렌더링하십시오. 간단한 시나리오에서 렌더링 기능은 현재 게임 상태 만 입력으로 사용합니다.

또한 예측 시스템, 그룹화 명령, diff 만 렌더링 등을 사용하여 많은 최적화를 수행 할 수 있습니다.

예를 들어, 명령 요청 / 시간 단위를 제한하는 것은 서버에 달려 있습니다.

이것이 이것이 사용중인 라이브러리 또는 환경의 문제인지 모르겠지만 완전히 잘못 접근하고 있다고 생각합니다.

대다수의 멀티 플레이어 게임에서는 실제 계산을 수행하는 서버 만 있습니다. 클라이언트는 실제 성능 문제만으로 3D 그래픽을 그리는 바보 같은 IO 머신입니다. 이 경우 클라이언트가 시각적으로 만 영향을 미치므로 20 또는 200 FPS에서 실행할 수 있는지 여부는 중요하지 않습니다. 즉, "클라이언트 업데이트"는 전혀 의미가 없습니다. 클라이언트는 서버가 계산할 수있는 것을 "예측"하려고 시도 할 수 있지만 이는 게임 플레이 느낌을 부드럽게하기위한 것이며 게임 플레이 자체에는 실제로 영향을 미치지 않습니다.

빠른 키보드 속도

나는 그것이 무엇을 의미하는지조차 모른다. 대부분의 사람들은 저가형 키보드의 속도를 따라 잡을 수 없으므로 플레이어의 성능에 어떤 영향을 미칩니 까?

그렇지 않으면 질문이 너무 광범위 해 보이기 때문에 실제로는 없을 수도있는 "일반적인"문제를 해결하는 대신 단일 실제 문제에 집중해야합니다.