socket.io 사용하면 다른 MMORPG와 비슷한 통신을 유지하며 메시지와 안정적으로 연결됩니다.
지금까지 내 디자인에서 클라이언트는 모든 업데이트 프레임과 함께 플레이어의 위치와 애니메이션 프레임을 보냅니다. 서버가 해당 메시지를 받으면 모든 클라이언트에게 메시지를 브로드 캐스트 한 다음 그에 따라 그래픽을 이동시킵니다.
예를 들어 1/10 초에 한 번만 '수집'하여 브로드 캐스트하는 것이 더 좋은 아이디어입니까?
또한 클라이언트는 메시지가 발생하거나 하나만 수집하자마자 많은 다른 메시지를 보내야 하는가? 첫 번째는 더 쉽게 구현됩니다.
답변:
나는 높은 수준의 토론에서 이것에 접근하고 당신의 질문을 향해 노력할 것입니다. 공개를 위해 개인적으로 socket.io를 사용하지는 않았지만 MMORPG와 관련하여 문제 공간에 많이 노출되었습니다.
MMORPG 엔진의 네트워크 아키텍처 설계 및 / 또는 기능을 제공하기위한 미들웨어 또는 오픈 소스 프로젝트 선택은 팀의 게임 디자인, 예산 및 기술 전문성에 영향을받는 가장 어려운 결정 중 하나입니다. 궁극적 인 선택은 다른 아키텍처 결정에 영향을 미칩니다 (때로는 디자인 결정에도 영향을 미침).
MMORPG 개발자 인 경우, 많은 사람들이 경고등과 사이렌을 발생시키는 큰 성공 (종종 치명적인 성공이라고도 함)을 계획합니다. 자라나는 무서운 많은 숫자 중 하나는 N 제곱 된 알고리즘 (이하 N ^ 2)입니다. 당신의 질문에 가장 먼저 나에게 튀어 나온 것은 엔티티가 정보를 브로드 캐스트하도록 요구하는 디자인처럼 들렸다는 것입니다. 다른 모든 연결된 엔터티 이것은 N ^ 2 문제의 전형적인 예입니다.
MMO는 일반적으로 몇 가지 다른 방식으로 문제를 공격함으로써 N ^ 2 문제를 해결합니다. 인식 시스템 (상황, 공간 등) : 엔티티가 다른 모든 엔티티의 일부 하위 세트를 인식하고, 플레이어를 다른 "샤드"로 분할, "영역"으로 플레이어를 분할 및 / 또는 인스턴스화, 너무 많은 것을 방해하는 게임 메커니즘 구현 함께 모이는 플레이어 (Asheron Call의 순간 이동 폭풍) 등
대부분의 MMORPG 및 많은 FPS 엔진에는 다음과 같은 다양한 기능을 지원하는 상당히 정교한 네트워킹 아키텍처가 있습니다.
나는 것을 발견 언리얼 네트워킹 설명서 및 밸브 네트워킹 문서는 문제의 다양한 좋은 프라이머를 제공합니다.
이제 질문에 접근하십시오.
예를 들어 1/10 초에 한 번만 '수집'하여 브로드 캐스트하는 것이 더 좋은 아이디어입니까?
규모 (관찰 개체 수), 업데이트 빈도 및 업데이트 크기에 따라 여기에 간단한 예 또는 대답이 없습니다. 예를 들어, 업데이트의 크기가 버퍼를 어딘가에 날려 버릴 수 있다면 모두 수집하는 것은 끔찍한 잘못 일 수 있습니다.
MMORPG 및 FPS 게임용 클라이언트는 일반적으로 "보통"보다 더 많은 업데이트 프레임에 대한 업데이트를받지 않더라도 "보이는"것을 시각화하도록 설계되었습니다. 신뢰할 수없는 통신 (UDP)을 사용하는 경우 빈 공간에 몇 개의 업데이트가 손실 될 것으로 예상 할 수 있으며 클라이언트는 안정적인 전송에 사용될 수있는 것보다 더 자주 업데이트를 전송하여이를 보완 할 수 있습니다.
socket.io 문서를 간단히 검토하면 신뢰할 수 있고 신뢰할 수없는 (용어에 휘발성) 통신 경로를 모두 지원하는 것처럼 보입니다.
업데이트가 필요한 빈도에 따라 태클을 통해 먼저 접근합니다 ...
플레이어가 일정한 속도로 직선으로 이동하는 경우 관찰 클라이언트가 플레이어가 어느 시점에 있는지 정확하게 예측할 수 있기 때문에 업데이트 빈도가 낮습니다. 플레이어가 단단한 원을 그리거나 빠르게 방향을 바꾸는 경우 훨씬 더 자주 업데이트해야합니다. 반대로, 플레이어가 전혀 움직이지 않을 때는 움직임 업데이트를 전혀 보낼 이유가 없습니다.
무엇이든, 일반적으로 클라이언트에서 서버로 모든 프레임을 업데이트하는 데 필요하지는 않습니다. 서버 자체는 각 프레임마다 메시지를 보내거나 지연시킬 수 있습니다 (대역폭 형성, 우선 순위 지정 및 업데이트 수명 참조).
다른 유형의 업데이트에는 다른 특성이 있습니다. 예를 들어 플레이어 또는 생물이 손상 될 때 수정되는 "건강"필드를 고려하십시오. 이를 구현하는 한 가지 방법은 각 변경 사항이 발생할 때마다 즉시 브로드 캐스트되지만 프레임 또는 연속 프레임에서 값이 여러 번 변경되면 처리 및 대역폭 낭비로 이어집니다 (대역폭 형성을 구현하는 네트워킹 아키텍처는 업데이트를 통합하여이 문제를 해결 함). 사용 가능한 대역폭이있는 경우 가장 최근의 클라이언트 만 관찰 클라이언트로 전송됩니다.
클라이언트가 발생하자마자 또는 하나의 메시지를 수집하자마자 많은 다른 메시지를 보내야 하는가?
다시, 간단한 예 또는 대답이 여기에서 작동하지 않습니다. 수집 된 것의 의미에 따라 ... 여러 상황에 따라 다를 수 있으며 네트워킹 계층의 구현에 따라 달라질 수도 있습니다.
하나의 메시지로 구현할 특정 엔터티에 대한 메시지를 수집하면 (구현에 따라 다름) 메시지를 보내기위한 대역폭 오버 헤드 (비용 절감)를 반대로 (문자열로 통신하는 필드 / 값 매핑과 같은 구현에 따라) 대역폭을 증가시킬 수 있습니다 더 간단한 특정 메시지 유형과 비교 한 요구 사항
socket.io 문서를 검토하면 메시지 오버 헤드가 스펙트럼의 최상위에 있기 때문에 많은 단일 업데이트와 달리 집계 메시지로 보낼 업데이트를 수집하는 것이 좋습니다.
복제하려는 모든 업데이트를 검토하는 것이 좋습니다. 예를 들어 대부분의 MMORPG 및 FPS는 X 이벤트를 클릭 한 플레이어에게 클라이언트를 관찰하기 위해 귀찮게하지 않습니다. .
실제 예는 다음과 같습니다. RuneScape는 ~ 0.6 초마다 한 번씩 "틱"합니다. 여기에서 읽을 수 있습니다 . 스크립트에서 밀리 초 대신 틱으로 타이밍과 지연을 지정하기 때문에 관점에서 사물을 단순화한다고 생각합니다. 물론, 크거나 느린 틱 속도로 인해 연결 속도가 느린 사용자는 다른 플레이어에 비해 큰 단점이 없습니다.
작업의 한 가지 방법은 실제 데이터 변경 사항을 해당 변경 사항의 브로드 캐스트에서 분리하는 것입니다. 객체가 변경되면 수정하고 '더티 (dirty)'플래그를 설정하고, 변경 사항을 브로드 캐스트 할 때가되면 플래그가 지정된 객체에 대한 데이터 만 보내고 플래그를 지 웁니다. 업데이트시 브로드 캐스트시 상태 만 보내기 때문에 여러 번 변경되는 값은 여기에 자동으로 병합됩니다. 변경된 사항 만 브로드 캐스트하도록 하위 오브젝트 또는 개별 특성에 플래그를 지정할 수도 있습니다.
일반적으로 애니메이션 프레임을 서버 나 다른 클라이언트로 보내지 않습니다. 정확한 애니메이션 상태는 일반적으로 프레젠테이션 세부 사항으로 간주되며 각 클라이언트가 해결하기 위해 남겨두고 대신 각 클라이언트가 현재 재생중인 애니메이션을 알고 있는지 확인합니다.