빠르게 시작해 보기

이 포스트에서는 Photon "Particle Demo"를 사용하여 Realtime API로 멀티플레이어 커뮤니케이션을 구현하는 방법을 보여줄 것입니다.

이 데모에는 당사의 Photon Unity SDK만 포함되어 있으나, 일반적인 흐름은 (1) 연결, (2) 룸 생성 그리고 (3) 이벤트 전송이 C# 그리고 다른 언어의 애플리케이션에서 일반적입니다.

유니티 엔진으로 개발하는 경우 게임 상태와 시뮬레이션을 동기화하는 데 도움이 되는 Fusion 또는 Quantum을 사용하는 것이 좋습니다.

마스터 서버 접속

처음에 해야 할 일은 클라이언트가 클라우드에 접속하는 것 입니다. 이 프로세스를 마스터 서버 접속이라고 합니다. 여기서부터 마스터 서버가 모든 클라이언트에서 게임 서버로 보내는 전송 내용, 클라우드 내 로드 밸런싱과 사용 가능한 룸을 관리하게 됩니다.

데모에 있는 코드를 자세히 살펴보겠습니다.

C#

// From GameLogic.cs                        
public GameLogic(string masterAddress, string appId, string gameVersion) : base(masterAddress, appId, gameVersion)
{
    this.LocalPlayer.Name = "usr" + SupportClass.ThreadSafeRandom.Next() % 99;

    this.AutoJoinLobby = false;
    this.UseInterestGroups = true;
    this.JoinRandomGame = true;

    this.DispatchInterval = new TimeKeeper(10);
    this.SendInterval = new TimeKeeper(100);
    this.MoveInterval = new TimeKeeper(500);
    this.UpdateOthersInterval = new TimeKeeper(this.MoveInterval.Interval);
}
                    

GameLogic클래스는 LoadBalancingClient 클래스에서 상속되었으므로 마스터와 게임 서버 간의 상태를 보관하고 자동으로 전이(transitions)를 실행합니다. GameLogic 생성자에서 사용된 아규먼트들에 대해서 좀 더 자세히 살펴보겠습니다.

  1. string masterAddress: 연결한 (마스터)서버의 URL. Photon 지역 목록을 살펴보세요.
  2. string appId: 당사의 클라우드 시스템에서 애플리케이션 식별에 사용됩니다. AppId 가 없다면 Photon Cloud 관리 화면에서 AppId를 찾을 수 있습니다. 데모 프로그램이 동작하게 하기 위해서는 유효한 AppId를 입력해야 합니다.
  3. strin gameVersion: 게임 빌드를 구분하기 위해 선택된 스트링입니다. 동일한 버전 번호을 가진 클라이언트 간에만 매치되고 서로 통신할 수 있습니다. 이 특성 때문에 이전 클라이언트 접속을 끊지 않고 기능 추가를 쉽게 할 수 있습니다.
particle demo screenshot (unity3d sdk)
Particle Demo 스크린샷 (Unity3D SDK)

연결 이후 Photon Cloud는 명령 처리 준비를 합니다. 이제부터는 모든 것이 관리되므로 세심하게 관리할 필요가 전혀 없습니다! 아래의 다이어그램에서 회색으로 표시된 사각형은 Photon Cloud 가 관리한다는 것을 볼 수 있습니다. 클라이언트는 화살표 옆에 있는 간단한 명령들만 전송하면 됩니다.

photon cloud simple workflow
Photon Cloud의 간단한 작업 흐름

이제 마스터 서버에 접속했으므로 룸의 목록을 보고 생성하고 참가할 수 있습니다. 이 시점에서 플레이어들은 서로 통신하거나 소통할 수 없습니다. 여기서부터 룸 개념이 작동하게 됩니다. 다음은 플레이어 간 연결하는 방법에 대하여 설명해드리고자 합니다.

로비, 룸 생성과 룸 참여

기본적으로 LoadBalancing API는 클라이언트가 연결되었을 때 게임의 "로비"로 이동시켜 줍니다. 로비에 있는 동안 Master 서버는 클라이언트에게 룸의 목록을 제공해 줍니다. 트래픽을 낮게 유지하기 위해서 로비에서는 클라이언트 간에 통신을 할 수 없습니다.

룸은 플레이어 간 통신하는 곳(게임 플레이 장소)과 분리된 지역으로 간주될 수 있습니다. 플레이어들이 동일한 룸에 있으면 서로 이벤트를 송수신 할 수 있고, 룸 속성을 변경/갱신 등을 할 수 있습니다.

다음에 나오는 예제에서는 "OpCreateRoom" 을 사용하여 룸을 생성하고 오픈합니다. 룸 하나를 생성하고 생성된 룸에 들어갑니다.

C#

    RoomOptions options = new RoomOptions();
    options.options.maxPlayers = 4;
    peer.OpCreateRoom("Room 42", options, TypedLobby.Default);

가장 주목해야 할 파라미터와 RoomOptions 들은 다음과 같습니다.

  • string roomName 룸의 이름으로 룸을 식별하고 들어가는데 사용됩니다.
  • bool .RoomOptionsisVisible 이 변수는 로비 (Master 서버에 연결되었으나 아직 룸에 들어가지 않은 플레이어들이 있는 곳)에서 룸을 보이게 할지에 대한 여부를 결정합니다. 이러한 룸들은 클라이언트가 정확한 룸의 명칭을 알 수 있다면 룸에 참여할 수 있습니다.
  • bool RoomOptions.isOpen 클라이언트가 참가할 수 있는지의 여부를 결정합니다. 룸 안에 있는 클라이언트들은 이 값이 변경되어도 영향을 받지 않습니다. 하지만 룸을 떠난 이후 isOpen 값이 false 이면 다시 참여할 수 없습니다.
  • byte RoomOptions.maxPlayers 룸에 들어갈 수 있는 최대 플레이어 수를 지정합니다. 0으로 설정을 하게 되면 무제한으로 들어갈 수 있습니다. 하나의 룸에 많은 수의 플레이어를 참여하게 하고 싶다면 당사의 Photon Server MMO Application 을 보셔야 할 것입니다!
  • Hashtable RoomOptions.customRoomProperties 은 선택적 키/값의 집합으로 룸에 대한 설명을 정의할 수 있습니다. 예: key = "level" , value = "de_dust" 등. 속성은 동일 룸에 있는 모든 클라이언트들에게 동기화되며 매치메이킹의 역할을 합니다. 아래에서 속성에 대해 자세히 살펴보세요.
  • string[] RoomOptions.customRoomPropertiesForLobby 는 로비에서 볼 수 있는 속성들입니다.

Photon에서는 실행 시에 룸과 플레이어의 프로퍼티들을 변경할 수 있으므로 customGameProperties 를 사용하여 설정하는 것에 제약이 없습니다. 룸 안에서는 room.SetCustomProperties(props) 를 사용하여 새로운 값을 설정하거나 기존의 값을 덮어쓰게 됩니다. 변경사항은 머지 될 것이므로 변경하고 싶은 키를 전달만 해주면 됩니다.

룸은 여러 개의 프로퍼티들을 가질 수 있으나 매치메이킹에서는 일반적으로 몇 개만 사용하기 때문에 Photon은 로비에서 사용할 수 있는 룸 프로퍼티 키 목록을 정의하는 것을 예측합니다. 심지어 RoomOptions.customRoomProperties 에 아직 정의되어 있지 않은 키들도 나중에 string[] customRoomPropertiesForLobby 와 값을 채워 사용할 수도 있습니다.

loadbalancing room properties example
LoadBalancing 룸 프로퍼티 예제

룸 프로퍼티와 마찬가지로 플레이어별로 커스텀 프로퍼티들을 설정할 수 있습니다. 각 클라이언트는 룸에 참여하기 전에도 LoadBalancingClient.localPlayer.SetCustomProperties() 를 이용하여 플레이어 프로퍼티들을 설정할 수 있습니다. 프로퍼티들은 해당 클라이언트로 값이 유지되며 클라이언트가 참여 또는 생성한 모든 룸과 동기화됩니다.

loadbalancing player properties example
LoadBalancing 플레이어 프로퍼티 예제

이제 룸을 성공적으로 생성했으므로 다른 플레이어들이 룸에 참여할 시간입니다! 룸에 참여하는 것으 빠르고 쉬워서 특별히 이 오퍼레이션에 대해서 설명할 부분이 없습니다.

C#


// From LoadBalancingClient.cs                        
public void OnOperationResponse(OperationResponse operationResponse)
{
    ...
    this.OpJoinRoom(name);
}
                

이제 플레이어들이 서로 어떻게 소통하는지 살펴보도록 하겠습니다.

이벤트 전송

우리는 상호 소통을 하려는 클라이언트들에 대해서 단순한 이벤트 시스템을 사용합니다. 이벤트는 주어진 룸 안에 있는 플레이어 사이에서 정보를 빠르고 신뢰성 있게 송수신 할 수 있는 주요 방법입니다. 게임 로직에 필요한 모든 데이터는 이 방식으로 클라이언트 간에 전송될 수 있습니다. 필요에 따라 프로토콜을 파라미터로 명시(UDP vs TCP 또는 신뢰 UDP vs 비신뢰 UDP) 하여 정보 교환 방식을 커스터마이징 할 수 있습니다.

loadbalancing raiseevent operation diagram
LoadBalancing RaiseEvent 작동 다이어그램

이벤트는 룸에 있는 참가자들에게 분배됩니다. 특정 플레이어, 그룹 또는 모든 사람들에게 이벤트를 전달할지 결정할 수 있습니다.

Particle 데모에서 사용한 색상 변경에 대한 이벤트를 예제로 살펴보겠습니다.

C#

                        
public void ChangeLocalPlayercolor()
{
    if (this.LocalPlayer != null)
    {
        this.LocalPlayer.RandomizeColor();
        this.loadBalancingPeer.OpRaiseEvent(DemoConstants.EvColor, this.LocalPlayer.WriteEvColor(), this.SendReliable, new RaiseEventOptions() { CachingOption = EventCaching.AddToRoomCache });
    }
}
                     
                    

OpRaiseEvent의 아규먼트는 다음과 같습니다.

  • byte eventCode 이벤트 코드로 발생시킬 실제 이벤트를 지정합니다. Photon에서는 255로 시작하여 아래로 감소하는 미리 정의된 이벤트들이 있습니다. 1부터 199까지 게임 로직에서 사용할 자신만의 이벤트를 정의하여 사용할 수 있습니다.
  • Hashtable evData 이 해시테이블에 전송할 데이터를 채울 수 있습니다. 이는 중앙 데이터 구조로서 클라이언트 사이에서 정보 교환에 사용될 것입니다. 게임 로직의 반복되고 표준화된 단계(예, 턴의 종료)는 이벤트로 전달하는 것이 좋습니다.
  • bool sendReliable 이 플래그를 "true"로 설정하면 UDP가 신뢰 UDP로 전환됩니다. 이 의미는 전송 시에 손실된 패킷들이 있으면 재전송 되고 클라이언트들이 보낸 순서대로 패킷을 해석한다는 것을 보장한다는 것입니다. 이렇게 하면 추가적인 메시지 데이터가 전체 통신에 추가되는 것은 물론 단계가 추가되므로 성능이 나빠지게 됩니다.
  • byte RaiseEventOptions.channelId 그룹에 다른 채널을 사용할 수 있고 전송하고 있는 이벤트의 우선순위를 정할 수 있습니다. 이 기능은 간단한 예제를 통하여 설명하겠습니다: 플레이어들의 위치에 대한 정보를 전송하기 위하여 채널 1을 사용하고 있습니다. 이런 유형의 게임에서는 매우 높은 신뢰가 필요하기 때문에 신뢰UDP로 설정해 놓았습니다. 특정 시점에서 채널 1에 있는 플레이어 한 명의 연결 상태가 좋지 않아 수많은 양의 패킷이 손실되어 엄청난 양의 메시지로 넘쳐나고 있으면 이 메시지는 재전송 되어야 합니다. 만약 새로운 중요한 이벤트( 라운드 종료와 같은)가 들어왔을 때 현재 클라이언트들이 채널 1로부터 수신된 모든 위치에 대한 정보를 갱신하려고 여전히 바쁘게 움직이고 있으면 라운드 종료 정보를 알리는 데 시간이 걸릴 것입니다. 따라서 이 이벤트를 channelId 0으로 처리하여 모든 큐의 메시지 중에서 가장 먼저 처리하는 것입니다. 이 기능을 잘 사용하면 긴급한 것에 반응하여 게임 로직의 흐름이 올바르게 진행되는 것을 보장할 수 있을 뿐만 아니라 연결 상태가 좋지 않은 환경에서도 처리할 수 있습니다.
  • int[] RaiseEventOptions.targetActors 룸에서 이벤트를 보내기 위한 ActorNumbers의 리스트.
  • EventCaching RaiseEventOptions.CachingOption 서버가 어떻게 이벤트 캐싱-wise를 다룰 것인지에 대해 영향을 미칩니다. 나중에 참가한 플레이어에 대한 이벤트 캐시 여부 또는 이전 캐시 된 이벤트의 삭제.
particle 데모 (unity3d sdk): 룸 뷰 스크린샷
Particle 데모 (Unity3d SDK): 룸 뷰 스크린샷

마지막으로 수신자 그룹에 지정해서 사용할 수 있는 추가적인 오버로드가 있습니다.

이 포스트를 시간 내어 읽어 주셔서 감사합니다! 이 아티클에 대하여 질문 또는 코멘트가 있으면 포럼을 통하여 저희에게 알려주세요. 저희는 귀하의 피드백을 매우 소중하게 여깁니다.

Back to top