2025-01-10 <추측항법을 어떻게 구현할까? (2)>

내일배움캠프 Node.js 트랙 52일차

추측항법을 어떻게 구현할까? (2)

지난 8일 TIL에서 이미 추측항법에 대해 작성한 바 있지만, 프로젝트를 계속 진행해본 중에 조금 더 많은 고민거리가 생겨났다. 처음 코드를 작성했을 땐 싱글 플레이라서 하나의 클라이언트만 고려하면 됐지만 멀티 플레이 기능을 추가한 이후론 동기화 방식이 더 자연스러웠으면 좋겠다는 희망사항이 생겼기 때문이다.

 

충돌 로직까지 서버에서 구현하기로 결심한 이상, 동기화 문제를 당장에 해결하는 건 요원해 보인다. 그래도 관련된 정보를 정리하며 차근차근 구현을 해볼까 한다.(이하 내용은 배현직 저자의 <게임 서버 프로그래밍>에서 참고하였다.)

게임 플레이 네트워킹

서버 - 클라이언트 간 네트워킹 방식엔 크게 두 종류가 있다. 모든 로직을 서버가 도맡는 방식과 렌더링을 클라이언트에 일임하는 방식이다. 전자의 경우엔 서버가 그래픽 데이터까지 가지고 있어서 클라이언트는 입출력 터미널 역할밖엔 하지 못한다. 그래서 옛날 텍스트 게임에서나 가능했던 방식이다. 우리가 집중해서 보아야 하는 건 주요 기능은 서버가 처리하되, 클라이언트가 렌더링을 담당하는 방식이다.

서버는 판단하고 명령한다. 클라이언트는 현상을 보고하고 그린다.

 

 

보다시피 클라이언트는 유저의 입력에 대한 정보만 서버에게 보내고 스스로 판단하지 않는다. 심지어는 입력된 정보를 그리지도 않는다. 서버가 패킷을 읽고 달라진 데이터를 응답해주었을 때, 클라이언트는 비로소 월드를 갱신한다.

 

그러나 물리적인 한계로 인해 클라이언트와 서버의 통신에는 지연 시간이 생길 수밖에 없다. 이걸 레이턴시라고 부른다고 지난 TIL에서 언급한 바 있다. 그리고 또 하나 염두해야 하는 점은 서버 - 클라이언트 간의 통신은 잦을 수록 서버에 무리를 준다는 점이다. 그리하여 두 호스트 간의 통신 횟수를 줄이면서도 렌더링의 자연스러움을 높이는 방식이 필요해졌다. 그리고 그 방법 중 하나가 추측항법이었다.

추측 항법의 예시

 

여기 P라는 이름의 물체가 있다. P가 역 디귿자로 움직였다고 가정하자. 레이턴시와 딜레이가 존재하는 게임 화면상에선 P의 경로를 아주 정확하게는 렌더링할 수 없을 것이다. 그래서 추측항법에서는 미리 레이턴시만큼 이동한 좌표를 계산해서 클라이언트에 전달한다. 만약 1초마다 한 번씩 통신을 하고 있고 레이턴시 또한 1초였다면, 2초만큼의 움직임을 미리 예측해서 클라이언트에게 전달하는 것이다.(어떻게 예측하는가는 8일자 TIL 참고)

 

 

그러나 이 방식도 완벽한 방법은 아니다. 왜냐하면 입력한 명령이 서버를 거쳐서 다시 도착할 때까지 시간이 걸리기 때문이다. 결국 입력이 처리되기까지 딜레이가 생기기 때문에 플레이하는 입장에선 답답해질 수밖에 없다.

 

그래서 게임사에서 흔히 사용하는 방식은 '사소한 것을 클라이언트에서 판단하기'이다.

 

이게 무슨 소리냐하면, 클라이언트가 일단 행동하고 서버가 검증한 뒤 오차를 벗어난 값이라면 다시 온전한 값으로 되돌리는 방식이다. 예를 들어 클라이언트가 해킹되어서 규정된 속도 이상으로 플레이어가 움직이고 있다면 서버가 뒤늦게 원래 있어야 하는 좌표로 이동시키는 것이다.

 

그리고 이보다 더 나아간 방법도 있는데, 바로 준비 동작(혹은 음성)만 연출하고 서버의 응답이 왔을 때 비로소 행동하는 것이다. 혹시 공격모션에 딜레이가 있는 수많은 게임들을 기억하는가? 소위 '흐읏 차'하는 음성과 함께 공격을 하는 캐릭터들. 혹은 '고고고'라고 외친 뒤 500ms 뒤에 움직이는 군단들. 그들의 모션 혹은 행위가 두 차례에 걸쳐서 이루어지는 건 사실 이런 현실적인 고민의 산물이라고 한다.