[📜일지] 네트워크 처음해봄, 클라이언트 예측?

[익명(ppukku999)]

위에가 호스트, 아래가 클라이언트

200ms 딜레이 줬음.

멀티플레이어 게임 프로그래밍 이라는 책 읽다가 직접 뭔가 해보고 싶었음.

Tcp 헤더가 너무 복잡해보이고, Ip 헤더도 복잡해보이고 Tcp로 서로 보낸거 확인받고 이런 과정에 겁 잔뜩 먹었는데,

제공해주는 소켓 클래스에서 Tcp 통신 전체가 구현되어있더라. 그냥 Tcp 프로토콜 설정해주고 Send()만 호출해주면 알아서 보내주는거 보고 ??? 싶었음.

메세지를 보낼 수 있다는걸 알았으니, 간단한건 구현 할 수 있지 않을까 싶어서 시작함.

서버 <-> 클라이언트 구조지만, 플레이어 중 한명이 서버 역할을 하는 구조로 만들어보고 싶었음.

클라이언트쪽에서는 자신의 인풋을 보내고 서버쪽에서는 플레이어의 움직임(포지션 + 이동벡터)을 보내줌.

처음에는 클라이언트쪽에서 이동을 누르면, 서버쪽에서 내 움직임을 보내주고, 내 움직임을 받은 후에야 플레이어가 움직일 수 있었음. 딜레이가 존재했음.

그래서 클라이언트 예측이란걸 적용해봄. 위 동영상이 그거임.

서버에서 답장을 보내주기 전에는 그냥 자신의 인풋으로 이동하다가, 서버에서 확인을 받은 순간에, 서버에서 받은 데이터를 클라이언트에 적용해주는 방식임.

클라이언트는 모든 인풋을 타임스탬프(틱)이랑 함께 기록해둠.

인풋을 서버로 보낼 때, 타임스탬프와 함께 보내줌. 그리고 자신은 인풋에 따라 플레이어를 움직여줌.

서버에서는 받은 타임스탬프를 포함해서 현재 플레이어의 위치를 보내줌.

클라이언트에서 타임스탬프 시점에 서버상 플레이어의 위치를 받았으니, 이전에 기록해둔 데이터와 비교를 할 수 있음.

이 때 차이가 존재한다면, 수정 후, 그 시점부터 현재시점까지의 시뮬레이션을 다시 돌려줌.

이러면 확인받은 틱까지는 서버와 완벽히 일치하게 되고, 그 이후의 인풋은 서버에서 답장해주기 전까지는, 클라이언트 상에서 판단해서 처리해줌.

난 이 개념만 보고 오~~ 하면서 구현을 시작함.

근데 가장 중요한게 빠져있었음.

이게 대부분의 경우에 완벽히 동작하려면,

클라이언트쪽에서 a시점에 이동을 누른 후 b시점에 뗐을때, 이 사이에 이동 시뮬레이션이 5회 실행된다고 치면, 서버 위에서도 무조건 5회 돌아야 함.

그렇지 않으면 위치에 차이가 생겨서 이동할때마다 조금씩 텔레포트 함.

근데 이런식으로 같은 시간차를 두고 들어오는 인풋이라도 그 사이에 이동 시뮬레이션이 1회 돌 수도 있고 2회 돌 수도 있음.

서버틱에 정확히 맞춰서 보낸다 해도 마찬가지임. 인풋1과 인풋2 사이에 시뮬레이션이 몇회 도는지는 절대 알 수 없음.

이에 대한 언급이 어디에도 없어서 한참 헤맴.

나중에 인터넷에서 코드를 찾아보니, 인풋에 변화가 있을때만 인풋데이터를 서버로 보내주는게 아니라, 매 틱마다 보내주는 방식으로 처리하더라.

이러면 확실히 정확하게 시뮬레이션이 일치하겠는데, 그걸 보기전까지는 에이 설마 그렇게 구현하겠어 하고 고려 자체를 안했던 방법이였음.

나는 인풋에 변화가 있을때만 보내주고 있었고, 그게 좀 더 마음에 들었음.

그래서 서버쪽에서 역으로 클라이언트의 시뮬레이션 횟수에 맞춰줬음.

우선 서버쪽에서 클라이언트의 인풋데이터를 받고 응답하는 시점을, 다음 인풋데이터를 받는 시점으로 설정해줬음.

왜냐면 그래야지 마지막 인풋이 클라이언트 위에서 몇 회 돌았는지 같이 온 타임스탬프를 이용해서 알 수가 있고, 해당 시점에 어느 위치에 존재해야 하는지를 결정할 수 있으니깐.

서버쪽에서는 틱마다 업데이트를 자체적으로 돌리면서 몇 회 시뮬레이션 됬는지 체크하는데, 이제 다음 인풋이 들어왔을때,

몇 회 시뮬레이션이 돌았는지와 몇 회 돌아야 하는지를 비교해서 덜 돌았으면 다 돌때까지 기다려주고, 더 돌았으면 되돌려줌.

사실 되돌려주는건 구현 안했는데, 클라이언트가 시뮬레이션을 더 돌리는 상황은 생각보다 드물게 일어나서 괜찮을 것 같음.

그 이유는, 시뮬레이션이 예상보다 2회 덜 돌았다면, 2 틱을 기다려준다음 다음 인풋을 처리해주는데, 이렇게 되면 이 인풋을 2 틱 늦게 처리해주기 때문에, 다음 인풋이 들어올 때 시뮬레이션이 덜 돌아간 상황일 확률이 높음.

이게 되게 헷갈리는데, 굳이 설명하자면

서버와 클라이언트 양쪽에서 틱의 길이가 완벽히 같다고 가정하고, 서버에서 처음 클라이언트의 인풋을 받으면 10틱만큼 기다렸다가 처리해준다고 생각해보면 됨.

인풋을 받은 a와 b 시점 사이에 30틱 만큼의 시뮬레이션이 돌아야 하는 경우임. a를 받은 시점에는 몇회 돌아야 하는지 모르는 채로 시뮬레이션을 돌리다가 b를 받은 후에야 몇회 돌아야 하는지 알 수 있음.

10틱만큼 딜레이가 있기 때문에, 연결이 안정적이라면, a 인풋을 받고 10틱 후에 시뮬레이션이 시작되니, 20회 근처의 시뮬레이션이 돈 상태에서 b 인풋을 받을거임. 이 상황에서 b의 틱 - a의 틱 을 해서 시뮬레이션이 돌아야 하는 횟수가 30 회라는 걸 알 수 있음.

근데 아직 19~21 회의 시뮬레이션이 돌았기 때문에 정확히 30회의 시뮬레이션을 돌리고 다음 인풋으로 넘어가 줄 수 있음.

그리고 틱의 길이가 일치하다는 가정 하에 자꾸 이 딜레이가 늘어나거나 줄어들거나 하지는 않을거라 생각함.

a와 b와 c 시점에 인풋 데이터를 받았고 각각 클라이언트에서 5회씩 시뮬레이션이 돌았을 때,

만약 서버 상에서 a와 b 사이에 4회 시뮬레이션이 돌았다면, b와 c 사이에는 6회 시뮬레이션이 돌거임.

b를 받는 시점에 딜레이가 1틱만큼 늘어났지만, c 시점에 다시 딜레이가 1틱만큼 줄어든다는 거임.

서버 위에서 돌아간 틱의 횟수와 클라이언트 위에서 돌아간 틱의 횟수가 일치하는 이상 이 딜레이는 유지됨.

어떠어떠한 이유로 한쪽에서 틱이 스킵되거나 차이가 발생하게 되는 경우에 이 딜레이의 간격이 변할거고, 너무 극단적이게 변했다면, 이제 텔레포트로 보정해주면서 초기화 시켜주면 될듯?

윗 동영상이 이런 방식으로, 인풋의 변화가 있을때만 서버로 데이터를 보내주면서 안정적으로 예측해주고 있음.

물리 시뮬레이션을 임의로 돌릴 수 있는 기능이 필요했음.

서버에서 응답을 받았고, 해당 틱부터 현재까지 5틱이 존재한다면, 그 순간 즉시 5 틱을 시뮬레이션 시켜줘야 함.

Physics.autoSImulation을 false로 설정해주면, fixedupdate마다 피직스 업데이트가 일어나지 않게 됨.

그 대신 Physics.Simulate()을 통해 직접 시뮬레이션을 시켜 줄 수 있음.

이러면 이제 윗 상황에서 5회 시뮬레이션이 필요할 때, Physics.Simulate()를 5회 실행시켜주면 됨.

클라이언트기 때문에, 클라이언트 예측을 제외하면 피직스 시뮬레이션이 일어나지 않음. 서버에서 받은 결과값으로 처리하니깐.

그런데 만약 물리 업데이트가 클라이언트에서도 일어나야 한다면, PhysicsScene을 이용해서 원하는 오브젝트들만 시뮬레이션 시켜줄 수 있다는 것 같음.

이렇게 서버의 검증이 필요한 상황을 구현했지만, 내가 이전에 만들던 게임에 멀티플레이를 추가한다면, 물리/이동에 관해서는 클라이언트를 완전히 믿는 구조로 갈 생각임.

서버(플레이어)에서 물리를 처리해주려면, 클라이언트 주변 + npc 주변을 전부 Lod0으로 로드해줘야 하는데, 무리가 많이 갈것 같음.

대신 물리가 일어나는 모든 오브젝트에는 관리해주는 플레이어가 정해저야 할 듯.

또한 Npc의 길찾기 경로 역시 가장 근처의 플레이어가 계산해서 서버 플레이어로 보내줄 생각임.

재밌더라. 근데 물어볼 사람이 없어서 힘든 부분은 있음. 내가 하는게 맞는건지 의문이 들 때 스트레스 진짜 많이 받음.

머릿속으로 상상하면서 이렇게 되겠지? 하는게 진짜 어지럽더라. 요즘 맨날 잘 때 누워서 잠들어야 하는데 머릿속이 미궁을 헤매고 있음.

[익명(116.124)]

멀티플레이어 게임 프로그래밍 책 너무 어려워서 읽다 포기함 ㅋㅋ