게임 서버에 대한 지식을 쌓기 위해 독학한 내용으로, 검색과 ChatGPT를 통해 공부한 내용을 작성합니다.
P2P (Peer to Peer)
말 그대로 플레이어(클라이언트)들이 서로 직접 연결해 데이터를 주고받는 네트워크 구조다.
적은 인원이 함께 게임을 진행하는 (대부분 10명 내외) MO 류의 게임에서 주로 사용된다.
플레이어의 클라이언트에서 직접 로직을 처리하므로 서버의 부담이 적고 (거의 없고) 빠른 액션 처리와 정확한 충돌처리가 가능하다.
P2P 방식은 다시 2가지로 나누어 진다.
모두가 동등한 P2P
게임에 참여한 플레이어끼리 그물처럼 모두가 연결한다.
자신의 컨트롤이나 처리 결과를 다른 플레이어에게 직접 알려주는 방식
이 방식은 로직이 분산되므로 판정에 어려움이 있다. 핵, 치트 검증이 불가하고, 하나의 아이템을 두 명이 동시에 먹었을 때
누가 먹은 것으로 할 것인지와 같은 판정의 애매함이 있어 동기화 또한 어려울 것으로 판단해 배제한다.
Host 방식 P2P / Super peer
플레이어 중 특정 1명이 호스트(서버) 역할을 하며 다른 플레이어들이 호스트 플레이어에게 접속한다.
이는 실제로도 CS 구조와 같은 방식이지만 서버의 역할을 플레이어가 하게 된다는 게 다른 점이다.
Host 역할은 보통 게임 방을 만든 사람이나, 참여자 중 컴퓨터 환경이 가장 좋은 플레이어가 호스트 역할을 한다.
장단점은 기본 P2P와 비슷하다. 응답성은 기본 P2P보다 조금 떨어지나 한명의 Host가 로직, 판정을 전담할 수 있어 동기화 문제나 판정의 애매함은 없도록 만들 수 있다.
작동 방식
- 게임 참여자들 간에 데이터를 교환
- 한 플레이어가 호스트 역할을 하며 다른 플레이어와 연결을 관리하거나, 모든 플레이어가 동등한 역할로 데이터를 주고 받기도 한다.
특징
- 분산형 구조 : 서버 없이 클라이언트들만으로 네트워크를 구성한다.
- 호스트의 PC 성능과 네트워크 품질에 따라 전체 게임 퀄리티가 좌우된다.
- 핵, 치트를 거의 막을 수 없다고 봐야한다. CS구조로 변경하거나 CS 구조의 검증 서버를 추가로 넣어서 핵을 차단할 수 있도록 개선하는 방식으로 구현해야 한다.
CS(Client-Server)
중앙 서버가 모든 클라이언트를 관리하는 네트워크 구조다.
MMORPG를 생각하면 쉽다. 게임 서버에서 모든 클라이언트의 명령을 처리하며 로직의 처리를 전담한다.
클라이언트는 사용자의 컨트롤 입력과, 결과 그래픽 처리, 애니메이션, 이펙트 등의 게임 뷰어 역할을 한다.
서버는 캐릭터 이동 경로부터 몬스터 AI, 데미지, 보상 등등 게임 대부분의 컨텐츠 로직을
서버가 처리해 결과를 클라이언트에 통보한다.
작동 방식
- 플레이어(클라이언트)는 모두 중앙 서버와 통신하며 게임 데이터를 주고받는다.
- 서버가 모든 게임 상태와 로직을 제어한다.
특징
- 중앙 집중형 구조 : 서버가 모든 플레이어를 조율한다.
- 서버가 다운되면 게임 전체가 중단될 수 있지만, 동기화와 공정성이 보장된다.
- 네트워크 환경이 좋아지면서 CS 구조로 액션 게임, 논타게팅 MMORPG 개발된다.
Listen Server
호스트 플레이어가 동시에 서버 역할을 수행하는 방식이다.
일반적으로 P2P와 CS의 중간 형태로 볼 수 있으며, 중앙 서버를 운영하지 않고 플레이어 중 한명이 게임 데이터를 관리한다.
다른 플레이어는 이 호스트에 접속해 게임을 진행한다.
작동 방식
- 한 플레이어가 게임을 생성하며, 호스트가 된다.
- 다른 플레이어는 호스트에 접속해 게임 데이터를 공유받고 동기화된다.
- 게임 로직(캐릭터 움직임, 이벤트 처리 등)은 호스트에서 처리되고 클라이언트로 전달된다.
| 특징 | P2P | CS | 리슨 서버 |
| 구조 | 클라이언트간 직접 연결 | 중앙 서버가 클라이언트 관리 | 한 플레이어가 서버 역할을 수행하고 나머지는 클라이언트 |
| 비용 | 서버 비용 없음 | 서버 유지 비용이 있음 | 서버 비용 없음 |
| 보안 | 낮음(치트나 해킹에 취약) | 높음 (서버에서 보안 관리) | 낮음(치트나 해킹에 취약) |
| 안정성 | 호스트 네트워크 품질 의존 | 서버 상태에 의존, 안정적 | 호스트 네트워크 품질 의존 |
| 확장성 | 낮음, 소규모 게임에 적합 | 높음, 대규모 멀티플레이 지원 가능 | 낮음, 소규모 협동 게임에 적합 |
| 지연(Latency) | 호스트 클라이언트 간 지연 가능 | 서버와의 물리적 거리 및 품질에 따라 다름 | 호스트 클라이언트 간 지연 가능 |
| 호스트 의존성 | 일반적으로 없음 SUPER PEER 방식은 높음 |
없음 | 높음 호스트 종료 시 세션 중단 가능 |
| 적합한 게임 | 소규모 협동 게임 | 대규모 멀티 플레이, 경쟁 중심 | 소규모 협동 게임 초기 단계 비용 절감 |
선택 시 고려사항
1. 게임 유형 :
- P2P : 소규모 협동 게임, 비경쟁적이고 간단한 멀티플레이 게임
- CS : 대규모 멀티플레이, 경쟁 중심, 치트 방지 필수
- 리슨 : 소규모 협동 게임, 초기 개발 단계에서 적합
2. 플레이어 수 :
- P2P : 적은 수의 플레이어에 적합 (보통 2~8명)
- CS : 수백~수천 명의 동시 접속이 가능
- 리슨 : 적은 수의 플레이어에 적합 (보통 2~8명)
3. 네트워크 품질 :
- P2P : 플레이어 간 네트워크 품질에 의존
- CS : 서버의 품질과 지리적 위치에 따라 달라짐
- 리슨 : 호스트의 네트워크 상태가 불안정하면 다른 플레이어도 영향 받음
4. 비용 :
- P2P : 서버 비용이 거의 들지 않는다.
- CS : 서버 유지 및 확장이 필요한 만큼 비용이 증가한다.
- 리슨 : 서버 비용이 거의 들지 않는다.
5. 보안 요구
- P2P : 낮음, IP 노출 및 치트 방지 어려움
- CS : 높음, 서버에서 게임 로직과 데이터 검증 가능
- 리슨 : 낮음, 호스트가 게임 데이터를 조작할 가능성이 있으며 치트 방지 어려움
지금 작업하고 있는 Project_II는 공포 협동 게임 장르다.
지금 게임의 특성을 분석해보자면
- 협동 및 생존
- 플레이어들이 협력하며 특정 목표를 달성해야 하고, 때로는 서로 다른 지역에서 동시에 작업하거나 소통해야할 수 있다.
- 멀티 플레이 환경
- 일반적으로 2~4명 소규모 팀을 구성하지만, 필요에 따라 더 많은 팀원 구성이 가능
- 동기화 중요
- 괴물의 위치, 환경 이벤트(몹 스폰 등 사운드 재생) 등이 모든 플레이어에게 동일하게 반영되어야 게임이 공정하게 진행됨
- 치트 방지 필요성
- 공포 게임 특성상 치트를 사용하는 플레이어가 있으면 몰입감이 떨어질 수도 있다.
Project_II에 CS 기반의 서버를 구축했을 때 장점
1. 동기화 :
- CS 방식은 모든 플레이어가 동일한 게임 상태를 유지하도록 중앙 서버에서 관리한다.
- 공포 게임에선 특히 괴물의 위치, 소리, 문 여닫힘과 같은 이벤트가 정확하게 동기화되어야 몰입감이 유지된다.
2. 보안 :
- 치트를 방지하려면 서버가 게임 로직을 직접 관리하고 클라이언트가 데이터를 조작할 여지를 최소화해야 한다.
3. 유저 경험 :
- 네트워크 품질이 다른 플레이어들 간에도 안정적인 경험 제공 가능
- P2P는 호스트의 네트워크 상태에 따라 전체 게임 품질이 좌우될 수 있는 반면, CS는 중앙 서버가 이를 보완
4. 확장성 :
- 게임이 인기를 얻어 더 많은 플레이어를 지원하거나 추가 콘텐츠를 제공하려면 CS 방식이 유리
단점
1. 비용 :
- 구축, 운영, 확장에 따른 경제적 부담이 예상 (중앙 서버 유지 비용)
2. 의존성 :
- 서버 다운 시 모든 사용자가 영향을 받는다.
3. 복잡성 :
- 서버와 백엔드 시스템의 설계 및 유지 관리 필요
4. 기술적 한계 :
- 지연 문제 및 스케일링의 어려움
CS 구축 시 추가 고려 사항
1. 서버 비용 관리 :
- 초기에는 AWS와 같은 클라우드 서비스를 통해 소규모로 시작하고, 유저 수 증가에 따라 서버를 확장하는 방식이 합리적
2. 혼합 모델
- 핵심 게임 로직은 CS로 관리하고, 일부 비중요 데이터를 P2P로 처리해 서버 비용을 줄일 수 있음
3. 근거리 서버 배치
- 유저 분포에 따라 물리적으로 가까운 위치에 서버를 두어 네트워크 지연을 줄일 수 있음
CS 기반 구축 결론
안정적인 동기화, 보안, 유저 경험에서 장점이 있다.
Project_II 가 P2P 기반의 서버를 구축했을 때 장점
1. 비용 절감 :
- 중앙 서버를 운영할 필요가 없으므로 초기 개발 및 유지 비용을 대폭 줄일 수 있다.
- 호스트가 게임 서버를 맡기 떄문에 클라우드 기반의 서버 인프라 구축 없이도 게임을 실행할 수 있다.
2. 구현 접근성 :
- 로컬 네트워크 기반에서 테스트가 용이, 멀티 플레이 프로토타이핑에 적합
3. 소규모 게임에 적합 :
- 2~8명 정도의 플레이어를 지원하는 협동 게임에서는 네트워크 부하가 크지 않아 원활히 작동할 수 있다.
4. 유연성 :
- 호스트 플레이어가 로비에서 게임 세션을 열고 닫는 등, 사용자가 쉽게 관리할 수 있다.
단점
1. 보안 문제 :
- 호스트가 클라이언트의 데이터를 조작할 가능성이 있다.
- 플레이어의 IP주소가 노출될 수 있어, 네트워크 공격의 위험이 있다.
2. 호스트 의존성 :
- 호스트가 게임을 종료하거나 연결이 끊기면 세션이 중단된다.
- 호스트의 하드웨어 성능과 네트워크 상태가 게임의 전반적인 품질에 큰 영향을 미친다.
3. 확장성 부족 :
- 플레이어 수가 증가하거나, 게임 로직이 복잡해지면 호스트가 이를 감당하지 못할 수 있다.
4. 동기화 이슈 :
- 호스트와 클라이언트 간 네트워크 레이턴시 문제가 발생할 수 있다.
- 모든 클라이언트가 동기화되지 않으면 게임 경험에 부정적인 영향을 줄 수 있다.
P2P 구축 시 추가 고려 사항
1. 호스트 교체 :
- 호스트가 나갔을 때 데이터 유실을 최소화하는 등 동기화 메커니즘 강화 필요
- 다른 클라이언트가 호스트 역할을 이어받는 기능 구현
2. 보안 강화 :
- 게임 데이터 암호화 및 신뢰할 수 없는 클라이언트 방어 메커니즘 필요
- 클라이언트 간 교차 검증을 통해 구현하는 것 추천
3. 네트워크 품질 확인 :
- 호스트를 자동 선택할 때 네트워크 대기 시간(Ping)과 하드웨어 성능을 기준으로 가장 적합한 플레이어를 선택하도록 설계
4. 추후 전환성 :
- 게임이 성공적으로 자리 잡은 후, CS 방식으로 전환이 가능하도록 코드를 유연하게 설계할 것, 주요 로직을 서버 독립적으로 작성하면 전환이 쉬워진다.
P2P 기반 서버 구축 결론
초기 개발 비용을 줄이고 소규모 협동 게임에 적합한 선택이다.
다만, 보안 문제와 호스트 의존성을 충분히 고려해야한다.
Project_II 가 Listen Server 기반으로 구축했을 때 장점
1. 비용 효율 :
- 별도의 중앙 서버를 운영하지 않으므로 서버 유지 비용이 없다.
- 언리얼 엔진에서 데디와 리슨 서버를 쉽게 개발 할 수 있도록 지원한다.
2. 유연성 :
- 플레이어가 직접 서버를 호스팅하므로 별도의 인프라가 필요 없다.
- 호스트가 직접 세션을 열고 닫는 등 자유로운 관리가 가능하다.
단점
1. 호스트 의존성 :
- 호스트의 네트워크 상태나 하드웨어 성능에 따라 게임 품질이 좌우된다.
- 호스트가 게임을 종료하거나 연결이 끊기면 세션이 중단된다.
2. 보안 문제 :
- 호스트가 게임 데이터를 조작할 수 있는 가능성이 존재, 치트에 취약
- 플레이어의 IP가 노출될 수 있어 네트워크 공격에 위험이 있다.
3. 확장성 부족
- 플레이어 수가 증가하거나, 복잡한 게임 로직을 요구하는 경우 호스트가 이를 감당하지 못할 수도 있다.
4. 동기화 문제
- 호스트와 클라이언트 간 레이턴시가 발생하면 게임이 끊기거나 동기화가 깨질 위험이 있다.
리슨 서버 구축 결론
소규모 협동 공포 게임 같은 특수한 조건에서 좋은 선택이 될 수 있지만, 게임이 성장하고 플레이어 수가 많아질 경우 CS 방식으로 전환하는 것이 더 적합할 수도 있다.
'Project_II' 카테고리의 다른 글
| 리슨 서버와 P2P Super peer 차이 (0) | 2024.12.26 |
|---|---|
| 언리얼 엔진 멀티플레이 Replication System 에 대하여 (0) | 2024.12.26 |