[💬] 유니티에서 멀티플레이

[익명(222.110)]

배경 지식을 되새김질 해보자..

보통 프로세스가 다른 프로세스와 상태를 공유하기 위해선 외부 프로세스와 통신을 수행해야 하는데

OS 에선 공유 메모리, 디스크립터 인터페이스 등으로 제공한다..

여기서 네트워크로 연결된 다른 컴퓨터랑 연결하는 경우는 주소 정보와 함께 소켓 디스크립터를 생성해서 사용한다..

소켓을 이용한 통신은 대표적으로 HTTP 를 통해 1회성 세션을 만들어서 다른 컴퓨터로부터 정해진 정보를 받아오거나

아니면 TCP, UDP 를 통해 Keep alive 형식으로 연쇄된 정보를 주고받는다..

이걸 활용하면 게임에서 대략 다음과 같은 형식을 구성 할 수 있는데..

REST: 주소로 노출된 특정 자원에 접근함

웹소켓: TCP 를 통해 HTTP 문서를 Keep-alive 형식으로 주고받아 HTTP 레이어에서 세션을 유지

RPC: TCP, UDP 를 통해 다른 컴퓨터한테 특정 프로세스에 어떤 로직을 열어달라고 요청 후 응답을 받음. 

요청 측에서는 로직의 시그니쳐만 인지하고 있음.

유니티에서 제공하는 멀티플레이 패키지를 알아보자

유니티에서는 HttpClient 가 강제되지 않기 때문에 굳이 웹소켓을 쓸 이유가 없다..

통신하고자 하는 프로세스끼리 소켓을 연결해서 통신하기만 하면 된다..

그러다보니 유니티에서 제공하는 멀티플레이 패키지의 모습은

서버는 비즈니스 로직을 최대한 배제하며

비즈니스 로직이 추가되는 클라이언트 내 GameObject 의 Behavior 객체들에 대해서

동기화하고자 하는 객체를 NetworkBehavior 로 정의하여 

해당 객체는 클라이언트 사이드에서 시뮬레이션을 통한 보간 + 네트워크의 값이 반환되면 동기화 하는 형식으로 동작한다.

클라이언트를 개발하는 입장에선 매우 단순하고 유용해보이지만, 다음과 같은 문제를 고민해봐야 할 것 같다.

- 게임의 비즈니스 로직상 보안 이슈가 없는지.. (ex: 특정 상태에서만 사용 할 수 있는 로직을 클라이언트 변조를 통해 맘대로 사용한다.)

- Network 객체들의 Life cycle은 어떻게 될까.. (언제 생성되고, 언제 소멸하나? 예외는 어떻게 처리되나? 의존성 때문에 메모리 릭이 발생하지 않을까?)

- 동기화에 집중된 통신인 만큼, 대역폭 성능은 어떨지.. (ex: 인벤토리나 캐릭터 정보와 같이, 읽기 전용 데이터이며 게임 플레이에 관계없는 정보는 별도로 HttpClient 를 정의해서 비동기로 게으르게 갱신하게 나눠주면 동기화 성능이 더 좋아질 듯 하다.)

게임의 워크플로우에 대한 동기화는 각 패키지마다 Manager 클래스를 제공하는데 이걸 이용해서 해야하는 것 같다..

유니티에서 대중적으로 사용되는 멀티플레이 패키지는 3개로

Unity MLAPI: 새로 만든 오피셜 패키지

  - 지들 설명으론 다된다는데 추측컨데 절대 그렇지 않을 것 같다.

    - 나온지 얼마 안됬기 때문이다.

  - 그래서 아직 문서는 안읽어봄

Mirror: UNet 이 deprecated 되면서 이를 포크해서 만들어낸 오픈소스 패키지

  - 클라이언트 기반 멀티 플레이 환경을 기대하여 만든 패키지

    - P2P, Host (Listen) 서버 형식

    - 동기화 대상 객체를 바인딩해서 RPC, SyncVar 기법으로 동기화한다(?)

    - 플랫폼별 RUDP 스펙의 프로토콜 지원함

    - 서버 어플리케이션으로 데디케이팅 하는게 불가능하진 않음

  - 튜토리얼을 몇개 돌려보니 포톤에 비해 배포, 자동화가 까다로울 것 같다.

Photon: 

  - 두 패키지 (BOLT 와 PUN) 가 지원된다. 둘을 비교하는 페이지가 있다: https://doc.photonengine.com/ko-kr/pun/current/reference/pun-vs-bolt

    - PUN: 직렬화 모델의 생성 (ProtoBuf 같은건가?) 과 RPC 호출을 중심으로 배포가능한 서버 어플리케이션으로 멀티플레이를 연결

    - BOLT: 동기화 기법자체는 PUN 과 다르지 않음. 

       - 세션간 High performance 를 목표로 한다고 소개하고 있다.

         - P2P, Host 서버 형식

         - 무료로 제공되는 패키지

결론:

 - 가볍고, 동기화 목적의 성향을 가지는 통신에 대해서 유니티에서 제공하는 RPC 패키지를 사용하자.

  - 유저 정보는 웹 서비스 형식으로 만들어서 제공하는 것이 훨씬 적합해보인다.

 - 원하는 멀티플레이 모델에 따라 각 패키지를 활용해보자.

  - P2P, Host 서버: Mirror, Bolt

  - Dedicated 서버: PUN

더 알아보고 싶은 것:

 - Mirror 와 Bolt 의 스펙 비교

 - Bolt API와 PUN API 는 유사할까? (왠지 그럴 것 같다.)

 - Analytics 서버는 어떻게 만들까

[익명(211.40)]

미러가 데디에 훨씬 적합하고 pun은 그냥 릴레이서버용입니다

[익명(211.40)]

mlapi는 유니티가 사오면서 원래 있던 기능도 많이 없애고 기능 자체가 너무 불편해서(또 유니티해버렸다) 추천하기 애매하지만 공식 지원이므로 쓰는게 나쁘진 않을듯 합네다.(저희 팀은 pun -> mirror -> mlapi 순으로 옮겨가면서 개발중입니다)

[익명(211.40)]

배포 서비스에 대한 지식이 전무하고 해킹에 취약해도 큰 상관 없으며 게임 세션 인원수가 많지 않고 게임 기대수익이 어느정도 높아서 비용 결제가 가능하다 => pun 데디도 해보고 싶고 난 전용 서버가 있거나 클라우드 지식이 어느정도 있으며 유니티 서버빌드로 간단한 데디 서버를 구현하고싶다 => mirror or mlapi

[익명(222.110)]

알려주셔서 감사합니다. 처음 배우는데 도움이 많이 됬어요..

[익명(222.110)]

> 배포 서비스에 대한 지식이 전무하고 해킹에 취약해도 큰 상관 없으며 게임 세션 인원수가 많지 않고 이 부분이 오히려 Bolt 나 Mirror 의 P2P 환경 개발에 적합한 조건이라고 생각했는데, 그렇지 않군요..

[익명(211.40)]

p2p는 논외로 뒀숩니다. 모든걸 p2p로 만드는 경우는 요즘엔 거의 없어가지구요(호스트 마이그레이션 등 이슈를 구현하느니 릴레이 서버를 두고 pun으로 가는게 합리적으로 보이긴 합니당)

[익명(211.40)]

볼트는 써보진 않았지만 각종 보간처리 이슈를 다 구현해 뒀다고는 하더군여 세션형 게임이고 규모가 크지 않다면 고려해볼만 한 것 같네여