네트워크 지연 보상 알고리즘을 사용하여 모바일 슈팅 게임의 탄도 계산 메커니즘을 강화한 방법

안녕하세요. 저는 Pixonic의 서버 개발자 Nikita Brizhak입니다. 오늘은 모바일 멀티플레이 시 렉 보상에 대해 말씀드리고자 합니다.

러시아어를 포함하여 서버 지연 보상에 관한 많은 기사가 작성되었습니다. 이 기술은 90년대 후반부터 멀티플레이어 FPS 제작에 적극적으로 사용되었기 때문에 이는 놀라운 일이 아닙니다. 예를 들어, 이 모드를 처음으로 사용한 QuakeWorld 모드를 기억할 수 있습니다.

모바일 멀티플레이어 슈팅 게임인 Dino Squad에서도 이를 사용합니다.

이 기사에서 나의 목표는 이미 작성된 내용을 수천 번 반복하는 것이 아니라 기술 스택과 핵심 게임플레이 기능을 고려하여 게임에서 지연 보상을 어떻게 구현했는지 설명하는 것입니다.

우리의 피질과 기술에 대한 몇 마디.

Dino Squad는 네트워크 모바일 PvP 슈팅 게임입니다. 플레이어는 다양한 무기를 장착한 공룡을 조종하며 6대6 팀으로 서로 전투를 펼칩니다.

클라이언트와 서버 모두 Unity를 기반으로 합니다. 슈팅 게임의 아키텍처는 매우 고전적입니다. 서버는 권위주의적이며 클라이언트 예측은 클라이언트에서 작동합니다. 게임 시뮬레이션은 사내 ECS를 사용하여 작성되었으며 서버와 클라이언트 모두에서 사용됩니다.

지연 보상에 대해 처음 들어보신 경우, 문제에 대한 간략한 설명은 다음과 같습니다.

멀티플레이어 FPS 게임에서 경기는 일반적으로 원격 서버에서 시뮬레이션됩니다. 플레이어는 입력(눌린 키에 대한 정보)을 서버에 보내고 이에 대한 응답으로 서버는 수신된 데이터를 고려하여 업데이트된 게임 상태를 플레이어에게 보냅니다. 이 상호 작용 방식을 사용하면 앞으로 키를 누르는 순간과 플레이어 캐릭터가 화면에서 움직이는 순간 사이의 지연 시간이 항상 핑보다 커집니다.

로컬 네트워크에서는 이 지연(일반적으로 입력 지연이라고 함)이 눈에 띄지 않을 수 있지만, 인터넷을 통해 플레이할 때는 캐릭터를 제어할 때 "얼음 위에서 미끄러지는" 느낌을 줍니다. 이 문제는 플레이어의 핑이 200ms인 경우가 여전히 우수한 연결로 간주되는 모바일 네트워크와 이중으로 관련됩니다. 종종 핑은 350, 500 또는 1000ms일 수 있습니다. 그러면 입력 지연이 있는 빠른 슈팅 게임을 플레이하는 것이 거의 불가능해집니다.

이 문제에 대한 해결책은 클라이언트 측 시뮬레이션 예측입니다. 여기서 클라이언트 자체는 서버의 응답을 기다리지 않고 플레이어 캐릭터에 입력을 적용합니다. 그리고 답변을 받으면 단순히 결과를 비교하고 상대의 위치를 ​​업데이트합니다. 이 경우 키를 누르고 결과를 화면에 표시하는 것 사이의 지연은 최소화됩니다.

여기서 뉘앙스를 이해하는 것이 중요합니다. 클라이언트는 항상 마지막 입력에 따라 자신을 그리고 적을 서버 데이터의 이전 상태에 따라 네트워크 지연으로 그립니다. 즉, 적을 향해 총을 쏠 때 플레이어는 자신을 기준으로 과거에 그를 봅니다. 클라이언트 예측에 대해 자세히 알아보기 우리는 이전에 썼다.

따라서 클라이언트 예측은 한 가지 문제를 해결하지만 다른 문제를 만듭니다. 플레이어가 과거에 적이 있었던 지점에서 총을 쏘면 서버에서 같은 지점에서 총격을 가할 때 적이 더 이상 그 위치에 없을 수 있습니다. 서버 지연 보상은 이 문제를 해결하려고 시도합니다. 무기가 발사되면 서버는 플레이어가 발사 당시 로컬에서 본 게임 상태를 복원하고 실제로 적을 공격할 수 있었는지 확인합니다. 대답이 "예"이면 해당 시점에 적이 더 이상 서버에 없더라도 적중 횟수가 계산됩니다.

이러한 지식을 바탕으로 우리는 다이노스쿼드에서 서버 지연 보상을 구현하기 시작했습니다. 우선, 클라이언트가 본 것을 서버에 복원하는 방법을 이해해야 했습니다. 그리고 정확히 무엇을 복원해야 합니까? 우리 게임에서 무기와 능력의 적중은 레이캐스트와 오버레이, 즉 적의 물리적 충돌체와의 상호 작용을 통해 계산됩니다. 따라서 우리는 플레이어가 로컬로 "본" 충돌체의 위치를 ​​서버에서 재현해야 했습니다. 당시 우리는 Unity 버전 2018.x를 사용하고 있었습니다. 물리 API는 정적이며 물리적 세계는 단일 복사본에 존재합니다. 상태를 저장한 다음 상자에서 복원할 수 있는 방법은 없습니다. 그래서 뭐 할까?

해결책은 표면에 있었고, 그 모든 요소는 이미 다른 문제를 해결하기 위해 사용되었습니다.

1. 각 클라이언트에 대해 키를 눌렀을 때 상대를 본 시간을 알아야 합니다. 우리는 이미 이 정보를 입력 패키지에 기록했으며 이를 사용하여 클라이언트 예측을 조정했습니다.
2. 게임 상태의 기록을 저장할 수 있어야 합니다. 우리는 상대방(따라서 충돌자)의 위치를 ​​​​유지할 것입니다. 우리는 이미 서버에 상태 기록을 갖고 있으며 이를 사용하여 빌드했습니다. 델타. 적절한 때를 알면 역사에서 올바른 상태를 쉽게 찾을 수 있습니다.
3. 이제 기록을 통해 게임 상태를 확보했으므로 플레이어 데이터를 실제 세계의 상태와 동기화할 수 있어야 합니다. 기존 충돌체 - 이동, 누락된 충돌체 - 생성, 불필요한 충돌체 - 파괴. 이 로직 역시 이미 작성되어 여러 ECS 시스템으로 구성되어 있습니다. 우리는 하나의 Unity 프로세스에서 여러 개의 게임룸을 보유하는 데 이를 사용했습니다. 그리고 물리적 세계는 프로세스당 하나이기 때문에 룸 간에 재사용되어야 했습니다. 시뮬레이션이 시작될 때마다 우리는 물리적 세계의 상태를 "재설정"하고 현재 방의 데이터로 다시 초기화하여 영리한 풀링 시스템을 통해 Unity 게임 객체를 최대한 재사용하려고 노력합니다. 남은 것은 과거의 게임 상태에 대해 동일한 논리를 호출하는 것뿐이었습니다.

이 모든 요소를 ​​종합함으로써 우리는 물리적 세계의 상태를 적절한 순간으로 되돌릴 수 있는 "타임머신"을 갖게 되었습니다. 코드는 간단해졌습니다.

public class TimeMachine : ITimeMachine
{
     //История игровых состояний
     private readonly IGameStateHistory _history;

     //Текущее игровое состояние на сервере
     private readonly ExecutableSystem[] _systems;

     //Набор систем, расставляющих коллайдеры в физическом мире 
     //по данным из игрового состояния
     private readonly GameState _presentState;

     public TimeMachine(IGameStateHistory history, GameState presentState, ExecutableSystem[] timeInitSystems)
     {
         _history = history; 
         _presentState = presentState;
         _systems = timeInitSystems;  
     }

     public GameState TravelToTime(int tick)
     {
         var pastState = tick == _presentState.Time ? _presentState : _history.Get(tick);
         foreach (var system in _systems)
         {
             system.Execute(pastState);
         }
         return pastState;
     }
}

남은 것은 이 기계를 사용하여 샷과 능력을 쉽게 보정하는 방법을 알아내는 것뿐이었습니다.

가장 간단한 경우, 역학이 단일 히트스캔을 기반으로 하는 경우 모든 것이 명확해 보입니다. 플레이어가 총을 쏘기 전에 물리적 세계를 원하는 상태로 롤백하고, 레이캐스트를 수행하고, 히트 또는 실패를 계산해야 하며, 세상을 초기 상태로 되돌립니다.

하지만 Dino Squad에는 그러한 메커니즘이 거의 없습니다! 게임에 있는 대부분의 무기는 여러 시뮬레이션 틱(경우에 따라 수십 틱) 동안 날아가는 수명이 긴 총알인 발사체를 생성합니다. 어떻게 해야 할까요? 몇 시에 비행기를 타야 할까요?

В 고대 기사 Half-Life 네트워크 스택에 대해 Valve 직원들도 같은 질문을 했고 그들의 대답은 다음과 같았습니다. 발사체 지연 보상은 문제가 있으며 이를 피하는 것이 좋습니다.

우리에게는 이 옵션이 없었습니다. 발사체 기반 무기는 게임 디자인의 핵심 기능이었습니다. 그래서 우리는 뭔가를 생각해내야 했습니다. 몇 가지 브레인스토밍 후에 우리는 효과가 있을 것 같은 두 가지 옵션을 공식화했습니다.

1. 발사체를 생성한 플레이어의 시간과 연결합니다. 서버 시뮬레이션의 모든 틱, 모든 플레이어의 모든 총알에 대해 우리는 물리적 세계를 클라이언트 상태로 롤백하고 필요한 계산을 수행합니다. 이 접근 방식을 통해 서버에 부하를 분산시키고 발사체의 비행 시간을 예측할 수 있게 되었습니다. 클라이언트에서 적의 발사체를 포함한 모든 발사체를 예측했기 때문에 예측 가능성이 특히 중요했습니다.

그림에서 틱 30의 플레이어는 예상하여 미사일을 발사합니다. 그는 적이 어느 방향으로 달리고 있는지 확인하고 미사일의 대략적인 속도를 알고 있습니다. 로컬에서 그는 33번째 틱에서 목표물을 맞춘 것을 확인합니다. 렉보상 덕분에 서버에도 나오네요

2. 첫 번째 옵션과 동일하게 모든 작업을 수행하지만 총알 시뮬레이션의 XNUMX틱을 계산한 후 멈추지 않고 동일한 서버 틱 내에서 비행을 계속 시뮬레이션하여 시간이 서버에 더 가까워질 때마다 하나씩 틱하고 충돌체 위치를 업데이트합니다. 우리는 다음 두 가지 중 하나가 발생할 때까지 이 작업을 수행합니다.

• 총알이 만료되었습니다. 이는 계산이 끝났음을 의미하며 실패 또는 적중을 계산할 수 있습니다. 그리고 이것은 총이 발사된 동일한 틱에 있습니다! 우리에게 이것은 플러스이자 마이너스였습니다. 플러스 - 슈팅 플레이어의 경우 적중과 적의 체력 감소 사이의 지연이 크게 줄어들었기 때문입니다. 단점은 상대방이 플레이어에게 발사할 때 동일한 효과가 관찰되었다는 것입니다. 적은 느린 로켓만 발사한 것처럼 보이며 피해는 이미 계산되었습니다.
• 총알이 서버 시간에 도달했습니다. 이 경우 시뮬레이션은 지연 보상 없이 다음 서버 틱에서 계속됩니다. 느린 발사체의 경우 이론적으로 첫 번째 옵션에 비해 물리 롤백 수가 줄어들 수 있습니다. 동시에 시뮬레이션의 불균일한 로드가 증가했습니다. 서버가 유휴 상태였거나 한 서버 틱에서 여러 총알에 대해 XNUMX개의 시뮬레이션 틱을 계산했습니다.

이전 그림과 동일한 시나리오이지만 두 번째 구성표에 따라 계산되었습니다. 미사일은 발사가 발생한 동일한 틱에서 서버 시간을 "따라잡았고" 히트는 다음 틱부터 계산될 수 있습니다. 31번째 틱에서는 ​​이 경우 지연 보상이 더 이상 적용되지 않습니다.

우리 구현에서 이 두 가지 접근 방식은 단 몇 줄의 코드에서만 달랐기 때문에 두 가지를 모두 만들었고 오랫동안 병렬로 존재했습니다. 무기의 메커니즘과 총알의 속도에 따라 우리는 각 공룡에 대해 하나 또는 다른 옵션을 선택했습니다. 여기서 전환점은 '이런 시간에 적을 여러 번 때리면 저런 보너스를 받는다' 같은 메카닉 게임의 등장이다. 플레이어가 적을 공격하는 시간이 중요한 역할을 하는 모든 메커니즘은 두 번째 접근 방식을 사용하는 것을 거부했습니다. 그래서 우리는 결국 첫 번째 옵션을 선택하게 되었고, 이제 이 옵션은 게임의 모든 무기와 모든 활성 능력에 적용됩니다.

이와 별도로 성능 문제를 제기할 가치가 있습니다. 이 모든 것이 속도를 늦출 것이라고 생각했다면 저는 그렇다고 대답하겠습니다. Unity는 충돌체를 이동하고 켜고 끄는 데 상당히 느립니다. Dino Squad에서는 "최악의" 경우 전투 중에 수백 개의 발사체가 동시에 존재할 수 있습니다. 각 발사체를 개별적으로 계산하기 위해 충돌기를 이동하는 것은 감당할 수 없는 사치입니다. 따라서 물리 "롤백" 수를 최소화하는 것이 절대적으로 필요했습니다. 이를 위해 우리는 플레이어의 시간을 기록하는 별도의 구성 요소를 ECS에 만들었습니다. 지연 보상이 필요한 모든 개체(투사체, 능력 등)에 추가했습니다. 이러한 엔터티 처리를 시작하기 전에 지금까지 엔터티를 클러스터링하고 함께 처리하여 각 클러스터에 대해 물리적 세계를 한 번씩 롤백합니다.

이 단계에서는 일반적으로 작동하는 시스템이 있습니다. 다소 단순화된 형태의 코드:

public sealed class LagCompensationSystemGroup : ExecutableSystem
{
     //Машина времени
     private readonly ITimeMachine _timeMachine;

     //Набор систем лагкомпенсации
     private readonly LagCompensationSystem[] _systems;
     
     //Наша реализация кластеризатора
     private readonly TimeTravelMap _travelMap = new TimeTravelMap();

    public LagCompensationSystemGroup(ITimeMachine timeMachine, 
        LagCompensationSystem[] lagCompensationSystems)
     {
         _timeMachine = timeMachine;
         _systems = lagCompensationSystems;
     }

     public override void Execute(GameState gs)
     {
         //На вход кластеризатор принимает текущее игровое состояние,
         //а на выход выдает набор «корзин». В каждой корзине лежат энтити,
         //которым для лагкомпенсации нужно одно и то же время из истории.
         var buckets = _travelMap.RefillBuckets(gs);

         for (int bucketIndex = 0; bucketIndex < buckets.Count; bucketIndex++)
         {
             ProcessBucket(gs, buckets[bucketIndex]);
         }

         //В конце лагкомпенсации мы восстанавливаем физический мир 
         //в исходное состояние
         _timeMachine.TravelToTime(gs.Time);
     }

     private void ProcessBucket(GameState presentState, TimeTravelMap.Bucket bucket)
     {
         //Откатываем время один раз для каждой корзины
         var pastState = _timeMachine.TravelToTime(bucket.Time);

         foreach (var system in _systems)
         {
               system.PastState = pastState;
               system.PresentState = presentState;

               foreach (var entity in bucket)
               {
                   system.Execute(entity);
               }
          }
     }
}

남은 것은 세부 사항을 구성하는 것뿐이었습니다.

1. 시간상 최대 이동 거리를 얼마나 제한해야 하는지 이해합니다.

열악한 모바일 네트워크 조건에서 게임에 최대한 접근할 수 있게 만드는 것이 중요했기 때문에 스토리를 30틱(틱 속도 20Hz)으로 제한했습니다. 이를 통해 플레이어는 매우 높은 핑에서도 상대를 공격할 수 있습니다.

2. 제 시간에 이동할 수 있는 물체와 이동할 수 없는 물체를 결정합니다.

물론 우리는 상대방을 움직이고 있습니다. 그러나 예를 들어 설치 가능한 에너지 쉴드는 그렇지 않습니다. 온라인 슈팅 게임에서 흔히 볼 수 있듯이 방어 능력에 우선순위를 두는 것이 더 낫다고 판단했습니다. 플레이어가 현재에 이미 방패를 배치한 경우 과거의 지연 보상 총알이 이를 통과해서는 안 됩니다.

3. 공룡의 능력(물기, 꼬리치기 등)에 대한 보상이 필요한지 결정합니다. 필요한 것이 무엇인지 결정하고 총알과 동일한 규칙에 따라 처리합니다.

4. 지연 보상이 수행되는 플레이어의 충돌체를 어떻게 처리할지 결정합니다. 좋은 방법으로, 그들의 위치는 과거로 이동해서는 안 됩니다. 플레이어는 자신이 현재 서버에 있는 것과 같은 시간에 자신을 볼 수 있어야 합니다. 그러나 슈팅 플레이어의 충돌체도 롤백하는데, 여기에는 몇 가지 이유가 있습니다.

첫째, 클러스터링이 향상됩니다. 핑이 가까운 모든 플레이어에 대해 동일한 물리적 상태를 사용할 수 있습니다.

둘째, 모든 레이캐스트 및 오버랩에서 우리는 항상 능력이나 발사체를 소유한 플레이어의 충돌체를 제외합니다. Dino Squad에서 플레이어는 슈팅 게임 기준으로는 다소 비표준적인 기하학을 가진 공룡을 제어합니다. 플레이어가 비정상적인 각도로 총을 쏘고 총알의 궤적이 플레이어의 공룡 충돌기를 통과하더라도 총알은 이를 무시합니다.

세 번째로, 렉 보상이 시작되기 전부터 ECS에서 얻은 데이터를 이용하여 공룡 무기의 위치나 능력 적용 지점을 계산합니다.

결과적으로 지연 보상된 플레이어의 충돌기의 실제 위치는 우리에게 중요하지 않으므로 보다 생산적이고 동시에 간단한 경로를 택했습니다.

네트워크 대기 시간은 단순히 제거할 수 없으며 마스킹만 할 수 있습니다. 다른 위장 방법과 마찬가지로 서버 지연 보상에도 장단점이 있습니다. 이는 총에 맞은 플레이어를 희생시키면서 총을 쏘는 플레이어의 게임 경험을 향상시킵니다. 그러나 Dino Squad의 경우 여기서 선택은 분명했습니다.

물론 이 모든 것은 프로그래머와 게임 디자이너 모두에게 전체적으로 서버 코드의 복잡성이 증가함에 따라 지불되어야 했습니다. 이전에 시뮬레이션이 시스템의 단순한 순차적 호출이었다면 지연 보상을 통해 중첩 루프와 분기가 나타났습니다. 또한 작업하기 편리하도록 많은 노력을 기울였습니다.

2019 버전(혹은 조금 더 이전 버전)에서 Unity는 독립적인 물리적 장면에 대한 완전한 지원을 추가했습니다. 우리는 모든 방에 공통된 물리적 세계를 빠르게 제거하고 싶었기 때문에 업데이트 직후에 서버에 이를 구현했습니다.

우리는 각 게임룸에 고유한 물리적 장면을 제공하여 시뮬레이션을 계산하기 전에 인접한 방의 데이터에서 장면을 "삭제"할 필요를 제거했습니다. 첫째, 생산성이 크게 향상되었습니다. 둘째, 프로그래머가 새로운 게임 요소를 추가할 때 장면 정리 코드에서 오류를 범하면 발생하는 모든 종류의 버그를 제거할 수 있게 되었습니다. 이러한 오류는 디버그하기 어려웠으며 한 방의 장면에 있는 물리적 객체의 상태가 다른 방으로 "흐르는" 결과를 낳는 경우가 많았습니다.

또한 우리는 물리적 장면을 사용하여 물리적 세계의 역사를 저장할 수 있는지에 대해 몇 가지 연구를 수행했습니다. 즉, 조건부로 각 방에 하나의 장면이 아닌 30개의 장면을 할당하고, 이를 순환 버퍼로 만들어 스토리를 저장한다. 일반적으로 이 옵션은 작동하는 것으로 판명되었지만 구현하지 않았습니다. 생산성이 크게 향상되지는 않았지만 다소 위험한 변경이 필요했습니다. 너무 많은 장면을 장시간 작업하면서 서버가 어떻게 동작할지 예측하기 어려웠습니다. 따라서 우리는 다음과 같은 규칙을 따랐습니다.파산하지 않았다면 고치지 마라.".

출처 : habr.com