권한 서버

Photon 과 물리

Photon 은 어떠한 신 또는 물리적으로 영향력이 없으며 서로 상호 작용을 하지 않습니다. Photon 을 매끄럽게 3D 엔진으로 통합 작업과정 동안 서버에서 물리를 수행하는 것은 곤란 합니다. 우리의 경험상 게임마다 요구 사항이 다릅니다( 장르별로 심지어 타이틀별로 다릅니다). 따라서 이것을 올바르게 처리하기 위한 간단하거나 일반적인 방식은 존재 하지 않습니다. 그리고 멀티플레이어 게임들을 호스트 하는 부분에서 가장 비용이 많이 드는 것 중의 하나가 될 것 입니다.

Photon 서버 SDK 에서는 물리 또는 필요로 하는 다른 모델을 사용하는 게임의 서버 권한을 작성해주는 툴을 얻을 수 있습니다.

물리 옵션들

서버 권한을 작성하기 위한 몇 가지 접근법이 있습니다. 다음 아이디어들은 예로 Unity3d 를 이용하지만 기본적으로 모든 3D 게임 엔진에서도 동일하게 수행 할 수 있습니다.

프로젝트를 취미로 만들거나 프로토타이핑의 목적일 때 필요한 부분만 사용할 수 있다는 것을 기억 해 주세요. 수 많은 플레이어가 없는 한 플레이어 1 인당 비용과 성능 관계없이 자신의 게임에 철저히 집중하여 작업을 진행합니다.

유니티 인스턴스 실행

실제로 Unity 인스턴스를 서버에서 실행 할 수 있습니다.
Photon 서버 로직은 C # 언어로 작성 되었기 때문에 Room별로 하나의 Unity 프로세스를 시작하고 다른 클라이언트인 것 처럼 통신 할 수 있습니다.
로컬에서는 러그를 추가하지 않습니다. 아무튼 유니티 인스턴스들의 시작, 중지 그리고 캐시 하기 위해서는 CPU 엔진 라이선스와 자동화된 작업흐름이 필요 합니다.
하나의 룸과 신에 대하여 1 개의 인스턴스를 작동시켜 서버의 신과 클라이언트 신이 동기화 되어야 합니다.

Unity의 물리는 각 플랫폼에 따라 결정되는 것이 아닙니다. 서버와 클라이언트의 차이로 인하여 시간이 지남에 따라 엔진에서 다른 결과를 보여주기 때문에 업데이트를 반드시 실행 해 주어야 합니다.

충돌 감지 라이브러리 사용

현재 우리가 권장하는 "권한 서버" 모델은 레벨 데이터를 내보낼 때 간단한 물리 엔진을 사용하는 것 입니다.
사실 노력이 좀 필요하지만, 런타임 비용을 최소화하면서 최고의 결과를 얻을 수 있습니다.
대부분의 게임에서는 충돌 감지만을 필요로하고 있습니다: 다른 유닛을 타격했다는 것은 총알/검이 튀는 것을 원하지 않는 다는 것을 의미 합니다.
그 타격에 대한 정보를 알고 싶을뿐입니다. Unity의 트리거는 이와 유사합니다: 실제 물리적 실체가 아니라 상자 또는 메쉬가 겹칠 때 설정된 callback이 생기면 코드가 반응합니다. "물리"가 트리거 되는 이벤트를 감소 시킬 수 있다면 성능이 향상될 것 입니다.

게임에 따라 Unity의 물리를 사용하지 않는 것이 좋은 경우가 있습니다. 간단한 2d 충돌 탐지 엔진의 경우에는 좋을 수 있습니다. C # 기반의 엔진은 Unity와 Photon에서도 사용할 수 있습니다. 이를 통해 같은 코드를 양쪽에 사용할 수 있습니다.

많은 게임에서 네비게이션에는 간단한 메쉬를 사용하고 있습니다. 클라이언트 측에서도 동일합니다. 플레이어가 나아갈 방향에 대해서만 알고 싶을 때 장면의 수풀처럼 세분화된 사항까지 로드 할 필요가 없습니다. 간단한 수준의 경우, 서버에서만 사용하는 편이 좋은 경우가 있습니다. 에디터로 부터 exporter 들을 작성하여 레벨 설정과 서버내의 결과에 사용하고 있는 고객도 계십니다.

물리 통신

서버가 물체를 이동 시키기 위해 실제 로직을 운영하고 있는 경우, 서버는 플레이어에서 입력만 있으면 그 결과로의 이동이나 이벤트 모두에 업데이트 정보를 전송합니다.

서버에서 클라이언트들이 "Mov" 오퍼레이션과 같은 입력을 "제출" 할 수 있도록 오퍼레이션을 구현할 수 있습니다. RaiseEvent 오퍼레이션과는 달리 이러한 오퍼레이션은 클라이언트의 데이터를 모두에게 보내지 않을 것이지만 특정 아이템의 서버 상태는 갱신 합니다. 파라미터들이 입력되고 클라이언트에서 보여지는 위치와 이동 데이터가 혼합 될 수 있습니다.

서버에서 특정 간격으로 로직을 수행 할 수 있습니다(RequestFiber.Schedule() 또는 RequestFiber.ScheduleOnInterval ()를 이용합니다). 변경된 이동 사항은 Photon 이벤트를 통해서 모든 클라이언트에게 전송되어야 합니다. 이벤트별로 이동 항목들의 목록을 보낼 수 있습니다: 각 항목은 ID, 위치와 속도를 포함 해야 할 것 입니다. 필요할 때 정보를 추가 합니다.

클라이언트 업데이트 사이에 몇 프레임의 추가를 허용한다면 대역폭을 절약 할 수 있습니다. 플레이어 수가 늘어나면 그 중요성은 높아집니다: 1초에 20의 업데이트를 32명의 플레이어가 2바이트 간격으로 보내면 이벤트는 1kB 크기가 됩니다.

하나의 Photon 이벤트가 여러 클라이언트로 전송 될 수 있으면 직렬화 작업을 줄이게 됩니다. 이동할 항목이 너무 많으면 다른 방식을 통해서 플레이어, 지역마다 등에 관심이 적은 것을 필터링 해야합니다.