서론
서든어택 - 배틀그라운드를 거쳐 발로란트까지 나는 FPS를 무지하게 좋아했고 즐겨했었다.
좋아하던 게임을 놓고 개발에 흥미가 생겨 개발자가 되고, 개발 공부를 계속해서 막 하던 도중 즐겨 보는 코딩관련 유튜브 채널에서 옛날 향수를 느끼게 해주는 주제로 영상이 하나 게시되었다.
모든 FPS의 대기 플레이가 불리하다는 것을 개발을 하면서 자연스럽게 깨닫게 되었는데, 서든어택을 할 당시만 해도 그런 정보들이 거의 전무해서 스나를 들고 있을때는 대기줌을 많이 했던 기억이 난다 ㅋㅋ
그 당시에는 잘하는 사람들의 플레이를 보고, 대회를 봐도 사실 피킹을 먼저하는 사람. 즉 대기스나보다 브레이킹을 거는 사람이 더 유리한 위치라는 것을 잘 인지하지 못했다. 그냥 잘하는 사람이 이기는거라고 생각했기 때문에..
발로란트로 넘어와서야 피킹을 먼저 하는 사람이 유리한 피커스 어드벤티지라는 개념을 이해하고 게임 플레이에 잘 써먹기 시작했었다.
아래는 라이엇 공홈의 발로란트의 피커스 어드벤티지에 대한 설명
요청과 응답
게임은 물론 같은 게임 속의 유저들의 실시간 정보의 업데이트가 중요하기 때문에 지속적으로 클라이언트와 서버 간의 데이터 동기화를 처리할 것이라고 생각한다. 나는 웹 개발자이기 때문에 게임 서버가 어떻게 동작하는지 정확하게는 알지 못하지만 클라이언트와 서버 간의 요청과 응답이라는 큰 틀에서 생각을 해보았다.
요청과 응답을 보내는 과정에서, 아무리 성능 좋은 클라이언트의 PC(기준을 PC로 잡겠음)와 서버가 있다고 해도
아래 그림처럼 일정 시간이 소요되는 것은 당연지사이다.
게임 서버
넷코드(NetCode)는 게임 서버와 네트워크를 총칭하는 속어로 게임에서 유저들 간의 핑 차이를 보정하기 위해 진행되는 일련의 네트워크 동기화 과정이다.
유저들이 중앙 서버에 접속해서 플레이하는 게임들에서는 중앙 서버가 넷코드의 주체가 되고, 유저들 중 한명이 호스팅 역할을 맡는 P2P방식에서는 해당 방장이 넷코드의 주체가 된다.
이 넷코드의 주체로부터 이벤트 세션을 갱신하는 과정에서 유저마다 제각각 다른 시차가 발생하게 되기 때문에(각각 다른 지역에서의 접속 때문에) 게임 내의 승패와 유저의 게임 진행에 큰 영향을 미친다.
게임 내의 모든 정보들을 동기화하기 위해, 틱 레이트(tick rate)라는 것을 설정하는데, 틱 레이트란 데이터 동기화 주기로 틱 레이트를 설정하여 1초에 몇 번 게임 데이터를 클라이언트에게 전달하여 실시간 게임 정보를 클라이언트들이 동기화할 수 있다.
게임 서버의 형태는 보통 P2P 혹은 Dedicate가 있다.
P2P
중앙 서버를 거치지 않고, 클라이언트 컴퓨터끼리 직접 통신하는 방식으로 다들 생각하는 그 P2P가 맞다.
같은 방의 유저들 중 임의로 한 명을 지정하여 서버로 만들어버린다.
대표적인 게임으로 콜옵이 있다고 한다.
장점
개발사에서 따로 서버비용이 들지 않는다는 장점, 중앙서버가 없기 때문에 해킹이나 변조의 위험이 없다.
단점
서버로 선정된 유저는 자신의 IP 주소가 다른 클라이언트에게 노출되는 위험이 있고
또한 ping이 0ms가 되어 다른 유저들보다 게임 플레이에 이점이 있기 때문에 형평성에 어긋난다. (방장사기맵)
Dedicated server
유저가 아닌, 전담하는 서버를 놓고 유저들의 실시간 데이터를 서버로 보내고 다시 클라이언트에게 뿌린다.
데디케이트 서버는 하나의 서버가 게임 한 판만을 전담하므로 게임의 시작과 함께 서버를 시작하여, 게임이 끝나면 서버도 종료된다. (중앙서버 - C/S 방식과 다른 것임!!)
이러한 특성을 잘 활용할 수 있는 대전게임, 인스턴스 던전, 배틀 로얄 게임 등에 주로 사용된다.
장점
서버 오류 시 다른 게임에 영향을 주지 않는다.
Scale-out에 용이하다 (분산처리)
단점
비용이 든다.. 특히 대규모 서버에 비해 매우 비효율적이기 때문에 대규모 서비스에는 비효율적이다.
보안 측면에서 p2p보다는 유리하지만, 중앙 서버 방식에 비해서는 취약할 수 있다.
피커스 어드벤티지
요청을 보내는데에도 시간이 소요되고, 응답을 받는데도 시간이 소요된다면 결국 피커스 어드벤티지는 모든 장르를 불문하고 어떤 게임에서든 적용되는 현상이라고 생각한다.
요청과 응답, 그리고 tick rate라는 개념까지 결합해서 피커스 어드밴티지를 생각해본다면 다음과 같이 생각해볼 수 있지 않을까?
1. 피커가 먼저 적을 발견한 시점에서의 데이터가 서버로 넘어감
2. 서버에서 tick rate 주기가 될 때까지 대기
3. 서버에서 클라이언트에게 게임 데이터 전송
4. 존버러가 피커 발견
아래의 그림에서, 존버러가 피커를 발견하는 시점은 무려 136ms 후다. 저티어 유저들은 별 차이가 없다고 느낄지 모르겠으나, 천상계 유저들에게 이 차이는 엄청난 차이가 될 것이다. 그렇기 때문에, 피커스 어드벤티지를 활용하라는 각종 정보글이나 영상을 봐도, 존버 시 가만히 대기하지말고 주기적으로 조금씩 움직여주라는 것이리라.
마무리
우연한 계기로, 자주 보는 코딩 채널에서 내가 가장 좋아했던 취미인 게임과, 현재 가장 흥미를 가지고 공부중인 개발을 접목시킨 영상을 보게 되어 얕은 지식으로나마 포스팅을 해보았다. tick rate라는 개념이 웹에서의 풀링 방식과 유사한 것인가? 라는 생각과 코딩애플님의 유튜브를 정독하고 있는데, 인덱스나 SQL Injection 등 좋은 소스들이 있어 공부에 활용하고 싶다는 생각과 함께 포스팅을 마무리한다.
역시 무언가 공부하거나 알게 되었을 때, 예전에는 그냥 넘겼던 것을 다른 시각으로 볼 수 있는 좋은 경험이었다고 생각한다.
잘못된 서술에 대한 지적은 언제나 환영합니다.
2023.04 ~ 백엔드 개발자의 기록
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!