넷코드

Netcode

넷코드는 온라인 게임의 네트워킹과 관련하여 게이머들이 가장 일반적으로 사용하는 포괄적인 용어이며, 종종 클라이언트와 서버 간의 동기화 문제를 가리킵니다.플레이어는 종종 게임에서 연결 문제가 발생했을 때 "나쁜 넷코드"를 추론합니다.일반적인 원인으로는 서버와 클라이언트 간의 지연, 패킷 손실, 네트워크 폭주 및 프레임 렌더링 시간이나 프레임환율 [1][2]불일치 등 네트워크 품질에 의존하지 않는 외부 요인 등이 있습니다.

넷코드 타입

게임의 동일한 시뮬레이션 또는 인스턴스에서 모든 플레이어의 입력이 즉시 실행되는 로컬 게임과는 달리 온라인 게임에서는 다른 플레이어의 동일한 프레임에 대한 입력이 특정 플레이어와 함께 도착하는 동안 각각의 플레이어의 입력이 즉시 수신되는 병렬 시뮬레이션이 여러 개 있다.지연(플레이어 간의 물리적 거리, 플레이어의 네트워크 연결 품질 및 속도 등에 따라 제한 또는 감소)[3]온라인 매치 중 게임은 각 프레임(60FPS에서 프레임당 16.66ms에 상당)에 대해 특정 프레임(예를 들어 프레임 번호 10)에 대한 리모트 플레이어의 입력이 다른 프레임이 이미 실행 중일 때 도달하면(예를 들어 프레임 번호 20, 166.66ms에 해당), 동기화 해제됩니다.플레이어 간 시뮬레이션이 생성됩니다.이 경합을 해결하고 게임을 원활하게 실행하기 위한 두 가지 주요 솔루션이 있습니다.

지연 베이스

피어 투 피어 모델에서 지연 기반 넷 코드를 사용하는 온라인 게임에서 두 플레이어의 입력 실행 및 동기(사이에서 90밀리초 ping 포함)에 관한 다이어그램입니다.

이 문제의 전형적인 해결책은 지연 기반의 넷코드를 사용하는 것입니다.리모트 플레이어의 입력이 늦게 도착하면 게임은 로컬 플레이어의 입력을 지연시켜 두 입력을 동기화시키고 동시에 실행한다.이 추가 지연은 플레이어에게 혼란을 줄 수 있지만(특히 지연 시간이 높을 경우), 전반적으로 변화는 그다지 눈에 띄지 않습니다.단, 이러한 지연은 현재 지연의 급격한 변동으로 인해 일관되지 않을 수 있습니다.플레이어 간의 지연 시간이 원격 플레이어의 설정된 버퍼 창을 초과하면 게임이 대기하여 화면이 "동결"됩니다.이것은 지연 기반의 넷코드가 문제의 [4]프레임 내의 모든 플레이어로부터 입력을 수신할 때까지 시뮬레이션을 계속할 수 없기 때문에 발생합니다.이 가변 지연은 오프라인 플레이(또는 LAN 게임)에 비해 일관되지 않고 반응하지 않는 경험을 유발하며 격투 [5]게임과 같이 타이밍에 민감하고 속도가 빠른 장르에서 플레이어의 성능에 부정적인 영향을 미칠 수 있습니다.

롤백

피어 투 피어 모델에서 롤백넷 코드를 사용하는 온라인 게임에서의 2명의 플레이어의 입력 실행 및 동기(양자간에 90밀리초 ping 포함)에 관한 그림.

이전 넷코드의 대체 시스템은 롤백넷코드입니다이 시스템은 로컬 플레이어의 입력을 오프라인 게임처럼 즉시 실행하고(지연 기반의 넷코드와 같이 지연되지 않도록), 리모트 플레이어의 입력을 기다리는 대신 예측한다(앞의 틱과 같은 입력을 할 것으로 가정).이러한 원격 입력이 도착하면(예: 45밀리초 후), 게임은 두 가지 방식으로 동작할 수 있습니다. 예측이 맞으면 게임은 그대로 계속됩니다. 예측이 틀리면 게임 상태가 되돌아가고 게임 플레이는 수정된 상태에서 다른 플레이어 또는 플레이어에 대한 "점프"로 간주됩니다(예: 동등).45 ms (예에 [1]따릅니다)일부 게임은 이러한 "점프"를 고정 입력 지연과 롤백으로 위장하기 위해 하이브리드 솔루션을 사용합니다.롤백은 지연 스파이크나 사용자 연결의 불일치와 관련된 기타 문제를 숨기는데 매우 효과적입니다. 예측은 대부분 정확하고 플레이어는 알아차리지도 못합니다.단, 이 시스템은 리프트 문제로 인해 머신 간의 티켓 교환이 균일하지 않기 때문에 클라이언트의 게임 속도가 느려질 때마다(통상 과열로 인해) 문제가 발생할 수 있습니다.이는 느린 속도로 입력을 받는 플레이어의 게임 플레이를 방해하는 시각적 결함을 발생시키는 반면, 게임이 느려지는 플레이어는 정상적인 속도로 다른 플레이어의 입력을 수신함으로써 나머지 플레이어보다 유리합니다(이를 일방 [6]롤백이라고 합니다).이 불균일한 입력 흐름(그리고 결과적으로 프레임 흐름도 불균일)에 대처하기 위해 모든 기계에 늦게 입력되는 것을 기다리는 등의 표준 솔루션이나 Skullgirls에서 현재 사용되고 있는 것과 같은 보다 기발한 솔루션이 있습니다.이것은 매 프레임마다 1프레임씩의 체계적인 누락으로 구성되어 있습니다.7. 문제가 발생한 경우 다양한 [7]머신에서 게임의 인스턴스를 점차 동기화하기 위해 건너뛴 프레임을 복구할 수 있습니다.

롤백 넷코드는 게임 엔진을 원래 상태로 되돌릴 수 있어야 하기 때문에 기존 많은 엔진을 수정해야 하기 때문에 Dragon Ball FighterZ의 프로듀서인 Tomoko H의 코멘트대로 AAA 타입의 게임(통상 견고한 엔진과 높은 트래픽 네트워크를 갖추고 있음)에서는 이 시스템의 구현에 문제가 있고 비용이 많이 들 수 있습니다.이로키, [8]그 중에서도.

이 시스템은 피어 투 피어 아키텍처 및 격투 게임과 관련된 경우가 많지만 클라이언트 서버 아키텍처(예를 들어 데이터베이스 관리 시스템에서 볼 수 있는 공격적인 스케줄러에는 롤백 기능이 포함됨) 및 기타 비디오 [1]게임 장르에서도 일반적으로 사용되는 롤백 네트워킹의 형태가 있습니다.

게임(주로 격투 게임)[9]에 롤백 네트워킹을 구현하도록 설계된 GGPO라는 이름의 MIT 라이센스 라이브러리가 있습니다.


넷코드 문제의 잠재적인 원인

레이텐시

온라인 게임에서는 레이텐시는 피할 수 없으며 플레이어의 경험의 질은 이와 엄격히 관련되어 있습니다(플레이어 간에 레이텐시가 많을수록 게임이 [1]입력에 반응하지 않는다는 느낌은 커집니다).플레이어의 네트워크의 레이텐시(대부분 게임의 제어에서 벗어남)가 문제의 유일한 요인이 될 뿐만 아니라 게임 시뮬레이션의 실행 방식에 내재된 레이텐시이기도 합니다.지연을 위장하거나 지연에 대처하기 위해 사용되는 몇 가지 지연 보정 방법이 있습니다(특히 지연 시간이 긴 값).[10]

틱레이트

게임 시뮬레이션의 단일 업데이트를 틱이라고 합니다.서버상에서 시뮬레이션을 실행하는 레이트를 서버의 틱레이트라고 부릅니다.이것은 렌더링 시스템이 없는 [11]클라이언트의 프레임 레이트와 본질적으로 동등한 서버입니다.tickrate는 시뮬레이션을 실행하는 데 걸리는 시간에 따라 제한되며, 변동하는 tickrate로 인한 불안정성을 줄이고 CPU 및 데이터 전송 비용을 절감하기 위해 의도적으로 더 제한되는 경우가 많습니다.틱레이트가 낮을수록 서버와 클라이언트 [12]간의 게임 시뮬레이션 동기화 지연이 증가합니다.두번째(그런 Valorant의 사례는)당 Tickrate 1사수들을 같은 게임을 위한 것이다 사이로 128 있는 가운데, 두번째(카운터-스트라이크:글로벌 오펜시브와 Overwatch 같은 게임에서)은 시속 60진드기, 콜 오브 듀티의 두번째(처럼 Fortnite과 전적지 5세의 콘솔 버전)[13]당 30진드기와 초당 20진드기 등이 논란이 되고 있는 경우:M.시rn 워페어, 콜 오브 듀티: 워존과 에이펙스 레전드).[14][15]또한 틱레이트가 낮으면 시뮬레이션의 [11]정밀도가 자연스럽게 떨어집니다.시뮬레이션 자체가 너무 길거나 클라이언트와 서버의 시뮬레이션 속도가 크게 다를 경우 문제가 발생할 수 있습니다.

사용 가능한 대역폭과 네트워크 통신에 걸리는 CPU 시간의 제한으로 인해 일부 게임에서는 중요도가 낮은 정보의 빈도와 우선순위를 제한하면서 특정 중요한 통신에 우선순위를 부여합니다.이는 tickrate와 마찬가지로 동기 지연을 효과적으로 증가시킵니다.게임 엔진은 (시뮬레이션의) 갱신이 특정 클라이언트 및/또는 게임 세계의 특정 오브젝트에 전송되는 횟수를 제한할 수 있으며, 또한 대역폭 사용을 돕기 위해 네트워크를 통해 전송되는 일부 값의 정밀도를 낮출 수도 있습니다.이러한 정밀도의 결여가 눈에 띄는 [11][16]경우가 있습니다.

소프트웨어의 버그

머신간의 각종 시뮬레이션 동기 에러도, 「넷 코드의 문제」에 해당할 가능성이 있습니다.여기에는 시뮬레이션을 다른 기계와 다르게 진행하거나 사용자가 인식했을 [2]때 전달되지 않는 버그가 포함될 수 있습니다.전통적으로 실시간 전략 게임(Age of Empires 등)은 잠금 스텝 피어 투 피어 네트워킹 모델을 사용해 왔습니다.이 모델에서는 시뮬레이션이 모든 클라이언트에서 완전히 동일하게 실행된다고 가정합니다.단, 어떤 이유로든 한 클라이언트가 보조를 맞추지 못할 경우 비동기화가 복합적으로 발생하여 복구할 [11][17]수 없게 될 수 있습니다.

전송 계층 프로토콜 및 통신 코드:TCP 및 UDP

다음 항목도 참조하십시오.UDP와 TCP의 비교

게임의 트랜스포트 계층 프로토콜(및 그 관리 및 코딩) 선택도 인식된 네트워킹 문제에 영향을 미칠 수 있습니다.

게임에서 TCP(Transmission Control Protocol)를 사용하면 플레이어 간에 대기 시간이 길어집니다.이 프로토콜은 데이터를 교환하고 읽을 수 있는 두 시스템 간의 연결을 기반으로 합니다.이러한 종류의 접속은 매우 신뢰성, 안정성, 순서 부여 및 구현이 용이하며, 인터넷상의 거의 모든 조작(Web 브라우징에서 E-메일 송신, IRC를 통한 채팅 등)에서 사용됩니다.그러나 이러한 연결은 고속 액션 게임이 필요로 하는 네트워크 속도에 적합하지 않습니다. 이러한 유형의 프로토콜(실시간 스트리밍 프로토콜)은 전송되는 패킷으로 데이터를 자동으로 그룹화합니다(이 알고리즘 - Nagle의 알고리즘 - 이 비활성화되지 않는 한 특정 양의 정보에 도달할 때까지 전송되지 않습니다).(시큐러티를 위해서 속도를 높인다)가 아니고, 머신간에 확립된 접속에 의해서 행해집니다.이러한 유형의 프로토콜은 또한 패킷이 손실되거나 패킷이 잘못된 순서로 도착하거나 중복될 때마다 매우 느리게 반응하는 경향이 있으며, 이는 실시간 온라인 게임에 매우 해로울 수 있습니다(이 프로토콜은 이러한 유형의 소프트웨어용으로 설계되지 않았습니다).

만약 게임이 사용자 데이터그램 프로토콜(UDP)을 사용한다면, 컴퓨터들 사이에 연결을 확립하는 대신 데이터가 직접 전송되고 수신되기 때문에 컴퓨터들 간의 연결은 매우 빠를 것이다.이 프로토콜은 이전 프로토콜보다 훨씬 단순하지만, 신뢰성과 안정성이 부족하며 TCP에 의해 처리되는 머신 간의 통신에 필수적인 기능(패킷을 통한 데이터 분할, 자동 패킷 손실 감지 등)을 처리하기 위해 자체 코드를 구현해야 합니다.; 이는 엔진의 복잡성을 증가시키고 그 자체로 문제를 [18]야기할 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c d Huynh, Martin; Valarino, Fernando (2019). An analysis of continuous consistency models in real time peer-to-peer fighting games.
  2. ^ a b "Addressing "Netcode" in Battlefield 4". EA Digital Illusions CE. March 2014. Retrieved 2014-03-30.
  3. ^ "Netcode [p1]: Fightin' Words". ki.infil.net. Retrieved 2020-12-07.{{cite web}}: CS1 maint :url-status (링크)
  4. ^ Staff, Ars (2019-10-18). "Explaining how fighting games use delay-based and rollback netcode". Ars Technica. Retrieved 2020-12-07.{{cite web}}: CS1 maint :url-status (링크)
  5. ^ Pinnacle. "The difference between LAN and Online esports". Pinnacle. Retrieved 2020-12-01.{{cite web}}: CS1 maint :url-status (링크)
  6. ^ Lee, Gerald (2020-04-08). Analysis: Why Rollback Netcode Is Better (Youtube).
  7. ^ Hills, Dakota 'DarkHorse' (2020-04-29). "Skullgirls receives an improved netcode update initially created by a fan of the game". EventHubs. Retrieved 2020-12-11.{{cite web}}: CS1 maint :url-status (링크)
  8. ^ Hills, Dakota 'DarkHorse' (2020-12-10). "The era of delay-based netcode may finally be over for good in fighting games depending on what SNK does with The King of Fighters 15". EventHubs. Retrieved 2020-12-10.{{cite web}}: CS1 maint :url-status (링크)
  9. ^ Pusch, Ricky (2019-10-18). "Explaining how fighting games use delay-based and rollback netcode". Ars Technica. Retrieved 2020-12-14.{{cite web}}: CS1 maint :url-status (링크)
  10. ^ "Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization". Valve Developer Community. Retrieved 2020-12-11.{{cite web}}: CS1 maint :url-status (링크)
  11. ^ a b c d "Source Multiplayer Networking". Valve. Retrieved 2014-03-30.
  12. ^ "Titanfall, de l'importance d'un bon tickrate". gamekult.com. 2014-03-29. Retrieved 2014-03-30.
  13. ^ "Battlefield V Server Tick Rate Revealed & Why It Matters". www.glitched.online. Retrieved 2020-12-05.
  14. ^ Davison, Ethan. "Valorant's super-fast servers are attracting streamers and pros in droves. Here's why". Washington Post. ISSN 0190-8286. Retrieved 2020-12-05.
  15. ^ "How bad is Apex Legends netcode compared to Fortnite and PUBG?". Dexerto. 2019-11-23. Retrieved 2020-12-05.
  16. ^ "Unreal Networking Architecture". Epic Games. Retrieved 2014-09-07.
  17. ^ Glenn Fiedler (24 February 2010). "What every programmer needs to know about game networking". Retrieved 2014-09-08.
  18. ^ Fiedler, Glenn (2008-10-01). "UDP vs. TCP". Gaffer On Games. Retrieved 2020-12-14.{{cite web}}: CS1 maint :url-status (링크)