Unreal Engine 멀티플레이 기초 - 서버 종류와 Dedicated Server 구조

About this offer

2. Unreal Engine 멀티플레이 기초 - 서버 종류와 Dedicated Server 구조 멀티플레이를 구현하기 전에 먼저 서버와 클라이언트가 어떤 구조로 동작하는지 이해할 필요가 있다. 이번 챕터에서는 P2P Server, Listen Server, Dedicated Server의 차이를 알아보고, Unreal Engine에서 Dedicated Server에 Client가 접속했을 때 GameMode, GameState, PlayerController, PlayerState, Character가 어떻게 생성되고 복제되는지 살펴봤다. P2P Server P2P는 각 컴퓨터가 Client이면서 Server 역할도 수행하는 구조 다. 강의에서는 다크소울과 토렌트를 예시로 들고 있다. Player 1 Server + Client Player 2 Server + Client Player 3 Server + Client 특정 서버 한 대가 모든 것을 담당하는 구조와 달리 각 참여자가 Server 역할을 함께 수행할 수 있다는 것이 특징이다. Listen Server Listen Server에서는 참가자 중 한 명이 Host 가 된다. Host는 Server와 Client 역할을 동시에 수행하고, 나머지 Guest는 Client 역할만 수행한다. 강의에서는 Minecraft와 Among Us를 예시로 소개한다. Host Server + Client / \ / \ Client Client Guest Guest 핵심은 다음과 같다. Host = Server + Client Guest = Client Dedicated Server Dedicated Server에서는 Server를 담당하는 프로세스가 Client와 분리되어 있다. 강의에서는 배틀그라운드를 예시로 사용한다. Dedicated Server / \ / \ Client 1 Client 2 Listen Server와 가장 큰 차이는 Server 역할과 게임을 플레이하는 Client의 역할이 분리된다는 점이다. Listen Server Host = Server + Client Dedicated Server Server = Server Player = Client Dedicated Server 실행 흐름 서버 프로세스가 실행되면 Level을 열고 다른 Client가 접속할 수 있는 상태가 된다. 강의에서는 PIE 또는 Server.exe 실행 이후 Open {Level}?Listen 형태로 Level을 열며, 이 과정에서 Socket이 생성되어 외부 Client가 접속할 수 있다고 설명한다. Server Process 실행 ↓ Level Open ↓ Socket 생성 ↓ Client 접속 대기 Level에는 WorldSettings가 존재하고, 해당 설정을 기반으로 GameMode와 GameState가 생성된다. Server Level ├─ GameMode └─ GameState GameMode는 Server에만 존재한다 이번 챕터에서 가장 중요한 내용 중 하나다. GameMode는 Server에만 존재한다. 강의에서도 전체 컴퓨터 중 Server 한 곳에만 GameMode Actor가 존재한다고 강조한다. 따라서 다음처럼 생각하면 이해하기 쉽다. Server ├─ GameMode O └─ GameState O Client ├─ GameMode X └─ GameState O GameMode는 게임의 규칙을 관리하는 Server 측 객체로 이해할 수 있다. 반면 GameState는 Server뿐 아니라 Client에도 복제되어 여러 Client가 게임의 상태를 알 수 있도록 사용된다. Client가 Server에 접속하는 과정 Client는 Server의 IP 주소와 Port 번호를 사용해 접속한다. 접속이 시작되면 Server가 Client에게 Level 정보를 전달하고, Client는 해당 Level을 연 뒤 성공 여부를 Server에 알린다. Client ↓ IP + Port를 이용해 접속 ↓ Server ↓ Level 정보 전달 ↓ Client가 Level Open Level을 정상적으로 연 Client에 대해서 Server에서는 해당 플레이어용 객체가 생성된다. PlayerState PlayerController PlayerCharacter 그리고 필요한 객체가 다시 Client에 복제된다. GameState 역시 Client로 복제된다. 두 번째 Client가 접속하면? Client2가 접속해도 동일한 과정이 반복된다. Server에는 Client2의 PlayerState PlayerController PlayerCharacter 가 추가로 생성된다. 결과적으로 Server에는 여러 Player에 대한 정보가 존재한다. Server GameMode GameState PlayerState 1 PlayerController 1 Character 1 PlayerState 2 PlayerController 2 Character 2 그리고 PlayerState와 PlayerCharacter가 Client 사이에 복제되면서 서로의 플레이어를 확인할 수 있게 된다. GameMode와 GameState 두 클래스는 이름이 비슷하지만 멀티플레이에서는 역할 차이가 중요하다. GameMode → Server에만 존재 → 게임 규칙 담당 GameState → Server에 존재 → Client에도 Replication → 여러 Client가 알아야 하는 게임 상태 GameMode는 Server 전용이라는 점을 기억하면 두 클래스의 차이를 이해하기 훨씬 쉬워진다. PlayerController, PlayerState, Character 멀티플레이에서는 세 객체 역시 자주 등장한다. PlayerController → 플레이어 제어 PlayerState → 플레이어 상태 정보 Character → 월드에 실제 존재하는 플레이어 캐릭터 특히 여러 플레이어가 알아야 하는 정보와 자신의 플레이어를 제어하기 위한 정보가 서로 다른 객체에 나뉘어 있다는 점이 중요하다. Client끼리는 직접 통신하지 않는다 이번 챕터에서 가장 중요하게 기억해야 할 또 하나의 규칙이다. Client와 Client는 직접 통신하지 않는다. 통신은 Server를 기준으로 이루어진다. 챕터 1-2 서버의 종류와 데디케... Client 1 ↓ Server ↓ Client 2 즉 다음과 같은 형태가 아니다. Client 1 → Client 2 이 구조 때문에 이후 배우게 될 RPC와 Property Replication에서도 Server와 Client의 실행 위치가 중요해진다. 이전 채팅 구현과 연결하기 앞선 챕터에서는 채팅 입력이 다음과 같이 동작했다. EditableTextBox ↓ UCXChatInput ↓ PlayerController ↓ PrintString 아직 하나의 Client 내부에서만 처리되는 구조였다. 멀티플레이 채팅으로 확장하려면 앞으로는 이 사이에 Server 통신이 들어가야 한다. Client 1 ↓ 채팅 입력 ↓ PlayerController ↓ Server ↓ 다른 Client 즉 앞에서 만든 채팅 UI와 PlayerController 구조가 이후 RPC를 학습하기 위한 기반이 된다. 마무리 이번 챕터에서 가장 중요하게 정리한 내용은 어떤 객체가 Server에 존재하고, 어떤 객체가 Client에 복제되는지 이해하는 것 이었다. 특히 다음 흐름을 이해해두면 이후 RPC와 Replication을 학습할 때 훨씬 수월할 것 같다. Server 실행 ↓ Level Open ↓ GameMode / GameState 생성 ↓ Client 접속 ↓ Player 관련 객체 생성 ↓ Client로 Replication ↓ 다른 Client와 상태 공유 그리고 모든 네트워크 통신의 기본은 결국 다음 구조로 귀결된다. Client ↔ Server Client끼리 직접 통신할 수 없다는 점이 앞으로 학습할 Server RPC, Client RPC, Multicast RPC, Property Replication 을 이해하는 출발점이다.