TIL

1. Listen Server

Listen Server는 한 명의 플레이어가 게임을 플레이하면서 동시에 서버 역할까지 수행하는 방식이다.

Host
= Server + Player

다른 플레이어
= Client

예를 들어 A가 방을 만들었다면 A의 게임이 서버 역할까지 담당한다.

A
→ 게임 플레이
→ Server 역할
→ Authority 보유

B, C, D
→ A에게 접속하는 Client

언리얼에서는 맵을 열 때 ?listen 옵션을 사용해 Listen Server를 열 수 있다.

const FString TravelPath = TravelMapPath + TEXT("?listen");
World->ServerTravel(TravelPath);

특징

• 별도의 서버 프로그램이 필요하지 않다.
• 방을 만든 플레이어가 서버 역할을 한다.
• Host가 종료하면 일반적으로 서버도 함께 종료된다.
• Host의 PC 성능과 네트워크 환경의 영향을 받을 수 있다.

---

2. Dedicated Server

Dedicated Server는 플레이어와 별도로 실행되는 서버 전용 프로세스가 서버 역할을 수행하는 방식이다.

Dedicated Server
→ 게임 판정
→ 게임 상태 관리
→ Authority

Player A, B, C, D
→ 모두 Client

Listen Server와 비교하면 다음과 같다.

Listen Server
Host = Server + Player

Dedicated Server
Server = 별도 프로세스
모든 Player = Client

특정 플레이어가 서버 역할을 하는 것이 아니므로 플레이어와 서버가 완전히 분리된다.

대신 서버 전용 빌드를 만들고 서버 머신이나 클라우드 등을 통해 별도로 실행해야 한다.

---

3. EOS

EOS(Epic Online Services)는 Epic에서 제공하는 온라인 서비스 기능 모음이다.

대표적으로 다음과 같은 기능을 제공한다.

로그인 / 인증
Session
Lobby
친구
매치메이킹
P2P 연결
통계 / 업적

중요한 것은 EOS 자체가 게임 서버는 아니라는 점이다.

현재 프로젝트에서는 주로 다음 기능을 사용한다.

EOS 로그인
+
Session 생성 / 검색 / 참가

즉 EOS는 플레이어들이 인터넷을 통해 서로의 게임을 발견하고 연결될 수 있도록 도와주는 역할을 한다.

---

4. Session

Session은 현재 참가 가능한 게임의 정보를 등록하고 검색·참가할 수 있도록 관리하는 단위이다.

Host가 방을 생성하면:

Host
→ CreateSession()

EOS
→ "현재 이런 게임이 열려 있다"는 Session 정보 등록

다른 플레이어는:

FindSessions()
↓
EOS에서 Session 검색
↓
방 발견
↓
JoinSession()
↓
실제 게임 서버에 접속

여기서 중요한 것은 다음과 같다.

CreateSession
≠
Server 생성

Session은 게임을 찾고 참가하기 위한 정보이고, 실제 Server가 Listen Server인지 Dedicated Server인지는 별개의 문제이다.

따라서 다음 구조가 모두 가능하다.

Listen Server + EOS Session

Dedicated Server + EOS Session

---

5. 연결 방식

각 개념은 다음과 같이 서로 다른 역할을 담당한다.

Server Authority
= 게임 상태의 최종 판정을 누가 담당하는가

Listen / Dedicated Server
= 실제 Server 역할을 누가 수행하는가

EOS
= 로그인, Session 등 온라인 기능을 제공하는 서비스

Session
= 열린 게임을 등록하고 검색·참가할 수 있도록 관리하는 정보

예를 들어 Listen Server + EOS Session 구조라면:

Host
→ Server + Player 역할

EOS
→ Host가 만든 Session을 등록

다른 Client
→ EOS에서 Session 검색
→ Host의 Listen Server에 접속

반대로 Dedicated Server + EOS Session이라면:

Dedicated Server
→ Server 역할

EOS
→ 해당 게임의 Session 등록

모든 Player
→ Client
→ EOS에서 Session 검색
→ Dedicated Server에 접속

즉 서버 실행 방식과 Session 시스템은 서로 독립적인 개념이다.

---

6. 실제 프로젝트의 멀티플레이 흐름

현재 프로젝트에서는 Session 생성이 성공한 뒤 다음과 같이 ?listen을 붙여 맵을 이동한다.

const FString TravelPath =
    TravelMapPath + TEXT("?listen");

World->ServerTravel(TravelPath);

따라서 방을 생성한 플레이어가 Listen Server 역할을 수행한다.

Host 흐름

EOS 로그인
↓
CreateSession()
↓
EOS에 Session 등록
↓
?listen으로 맵 이동
↓
Host가 Listen Server가 됨
↓
Host = Server + Player

Client 흐름

EOS 로그인
↓
FindSessions()
↓
EOS에서 등록된 Session 검색
↓
JoinSession()
↓
접속 정보 획득
↓
Host의 Listen Server에 접속

따라서 현재 사용하고 있는 방식은 다음과 같이 정리할 수 있다.

EOS Session을 이용한 Listen Server 구조

EOS가 실제 게임 서버를 대신 실행하는 것은 아니다.

실제 Server는 방을 만든 Host의 게임 인스턴스이며, EOS Session은 다른 플레이어가 인터넷을 통해 그 방을 검색하고 참가할 수 있도록 연결하는 역할을 한다.

현재 진행중인 프로젝트 SlimeParty는 서버가 게임 상태의 최종 권한을 가지는 Server Authority 구조를 기반으로 하며, EOS Session을 통해 방을 등록·검색하고 방을 생성한 플레이어가 Listen Server 역할을 수행하는 방식이다.