Hyun JaeHoon

공부용 블로그, 각종 조언들 감사합니다

3 분 소요

게임 서버에 대하여

일반적인 온라인 게임이라면
게임 서버 외에도 다양한 서버가 존재한다

  • 게임 서버 (우리가 다룰 내용)
  • 로그인 서버
  • 계정 관리용 서버
  • 로비 Or 채팅용 서버
  • DB 서버
  • 결제용 서버 등 그 외의 서버들

이건 ‘게임의 구조’ 보다는
‘전반적인 프로그램/게임 서비스 의 구조’에 가깝기도 하여
너무 깊게 다루지는 않을 예정이다

게임 서버의 종류

게임 서버는 크게 3가지 종류로 나뉜다

  • P2P(다만 이 구조는 네트워크 모델에 가까운 개념)
  • Listen Server
  • Dedicated Server

사전 요약 표

모델 서버 존재 누가 서버 역할? 해킹·보안 대규모 가능? 사용처
P2P 없음 모두 최악 불가 구시대 RTS
Listen Server 있음 플레이어 한 명 낮음 낮음 소규모 협동
Dedicated Server 있음 독립된 서버 매우 높음 최고 대부분의 AAA

P2P (Peer-to-Peer)

Image

 A  <---->  B
 |  \      / |
 |    \  /   |
 \      X    /
   \    |   /
       C

모든 플레이어가 서로 직접 통신하는 구조

사실 별도의 ‘서버’를 사용하기 보다는
각각의 플레이어(클라이언트)가 서로에게 직접 패킷을 주고 받음

플레이어 A의 입력이 B,C 등을 전달되고
B의 입력 또한 A,C 등으로 전달되는 방식

  • 어찌보면 모두가 서버 역할을 한다 볼 수 있음

  • 그렇기에 권한(Auth)을 가진 서버가 없음

  • 사용된 게임들?
    스타1, 워크3, 철권 6, 콘솔/아케이드 계열의 온라인 게임

공평한 처리를 위하여
LockStep 방식을 채용

  • 모든 플레이어가 다음 프레임 계산 전에
    ‘서로’의 모든 정보를 받아야 함

  • 100% 동기화되지만,
    한 명의 사양이 느릴경우, 전체가 느려지는 단점이 있었음
    (과거의 게임에서 사양 안좋은 1명 참가시, 전체 게임이 느려진 사유)

장점/단점

  • 장점
    • 모든 플레이어가 동등한 ‘권한’을 지녀 구조적으로 단순
    • 모든 플레이어의 사양이 동일하고 근접한 위치라면 지연이 거의 없음
    • 서버 유지 비용 x
  • 단점
    • 보안이 사실상 없음(모든 플레이어가 ‘동등’한 권한이 있으므로)
    • 사양이 안좋은 쪽에 맞춰짐
    • 인원이 늘어날수록 성능적인 문제 또한 심각해짐

여전히 사용하는가?

거의 사용하지 않지만
특정 장르에서 ‘응용’하여 사용됨

  • 격투게임에서
    게임 플레이의 지연을 줄이기 위해 사용
    (1 ㄷ 1은 Peer to Peer에 적합함)
    • 다만 보안 문제를 위하여 ‘Rollback NetCode’라는
      안전하게 응용한 방식을 채택한 것
      (격투 게임은 입력 지연을 최소화하는 것이 UX에 직결되므로)
    • 또한 격투게임은 ‘입력 정보’만을 교환하기에 비교적 안전한 편
  • 그 외에도 1대 1 경쟁 같은 모바일 계열에서 채택 가능

클라이언트의 입력 값이 ‘단순’하고
그에 따라 양측에서 데이터 변조 가능성이 적다면
채택을 고심할만 하다

Listen Server

Image

플레이어 중 한 명이 ‘서버’ 역할을 동시에 맞는 구조

  • Host : Server + Client
  • 나머지 : 일반 Client

Host는 같은 프로세스 내부에서
서버 로직 - 게임 로직, Actor 관리 및 판정
클라 로직 - 렌더링 , UI
가 동시에 돌아감

다른 Guest 들은 Host_IP를 통해 계산받음

어찌본다면 권한을 Host에 몰아준
P2P의 일종에 가깝기도 하다
(권한 모델 자체는 Dedicated 와 비슷한 편)

다만, Host의 게임 종료 시,
모든 플레이어가 같이 종료됨

  • 사용된 게임?
    마인크래프트, 어몽어스, 테라리아 등 소규모 협동 게임 계열
  • Unreal에서도 설정을 통해 구현이 가능

장점 / 단점

  • 장점
    • 서버 유지비 필요 x (역시 클라이언트 중 하나가 서버 역할을 하므로)
    • 설정이 다소 쉬운 편
  • 단점
    • Host의 성능이 곧 서버의 성능에 직결됨
    • Host 종료 시, 게임 종료
    • 보안 이슈 (Host의 데이터 조작 가능성은 남아 있음)

어떤 게임에 사용하는가?

  • 소규모 협동 게임
  • 파티 게임
  • 서바이벌 / 생존 / 건설 계열
  • 싱글 게임이지만 멀티 지원

보안적 이슈로 인하여, 경쟁 계열 게임에서는 채택하진 않는 편

Dedicated Server

Image

플레이어가 아닌, 서버용 프로그램만을 실행하는 구조

  • 서버 역할의 프로그램이 별도로 존재
    • 서버는 렌더링 X(그래픽 X)
    • 사운드, UI, 입력 등도 없음
    • 오로지 게임 로직을 처리해주는 역할만 수행
  • 대부분의 게임 로직을 수행
    • Actor 생성 및 파괴
    • 물리/충돌
    • AI의 로직
    • 움직임 관리
    • GameState, GameMode 관리
      -> 클라이언트는 ‘렌더링/UI/Input’처리만 진행하도록!

대부분의 ‘경쟁’ 게임에서 사용하는 게임 서버 구조

실행 흐름

  1. 서버 프로세스 실행

  • PIE, Server.exe 를 통해 실행한 방식
    (실행할 때 Open {Level이름}?Listen 명령어가 인자로 전달)
    (해당 Level을 열어둠)

  • Socket을 생성하고 다른 PC가 접속 가능하게 함

Image

  1. 서버가 게임 World 생성

  • Level의 WorldSettings를 통해
    GameMode, GameState 액터를 생성

  • GameMode는 서버에만 존재

Image

  1. 클라이언트의 접속 시도
  • 클라이언트는 서버의 IP와 Port 번호로 접속을 시도
  • 서버는 접속 시도하는 클라이언트에 Level 정보를 넘김
  • 클라이언트가 Level Open 성공시, 다시 서버로 결과 송신

Image

  1. 접속 성공한 클라이언트용 데이터를 생성 후 복제
  • 서버에서 PlayerState, PlayerController, PlayerCharacter 생성
  • 이후, 접속한 클라이언트에 복제
    (이 때 GameState도 복제하여 전송)

Image

  1. 접속 시도 2
  • 마찬가지로 클라 2도 접속 요청

Image

  1. 복제 2

  • 이 때, 신규 접속한 클라2의 데이터 중
    PlayerState, PlayerCharacter를 클라1에도 복제하여 전송함

  • 마찬가지로 클라2에도 클라1의 PlayerState, PlayerCharacter가 복제되어 전송됨

Image

  • 클라이언트 <-> 클라이언트의 직접 통신은 x

  • 진짜 핵심적인 로직은 서버에서 ‘진짜’를 관리

    • 필요한 데이터만을 클라이언트로 ‘복사’하여 전달함
    • RPC, Replicate 프로퍼티와 연관된 핵심 개념중 하나
      • RPC(Remote Procedure Call) : 서버->클라, 클라-> 서버 등 특정 호출로 인한 이벤트 처리
      • Replicate Property : 서버->클라 를 통해 변수 와 같은 데이터 동기화 처리
        (이 둘은 나중에 더 자세히 알아볼 예정)

장점 / 단점

  • 장점
    • 높은 보안성, 그로 인한 공정성
    • 확장성으로 인한 대규모 인원 접속 가능
    • 각 PC 성능과 게임 로직과 무관
    • 서버의 유지/ 종료 를 서버 회사가 통제
  • 단점
    • 운영 비용 발생(일반적으로 AWS 등을 사용하여 서버 비용 부담)
    • 배포 프로그램의 복잡성 (업데이트/패치 에 대한 처리 필요)
    • 권한 검증, 패킷 처리에 따른 구조적 복잡성

댓글남기기

참고