[📜일지] [UE4 멀티 FPS 개발일지 #3] 총기 구현 및 네트워킹

[오더리움(othereum)]

총기 매커니즘 자체는 구현하기 쉬운데, 네트워크 동기화 작업이 진짜 빡셌다.

렉을 못느끼도록 클라이언트 예측을 사용하는데, 이게 예측을 잘못했을때 교정해주는 방법을 어떻게 해야할지 한참 고민했음.

처음엔 그냥 property replication 썼는데, 문제는 이게 서버측 프로퍼티 값이 변경되었을 때만 리플리케이션 되는거라, 만약 클라이언트가 예측으로 값을 변경했는데, 서버에서 검증해보니 변경이 불가능하다면 값 변경을 취소해야 하는데, 서버의 값은 안바뀌었으니 리플리케이션으론 알려줄 방법이 없는거임. 결국 클라이언트의 정보는 그대로 잘못된 상태로 남아있게 됨. (물론 이럴 때마다 RPC로 알려주는 방법이 있긴 한데, 불완전했음)

여러가지 방법을 생각해보고 시도해봤지만, 내가 결론 내린 최선의 방법은 아래와 같음.

1. 서버가 owner 클라이언트에게 일정 주기 (일단 0.5초로 해놓음) 마다 'correction data'라는 이름으로 서버의 최신 데이터를 보냄.
2. 이걸 받은 클라이언트는 바로 받은 값으로 업데이트해줄 수도 있겠지만, 그랬다간 내가 예측중인 데이터가 더 최신일 수도 있는데 이걸 버리고 과거로 돌아가게 되는 꼴임. 이해 쉽게 설명하자면, 총을 연사로 갈기고 있다고 생각해보셈. 클라는 예측을 사용하니 일단 1발 까고 보는거임. 그럼 29발인데, 아직 패킷이 서버엔 도착하지 않아서 서버는 30발임. 이때 correction data를 전송하면, 지금 29발인데 30발로 교정하라는 말이 됨. 과거로 돌아가는 거지. 분명히 문제가 있음.
   
3. 그래서 클라이언트 프로퍼티의 값이 변경될 때, 그 시각을 기록해두고, correction data를 받았을 때, 프로퍼티 값이 변경된 지 꽤 오래된 경우에만 교정을 해주는 식으로 했음. 변경된지 오래되었다는 건, 그 시간동안 충분히 서버와 동기화되어, 클라이언트 입장에선 최신 데이터일 확률이 높다고 판단할 수 있는 거임. '오래되었다'의 기준은 RTT(round trip time, 핑)으로 했음.
   

테스트해보니 가장 괜찮은 결과를 보여줘서, 기존의 앉기/엎드리기 관련 교정 코드도 이 방식으로 바꿔줬다. 훨씬 generic하게 처리할 수 있어서 좋았다.

아래는 실제 코드다

이 함수는 매 틱마다 호출됨. 첫 if문은 간단히 말하면 서버에서만 실행하도록 걸러주는 거임

그래서 0.5초마다 클라이언트에게 correction data 보내주는 거고 ㅇㅇ

클라이언트에서 correction data 받아서 실제로 교정해주는 코드임. IsExpired 보면 알다시피 수정 후 지난 시간이 ping 이상이어야만 교정해주는 거고.

344번 줄에서 핑에 4를 곱해주는건 별거 아니고 원래 4로 나눠서 저장되어있어서 다시 곱해준거임.

356번 줄 if문은 총 쏘다가 멈춰서 Idle 상태일 때 Firing으로 교정되면 난 누르지도 않았는데 총 발사되는 현상이 있어서 예외처리 해준거임. 반대로 쏘다가 지맘대로 멈추는 상황도 ㅇㅇ

시발 멀티플레이 게임만 아니었어도 개발 기간 30%로 줄었을거다 ㄹㅇ 아직 게임같지도 않은 수준인데 이렇게 힘든거 보면 앞날이 깜깜하다

3일 연휴를 이렇게 날려버리니까 기분이 참 상쾌해

[익명(220.74)]

님 좀 짱인듯...

[익명(39.123)]

추천 ~~

[익명(14.37)]

인붕이들이랑은 수준이 다른데? ㅋ

[익명(121.183)]

와 잘만드시네요

[익명(223.33)]

총이랑 애니메이션 에셋임?

[오더리움(othereum)]

ㅇㅇ 난 모델링이나 애니메이팅같은건 하나도 할줄몰라서 - dc App

[익명(119.70)]

네트워크는 뭐쓰는거에요?

[오더리움(othereum)]

언리얼 내장 리플리케이션 시스템

[익명(118.128)]

어떤식으로 Fire 하는데? 클라에서 ServerFire 호출하고 서버에서 값 소모해주고 RPC 돌면 보통은 문제 없잖아 서버측 프로퍼티가 안바꼈는데 클라쪽 프로퍼티가 바뀌어서 무결성검사를 하는경우가 왜 생기는거임?

[오더리움(othereum)]

1. 어떤식으로 Fire 하는데?: 발사할 때마다 RPC 호출하면 트래픽 부하 심하고, 연발 총기 RPM 어긋남. 그래서 state machine 기반으로 만들어서 state 변경을 요청하도록 구현했음. 총을 발사하려면 Firing state로 변경하도록 하면 되는거지. 멈추려면 Idle state로 변경하도록 요청하면 되는거고 2. ~~경우가 왜 생기는거임?: 여러가지 있는데, 내가 경험한 문제 하나 말해줄게. 달리면서 재장전을 못하도록 해놨는데, 이게 달리기를 취소한 직후에 재장전을 하면 확률적으로 어긋남. 패킷이 순서대로 도착한다는 보장이 없기 때문에, 클라이언트에서는 달리기 취소 하고 재장전 해서 성공이라고 판단할 수 있지만, 서버는 아직 달리고 있는 걸로 알고 있을 수도 있는거임

[오더리움(othereum)]

실제로는 달리기 멈춘 후에도 0.15초 동안은 달리기/발사/사격모드 변경 등등 다 못하게 되어있는데, 그래서 이런 현상이 더 심함. RTT가 항상 일정한게 아니라서 ㅇㅇ

[오더리움(othereum)]

그 외에도, 캐릭터 위치가 서버와 클라가 항상 조금씩 다르기때문에, 어떤 장애물을 앉아서 지나가다가 빠져나오자마자 일어선다고 할 때, 클라는 빠져나왔다고 보고 성공했어도, 서버는 아직 빠저나오기 직전이라 실패할 수도 있는거지

[익명(118.128)]

Firing State 얘기하는거보면 UT 코드 기반으로 작업하는거 같은데 여기서도 문제가 생기는거임? state 변경시에 생기는 오차같은건 생각안해봤는데 깊게 파니까 별 버그가 다 생기나보네 ㄷㄷ 지금 저렇게 주기별로 업데이트해주는경우는 트래픽 부하는 별로 안심함?? 0.5초에 한번씩인데 이것도 은근히 많이 쓸거같은데

[익명(118.128)]

확실히 고닉이라 댓글이 빨라서 좋네 ㅎㅎㅎ 카페보다 낫다

[오더리움(othereum)]

무기 상태는 4바이트, 캐릭터 무브먼트 상태는 3바이트니까, 초당 14바이트정도네. 거기에 RPC 오버헤드 더하면 좀 더 되려나. 이정도면 사실 기본적인 캐릭터 무브먼트의 상태 리플리케이션이나 유저 입력 동기화같은거에 비하면 되게 적은거라 괜찮다고 판단했음

[오더리움(othereum)]

그리고 교정 RPC는 unreliable로 해서 더 괜찮을듯 ㅇㅇ

[익명(118.128)]

오우야 답변감사감사 개발 힘내 형

[오더리움(othereum)]

[익명(180.230)]

싱글은 튜토리얼이나 정보, 에셋템플릿같은거도 많은데 멀티쪽, 특히 코옵같은 소수가 아니라 MMO같은 다수가되면 더더 정보가 없어서 내가보기엔 싱글만들거 멀티로 만들기 시작하면 개발기간이 본래 걸릴 기간보다 몇배는 더 걸리는거같음 특히 멀티도 슈터는 반응을 잘해줘야해서 더 난이도가 올라가는거같고

[익명(180.230)]

멀티아니면 30퍼센트라고 말하는건 네트워킹쪽도 꽤 지식이 있거나 경험이 있기떄문에 그런것임?

[오더리움(othereum)]

뭐 전에 이미 언리얼로 멀티 TPS겜 만들어서 출시해본 경험 있긴하니까

[익명(180.230)]

아 경험 있으면 초보인 다른 인디개발자에 비해 순식간에 만들겠네 네트워킹,멀티겜만드는 지식은 학원이나 그쪽게임회사에 일하거나 해서 배움? 보통 어떤식으로 알게됨? 유튜브나 구글로 뒤져보기엔 정보가 적어보이던데

[오더리움(othereum)]

걍 학교에서 독학했는뎅

[오더리움(othereum)]

뭐 거의 삽질로 얻은 지식들이지. 가장 도움 된 건 언리얼 소스코드? 오픈소스인 덕분에 모르는거 있으면 걍 소스코드 까서 보면 됨 ㅇㅇ