[Book] 게임 서버 프로그래밍 교과서 - 5장 게임 네트워킹

 5장 게임 네트워킹

 

1. UML

UML은 단순히 플로차트 그 이상의 역할을 한다.

데이터 정의와 프로세스 정의가 편해지고 프로그램 구조 명세를 표현하는 대표적 수단이다.

 

1) UML 시퀀스 다이어그램

UML 시퀀스 다이어그램은 객체와 메시지를 사용하고 객체 간 메시징 흐름을 일목요연하게 표현할 수 있다.

• 객체는 상호 작용의 주체(클라이언트, 서버)로 네모 상자에 해당된다.
• 메시지는 상호 작용의 내용으로 가로 화살표에 해당된다.

 

시퀀스 다이어그램

 

2) 액티비티 다이어그램

시퀀스 다이어그램은 주고받은 메시지를 어떻게 처리하는지 자세하게 표현하기엔 한계가 있다. 그래서 시퀀스 다이어그램에 플로차트를 함께 사용한다면, 보다 자세하게 프로그램의 실행 방식을 그림으로 묘사할 수 있게 된다. 이것이 액티비티 다이어그램이다.

• 실런더 도형은 활동 상태를 의미하며 맨 위에 있는 것은 최초 상태를 의미한다.
• 화살표를 이용해서 활동 상태의 변화 과정인 실행 흐름을 표현한다.
• 마름모로 조건 분기문을 보여줄 수 있다.

 

액티비티 다이어그램

 

2. 게임 플레이 네트워킹

1) 모든 역할을 서버에서 하기

가장 고전적인 방식인 모든 역할을 서버에서 하는 모델을 알아보자.

예를 들어 텍스트 모드에서 터미널로 플레이하는 게임들이 이 방식을 사용했다.

 

모든 역할을 서버에서 하는 모델

 

이 모델에서 클라이언트가 하는 역할은 너무나 단순하다.

• 사용자 입력
• 화면 출력

 

서버가 하는 역할은 클라이언트가 하는 역할을 뺀 나머지이다.

• 게임 로직 연산
• 화면 렌더링(그래픽 데이터 보유)
• 화면 송출(비디오 스트리밍)

 

과거와 달리 지금은 게임 그래픽 품질이 매우 높기 때문에 렌더링과 게임 로직을 모두 서버에서 담당하기엔 무리가 있다. 클라이언트-서버 상호 작용을 최적화해 주어야 한다.

 

2) 렌더링은 클라이언트에서 하기

더 나은 방법은 게임 서버가 하는 역할 중에서 렌더링을 클라이언트에서 담당하는 것이다.

 

렌더링은 클라이언트에서 하는 모델

 

이 모델에서 서버와 클라이언트가 하는 일은 다음과 같다.

• 서버는 렌더링을 위한 최소 정보인 게임 월드 상태만 클라이언트에 보낸다.
  • 월드 상태의 연산은 서버에서 한다.
  • 월드 상태는 월드에 있는 모든 캐릭터의 위치와 기타 정보(채팅, 몬스터 등)를 말한다.
  • 메시지에는 캐릭터 이동, 채팅 입력, 아이템 사용 등 씬의 상태에 영구적 변화를 가하는 지속성 이벤트가 있고 반대로 특정 좌표에서 수류탄이 터지는 등 씬의 변화에 영향을 잠깐 주고 사라지는 단발성 이벤트가 있다. 파티클과 같이 오브젝트의 결과가 정해져 있는 경우, 단발성 이벤트로 구현해야 서버에서 클라이언트로 보내는 메시지 양이 작아지므로 더 효과적이다.
• 클라이언트는 렌더링을 수행하며 이를 위한 그래픽 리소스는 클라이언트에서 보유한다.
• 서버와 클라이언트의 월드 상태를 동일하게 유지한다. 즉, 동기화한다.

 

이 방식을 원활하게 작동하려면, 레이턴시가 1/60초보다 훨씬 낮아야 하며 항상 균일해야 한다. 왜냐하면 서버와 클라이언트는 1/60초마다 상태를 업데이트하고 이를 지체 없이 보여줘야 하기 때문이다. 그러나 서버에 접속해 있는 클라이언트 수가 많아질수록 서버에서 해야 되는 일도 늘어나게 된다. 그래서 1/60초마다 보내는 것이 불가능한 경우가 생길 수 있다. 어떻게 해결해야 할까?

 

간단히 1/30초나 1/10초 단위로 월드 변화를 알리면 된다. 하지만 이 방법은 캐릭터 움직임이 딱딱해지는 문제를 발생시킨다. 이 문제를 해결하려면 값을 강제로 부드럽게 만들어야 한다. 서버에서 받는 상태 변화 메시지를 즉시 반영하는 것이 아닌 일정 시간에 걸쳐 서서히 목적 상태로 변화하게 하는 것이다. 이를 상태 값 보정이라 한다.

• 선형 보간이나 스플라인 같은 곡선형 보간이 있다.

 

3) 추측 항법

상태 값 보정을 사용하면 딱딱해지는 문제는 해결할 수 있지만, 원하는 결과는 사실 아니다. 레이싱 게임이나 FPS 게임을 개발하고 있다면 이는 큰 문제가 될 수 있다. 그럼 또 어떻게 해결해야 할까?

 

상대방 움직임을 어느 정도 예상해서 그 위치로 갈 수 있게 보정하는 추측항법을 사용하면 된다. 추측항법이 제대로 작동하려면 두 기기 간의 레이턴시와 캐릭터의 위치, 속도를 알고 있어야 한다.

 

레이턴시를 측정하는 방법에는 대표적으로 라운드 트립 레이턴시가 있다.

• 기기 A에서 기기 B에 패킷을 보낸다.
• 기기 B는 이를 받으면 기기 A에 패킷을 보낸다.
• 기기 A는 패킷을 보낸 시간과 현재 시간의 차이를 구하여 2로 나눈다.

 

이제 추측항법을 어떻게 처리하는지 알아보자.

 

추측항법 처리 과정

 

• 기본 설정
  • 캐릭터 원본이 있는 쪽(이쪽)을 P0이라 하며 P0(t)는 시간 t에서 원본 위치이다.
  • 캐릭터의 이동 정보를 받는 쪽(사본이 있는 쪽, 저쪽)을 P라 하며 P(t)는 시간 t에서 사본 위치이다.
  • a는 레이턴시이다.
  • V0은 속도 벡터이다.
• 과정
  • 이쪽에서 P0(t=0), P0(t=1)을 보내고 저쪽에서 P(t=0+a), P(t=1+a), P(t=2+a)를 받는다.
  • 저쪽 기기에서 이동 정보를 받았을 때는 이미 a만큼 시간이 지난 상태이기 때문에 정확한 위치는 a만큼의 미래가 되어야 한다. (P(t+a) = P0(t) + a*V0(t))
  • 계산된 위치대로 이동을 하면, 화면에 캐릭터가 살짝 점프하는 것처럼 보이는 문제가 발생한다. 이를 해결하기 위해 앞서 언급한 상태 값 보정 방법을 사용하면 된다.

 

레이턴시를 완전히 없앨 수는 없지만 레이턴시로 발생하는 문제를 숨길 수 있다. 추측항법을 포함해 이러한 방법을 통틀어 레이턴시 마스킹이라 한다.

 

3. 레이턴시 마스킹

추측항법을 이용해 캐릭터 이동을 구현하면, 인터넷 환경이 좋지 않을 때 답답함을 느낄 수 있다. 방향키를 눌러도 즉시 움직이지 않고 방향키를 떼도 즉시 멈추지 않는 현상이 발생할 것이다.

 

이 문제를 해결하는 방법 중 하나는 사소한 것들은 클라이언트에서 판단하는 것이다. 예를 들어 플레이어의 위치는 클라이언트에서 판단하고 이를 서버로 보내주는 것이다. 이 방법은 플레이어가 조종하는 캐릭터가 즉시 반응하도록 제공할 뿐만 아니라 서버에서 플레이어 캐릭터를 움직이는 데 필요한 연산을 하지 않아도 된다.

 

하지만 단점도 존재한다. 예를 들어 클라이언트가 해킹을 당해 이동 속도를 매우 빠르게 설정했다면 어떻게 될까?

이 문제를 해결하기 위한 몇 가지 방법이 존재하는데, 레이턴시나 기획 등에 의해 결정하면 된다.

 

• 방법 1: 서버가 이동 정보를 받으면 정상적인 값 범위에 있는지 검사한다.
• 방법 2: 먼저 클라이언트에서 자기 캐릭터를 일방적으로 움직이지만, 서버에서 이동 정보 메시지를 받으면 앞서 움직였던 위치를 무시하고 서버 메시지에 따라 이동한다.
• 방법 3: 플레이어가 어떤 행동을 하면, 행동 명령에 대한 메시지를 서버에 보내는 동시에 행동 연출 일부를 즉시 보여준다. 서버에서는 행동 명령을 받아 처리 후 클라이언트로 메시지를 보낸다. 클라이언트는 이 메시지를 받으면 나머지 연출을 보여준다.

 

4. 넓은 월드, 많은 캐릭터 처리

월드 안에 캐릭터가 많더라도 플레이어 화면에 나타나는 캐릭터는 극히 일부이다. 서버가 가진 월드 상태 중 변화하는 것 모두를 플레이어에게 보낼 필요가 없다. 가시 영역 필터링을 이용해 플레이어의 가시 영역 내 월드, 캐릭터만 보이도록 해도 된다.

 

그러나 서버에서는 모든 플레이어가 모든 캐릭터 정보를 가지고 있어야 한다. 그뿐만 아니라 서버는 모든 플레이어의 가시 영역 정보도 가지고 있어야 한다.

 

5. 실시간 전략 시뮬레이션 게임에서 네트워크 동기화

전략 시뮬레이션 게임에서는 등장하는 캐릭터 수가 수백 개에 육박한다. 플레이어 수가 적음에도 캐릭터 수는 많기 때문에 지금까지 알아본 방식보단 락스텝 동기화 알고리즘을 사용하는 것이 좋다.

 

락스텝은 컴퓨터 프로그램의 같은 상태에 같은 압력을 주면 같은 결과가 나온다는 원리를 응용한 것이다.

• 각 플레이어는 다른 플레이어들에게 입력 명령을 보낸다.
• 플레이어의 입력 명령에 따라 모든 클라이언트가 동시에 씬 업데이트를 한다.
• 즉, 각 클라이언트 플레이어의 입력 명령만 주고받으며 씬을 구성하는 캐릭터의 이동 상태를 주고받지는 않는다.

 

6. 실제 레이턴시 줄이기

지금까지는 주어진 레이턴시에서 어떻게 최대한 원활하게 멀티플레이를 할지 살펴보았지만, 가능하면 실제 레이턴시를 줄이는 것도 중요하다.

• TCP 대신 UDP를 사용하는 것이 좋다. 왜냐하면 TCP는 패킷 재전송을 위한 지연 시간이 발생하기 때문이다.
• 똑같은 양의 데이터를 보낸다고 하더라도 가급적 적은 수의 패킷으로 보내는 것이 좋다. 예를 들어 1초에 메시지를 100개 이상 보낼 때는 뭉쳐서 보내면 더욱 효과적이다. 이 뭉치는 시간은 10밀리 초 이하가 적당하다.
• 클라이언트와 서버 간 통신(C/S)과 클라이언트끼리 통신(P2P)하는 것을 섞어 쓰는 것도 방법이다.

 

7. 게임 플레이 이외의 네트워킹

게임을 처음 시작하면 대부분 로그인 과정이 나온다.

• 로그온 요청 메시지를 서버로 전송한다.
• 서버는 파일이나 데이터베이스에서 해당 유저의 ID와 비밀번호를 받아서 식별한다.
• 식별 결과, 즉 로그온 처리 결과를 클라이언트에 통보한다.

 

로그온 과정

 

로그인에 성공했다면 이제 캐릭터를 만들거나 선택해야 한다.

 

캐릭터 만드는 과정

 

다음으로 플레이어가 수동으로 방을 만들고 다른 플레이어가 수동으로 방에 들어가는 방식을 설계해보자.

실제 게임에서 많이 사용되는 매치메이킹 설계 방법은 9장에서 알아볼 것이다. 매치메이킹은 나와 실력이 비슷한 플레이어들과 플레이하도록 하는 것이다.

 

방 생성 및 입장

 

8. 해킹과 보안

게임 개발에서 골치 아픈 것 중 하나는 해킹이므로 게임 서버를 개발할 때는 해킹과 보안을 신중하게 생각해야 한다.

• 크래킹: 게임 외 분야에서 흔히 이야기하는 해킹이다. 다른 사람의 ID와 비밀번호를 보거나 서버에 저장된 데이터를 훼손하는 것을 말한다.
• 치트 혹은 조작: 게임에서만 발견되는 형태의 해킹이다. 내 능력치를 비정상적으로 높이거나 다른 사람의 플레이를 망치는 것을 말한다.

 

1) 네트워크 해킹

인터넷은 수많은 네트워크 기기의 집합체이며 각 네트워크 기기는 여러 사람이 공유해서 사용한다. 이런 구조 특성상 다른 컴퓨터의 통신을 도청하는 것을 막을 수는 없다. 따라서 암호화 알고리즘을 이용해 데이터를 암호화하여 보내야 한다.

 

요즘 많이 사용되는 암호화 알고리즘은 암호키를 이용하는 것이다. 암호키를 모르면 원래 내용이 무엇인지 알 수 없다.

 

2020.04.30 - [📝 Computer Science/✏ Network & Web] - 공개키(Public Key) 암호화와 개인키(Private Key) 암호화

공개키(Public Key) 암호화와 개인키(Private Key) 암호화

 

2) 클라이언트, 서버 해킹

3) 게임 치트