Megapackage: Factorio 개발자가 200명의 플레이어를 위한 멀티플레이어 문제를 해결한 방법

올해 XNUMX월에 선수로 참가했습니다. KatherineOfSky MMO 이벤트. 나는 플레이어 수가 특정 수에 도달하면 몇 분마다 일부 플레이어가 "떨어지는" 것을 발견했습니다. 운 좋게도 당신에게는 (그러나 나는 아닙니다), 나는 그 선수 중 하나였습니다 매번좋은 연결에도 불구하고. 나는 그것을 개인적인 도전으로 받아들이고 문제의 원인을 찾기 시작했습니다. XNUMX주간의 디버깅, 테스트 및 수정 끝에 버그가 마침내 수정되었지만 여정은 그렇게 쉽지 않았습니다.

멀티플레이어 게임의 문제는 추적하기가 매우 어렵습니다. 일반적으로 매우 특정한 네트워크 매개변수와 매우 특정한 게임 상태(이 경우 200명 이상의 플레이어)에서 발생합니다. 그리고 문제를 재현할 수 있는 경우에도 중단점을 삽입하면 게임이 중지되고 타이머가 엉망이 되며 일반적으로 시간 초과로 인해 연결 시간이 초과되기 때문에 제대로 디버깅할 수 없습니다. 그러나 인내와 훌륭한 도구 덕분에 꼴사나운 나는 무슨 일이 일어나고 있는지 알아낼 수 있었다.

요컨대 버그와 지연 상태 시뮬레이션의 불완전한 구현으로 인해 클라이언트는 때때로 약 400개의 게임 엔터티를 선택하기 위한 플레이어 입력 작업으로 구성된 한 클럭 주기에 네트워크 패킷을 전송해야 하는 상황에 처했습니다. 우리는 그것을 "메가 패킷"이라고 부릅니다). 그런 다음 서버는 이러한 모든 입력 작업을 올바르게 수신해야 할 뿐만 아니라 다른 모든 클라이언트에 전송해야 합니다. 200개의 클라이언트가 있는 경우 이는 빠르게 문제가 됩니다. 서버에 대한 채널이 빠르게 막혀 패킷이 손실되고 다시 요청된 패킷이 캐스케이드됩니다. 입력 작업을 연기하면 더 많은 클라이언트가 메가 패킷을 보내기 시작하고 눈사태가 더욱 강해집니다. 성공적인 클라이언트는 복구를 관리하고 나머지는 모두 떨어집니다.


문제는 상당히 근본적인 문제였고, 수정하는 데 2주가 걸렸습니다. 꽤 기술적인 내용이므로 아래에서 흥미로운 기술 세부정보를 설명하겠습니다. 하지만 먼저 0.17.54월 4일에 출시된 버전 XNUMX 이후 일시적인 연결 문제에 직면하여 멀티플레이어가 더 안정적이 되었고 지연 숨기기의 버그가 훨씬 줄었습니다(제동 및 텔레포트 감소). 또한 전투 지연이 숨겨지는 방식을 변경했으며, 이를 통해 조금 더 원활해지기를 바랍니다.

멀티플레이어 메가 팩 - 기술 정보

간단히 말해서 게임의 멀티플레이어는 다음과 같이 작동합니다. 모든 클라이언트는 플레이어 입력("입력 작업"이라고 함)만 수신 및 전송하여 게임 상태를 시뮬레이션합니다. 입력 작업). 서버의 주요 작업은 전송입니다. 입력 작업 모든 클라이언트가 동일한 주기에서 동일한 작업을 수행하도록 합니다. 게시물에서 이에 대한 자세한 내용을 읽을 수 있습니다. FFF-149.

서버가 어떤 조치를 취할지 결정해야 하므로 플레이어의 조치는 다음 경로를 따라 이동합니다. 플레이어 조치 -> 게임 클라이언트 -> 네트워크 -> 서버 -> 네트워크 -> 게임 클라이언트. 즉, 플레이어의 각 작업은 네트워크를 통해 왕복 경로를 만든 후에만 수행됩니다. 이로 인해 게임이 매우 느리게 보였을 것이므로 게임에서 멀티 플레이어가 등장한 직후 지연을 숨기는 메커니즘이 도입되었습니다. 대기 시간 숨기기는 다른 플레이어의 작업 및 서버 의사 결정을 고려하지 않고 플레이어 입력을 시뮬레이션합니다.

Factorio에는 게임 상태가 있습니다. 게임 상태 맵, 플레이어, 엔티티 및 기타 모든 것의 완전한 상태입니다. 서버에서 받은 작업을 기반으로 모든 클라이언트에서 결정적으로 시뮬레이트됩니다. 게임 상태는 신성하며 서버나 다른 클라이언트와 달라지기 시작하면 비동기화가 발생합니다.

하지만 게임 상태 지연 상태 대기 시간 상태. 기본 상태의 작은 하위 집합을 포함합니다. 대기 시간 상태 신성하지 않으며 플레이어의 입력을 기반으로 미래에 게임 상태가 어떻게 될지에 대한 그림을 나타냅니다. 입력 작업.

이를 위해 생성된 파일의 사본을 보관합니다. 입력 작업 지연 대기열에서.

즉, 클라이언트 측 프로세스의 끝에서 그림은 다음과 같습니다.

1. 적용하다 입력 작업 모든 플레이어 게임 상태 이러한 입력 작업이 서버에서 수신된 방식입니다.
2. 지연 대기열에서 모든 항목 제거 입력 작업, 서버에 따르면 이미 적용되었습니다. 게임 상태.
3. 삭제 대기 시간 상태 와 정확히 동일하게 보이도록 재설정하십시오. 게임 상태.
4. 지연 대기열의 모든 작업을 다음에 적용합니다. 대기 시간 상태.
5. 데이터 기반 게임 상태 и 대기 시간 상태 플레이어에게 게임을 렌더링합니다.

이 모든 것은 모든 소절에서 반복됩니다.

너무 어렵다? 긴장을 풀지 마십시오. 그게 전부가 아닙니다. 신뢰할 수 없는 인터넷 연결을 보완하기 위해 다음과 같은 두 가지 메커니즘을 만들었습니다.

• 건너뛴 틱: 서버가 결정한 경우 입력 작업 게임의 전술에 따라 실행될 것입니다. 입력 작업 일부 플레이어(예: 지연 증가로 인해)는 기다리지 않고 이 클라이언트에게 "귀하를 고려하지 않았습니다. 입력 작업, 다음 막대에 추가하려고 합니다. 이는 한 플레이어의 연결(또는 컴퓨터) 문제로 인해 다른 플레이어의 맵 업데이트 속도가 느려지지 않도록 하기 위한 것입니다. 주목할 가치가 있습니다 입력 작업 무시되지 않고 단순히 연기됩니다.
• 전체 왕복 대기 시간: 서버는 각 클라이언트에 대한 클라이언트와 서버 간의 왕복 대기 시간을 추측하려고 시도합니다. 5초마다 필요에 따라 클라이언트와 새로운 지연 시간을 협상하고(과거의 연결 동작 방식에 따라 다름) 그에 따라 왕복 지연 시간을 늘리거나 줄입니다.

이러한 메커니즘 자체는 매우 간단하지만 함께 사용하면(종종 연결 문제가 발생함) 코드 논리를 관리하기 어려워지고 엣지 케이스가 많이 발생합니다. 또한 이러한 메커니즘이 작동하면 서버와 지연 대기열은 특수한 규칙을 올바르게 구현해야 합니다. 입력 작업 자격 StopMovementInTheNextTick. 덕분에 연결 문제가 발생하면 캐릭터가 스스로 실행되지 않습니다(예: 기차 아래).

이제 엔터티 선택이 어떻게 작동하는지 설명해야 합니다. 통과 유형 중 하나 입력 작업 엔터티의 선택 상태 변경입니다. 플레이어가 마우스로 가리키고 있는 엔터티를 모든 사람에게 알려줍니다. 보시다시피 이것은 클라이언트가 보내는 가장 빈번한 입력 작업 중 하나이므로 대역폭을 절약하기 위해 가능한 한 적은 공간을 차지하도록 최적화했습니다. 이는 다음과 같이 구현됩니다. 각 개체가 선택되면 절대 고정밀 지도 좌표를 저장하는 대신 게임이 이전 선택 항목에서 상대적으로 낮은 정밀도 오프셋을 저장합니다. 이것은 일반적으로 마우스 선택이 이전 선택과 매우 가깝기 때문에 잘 작동합니다. 이것은 두 가지 중요한 요구 사항을 발생시킵니다. 입력 작업 절대로 건너뛰어서는 안 되며 올바른 순서로 수행해야 합니다. 이러한 요구 사항은 다음에 대해 충족됩니다. 게임 상태. 하지만 과제 이후로 대기 시간 상태 플레이어에게 "충분히 좋아 보이는" 상태에서는 지연 상태에 만족하지 않습니다. 대기 시간 상태 고려하지 않는다 많은 경계선 사례클록 건너뛰기 및 왕복 전송 지연 변경과 관련됩니다.

이것이 어디로 가고 있는지 이미 짐작할 수 있습니다. 마지막으로, 우리는 메가패키지 문제의 원인을 보기 시작했습니다. 문제의 근원은 엔터티 선택 논리가 대기 시간 상태, 이 상태가 항상 올바른 정보를 포함하는 것은 아닙니다. 따라서 메가패킷은 다음과 같이 생성됩니다.

1. 플레이어에 연결 문제가 있습니다.
2. 주기를 건너뛰고 왕복 전송 지연을 조절하는 메커니즘이 작동합니다.
3. 지연 상태 큐는 이러한 메커니즘을 고려하지 않습니다. 이로 인해 일부 작업이 조기에 제거되거나 잘못된 순서로 실행되어 잘못된 대기 시간 상태.
4. 플레이어는 연결 문제가 없으며 서버를 따라잡기 위해 최대 400주기를 시뮬레이트합니다.
5. 각 주기에서 새 작업이 생성되고 서버로 전송될 준비가 되어 엔터티 선택이 변경됩니다.
6. 클라이언트는 400개 이상의 엔터티 선택 변경 사항이 포함된 메가 패킷을 서버로 보냅니다(다른 동작과 함께 발사 상태, 보행 상태 등도 이 문제로 인해 어려움을 겪었습니다).
7. 서버는 400개의 입력 작업을 수신합니다. 단일 입력 동작을 건너뛸 수 없기 때문에 모든 클라이언트에게 이러한 동작을 수행하도록 지시하고 네트워크를 통해 전송합니다.

아이러니한 점은 대역폭을 보존하도록 설계된 메커니즘으로 인해 거대한 네트워크 패킷이 생성되었다는 것입니다.

모든 업데이트 에지 케이스 및 지연 대기열 지원을 수정하여 이 문제를 해결했습니다. 시간이 꽤 걸렸지만 빠른 해킹에 의존하기보다는 결국 제대로 해낼 가치가 있었습니다.

출처 : habr.com