멀티 플레이어 게임 프로그래밍(1)

1장 - 네트워크 게임의 개요

트라이브스 (1998, FPS) 

- 효율성 문제로 비신뢰성 프로토콜 사용(반드시 도착한다는 보장 없음)

- CS 모델 채용

P2P 모델 - O(n2)의 대역폭 필요, 각각의 플레이어들이 주어진 대역폭을 나눠써야함(128명이라면 16,384로 나눠서)

CS 모델 - 서버만 O(n) 대역폭 처리하면 됨

 

- 네트워킹 모델

 

1. 플랫폼 패킷 모듈

패킷 - 네트워크로 보내기 위해 데이터를 묶어놓은 한 단위

- 유일하게 플랫폼 종속적인 계층

- 표준 소켓 API를 감싸놓은 것. 다양한 패킷 형식을 조립하고 전송하려는 목적으로(버클리 소켓과 유사)

 

2. 연결 관리자

- 두 컴퓨터 사이의 연결 추상화

- 윗단의 스트림 관리자가 내려주는 데이터를 플랫폼 패킷 모듈로 전달해주는 역할

- DSN 보장(맡긴 패킷이 전달되었는지 까지만!!! 확실히 알려준다는 뜻)

- 스트림 관리자는 특정 데이터가 무사히 전달되었는지 판단 가능

- 배달 상태 통지는 수신 측의 확인 응답에 따라 비트 필드를 사용한 슬라이드 윈도 기법으로 구현됨

 

3. 스트림 관리자

- 다른 여러 상위 관리자를 대신하여 데이터를 연결 관리자에 보냄

- ((중요)) 허용 최대 데이터 전송률을 조절함

- 여러 시스템이 데이터 전송을 요청하므로, 우선순위 관리도 함

- 어떤 데이터를 보낼지 결정한 뒤 패킷을 꾸려 연결 관리자에 보내고, 잘 전달 되었는지 상위 관리자들한테 알려줌

- 패킷 하나에 이동 관리자 데이터 + 이벤트 관리자 데이터 + 고스트 관리자 데이터 이런 식으로 섞어 보내는 경우가 다반사

 

4. 이벤트 관리자

- 게임 시뮬레이션 중 발생하는 이벤트의 대기열 관리

- 일종의 간이 RPC로 여기면 됨

- RPC : 호출 시 원격 머신에서 실행되는 함수 또는 프로시저

- 이벤트의 우선순위를 매길 수 있는 권한

- 가장 우선순위가 높은 이벤트부터 처리하다가 특정 조건(패킷 꽉 차거나, 이벤트 큐가 비거나, 계류 중인 이벤트가 넘 많거나)이 되면 처리 중지

- 각 이벤트의 전송 기록을 추적하여 확실한 전달 보장

(보장하려는 이벤트의 확인 응답이 없으면 대기열 맨 앞에 해당 이벤트를 다시 끼워 넣어서 보냄)

 

5. 고스트 관리자

- 가장 중요한!!! 시스템

- 특정 클라이언트에게 유의미하다고 여겨지는 동적 객체를 복제 혹은 고스트 사본을 만드는 일을 함

- 고스트 : 클라이언트가 서버에서 받아둔 여러 객체 정보를 일컫는 말

- 고스트를 전송 또는 수신하는 일을 함

- 서버 -> 클라로 가능한 많은 객체 상태를 전송함. 모든 클라가 가장 최신의 상태로 업데이트 되어 있게끔 보장

 

6. 이동 관리자

- 플레이어의 이동 데이터를 최대한 빨리 전송하는 일을 함

 

 

에이지 오브 엠파이어(1997, RTS)

결정론적 락스텝 모델

- 컴퓨터 하나하나가 P2P 방식으로 다른 모든 컴퓨터에 연결하는 방식

- 유닛을 하나하나 동기화 하는 대신, 플레이어가 입력한 명령을 동기화하기로 함

- 대역폭 관리가 수월해짐, 대신 모든 플레이어의 게임 인스턴스는 스스로 시뮬레이션을 돌려야함

- 다른 인스턴스와 정확하게 동기화 할 수 있는지? 중요)

 

1. 턴 타이머

- 일정 기간마다 명령을 쌓아놓는 방식

- 예를 들어 200밀리초로 턴을 잡으면, 그 동안 모든 명령은 대기열 버퍼에 쌓임

200밀리초가 지나면 턴이 완료 되어 대기열에 쌓아둔 모든 명령이 다른 플레이어들에게 전송됨

*핵심* 수신 측이 명령 대기열을 받는 즉시 처리 X, 두 번의 턴 이후 처리한다는 것

- 장점 : 경기 내내 모든 입력을 모아 저장해놓더라도 메모리 용량이나 부담이 적음

 

2. 동기화

- 유사 난수 발생기를 사용해 동기화

- Seed값을 통일해 두어도 단 한 번이라도 서로 다른 횟수로 호출하면 더 이상 같은 값이 나오지 않게됨

- 장점 : 서로 동기화되는 것과 관련된 치트를 쓰기 어려워짐(다른 인스턴스가 즉각 알아챌 수 있음)

- 단점 : 보여줘선 안될 정보를 보여주는 치트(맵핵)에 무방비