This document is about: FUSION 2

SWITCH TO

FUSION 2 SHARED FUSION 1 FUSION 2

타임프레임과 시간

멀티플레이어 게임에서의 시간

네트워킹의 시간은 종종 혼란스럽고 정확히 파악하기 매우 어려울 수 있습니다. "실제" 시간은 거의 없고, 오히려 상대적인 시간과 그로 인한 시간 역설은 게임 제작자가 해결하거나 숨기는 방법을 결정해야 합니다.

매우 복잡한 온라인 멀티플레이어 게임의 주요 측면은 네트워크 지연 시간입니다. 피어는 다른 피어의 과거에 대해서만 알 수 있습니다.

이 지연 시간 때문에 두 가지 기본 타임프레임이 존재합니다:

원격 타임프레임
로컬 타임프레임

원격 타임프레임

원격 타임프레임은 서버에서 클라이언트에 도착한 틱(그리고 관련 객체 상태)을 설명합니다. 이 타임프레임은 가장 최근에 확인된 과거입니다.

이 타임프레임은 클라이언트에만 존재하며 특정 "시간" 자체가 아니라 최근 확인된 서버 상태에 대한 보다 일반적인 설명입니다.

노트: 서버에 원격 타임프레임이 없습니다. 유일한 서버 타임프레임은 로컬입니다.

로컬 타임프레임

로컬 타임프레임은 모든 시뮬레이션이 완료된 후(해당하는 경우 재시뮬레이션 및 예측 포함) 로컬에 존재하는 객체의 상태를 설명합니다. 클라이언트에서는 이를 예측 상태라고도 합니다. 서버/호스트에는 이 타임프레임이 유일하게 존재합니다.

서버가 관련 틱을 시뮬레이션하기 전에 클라이언트가 서버에 입력(서버 모드용) 및 상태(공유 모드용)를 제공하려면 클라이언트가 서버보다 먼저 존재해야 합니다. 따라서 클라이언트의 로컬 타임프레임은 항상 원격 타임프레임보다 앞서 있습니다.

순방향 시뮬레이션 후 존재하는 네트워크 객체의 상태입니다. 이 타임프레임은 객체가 시뮬레이션의 일부일 경우에만 존재합니다(Object.IsInSimulation == true).

원격/로컬 불일치 숨기기

클라이언트는 이러한 타임프레임 간의 차이를 숨기기 위한 두 가지 주요 메커니즘을 가지고 있으며, 다음과 같은 패러독스가 생성됩니다:

예측: 모든 객체는 로컬 타임프레임(예측)으로 외삽 됩니다. 이렇게 하면 모든 네트워크 객체는 항상 해당 틱(서버의 틱)에 대해 대략적인 상태가 됩니다. 불가피한 오류는 조정 및 재시뮬레이션을 통해 지속적으로 수정됩니다. 예측에 대한 자세한 내용은 여기에서 확인할 수 있습니다.
지연 보상: Fusion에는 여러 기간 동안 쿼리(레이캐스트 등)를 사용할 수 있는 지연 보상 시스템이 내장되어 있습니다. 지연 보상을 통해 플레이어는 원격 타임프레임에 있는 객체와 상호 작용할 수 있으며, 이러한 쿼리를 플레이할 때 서버에 의존하여 원격 타임프레임의 클라이언트 렌더링 객체를 설명합니다. 그러면 서버가 플레이어 입력을 시뮬레이션할 때 과거에 대해 쿼리를 수행하여 플레이어가 당시 세상을 어떻게 보았는지 설명합니다. Fusion의 지연 보상 시스템에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

시간문제 예제: 테니스

우리가 해결하고 있는 시간 역설의 간단한 예로는 두 명의 테니스 선수가 있습니다.

플레이어 1이 상대방에게 공을 치는 것입니다. 공이 상대방에게 닿는 것을 볼 수 있지만, 상대방이 100밀리초 동안은 알 수 없습니다:

스윙해서 공을 뒤로 치거나, 아니면
스윙과 미스, 또는
스윙도 하지 않았습니다

플레이어 1은 무엇을 보여주나요?

여기서 상대를 정확하게 예측할 수는 없습니다. 왜냐하면 그들의 가능한 모든 행동은 극도로 다른 결과를 낳기 때문입니다. 하지만 우리는 너무 늦기 전까지는 공에 대한 그들의 반응을 알 수 없을 것입니다.

이 예에서는 공유 모드에서 이 문제를 해결하기가 더욱 어렵기 때문에 서버/클라이언트 모드 및 공유 모드가 아닌 경우를 가정합니다.

해결 방법 1: 예측하지 않음

이 처리는 가장 쉽지만 최악의 사용자 경험을 제공합니다. 이 경우 모든 객체는 원격 타임프레임(입력 권한(로컬 플레이어 객체)를 포함하여 원격 타임프레임에 표시됩니다.

객체	예측	렌더링
로컬 플레이어	없음	리포트 타임프레임
공	없음	리포트 타임프레임
상대	없음	리포트 타임프레임

플레이어는 서버에 입력을 전송하지만 서버 상태가 변경된 후에만 로컬로 이동합니다. 그러면 모든 클라이언트에서 100% 정확하고 일관된 결과가 생성되지만 호스트를 제외한 모든 플레이어는 허용할 수 없는 입력 지연 시간이 생성됩니다.

노트: 게임 역학으로 입력 지연 시간을 가릴 수 있는 기능에 맞게 변형된 것들이 있습니다. 예를 들어, 실제 스트로크가 발생하기 150ms 전에 플레이어가 스윙을 시작해야 하는 스윙에 와인드업이 필요할 수 있습니다. 플레이어의 스윙 입력은 즉시 서버로 전송되고, 스윙이 로컬 플레이어에서 실행될 때쯤 서버에서 확인된 히트가 도착할 것입니다. RTT는 가변적이고 일부 사용자 정의 예측 및 수정이 사용될 가능성이 높기 때문에 이는 사소한 해결책이 아니라는 점에 유의해야 합니다

해결 방법 2: 전체 예측

이전 해결 방법과 반대로, 여기서는 모든 것을 예측하려고 시도합니다. 예측에 대한 자세한 여기에서 보실 수 있습니다.

예측의 이점은 플레이어가 입력에서 즉각적인 결과를 얻고 모든 물체는 여전히 동일한 시간대에 있으므로 시간이 일치된다는 것입니다. 그러나 우리는 이 방정식에서 정확하게 예측할 수 없는 매우 중요한 부분을 가지고 있는데, 바로 상대의 입력입니다.

객체	예측	렌더링
로컬 플레이어	있음	로컬 타임프레임
공	있음	로컬 타임프레임
상대	있음	로컬 타임프레임

로컬 플레이어는 대부분의 측면을 정확하게 예측할 수 있지만(정확한 입력을 알고 있음), 여전히 상대의 행동을 정확하게 예측할 수 없으며, 결과적으로 공이 다른 플레이어에게 도달하면 정확하게 예측할 수 없습니다. 이 문제를 해결하기 위해 전체 예측을 사용하는 결과는 공과 상대의 위치를 상당히 극단적으로 수정하는 것이며, 이는 이상적이지 않습니다.

해결 방법 3: 지연 보상

이는 이 역설을 처리하기 위한 최초의 혼합 시간 접근 방식으로 이어집니다. 이 경우 상대방과 공은 예측 오류 문제를 피하기 위해 원격 시간대에 유지되지만 로컬 플레이어는 로컬 타임프레임에 유지됩니다. 그러나 이러한 시간의 혼합은 로컬 플레이어가 서버 또는 다른 클라이언트 세계와 일치하지 않는 현재 틱의 세계를 보고 있음을 의미합니다. 지연 보상을 통해 플레이어는 마치 로컬 시간대에 있는 것처럼 쿼리(레이캐스트 등)를 사용하여 원격 시간대의 객체 히트 박스와 상호 작용할 수 있습니다. 서버는 각 틱을 시뮬레이션할 때 히트 박스 상태를 쿼리가 만들어질 때 플레이어가 어떻게 보았는지 다시 감음으로써 이를 설명할 수 있습니다.

Fusion의 지연 보상 시스템에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

객체	예측	렌더링
로컬 플레이어	있음	로컬 타임프레임
공	없음	리모트 타임프레임
상대	없음	리모트 타임프레임

이것이 만드는 문제는 로컬 플레이어가 공을 치려고 할 때 로컬 플레이어가 현재 서버의 위치가 아닌 공과 상호 작용하고 있다는 것입니다. 따라서 로컬 플레이어에 대한 예측은 플레이어가 공을 치는 결과를 낳을 것입니다. 그러나 해당 플레이어가 스윙한 곳에 틱이 도착하면 서버는 공이 플레이어를 한참 지난 것으로 볼 것입니다. 서버는 이미 미스를 시뮬레이션했고 그 미스 후 틱을 플레이어를 훨씬 지난 모든 클라이언트에게 보냈습니다.

시차 보상을 통해 서버는 볼 히트 박스를 스윙할 때 플레이어가 본 곳으로 되감고, 플레이어가 실제로 공을 쳤다면 지금의 위치로 과감하게 수정할 수 있습니다. 하지만 그렇게 하면 공에 대한 방대하고 거슬리는 수정이 생성될 것입니다. 따라서 시차 보상은 여기에 도움이 되지 않습니다.

해결 방법 4: 타임프레임 이동

이는 이 역설을 처리하기 위한 두 번째 혼합 시간 접근 방식으로 이어집니다. 이 경우 상대방은 예측 오류 문제를 피하기 위해 원격 시간대에 유지되고 로컬 플레이어는 로컬 시간대에 유지됩니다. 공은 로컬 시간대에 예측되지만 로컬 및 원격 시간대의 혼합으로 렌더링 됩니다. 공이 로컬 플레이어 근처에 있을 때 예측된 위치를 표시하면서 로컬 시간대에 렌더링 됩니다. 공이 상대방 근처에 있을 때는 원격 시간대에 렌더링 됩니다. 둘 사이를 이동하면 한 시간대에서 다음 시간대로 이동합니다.

객체	예측	렌더링
로컬 플레이어	있음	로컬
공	있음	거리 기반의 변수
상대	없음	원격

볼은 예측되므로 스윙할 시간이 되면 로컬 플레이어의 틱에 맞는 위치에 있게 됩니다. 공의 예측은 잘못된 것입니다. (예측은 상대가 오래된 위치에 있고 스윙에 실패할 것입니다.) 하지만 공이 이 예측을 렌더링 하지 않기 때문에(원격 시간대에 볼을 렌더링 하는 것입니다.) 모든 누락된 예측은 플레이어가 볼 수 없습니다.

이 경우 공이 실제 공의 속도보다 느린 속도로 상대방을 향해 이동하는 것처럼 보이고, 렌더 시간 이동으로 인해 공이 증가된 겉보기 속도로 플레이어에게 도달하는 것이 결과적인 아티팩트입니다.

시뮬레이션 vs 렌더링

시뮬레이션과 렌더링의 차이를 이해하기 위한 또 다른 중요한 시간 개념입니다.

시뮬레이션: Fusion은 일정한 간격(Runner.DeltaTime, 즉 1f / 1f / TickRate)으로 시뮬레이션에 참여하는 모든 네트워크 동작을 FixedUpdateNetwork()로 호출합니다. 시뮬레이션 후 모든 네트워크 동작의 상태를 캡처하여 이를 스냅샷이라고 합니다. 이러한 스냅샷은 키프레임이라고 생각할 수 있습니다.
렌더링: 유니티의 화면 새로 고침은 시뮬레이션의 간격과 거의 일치하지 않습니다. 특히 이동할 때마다 시뮬레이션의 최신 결과를 사용자에게 제시하면 매우 히치적인 결과가 생성됩니다. 보간은 이전에 시뮬레이션된 두 프레임 사이를 항상 조정함으로써 이 문제를 해결합니다.

로컬 및 원격 타임프레임

멀티플레이어 게임 개발은 주로 지연과 손실로 인한 문제를 해결하는 것입니다. 지연 시간 때문에 진정한 단일 시간은 없습니다. 모든 시간은 상대적이 됩니다. 그리고 이러한 상대적인 시간을 타임프레임이라고 말합니다. 구체적으로 로컬 및 원격 타임프레임:

원격 타임프레임: 이 타임프레임은 클라이언트에만 존재하며 수신된 서버 상태를 나타냅니다. 이 타임프레임은 특정 시간 자체가 아니라 최근 확인된 서버 상태에 대한 보다 일반적인 설명입니다. 참고: 서버에는 원격 타임프레임이 없습니다. 유일한 타임프레임은 로컬입니다.
로컬 타임프레임: 순방향 시뮬레이션 후 존재하는 네트워크 객체의 상태입니다. 이 타임프레임은 객체가 시뮬레이션의 일부일 경우에만 존재합니다(Object.IsInSimulation == true).

최고의 경험을 만들기 위해 플레이어에게 제공할 시간 프레임을 선택하는 것은 게임 개발자에게 달려 있습니다.

네트워킹의 주요 시간 역설은 플레이어에게 입력과 동작에 대한 즉각적인 감각을 제공해야 하는 요구에서 비롯됩니다. 플레이어가 버튼을 누르거나 조이스틱을 움직이면 그 기대는 즉각적인 반응입니다.

기본적인 서버 클라이언트 아키텍처에서 예측이 없으면 플레이어가 키를 누르고 해당 키는 서버로 전송됩니다. 서버는 게임 시뮬레이션의 상태를 변경하여 해당 키에 응답합니다. 그런 다음 모든 플레이어에게 업데이트된 게임 상태를 전송합니다. 이렇게 하면 모든 상태의 플레이어 간에 완벽하게 일치하게 됩니다.

하지만 이는 대부분의 게임에서 허용되지 않는 대량의 입력 지연을 유발합니다. 이에 대응하기 위해 대부분의 네트워킹 아키텍처는 이 지연 시간을 숨기기 위해 예측 또는 지연 보상을 사용합니다.

그러나 네트워킹에는 항상 네트워크 엔티티의 상태에 대한 진실의 근원이 되는 피어(상태 권한)가 하나밖에 없습니다. 그 권한 있는 피어가 로컬 플레이어의 피어가 아니라면 예측을 해야 합니다.

서버 모드 및 타임프레임

서버 및 호스트 모드에서 클라이언트는 예측 가능한 미래에 존재하는 것으로 간주될 수 있으며(해당 로컬 타임프레임), 클라이언트는 과거 틱(리모트 타임프레임)에 대한 서버 스냅샷이 도착한 후에만 객체의 실제 상태를 알 수 있습니다.

플레이어 입력은 기록되고 틱마다 서버로 전송되며, 이러한 입력은 해당 틱의 시뮬레이션에서 서버에 의해 사용됩니다.

서버 클라이언트 모드(서버/호스트/단일)에서 서버는 모든 네트워크 개체에 대한 상태 권한입니다. 따라서 서버는 예측되지 않은 로컬 타임프레임을 가진 유일한 피어이며 실제 현재 존재하는 유일한 피어입니다. FixedUpdateNetwork()에서 서버가 네트워크 객체의 속성에 대해 수행하는 모든 변경 사항은 권한 있으며 최종적입니다.

그러나 클라이언트는 각 틱에 대해 플레이어 입력을 서버에 제공하고 서버가 각 틱을 시뮬레이션하기 전에 먼저 서버에 도착해야 합니다. 서버는 기록을 수정할 수 없으므로 틱에 대한 플레이어 입력이 해당 틱 시뮬레이션에 맞춰 서버에 도달하지 않으면 입력이 손실되고 서버는 이전 입력을 추정하거나 해당 플레이어에 대한 기본 입력 값을 사용해야 합니다.

이러한 이유로 각 Tick에 대한 입력을 수집하고 해당 Tick의 Server 시뮬레이션보다 훨씬 먼저 서버에 전송하기 위해 클라이언트는 미래에 존재 해야 합니다. 클라이언트가 얼마나 앞서 있어야 하는지는 평균 RTT(라운드 트립 타임)의 함수입니다. RTT/Ping이 클수록 필요한 클라이언트 예측 창은 커집니다. 이 예측 창은 서버/클라이언트 게임 네트워킹에서 시간 역설의 주요 원인인데, 이는 클라이언트가 현재 로컬 타임프레임에 대한 실제 상태를 모르기 때문입니다.

~~혼합된 타임프레임의 이 역설을 숨기거나 해결하기 위한 두 가지 전략이 있습니다.~~

모든 개체를 로컬 현재(예측)로 외삽 합니다. 이렇게 하면 모든 네트워크 객체는 항상 서버의 해당 틱에 대해 대략적으로 상태가 됩니다.
지연 보상을 사용하여 여러 기간 동안 상호 작용할 수 있습니다. 지연 보상을 사용하면 플레이어는 원격 타임프레임에 있는 객체와 상호 작용할 수 있으며, 서버를 통해 클라이언트가 시뮬레이션을 실행할 때 이전 네트워크 객체 상태를 확인할 수 있습니다.