지난 XNUMX주 동안 저는 제 게임의 온라인 엔진 작업을 해왔습니다. 그 전에는 게임에서의 네트워킹에 대해 전혀 몰랐기 때문에 모든 개념을 이해하고 나만의 네트워킹 엔진을 작성할 수 있도록 많은 기사를 읽고 많은 실험을 했습니다.

이 가이드에서는 자신만의 게임 엔진을 작성하기 전에 배워야 할 다양한 개념과 이를 배우기 위한 최고의 리소스 및 기사를 여러분과 공유하고 싶습니다.

일반적으로 네트워크 아키텍처에는 피어 투 피어(P2P)와 클라이언트-서버라는 두 가지 주요 유형이 있습니다. PXNUMXP(Peer-to-Peer) 아키텍처에서는 연결된 플레이어 쌍 간에 데이터가 전송되는 반면, 클라이언트-서버 아키텍처에서는 플레이어와 서버 간에만 데이터가 전송됩니다.

일부 게임에서는 여전히 PXNUMXP 아키텍처가 사용되지만 클라이언트-서버가 표준입니다. 구현하기가 더 쉽고, 더 작은 채널 폭이 필요하며, 부정 행위로부터 더 쉽게 보호할 수 있습니다. 따라서 이 튜토리얼에서는 클라이언트-서버 아키텍처에 중점을 둘 것입니다.

특히 우리는 권위주의적인 서버에 가장 관심이 많습니다. 이러한 시스템에서는 서버가 항상 옳습니다. 예를 들어 플레이어가 자신이 좌표 (10, 5)에 있다고 생각하고 서버가 플레이어에게 (5, 3)에 있다고 알려주는 경우 클라이언트는 해당 위치를 서버가 보고한 위치로 바꿔야 하며 그 반대는 아닙니다. 그 반대. 신뢰할 수 있는 서버를 사용하면 사기꾼을 더 쉽게 식별할 수 있습니다.

네트워크 게임 시스템에는 세 가지 주요 구성 요소가 있습니다.

• 전송 프로토콜: 클라이언트와 서버 간에 데이터가 전송되는 방식입니다.
• 애플리케이션 프로토콜: 클라이언트에서 서버로, 서버에서 클라이언트로 전송되는 내용과 형식.
• 애플리케이션 로직: 전송된 데이터를 사용하여 클라이언트와 서버의 상태를 업데이트하는 방법입니다.

각 부분의 역할과 이와 관련된 과제를 이해하는 것이 매우 중요합니다.

전송 프로토콜

첫 번째 단계는 서버와 클라이언트 간에 데이터를 전송하기 위한 프로토콜을 선택하는 것입니다. 이를 위한 두 가지 인터넷 프로토콜이 있습니다. TCP и UDP. 그러나 그 중 하나를 기반으로 자신만의 전송 프로토콜을 만들거나 이를 사용하는 라이브러리를 사용할 수 있습니다.

TCP와 UDP의 비교

TCP와 UDP는 모두 다음을 기반으로 합니다. IP. IP는 패킷이 소스에서 수신자에게 전송되는 것을 허용하지만, 전송된 패킷이 조만간 수신자에게 도달하고, 적어도 한 번은 수신자에게 도달하며, 패킷 순서가 올바른 방식으로 도착한다는 것을 보장하지 않습니다. 주문하다. 더욱이, 패킷은 다음 값으로 주어진 제한된 양의 데이터만 포함할 수 있습니다. MTU.

UDP는 IP 위에 있는 얇은 계층일 뿐입니다. 따라서 동일한 제한 사항이 있습니다. 이에 비해 TCP에는 많은 기능이 있습니다. 오류 검사를 통해 두 노드 간의 안정적이고 질서 있는 연결을 제공합니다. 따라서 TCP는 매우 편리하며 다른 많은 프로토콜에서 사용됩니다. HTTP, FTP и SMTP. 그러나 이러한 모든 기능에는 대가가 따릅니다. 지연.

이러한 기능이 지연 시간을 유발할 수 있는 이유를 이해하려면 TCP 작동 방식을 이해해야 합니다. 송신 노드가 수신 노드에 패킷을 전송할 때 승인(ACK)을 수신할 것으로 예상합니다. 특정 시간이 지나도 패킷을 받지 못하면(패킷이나 승인이 손실되었거나 다른 이유로 인해) 패킷을 다시 보냅니다. 또한 TCP는 패킷이 올바른 순서로 수신되도록 보장하므로 손실된 패킷이 수신될 때까지 수신 호스트에서 이미 수신했더라도 다른 모든 패킷을 처리할 수 없습니다.

그러나 여러분이 상상할 수 있듯이 멀티플레이어 게임의 지연 시간은 매우 중요합니다. 특히 FPS와 같은 액션이 가득한 장르에서는 더욱 그렇습니다. 이것이 바로 많은 게임이 자체 프로토콜과 함께 UDP를 사용하는 이유입니다.

기본 UDP 기반 프로토콜은 다양한 이유로 TCP보다 더 효율적일 수 있습니다. 예를 들어 일부 패킷은 신뢰할 수 있는 것으로 표시하고 다른 패킷은 신뢰할 수 없는 것으로 표시할 수 있습니다. 따라서 신뢰할 수 없는 패킷이 수신자에게 도달했는지 여부는 중요하지 않습니다. 또는 한 스트림의 패킷 손실로 인해 나머지 스트림의 속도가 느려지지 않도록 여러 데이터 스트림을 처리할 수 있습니다. 예를 들어 플레이어 입력을 위한 스레드와 채팅 메시지를 위한 또 다른 스레드가 있을 수 있습니다. 긴급하지 않은 채팅 메시지가 유실되어도 긴급한 입력이 느려지지 않습니다. 또는 비디오 게임 환경에서 더 효율적이기 위해 독점 프로토콜이 TCP와 다르게 안정성을 구현할 수도 있습니다.

그렇다면 TCP가 너무 형편없다면 UDP를 기반으로 자체 전송 프로토콜을 만들까요?

조금 더 복잡합니다. TCP는 게임 네트워크 시스템에는 거의 최적이 아니지만 특정 게임에서는 꽤 잘 작동하고 귀중한 시간을 절약할 수 있습니다. 예를 들어, 턴제 게임이나 지연 시간과 패킷 손실이 인터넷보다 훨씬 낮은 LAN 네트워크에서만 플레이할 수 있는 게임에서는 지연 시간이 문제가 되지 않을 수 있습니다.

World of Warcraft, Minecraft 및 Terraria를 포함한 많은 성공적인 게임은 TCP를 사용합니다. 그러나 대부분의 FPS는 자체 UDP 기반 프로토콜을 사용하므로 아래에서 이에 대해 자세히 설명하겠습니다.

TCP를 사용하기로 결정했다면 비활성화되어 있는지 확인하세요. Nagle의 알고리즘, 전송하기 전에 패킷을 버퍼링하기 때문에 대기 시간이 늘어납니다.

멀티플레이어 게임의 맥락에서 UDP와 TCP의 차이점에 대해 자세히 알아보려면 Glenn Fiedler의 기사를 읽어보세요. UDP 대 TCP.

자체 프로토콜

자신만의 전송 프로토콜을 만들고 싶지만 어디서부터 시작해야 할지 모르시나요? Glenn Fiedler가 이에 대해 두 개의 놀라운 기사를 썼기 때문에 운이 좋았습니다. 당신은 그들에게서 많은 현명한 생각을 발견하게 될 것입니다.

첫 번째 기사 게임 프로그래머를 위한 네트워킹 2008년은 두 번째 것보다 쉬웠고, 게임 네트워크 프로토콜 구축 2016. 오래된 것부터 시작하는 것이 좋습니다.

Glenn Fiedler는 UDP 기반의 사용자 정의 프로토콜 사용을 강력히 지지합니다. 그리고 그의 기사를 읽은 후에는 TCP가 비디오 게임에 심각한 단점이 있다는 그의 의견을 받아들이게 될 것이며 자신만의 프로토콜을 구현하고 싶을 것입니다.

그러나 네트워킹이 처음이라면 TCP나 라이브러리를 사용하는 것이 좋습니다. 자신만의 전송 프로토콜을 성공적으로 구현하려면 사전에 많은 것을 배워야 합니다.

네트워크 라이브러리

TCP보다 더 효율적인 것이 필요하지만 자체 프로토콜을 구현하고 많은 세부 사항을 다루어야 하는 번거로움을 겪고 싶지 않다면 네트워킹 라이브러리를 사용할 수 있습니다. 그것들이 많이 있습니다 :

• 요짐보 글렌 피들러
• RakNet, 더 이상 지원되지 않지만 그 중 하나가 포크입니다. SLikeNet 아직도 활발히 활동하고 있는 것 같습니다.
• 이넷 멀티플레이어 FPS용으로 만들어진 라이브러리입니다. 입방체
• 게임네트워킹소켓 판막

모두 시도해 보지는 않았지만 사용하기 쉽고 안정적이기 때문에 ENet을 선호합니다. 또한 초보자를 위한 명확한 문서와 튜토리얼도 제공됩니다.

전송 프로토콜: 결론

요약하면 TCP와 UDP라는 두 가지 주요 전송 프로토콜이 있습니다. TCP에는 신뢰성, 패킷 순서 보존, 오류 감지 등 유용한 기능이 많이 있습니다. UDP에는 이 모든 기능이 없지만 TCP는 특성상 대기 시간이 길어 일부 게임에서는 허용되지 않습니다. 즉, 낮은 대기 시간을 보장하기 위해 UDP 기반의 자체 프로토콜을 만들거나 UDP에서 전송 프로토콜을 구현하고 멀티플레이어 비디오 게임에 적합한 라이브러리를 사용할 수 있습니다.

TCP, UDP 및 라이브러리 간의 선택은 여러 요인에 따라 달라집니다. 첫째, 게임의 요구 사항에서 낮은 지연 시간이 필요한가요? 둘째, 애플리케이션 프로토콜 요구 사항에서 신뢰할 수 있는 프로토콜이 필요한가요? 다음 부분에서 살펴보겠지만, 신뢰할 수 없는 프로토콜이 매우 적합한 애플리케이션 프로토콜을 생성하는 것이 가능합니다. 마지막으로, 네트워크 엔진 개발자의 경험도 고려해야 합니다.

두 가지 조언이 있습니다.

• 모든 코드를 다시 작성하지 않고도 쉽게 대체할 수 있도록 애플리케이션의 나머지 부분에서 전송 프로토콜을 최대한 추상화합니다.
• 과도하게 최적화하지 마십시오. 네트워킹 전문가가 아니고 사용자 정의 UDP 기반 전송 프로토콜이 필요한지 확실하지 않은 경우 TCP 또는 안정성을 제공하는 라이브러리로 시작한 다음 성능을 테스트하고 측정할 수 있습니다. 문제가 발생하고 그 원인이 전송 프로토콜이라고 확신하는 경우 고유한 전송 프로토콜을 만들어야 할 때일 수 있습니다.

이 부분의 마지막 부분을 읽어보시기 바랍니다. 멀티플레이어 게임 프로그래밍 소개 여기에서 논의된 많은 주제를 다루는 Brian Hook의 글입니다.

애플리케이션 프로토콜

이제 클라이언트와 서버 간에 데이터를 교환할 수 있으므로 어떤 데이터를 어떤 형식으로 전송할지 결정해야 합니다.

고전적인 방식은 클라이언트가 입력이나 작업을 서버에 보내고, 서버는 현재 게임 상태를 클라이언트에 보내는 것입니다.

서버는 전체 상태가 아닌 플레이어 근처에 있는 엔터티로 필터링된 상태를 보냅니다. 그가 이렇게 하는 데에는 세 가지 이유가 있습니다. 첫째, 완전한 상태가 너무 커서 고주파수로 전송될 수 없습니다. 둘째, 대부분의 게임 로직이 게임 서버에서 시뮬레이션되기 때문에 클라이언트는 주로 시각적 및 오디오 데이터에 관심이 있습니다. 셋째, 일부 게임에서 플레이어는 특정 데이터(예: 지도 반대편에 있는 적의 위치)를 알 필요가 없습니다. 그렇지 않으면 패킷을 감지하여 그를 죽이기 위해 이동할 위치를 정확히 알 수 있습니다.

직렬화

첫 번째 단계는 전송하려는 데이터(입력 또는 게임 상태)를 전송에 적합한 형식으로 변환하는 것입니다. 이 과정을 직렬화.

즉시 떠오르는 생각은 JSON이나 XML과 같이 사람이 읽을 수 있는 형식을 사용하는 것입니다. 그러나 이는 완전히 비효율적이며 대부분의 채널을 낭비하게 됩니다.

대신 훨씬 더 컴팩트한 바이너리 형식을 사용하는 것이 좋습니다. 즉, 패킷에는 몇 바이트만 포함됩니다. 여기서 생각해 볼 문제가 있습니다 바이트 순서, 컴퓨터마다 다를 수 있습니다.

데이터를 직렬화하려면 다음과 같은 라이브러리를 사용할 수 있습니다.

• 플랫버퍼 Google
• 캡틴 프로토 샌드스톰 컴퍼니
• 시리얼 셰인 그랜트와 랜돌프 부히스

라이브러리가 휴대용 아카이브를 생성하고 엔디안을 고려하는지 확인하세요.

대체 솔루션은 직접 구현하는 것입니다. 특히 코드에 데이터 중심 접근 방식을 사용하는 경우에는 특별히 어렵지 않습니다. 또한 라이브러리를 사용할 때 항상 가능하지 않은 최적화를 수행할 수 있습니다.

Glenn Fiedler는 연재에 관한 두 가지 기사를 썼습니다. 패킷 읽기 및 쓰기 и 직렬화 전략.

압축

클라이언트와 서버 간에 전송되는 데이터의 양은 채널의 대역폭에 의해 제한됩니다. 데이터 압축을 사용하면 각 스냅샷에서 더 많은 데이터를 전송하거나, 업데이트 빈도를 높이거나, 단순히 채널 요구 사항을 줄일 수 있습니다.

비트 포장

첫 번째 기술은 비트 패킹입니다. 이는 원하는 값을 설명하는 데 필요한 비트 수를 정확하게 사용하는 것으로 구성됩니다. 예를 들어, 16개의 서로 다른 값을 가질 수 있는 열거형이 있는 경우 전체 바이트(8비트) 대신 4비트만 사용할 수 있습니다.

Glenn Fiedler는 기사의 두 번째 부분에서 이를 구현하는 방법을 설명합니다. 패킷 읽기 및 쓰기.

비트 패킹은 특히 다음 섹션의 주제인 샘플링과 잘 작동합니다.

견본 추출

견본 추출 값을 인코딩하기 위해 가능한 값의 하위 집합만 사용하는 손실 압축 기술입니다. 이산화를 구현하는 가장 쉬운 방법은 부동 소수점 숫자를 반올림하는 것입니다.

Glenn Fiedler(다시 한번!)는 자신의 기사에서 샘플링을 실제로 적용하는 방법을 보여줍니다. 스냅샷 압축.

압축 알고리즘

다음 기술은 무손실 압축 알고리즘입니다.

제 생각에는 여러분이 알아야 할 가장 흥미로운 세 가지 알고리즘이 있습니다.

• 허프만 코딩 미리 계산된 코드를 사용하면 매우 빠르고 좋은 결과를 얻을 수 있습니다. 이는 Quake3 네트워킹 엔진에서 패킷을 압축하는 데 사용되었습니다.
• ZLIB 데이터 양을 절대 늘리지 않는 범용 압축 알고리즘입니다. 어떻게 볼 수 있나요? 여기에, 다양한 용도로 사용되었습니다. 상태를 업데이트하는 데 중복될 수 있습니다. 그러나 자산, 긴 텍스트 또는 지형을 서버에서 클라이언트로 보내야 하는 경우 유용할 수 있습니다.
• 실행 길이 복사 - 이것은 아마도 가장 간단한 압축 알고리즘이지만 특정 유형의 데이터에 매우 효과적이며 zlib 이전의 전처리 단계로 사용할 수 있습니다. 이는 인접한 많은 요소가 반복되는 타일이나 복셀로 구성된 지형을 압축하는 데 특히 적합합니다.

델타 압축

마지막 압축 기술은 델타 압축입니다. 현재 게임 상태와 클라이언트가 수신한 마지막 상태 간의 차이점만 전송된다는 사실로 구성됩니다.

Quake3 네트워크 엔진에서 처음 사용되었습니다. 사용 방법을 설명하는 두 가지 기사는 다음과 같습니다.

• Quake3 네트워킹 모델 브라이언 후크
• Quake 3 소스 코드 검토: 네트워크 모델 파비앙 상글라스 [번역 Habré에 관한 기사, "네트워크 모델" 섹션 참조]

Glenn Fiedler도 그의 기사의 두 번째 부분에서 이 용어를 사용했습니다. 스냅샷 압축.

암호화

또한 클라이언트와 서버 간의 정보 전송을 암호화해야 할 수도 있습니다. 여기에는 몇 가지 이유가 있습니다.

• 개인정보 보호/기밀성: 메시지는 수신자만 읽을 수 있으며 네트워크를 스니핑하는 다른 사람은 메시지를 읽을 수 없습니다.
• 인증: 플레이어 역할을 수행하려는 사람은 자신의 키를 알아야 합니다.
• 치트 예방: 악의적인 플레이어가 자신만의 치트 패키지를 만드는 것이 훨씬 더 어려울 것이며, 암호화 체계를 재현하고 키(연결할 때마다 변경됨)를 찾아야 합니다.

이를 위해 라이브러리를 사용하는 것이 좋습니다. 나는 사용하는 것이 좋습니다 라이브러리 나트륨, 특히 간단하고 훌륭한 튜토리얼이 있기 때문입니다. 특히 흥미로운 것은 다음과 같은 튜토리얼입니다. 키 교환, 각각의 새로운 연결마다 새로운 키를 생성할 수 있습니다.

응용 프로토콜: 결론

이것으로 우리의 애플리케이션 프로토콜이 마무리됩니다. 나는 압축이 완전히 선택 사항이며 이를 사용하기로 한 결정은 게임과 필요한 대역폭에만 달려 있다고 믿습니다. 제 생각에는 암호화는 필수이지만 첫 번째 프로토타입에서는 암호화 없이도 할 수 있습니다.

애플리케이션 로직

이제 클라이언트에서 상태를 업데이트할 수 있지만 대기 시간 문제가 발생할 수 있습니다. 플레이어는 입력을 완료한 후 게임 상태가 서버에서 업데이트될 때까지 기다려야 그것이 세계에 어떤 영향을 미쳤는지 확인해야 합니다.

게다가 두 가지 상태 업데이트 사이에는 세계가 완전히 정적입니다. 상태 업데이트 속도가 낮으면 움직임이 매우 불안정해집니다.

이 문제의 영향을 줄이는 몇 가지 기술이 있으며 다음 섹션에서 이에 대해 다루겠습니다.

지연 시간 평활화 기술

이 섹션에 설명된 모든 기술은 시리즈에서 자세히 설명됩니다. 빠르게 진행되는 멀티플레이어 가브리엘 감베타. 이 훌륭한 기사 시리즈를 읽어 보시기를 적극 권장합니다. 또한 이러한 기술이 실제로 어떻게 작동하는지 확인할 수 있는 대화형 데모도 포함되어 있습니다.

첫 번째 기법은 서버의 응답을 기다리지 않고 입력된 결과를 직접 적용하는 것이다. 그것은이라고 클라이언트 측 예측. 그러나 클라이언트는 서버로부터 업데이트를 받으면 예측이 올바른지 확인해야 합니다. 그렇지 않은 경우에는 서버에서 받은 내용에 따라 상태를 변경하면 됩니다. 서버가 권위적이기 때문입니다. 이 기술은 Quake에서 처음 사용되었습니다. 기사에서 자세한 내용을 읽을 수 있습니다. Quake Engine 코드 검토 파비앙 상글라스 [번역 아브레].

두 번째 기술 세트는 두 상태 업데이트 사이에서 다른 엔터티의 이동을 원활하게 하는 데 사용됩니다. 이 문제를 해결하는 방법에는 보간(interpolation)과 외삽(extrapolation)이라는 두 가지 방법이 있습니다. 보간의 경우 마지막 두 상태가 선택되고 한 상태에서 다른 상태로의 전환이 표시됩니다. 단점은 클라이언트가 항상 과거에 일어난 일을 보기 때문에 약간의 지연이 발생한다는 것입니다. 외삽은 클라이언트가 받은 마지막 상태를 기반으로 엔터티가 이제 어디에 있어야 하는지 예측하는 것입니다. 단점은 개체가 이동 방향을 완전히 바꾸면 예측과 실제 위치 사이에 큰 오류가 발생한다는 것입니다.

FPS에서만 쓸 수 있는 최신, 최첨단 기술은 지연 보상. 지연 보상을 사용할 때 서버는 대상을 향해 발사할 때 클라이언트의 지연을 고려합니다. 예를 들어, 플레이어가 화면에서 헤드샷을 수행했지만 실제로는 지연으로 인해 목표물이 다른 위치에 있는 경우 지연으로 인해 플레이어의 살인 권리를 거부하는 것은 불공평합니다. 따라서 서버는 플레이어가 발사한 순간으로 시간을 되돌려 플레이어가 화면에서 본 것을 시뮬레이션하고 샷과 대상 간의 충돌을 확인합니다.

Glenn Fiedler(늘 그랬듯이!)는 2004년에 기사를 썼습니다. 네트워크물리학(2004), 그는 서버와 클라이언트 간의 물리 시뮬레이션 동기화를 위한 기반을 마련했습니다. 2014년에 그는 새로운 시리즈의 기사를 썼습니다. 네트워킹 물리학, 물리 시뮬레이션을 동기화하는 다른 기술을 설명했습니다.

Valve 위키에도 두 개의 기사가 있습니다. 소스 멀티플레이어 네트워킹 и 클라이언트/서버 게임 내 프로토콜 설계 및 최적화의 지연 시간 보상 방법 지연에 대한 보상을 고려합니다.

부정행위 방지

부정행위를 방지하는 방법에는 크게 두 가지가 있습니다.

첫째: 사기꾼이 악성 패킷을 보내는 것을 더 어렵게 만듭니다. 위에서 언급했듯이 이를 구현하는 좋은 방법은 암호화입니다.

둘째: 권위주의적 서버는 명령/입력/작업만 수신해야 합니다. 클라이언트는 입력을 보내는 것 외에는 서버의 상태를 변경할 수 없어야 합니다. 그런 다음 서버는 입력을 받을 때마다 사용하기 전에 입력이 유효한지 확인해야 합니다.

응용 논리: 결론

클라이언트와 서버가 동일한 컴퓨터에서 실행되는 경우에도 열악한 조건에서 게임 동작을 테스트할 수 있도록 높은 대기 시간과 낮은 새로 고침 빈도를 시뮬레이션하는 방법을 구현하는 것이 좋습니다. 이는 지연 평활화 기술의 구현을 크게 단순화합니다.

기타 유용한 리소스

네트워크 모델에 대한 다른 리소스를 탐색하려면 여기에서 찾을 수 있습니다.

• 글렌 피들러의 블로그 – 그의 블로그 전체는 읽을 가치가 있으며 거기에는 훌륭한 기사가 많이 있습니다. 여기에 네트워크 기술에 관한 모든 기사를 모아놓았습니다.
• 멋진 게임 네트워킹 작성자: M. Fatih MAR은 온라인 비디오 게임 엔진에 관한 포괄적인 기사 및 비디오 목록입니다.
• В r/gamedev 하위 레딧의 위키 유용한 링크도 많이 있습니다.

출처 : habr.com