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

안녕하세요, 저는 Pixonic의 서버 개발자 Nikita Brizhak입니다. 오늘은 모바일 멀티플레이어의 지연 보상에 대해 이야기해 보고 싶습니다.

서버 지연 보상에 대한 기사는 러시아어를 포함하여 많이 작성되었습니다. 이는 놀라운 일이 아닙니다. 이 기술은 90년대 후반부터 멀티플레이어 FPS 제작에 적극적으로 사용되어 왔기 때문입니다. 예를 들어, 이를 가장 먼저 도입한 모드 중 하나인 QuakeWorld 모드를 떠올려 보세요.

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

이 글에서 제가 말하고자 하는 것은 이미 천 번이나 쓰여진 내용을 반복하는 것이 아니라, 기술 스택과 핵심 게임플레이의 특성을 고려하여 게임에 지연 보상을 어떻게 구현했는지 설명하려는 것입니다.

당사의 핵심과 기술에 대해 간단히 설명하겠습니다.

다이노 스쿼드는 온라인 모바일 PvP 슈팅 게임입니다. 플레이어는 다양한 무기를 장착한 공룡을 조종하고 6대 6 팀으로 전투를 벌입니다.

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

지연 보상에 대해 처음 들어보셨다면, 이 문제에 대한 간략한 소개는 다음과 같습니다.

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

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

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

여기서 미묘한 차이를 이해하는 것이 중요합니다. 클라이언트는 항상 마지막 입력을 기반으로 자신을 그리고, 적군은 네트워크 지연을 적용하여 서버에서 받은 데이터의 이전 상태를 기반으로 그립니다. 즉, 적을 공격할 때 플레이어는 자신과 상대적인 과거를 보게 됩니다. 클라이언트 예측에 대한 자세한 내용 우리는 이전에 썼다.

따라서 클라이언트 예측은 하나의 문제를 해결하지만 또 다른 문제를 야기합니다. 플레이어가 과거에 적이 있던 지점을 향해 총을 쏘면 서버에서 같은 지점을 향해 총을 쏘면 적이 더 이상 그 자리에 없을 수 있습니다. 서버 지연 보상은 이 문제를 해결하려고 시도합니다. 무기가 발사되면 서버는 발사 당시 플레이어가 로컬에서 본 게임 상태를 복원하고 실제로 적을 맞히는 것이 가능했는지 확인합니다. 대답이 "예"인 경우, 적이 더 이상 서버상에 없더라도 타격이 계산됩니다.

이러한 지식을 바탕으로 우리는 Dino Squad에 서버 측 지연 보상을 구현하기 시작했습니다. 우선, 클라이언트가 본 내용을 서버에 복원하는 방법을 이해하는 것이 필요했습니다. 그리고 정확히 무엇을 복원해야 할까요? 우리 게임에서는 무기와 능력의 적중률이 레이캐스트와 오버랩을 통해 계산됩니다. 즉, 적의 물리적 충돌체와의 상호 작용을 통해 계산됩니다. 따라서 플레이어가 로컬에서 "본" 이러한 충돌체의 위치를 ​​서버에서 재현해야 했습니다. 당시 우리는 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;
     }
}

이 기계를 사용하여 샷과 능력의 지연을 보완하는 방법은 아직 알려지지 않았습니다.

가장 간단한 경우, 즉 메커니즘이 단일 히트스캔 기반으로 구축되면 모든 것이 명확해 보입니다. 플레이어가 총을 쏘기 전에 물리적 세계를 원하는 상태로 되돌려야 하고, 레이캐스트를 만들어야 하며, 명중 또는 미스를 계산해야 하고, 세계를 초기 상태로 되돌려야 합니다.

하지만 다이노 스쿼드에서는 이런 메커니즘이 거의 없습니다! 게임에 나오는 대부분의 무기는 발사체를 생성합니다. 발사체는 여러 시뮬레이션 틱(어떤 경우에는 수십 틱) 동안 날아가는 장수명 총알입니다. 이걸 어떻게 해야 할까? 몇 시에 비행기를 타야 할까?

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

우리에게는 이런 옵션이 없었습니다. 투사체 기반 무기는 게임 디자인의 핵심 특징이었거든요. 그래서 우리는 뭔가를 생각해내야 했습니다. 여러 가지 브레인스토밍을 한 후, 우리는 실행 가능한 것으로 보이는 두 가지 옵션을 생각해냈습니다.

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

그림에서 틱 30의 플레이어는 예상에 따라 미사일을 발사합니다. 그는 적이 달려가는 방향을 보고 미사일의 대략적인 속도를 알고 있습니다. 로컬적으로 그는 틱 33에서 목표를 달성했다는 것을 확인합니다. 지연 보상 덕분에 서버에도 도달할 것입니다.

2. 첫 번째 옵션과 동일한 작업을 수행하지만 총알 시뮬레이션의 한 틱을 계산한 후에는 멈추지 않고 같은 서버 틱 내에서 총알 비행 시뮬레이션을 계속합니다. 시뮬레이션할 때마다 총알 시간을 서버 시간에 한 틱씩 더 가깝게 만들고 충돌체의 위치를 ​​업데이트합니다. 우리는 다음 두 가지 중 하나가 일어날 때까지 이 작업을 반복합니다.

• 총알의 수명이 만료되었습니다. 이는 계산이 끝났다는 것을 의미하며, 우리는 맞은 것과 틀린 것을 셀 수 있습니다. 그리고 이는 총이 발사된 시점과 같은 시점에 일어났습니다! 우리에게는 이것이 장점이기도 하고 단점이기도 했습니다. 장점 - 사격하는 플레이어의 경우 적의 체력이 감소하는 순간까지 걸리는 시간이 크게 줄어들기 때문입니다. 마이너스 - 적이 플레이어에게 총을 쏘았을 때도 같은 효과가 관찰되었습니다. 적은 느린 로켓을 쏘았을 뿐이지만, 데미지는 이미 계산되었습니다.
• 총알이 서버 시간에 도달했습니다. 이 경우, 지연 보상 없이 다음 서버 틱에서 시뮬레이션이 계속됩니다. 느린 발사체의 경우 이론적으로 첫 번째 옵션에 비해 물리적 롤백 횟수를 줄일 수 있습니다. 동시에 시뮬레이션 부하의 불균형도 커졌습니다. 서버가 유휴 상태이거나, 한 서버 틱에서 여러 총알에 대한 10틱의 시뮬레이션을 계산했습니다.

이전 그림과 동일한 시나리오이지만, 두 번째 방식에 따라 계산되었습니다. 미사일은 발사된 순간과 같은 틱에서 서버 시간을 "따라잡았고", 다음 틱부터 명중이 계산될 수 있습니다. 31번째 틱에서는 ​​이 경우 지연 보상이 더 이상 적용되지 않습니다.

우리가 구현한 방식에서는 이 두 가지 접근 방식이 문자 그대로 몇 줄의 코드 차이로 달랐기 때문에 둘 다 작성했고, 오랫동안 이 둘은 병행해서 사용되었습니다. 무기의 메커니즘과 총알 속도에 따라 우리는 각 공룡에 대해 하나 또는 여러 개의 옵션을 선택했습니다. 여기서 전환점은 "적을 특정 시간 동안 특정 횟수만큼 공격하면 특정 보너스를 얻는다"와 같은 게임 메커니즘을 도입한 것입니다. 플레이어가 적을 공격하는 타이밍이 중요한 모든 메커니즘은 두 번째 접근 방식과 잘 어울리지 않았습니다. 결국 우리는 첫 번째 옵션을 선택했고, 이제 이 옵션은 게임 내 모든 무기와 모든 능동 능력에 적용됩니다.

생산성 문제는 별도로 제기할 가치가 있습니다. 만약 이 모든 것이 속도를 늦출 것이라고 생각했다면, 나는 이렇게 답할 것이다. 사실은 바로 그것이다. 유니티는 움직이는 콜라이더를 사용하는데, 이를 켜고 끄는 속도가 매우 느립니다. 다이노 스쿼드에서는 최악의 경우 수백 개의 투사체가 동시에 전투에 참여할 수도 있습니다. 각 발사체를 개별적으로 세기 위해 충돌기를 옮기는 것은 감당할 수 없는 사치입니다. 그러므로 물리적 롤백의 횟수를 최소화하는 것이 절대적으로 필요했습니다. 이러한 목적을 위해 우리는 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. 지연 보상이 수행되는 플레이어의 충돌체를 어떻게 처리할지 결정합니다. 이상적으로는, 플레이어의 위치가 과거로 이동하지 않아야 합니다. 플레이어는 현재 서버에 있는 시간과 동일한 시간을 볼 수 있어야 합니다. 하지만 우리는 사격하는 플레이어의 충돌체도 롤백하는데, 여기에는 몇 가지 이유가 있습니다.

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

두 번째로, 모든 레이캐스트와 오버랩에서 우리는 항상 능력이나 발사체를 소유한 플레이어의 충돌체를 제외합니다. 다이노 스쿼드에서 플레이어는 슈팅 게임의 기준으로 보면 상당히 특이한 기하학적 구조를 가진 공룡을 조종합니다. 플레이어가 특이한 각도로 총을 쏘고 총알의 궤적이 플레이어의 공룡 충돌기를 통과하더라도 총알은 이를 무시합니다.

셋째, 지연 보상이 시작되기 전에도 ECS에서 얻은 데이터를 바탕으로 공룡 무기의 위치나 능력을 사용하는 시점을 계산합니다.

결과적으로 지연이 보정된 플레이어의 콜라이더의 실제 위치는 우리에게 중요하지 않으므로, 우리는 더 생산적이고 동시에 더 간단한 길을 택했습니다.

네트워크 지연은 간단히 제거할 수 없으며, 마스크로만 가릴 수 있습니다. 다른 마스킹 방법과 마찬가지로 서버 지연 보상에도 단점이 있습니다. 총을 맞는 플레이어의 게임 플레이 경험은 향상되지만, 총을 맞는 플레이어의 게임 플레이 경험은 저하됩니다. 하지만 디노 스쿼드의 경우 선택은 명확했습니다.

물론, 이 모든 것은 프로그래머와 게임 디자이너 모두에게 서버 코드의 복잡성이 증가하는 결과를 가져왔습니다. 이전 시뮬레이션이 시스템의 단순한 순차적 호출이었다면, 지연 보상을 통해 중첩 루프와 분기가 나타났습니다. 또한 우리는 작업하기 쉽게 만들기 위해 많은 노력을 기울였습니다.

2019 버전(아니면 조금 더 이전 버전)에서 Unity는 독립적인 물리적 장면에 대한 완전한 지원을 받게 되었습니다. 우리는 가능한 한 빨리 모든 객실의 공통된 물리적 세계를 없애고 싶었기 때문에 업데이트 직후에 서버에 이를 구현했습니다.

각 게임방에 고유한 물리 장면을 제공함으로써 시뮬레이션을 계산하기 전에 주변 방의 데이터에서 장면을 "정리"할 필요성을 없앴습니다. 첫째, 생산성이 크게 향상되었습니다. 두 번째로, 프로그래머가 새로운 게임 요소를 추가할 때 장면 정리 코드에서 실수를 하면 발생할 수 있는 다양한 버그를 제거할 수 있었습니다. 이러한 버그는 디버깅하기 어려웠고, 종종 한 방의 장면에 있는 물리적 객체의 상태가 다른 방으로 "흘러들어가는" 현상이 발생했습니다.

또한, 우리는 물리적 장면을 사용하여 물리적 세계의 역사를 저장할 수 있는지에 대한 연구도 수행했습니다. 즉, 조건부로 각 방에 하나의 장면이 아닌 30개의 장면을 할당하고 이를 순환 버퍼로 만들어서 기록을 저장한다는 의미입니다. 전반적으로 이 옵션은 효과적인 것으로 나타났지만, 우리는 이를 구현하지 않기로 결정했습니다. 생산성이 엄청나게 증가하지는 않았지만, 오히려 위험한 변화가 필요했기 때문입니다. 이렇게 많은 장면을 오랫동안 작업하다 보면 서버가 어떻게 동작할지 예측하기 어렵습니다. 그래서 우리는 다음 규칙을 따랐습니다.파산하지 않았다면 고치지 마라.".

출처 : habr.com