네트웍 동기화 개론과 고급 동기화 기법

네트웍 동기화 개론과 고급 동기화 기법 D² 김주복 | 2019.04.26

네트웍 동기화 이론 게임에서 활용되는 기본적인 네트워크 동기화 이론을 살펴보자

네트웍 동기화 이론 실시간 게임의 동기화 방식은 크게 다음의 세 가지다 • 결정론적 락스텝 • 스냅샷 보간 • 스테이트 동기화 참고 Fast-Paced Multiplayer, Gabriel Gambetta Introduction to Networked Physics, Glenn Fiedler

결정론적 락스텝 실행이 완전히 동일한 (결정론적) 로직을 바탕으로 입력만 동기화 클라이언트들이 입력을 보내면 서버가 입력을 모아서 클라이언트들에게 전송하고 각자 동일한 시뮬레이션을 진행한다

특징 많은 캐릭터와 복잡한 로직을 간단하게 동기화할 수 있다 입력 조작과 프레임 진행만 동기화하면 게임 로직이 동기화된 상태로 진행된다 레이턴시가 큰 참여자가 있을 때 스톨이 발생 매 프레임 모든 클라이언트의 입력을 받아야 프레임 업데이트가 가능하기 때문 결정론적으로 로직을 작성하는 것이 매우 어려움 특히 부동소수점의 처리는 하드웨어마다 매우 다르고, 옵션을 통해서 일치시키면 성능이 대폭 떨어지는 경우가 많음 참가자 수가 적은 RTS에서 사용 (10명 이내) 참가자 수가 늘어날 수록 입력 패킷 도달 지연이 발생할 가능성이 크게 높아지기 때문

스냅샷 동기화 클라이언트가 입력을 보내면 서버가 월드를 시뮬레이션해서 스냅샷을 배포 클라이언트들이 입력을 보내면 서버는 시뮬레이션을 진행한 후 스냅샷을 배포하면 클라이언트들은 각자 자기 월드에 스냅샷을 적용한다

특징 참가자의 레이턴시에 의존하지 않는 시뮬레이션 입력이 제때 도달하지 않으면 해당 클라이언트의 입력은 다음에 처리, 스톨되지 않음 씬의 복잡도가 높아지면 대역폭 부담이 큼 항상 모든 객체의 상태를 동기화하기 때문에 객체가 늘어나면 상태 스냅샷 패킷도 커진다 패킷 드롭을 가정하면 발송 빈도를 높여야 하는데, 그러면 스냅샷 구축 부담도 같이 커진다 참가자 수가 적은 FPS에서 사용

상태 동기화 스냅샷 동기화와 거의 동일하지만 변화가 큰 객체의 동기화를 우선 클라이언트들이 입력을 보내면 서버는 시뮬레이션을 진행한 후 수신자별로 우선순위가 높은 변경점을 우선해서 발송

특징 동기화에 필요한 대역폭을 적절하게 관리 가능 우선순위를 통해서 대역폭을 관리 가능 각 클라이언트에 다른 시야를 제공하는 것도 자연스러움 각 클라이언트가 전달 받은 업데이트를 트래킹하기 때문에 시야 제한을 적용하는 것도 추가 부담이 거의 없음 상대적으로 참가자 수가 많은 FPS에서 사용 (100명 이내)

??? 우리가 아는 방식이랑 다른데? MMORPG에서 주로 사용하는 방식은 이벤트 기반 동기화 • 게임의 완전한 시뮬레이션은 클라이언트에서만 수행 • 클라이언트는 주요 행동에 대해서 서버에 허가를 요청 • 서버는 상대적으로 단순화된 게임 로직을 요청 시에만 실행해서 검증

왜 이렇게 다르지? 요구사항의 차이가 가장 크다 결정론적 락스텝 등장하는 캐릭터 수가 가장 중요 난이도 높은 결정론적 구현을 수반 (동시 접속자 O(10)) 상태 동기화 캐릭터의 위치와 움직임이 가장 중요 많은 수의 동시 접속자를 포기 (동시 접속자 O(100)) 이벤트 기반 동기화 동시 접속자의 숫자가 가장 중요 정교한 액션의 동기화를 희생 (동시 접속자 O(1000))

스테이트 복제 vs 이벤트 복제 스테이트(값) 복제 결과를 일치시키기 어려운 데이터를 복제해서 느슨하게 동기화하는 것이 핵심 캐릭터의 이동, 파라메터 변경 같이 변화를 예측할 수 없는 데이터에 적용 이벤트 복제 MMORPG나 결정론적 락스텝 모델에서 대역폭을 줄일 수 있는 비결 애니메이션, 이펙트, 사운드 등 대체적으로 시작/끝만 맞추면 되는 데이터에 적용 DOT(Damage-over-Time)? 생각해 볼 만한 문제

고급 동기화 기법 싱글 플레이 AAA 게임의 느낌을 온라인에서도

상태 동기화를 가정 액션성이 높은 게임 로직을 동기화하는 데 최선 특히 물리 동기화까지 지원하려면 선택의 여지가 별로 없음

목록 선실행, 롤백, 재실행 엔티티 보간 랙 보상 서버 주도 선판정, 이슈 큐잉 애니메이션 생략, 입력 딜레이 위치 에러 디졸빙 (쇼브, 발사체)

만악의 근원, 레이턴시 모든 고급 동기화 기법은 레이턴시를 숨기기 위한 것이다 단순한 자동 동기화로는 핑만큼 반응이 느리게 발생하기 때문에 반응성이 떨어진다 라이엇 게임즈는 심지어 자체 망까지 구축하기도… ISP들에 협조를 요청했는데 거절 당해서 그랬다고… FIXING THE INTERNET FOR REAL TIME APPLICATIONS: PART II

선실행 (Prediction) 서버의 응답을 미리 예상해서 클라이언트가 먼저 실행 많은 게임에서 이동은 누르는 즉시 서버의 응답을 기다리지 않고 캐릭터가 움직이는 경우가 많은데 이것이 선실행이다 A) 서버 응답을 대기하는 예 B) 서버 응답을 대기하지 않고 선실행하는 예

선실행의 문제점 선실행은 서버 응답과 충돌할 수 있다 클라이언트에서 10→11→12로 이동을 선실행한 뒤에 서버로부터 11, 12로의 이동을 승인 받으면 클라이언트에 보이는 위치는 10→11→12→11→12로 튀게 된다 p = (11,10)

롤백/재실행 (Rollback/Reconciliation) 선실행 충돌을 해소하려면 요청을 기록하고 응답과 대조해야 한다 10→11→12로 이동을 선실행할 때 11로의 이동과 12로의 이동을 모두 큐잉한 다음 서버로부터 11로의 이동에 응답이 오면 10으로 롤백한 다음 서버의 응답을 적용하고 12로의 이동을 다시 선실행한다 최종 결과는 아래와 같이 튐 문제가 사라진다 10→11→12(→10→11→12)(→11→12)

리모트 클라이언트 시점의 문제 다른 클라이언트가 주도해서 움직이는 객체의 업데이트는 부정기적이다 서버 업데이트율에 따라 끊겨 보이게 되고, 특히나 패킷이 제때 도달하지 않으면 움직임이 더욱 끊기게 된다 Sudden Jump Sudden Jump

엔티티 보간 (Entity Interpolation) 버퍼링을 통해서 해결한다 서버로부터 받는 응답을 몇 프레임 정도 버퍼링하고, 화면에는 버퍼의 오래된 두 프레임 사이의 정보를 보간해서 렌더링한다 동영상 재생 등에 사용하는 지터 버퍼 플레이 아웃 알고리즘과 동일하다 60프레임에 100ms 정도를 사용 2~5% 패킷 드랍율을 가정하고 2연속 드랍 시에 멈추지 않는 버퍼 소스 엔진도 기본 100ms를 가정 (cl_interp 0.1) 이전 두 서버 응답을 보간해서 사용한다

엔티티 보간의 문제 모든 플레이어는 항상 다른 플레이어의 과거 모습을 보게 된다 정확하게는 (서버 → 클라이언트 레이턴시) + (플레이 아웃 버퍼링 시간)만큼 과거 서버에서 인식하는 상대방의 위치 엔티티 인터폴레이션으로 인해 내가 보는 상대방의 위치 상대방이 스스로 인식하는 자신의 위치

랙 보상 (Lag Compesation) 서버가 히트 판정 시 타겟을 과거로 돌려서 판정하는 기능 엔티티 보간 버퍼 시간 + 클라이언트-서버 레이턴시 만큼 엔티티를 되감아서 피격 판정을 수행한다 서버에서 인식하는 상대방의 위치 레이턴시를 고려했을 때, 클라이언트가 인식하는 상대방의 위치 (여기서 판정 처리)

맞은 사람한테 불공정하지 않나? 실제로 그렇지만 잘 인식하기 어려움 FPS의 피격은 거의 행동을 멈추지 않기 때문에 즉각적인 불쾌감이 덜함 공격자가 멀리 있기 때문에 조준이 정확한지 알기 어려움 죽으면 킬캠을 통해 공격자 시점의 조준을 보여주기 때문에 납득하게 됨 게임 디자인 상의 선택 최대한 싱글 플레이 게임처럼 반응성이 좋게 느껴지게 하는 것 단, 되감는 한도를 제한할 필요는 있음 최대 100~200ms 가량 FPS 게임 레딧마다 랙 보상의 불공정함을 토로하는 글이 넘쳐남

근접 공격의 문제 히트 프레임에 피격 리액션이 정확히 맞물려야 타격감이 연출 하지만 서버가 히트 프레임에 맞춰 타격 결과를 보내면 레이턴시 때문에 거의 항상 피격 리액션이 늦게 나오게 됨

서버 주도 선판정 및 이슈 큐잉 서버가 히트 프레임 도달 전에 판정 결과를 클라이언트에 통지 각 클라이언트는 결과를 히트 프레임까지 대기했다가 실행 M2:아레나에서 사용한 기술 M2: 아레나에서는 50ms 정도 앞서 클라이언트가 히트 요청을 발송 히트 프레임보다 빠른 시점에 서버가 피격 판정을 수행 피격 리액션을 시작

맞은 사람한테 불공정하지 않나? (2) 실제로 그렇다, 문제는… 근접 공격은 대체로 행동을 정지시켜서 불쾌감이 크다 FPS와 달리 공격자 위치가 매우 가깝기 때문에 맞을 지 빗나갈 지 예상이 가능하다 0.1~0.2초 사이의 짧은 시간에도 30cm 이상 움직일 수 있다 불공정하게 느낄 수 있는 가능성이 매우 큼

공격자가 인지하는 히트 서버가 인지하는 히트 피격자가 인지하는 히트

A가 인지하는 히트 프레임 B가 인지하는 히트 프레임 락이 히트 프레임부터 걸린다고 하면 이후의 공격에도 불공정하게 노출됨

애니메이션 생략 서버와 리모트 클라이언트에서는 공격 애니메이션을 레이턴시만큼 생략 1.1~1.2배 이내로 재생 속도를 높여서 갭을 줄이고, 그걸로도 불가능하면 아예 모션을 생략하고 시작한다 NPC의 공격은 루핑되는 전조 동작을 항상 포함한다 (동기화된 시계를 바탕으로 공격을 시작해서 레이턴시를 숨김) 레이턴시만큼 모션을 생략 레이턴시만큼 모션을 생략

입력 딜레이 근접 공격이 예상되는 경우, 선실행에 딜레이를 준다 서버에 요청은 바로 발송하고, 대신 칼 휘두르는 사운드 등으로 피드백을 바로 발생시킨다 결정론적 락스텝 혹은 격투 게임에서 많이 사용하는 방식 50ms~100ms 이내에서 거슬리지 않는 최대치를 적용한다

위치 갭 줄이기 이동 중인 적을 공격했을 때 리액션이 불쾌할 수 있다

A 기준으로 피격 위치를 정하면 B 입장에서는 뒤로 끌려가는 게 불쾌하다 B 기준으로 피격 위치를 정하면 A 입장에서는 맞은 위치가 의아하다

쇼브를 이용한 조정 행동 정지를 일으키는 히트에 수반되는 쇼브를 활용 쇼브 = 피격 시 약간씩 밀려나는 동작 피격 시점에서는 A도 B도 각자 보는 위치에서 피격 동작을 시작한다 대신 쇼브 목적지를 서버 기준과 B 기준의 중간 위치로 정해서 최종적으로 동기화시킨다

발사체의 위치 갭 조정 발사체의 경우, 서버-클라이언트 사이에 위치 갭이 지속적으로 발생한다

에러 숨기기 여러 프레임에 걸쳐 서버-클라이언트 사이의 오차를 숨긴다 이러면 레이턴시 때문에 로켓이 늦게 닿는 것처럼 보이는 문제를 숨길 수 있다 로켓 등의 피격 판정도 근접 공격처럼 선판정-이슈 큐잉을 도입할 수 있는 여지가 있다 이 사례는 애니메이션 생략에 가깝지만 you get the point https://twitter.com/PicoTanks/status/1097623864966819840

다시 한 번, 목록 선실행, 롤백, 재실행 엔티티 보간 랙 보상 서버 주도 선판정, 이슈 큐잉 애니메이션 생략, 입력 딜레이 위치 에러 디졸빙 (쇼브, 발사체)

네트웍 동기화 개론과 고급 동기화 기법

Slide 1

Slide 2

Slide 3

Slide 4

Slide 5

Slide 6

Slide 7

Slide 8

Slide 9

Slide 10

Slide 11

Slide 12

Slide 13

Slide 14

Slide 15

Slide 16

Slide 17

Slide 18

Slide 19

Slide 20

Slide 21

Slide 22

Slide 23

Slide 24

Slide 25

Slide 26

Slide 27

Slide 28

Slide 29

Slide 30

Slide 31

Slide 32

Slide 33

Slide 34

Slide 35

Slide 36

Slide 37

Slide 38

Slide 39

Slide 40

Slide 41