타입 0 인스턴스에서 동시 연결 수 상한선은 100입니다. 그 외 제한은 없습니다. “방 25개 상한선”은 일반적인 게임에서 양호한 성능을 유지하면서 만들 수 있는 최대 방 수를 추정한 것입니다.

양호한 성능을 유지하면서 만들 수 있는 실제 방 수는 한 장면(scene)에서 복제된 개체의 수 등 여러 요인에 따라 달라집니다. 적정 방 수를 초과하면 게임 성능이 떨어지고 게임 플레이에 문제가 생길 수 있습니다. 따라서, Strix Cloud에서는 게임 타이틀에서 방 서버 인스턴스당 최대 방 수를 제한할 수 있습니다. 이 제한은 고정된 값이 아니며 사용자가 게임에 맞추어 마음대로 정할 수 있는 것입니다. 타입 0 인스턴스에서도 25보다 큰 수를 설정할 수 있습니다. 기본 값은 100입니다. 사용자가 설정한 한도에 도달하면 방은 그것을 초과해 만들 수 없습니다.

한편, Strix Cloud는 방 수 외에도 인스턴스 사양과 관계없이 월간 무료 데이터 용량이 60GB로 제한되어 있습니다. 데이터가 이것을 초과하면 데이터 추가 요금이 발생합니다. 결제 방법을 등록하지 않고 타입 0 인스턴스를 이용할 수 있지만 결제 방법 설정 없이 월 데이터 전송이 60GB에 도달하면 인스턴스가 멈출 수도 있습니다.

• 서로 다른 게임 타이틀이 같은 서버를 공유하면 특정 게임 타이틀의 부하가 지나치게 높아졌을 때 다른 게임 타이틀이 영향을 받습니다.
• 서로 다른 게임 타이틀의 클라이언트가 같은 방에 모이면 복제와 동기화를 처리하는 데 문제가 생깁니다. 이는 네트워크 개체의 타입 ID 같은 일부 정보에 일관성이 사라지거나 각종 STRIX 컴포넌트의 설정이 서로 어긋나기 때문입니다. 이것을 피하기 위해서는 서로 다른 게임 타이틀의 클라이언트가 같은 방에 모이지 않도록 관리해야 합니다.

인스턴스는 언제든 다운그레이드와 업그레이드가 가능합니다. 단, 그 후에는 반드시 서버를 다시 시작해야 합니다.

방 수의 경우, 조건 없이 방을 검색한 후 방의 수를 세면 알 수 있습니다. 프로세스 중에 각 방에 있는 플레이어 수를 모두 더해도(memberCount 속성) 실제 연결 수를 알 수 있습니다. 단, 방이 많거나 프로세스 중에 방이 생성 또는 삭제되거나, 플레이어들이 방에 들락날락할 수 있다면 도출되는 수는 추정값으로 봐야 합니다.

사람들이 한 그룹으로서 애플리케이션을 하나 관리해야 한다면 그 그룹 안에서 공유 계정을 만들면 됩니다. 단 공유 계정은 보안 문제가 생길 수도 있으므로 공유 계정을 쓸 때는 조심해야 합니다.

Strix Cloud의 요금은 인스턴스 이용료, 인스턴스 관리비, 데이터 추가 요금 등 세 가지로 나뉩니다. 그중에서 인스턴스 이용료와 데이터 추가 요금은 정지 인스턴스에는 부과되지 않습니다. 단, 타입 1 이상 인스턴스에는 정지 시에도 인스턴스 관리비가 부과됩니다.

Strix Cloud의 서버 인스턴스는 오랫동안 계속 실행해도 안정적인 운영이 가능하도록 설계되어 있습니다. 정기적으로 재시작할 필요는 없습니다. 물론 운영 중에 정기적으로 재시작하면 더 안정적으로 실행됩니다. 그러나 Strix Cloud는 자동 재시작 기능이 없습니다. 따라서 수동으로 해야 합니다.

방 서버 수 또는 구성을 변경할 경우, 서버 인스턴스를 재시작해야 할 수도 있습니다. 서버 부하가 너무 높아져 운영이 불안정해져도 서버 인스턴스 재시작이 필요할 수 있습니다. 그런 상황을 피하려면 게임 타이틀에 맞추어 방 수 또는 초당 메시지 수를 제한해야 합니다.

STRIX는 퍼블릭이라는 OAuth 클라이언트 타입을 지원하며 네이티브 애플리케이션 프로파일을 기반으로 합니다. 또한 허가 코드 부여를 이용하는 것으로 가정합니다. 단, 필요하다면 클라이언트 프로그램 설계에 따라 클라이언트 자격증명 부여 같은 다른 부여를 이용해도 됩니다.

토큰 허가를 이용하려면 서버 측 설정이 필요합니다. Strix Cloud를 이용할 때는 애플리케이션 대시보드의 옵션 페이지에서 허가 활성화 체크박스에 체크해 주십시오. 또한 사용자 리소스 URL에 리소스 서버의 “사용자 식별 정보를 제공하는 서비스”(OpenID Connect의 UserInfo 엔드포인트)의 엔드포인트 URL을 입력하십시오. 보호 리소스인 식별 정보의 형식은 (OpenID Connect의 openid 스키마 같은) JSON 개체이며 “사용자 ID”(“서브” 클레임 등)와 “사용자명”(“이름” 클레임 등)이 들어 있다고 가정합니다.

실제 OAuth 플로우는 다음과 같습니다.

(1) 게임 프로그램은 플랫폼의 기본 웹 브라우저를 시작하여 허가 서버의 허가 엔드포인트에 접속, 리소스 소유자(플레이어)에게 허가 코드를 발급합니다.
(2) 게임 프로그램은 허가 코드를 받은 후 허가 서버의 토큰 엔드포인트에 OAuth 클라이언트로 접속하여 접속 토큰을 받습니다.
(3) 게임 프로그램은 SDK에 액세스 토큰을 전달합니다. (Strix Unity SDK를 이용할 때는 StrixNetwork.instance.authorizationAccess 토큰으로 설정합니다. Strix Unreal SDK를 이용할 때는 그것을 InitializeStrixNetworkWithHttpAccessToken 함수의 전달인자로 지정하십시오.) 토큰이 서버 연결 중에 STRIX 서버로 전송됩니다.
(4) STRIX 서버는 토큰을 이용하여 리소스 서버에 OAuth 클라이언트로 접속, (OAuth의 관점에서) 보호 리소스인 플레이어 식별 정보를 받습니다.

이것으로 OAuth 플로우는 끝나지만 STRIX 서버는 이후 클라이언트 인증에 쓰이는 STRIX 자체 클라이언트 인증 토큰을 발급합니다. 또한 리소스 서버에서 받는 식별 정보(즉 사용자명, 사용자 ID) 중 일부는 클라이언트(플레이어)가 방에 들어오면 자동으로 방 구성원 속성으로 설정됩니다.

예를 들어, 클라이언트가 50명 있는 방에서 동기화에 필요한 통신 데이터의 양은 다음과 같이 계산합니다.

한 클라이언트가 메시지를 보내면 서버에서 그 메시지를 50 클라이언트에게 보냅니다. 즉 총 50 메시지를 보내는 것입니다. 50 클라이언트 각각이 메시지를 하나씩 보내면 서버는 50 메시지를 받아 총 2,500 메시지(50 x 50)를 보내게 됩니다. 이 값에 클라이언트 하나가 1초에 보내는 메시지 수를 곱하면 서버가 1초에 보내는 메시지 수가 나옵니다. 이 값에 메시지당 데이터 크기를 곱하면 서버에서 초당 나오는 데이터의 양을 추정할 수 있습니다. 공식은 “50 × 50 × (클라이언트당 초당 메시지 수) × (메시지 하나의 데이터 크기)”입니다.

서버 구성 매개변수에 따라 이 값의 최대값이 정해지므로 초당 데이터 양을 효과적으로 제한할 수 있습니다.

메시지의 크기는 콘텐츠에 따라 달라집니다. 텍스트 채팅에서 나오는 메시지가 점유하고 있는 채팅 텍스트 스트링의 바이트 수(UTF-8)에 헤더(30~40바이트)를 더하면 대략 맞습니다.

StrixReplicator 컴포넌트가 복제를 하거나 StrixMovementSynchronizer가 이동 동기화를 하면 메시지가 생성되며 이 메시지들은 데이터 추가 요금을 계산할 때 데이터의 양에 반영됩니다. StrixMovementSynchronizer는 지정된 기간에 SyncPeriodMin과 SyncPeriodMax를 통해 메시지를 보내며, 이동 동기화에 필요한 데이터는 일반 게임에서 데이터 대부분을 차지합니다.

게임 클라이언트에서 마스터 서버와 방 서버에 접속할 때는 http/https와 같은 웹 프로토콜과는 다른 통신 프로토콜을 이용하며, 이것은 일반 프록시를 통과하지 못합니다. TCP 연결을 투명하게 통과하는 프록시가 필요합니다. 방화벽 뒤에서 접속해야 한다면 소위 “포트의 구멍”이라고 하는 기법을 이용하기를 권장합니다.

WSS(Secure WebSocket)를 통신 프로토콜로 선택하는 경우, 비교적 새 프록시를 사용할 수 있습니다. 단 wss 프로토콜을 지원하는 경우에 한합니다. 프록시 사양을 참조해 주십시오.

서버 인스턴스가 시작되면 IP 주소가 동적으로 할당됩니다. 재시작할 때 바뀌기도 합니다. Strix Cloud의 서버 인스턴스가 특별히 이용하는 IP 주소는 없다고 보면 됩니다.

Strix Cloud에서는 한 서버 인스턴스에 연결되어 있는 클라이언트의 수를 의미합니다.

Strix Unity SDK 버전 1.5.0부터 HTML5/WebGL 플랫폼에 대한 빌드가 가능합니다. 기존 STRIX 클라이언트를 WebGL 플랫폼에서 실행하기 위해서는 서버 구성과 일부 스크립트를 업데이트해야 합니다. 자세한 내용은 설명서를 참조해 주십시오.

리드 플레이어가 방을 만들고 자체 사용자 관리 서버(STRIX와 다른 것)를 통해 친구들을 방에 초대한다고 가정해 보겠습니다.

이때 방을 고유하게 식별하는 데 필요한 정보는 방의 primaryKey 속성입니다. 또한 그것에 연결하기 위해서는 방 서버의 주소(IP 주소와 포트 번호)가 필요합니다. 리드 플레이어는 이 정보를 받아 친구들에게 전달해야 합니다. 그러면 각 친구는 받은 정보를 이용해 JoinRoom을 호출, 방에 들어갑니다.

이 프로세스를 구체적으로 설명하면 다음과 같습니다.

방을 만든 후에는 StrixNetwork.instance.room.GetPrimaryKey()를 통해 방의 primaryKey 속성을 이용할 수 있습니다.
연결된 방 서버의 주소는 StrixNetwork.instance.roomSession.messageChannel.GetRemoteAddress()를 통해 알 수 있습니다.
각 친구는 이것을 받고 StrixNetwork의 JoinRoom 메서드를 이용해 방에 들어갑니다.

플레이어들에게 보여줄 정보가 방 속성에 저장되어 있다고 하겠습니다.
초대장에서 가져온 주소로 지정된 방 서버에 연결한 후 primaryKey로 방의 방 속성을 가져옵니다.

방에 들어가지 않고도 StrixNetwork.instance.roomSession.Connect()를 이용해 방 서버에 연결할 수 있습니다.
이어서, StrixNetwork.instance.roomSession.roomClient.Get()에 방의 primaryKey를 지정하면 방 속성을 가져올 수 있습니다.

미리 정의한 개체(GameObject prefab)가 동적으로 인스턴스화될 때 미리 StrixReplicator가 연결되어 있다면 그 개체는 자동으로 복제되고 레플리카가 다른 클라이언트에 생성됩니다. 동시에, 동기화 대상이 되는 개체 속성의 값도 동기화됩니다. 레플리카가 생성되면 일반 개체 인스턴스화 이벤트(예: Unity의 Start callback)가 실행되므로 프로젝트의 자동 생성으로 촉발되는 프로세싱은 무엇이든 이 이벤트를 이용해 가능합니다.

반면, 동적으로 생성된 비복제 개체(StrixReplicator가 없는 GameObjects)는 통보가 불가능합니다. 아쉽게도 STRIX에는 그런 기능이 없습니다. 대신에, 클라이언트는 그 동적 개체를 만든 클라이언트에서 RPC 또는 메시지 전달 기능을 이용하여 다른 클라이언트로 커스텀 메시지를 보내는 방법으로 이 기능을 구현할 수 있습니다.

StrixNetwork.instance.roomSession.roomClient에는 두 이벤트가 있습니다. RoomJoinNotified는 누군가 방에 들어오면 알려주고 RoomLeaveNotified notifies는 누군가 방에서 나가면 알려줍니다.

Strix Unity SDK에는 방장이 바뀌면 알려주는 이벤트가 있습니다. 이 이벤트는 StrixNetwork.instance.roomSession.roomClient.RoomOwnerChanged로 이용할 수 있습니다. 이 이벤트 처리기는 해당 프로세싱에 적합합니다.

방장이 업데이트나 코루틴(coroutine) 중에 바뀌었는지 확인하고 싶다면 이벤트 처리기 대신 전 방장의 UID를 현 방장의 UID와 비교하면 됩니다. StrixNetwork.instance.room.GetOwnerUid()로 현 방장을 나타내는 UID를 가져온 후 그것을 전 방장의 UID와 비교하는 것입니다. UID는 인터페이스이므로 == 연산자를 쓰면 안 되고 대신 StrixNetwork.instance.room.GetOwnerUid().Equals(previousRoomOwnerUid)와 같이 Equals 메서드를 써야 합니다.

클라이언트가 사용자 인증을 했고 사용자의 식별정보만 필요하다고 가정할 수 있다면 “name”이라고 하는 방 구성원 속성에 사용자의 신원을 설정할 수 있습니다. 타이틀이 플레이어에게 보여줄 사용자명과 프로그램이 내부에서만 이용할 사용자 ID를 구분한다면 일반적으로 사용자명은 “name” 속성에, 사용자 ID는 직접 정의하는 커스텀 속성에 저장합니다. 규칙은 “userid”를 원하는 목적에 맞추어 커스텀 속성의 이름으로 이용하는 것입니다.

서버를 통해 인증을 마친 사용자 정보를 받고 싶다면 토큰 인증 제도를 이용할 수 있습니다. 즉, 외부 인증 서버로 인증 토큰을 발급하면 클라이언트가 그것을 STRIX 서버로 전달하고 STRIX 서버는 사용자명과 사용자 ID를 인증 서버로부터 받습니다. 이 구조에서, STRIX 서버가 인증 서버에서 받는 사용자명과 사용자 ID는 자동으로 “name” 방 구성원 속성과 “userId” 커스텀 방 구성원 속성으로 각각 설정됩니다.

토큰 인증 제도에 관해서는 Strix Unity SDK 사용설명서를 참조해 주십시오. Strix Cloud에서 토큰 인증을 수행하도록 서버를 설정하는 방법은 Strix Cloud 사용자 가이드를 참조해 주십시오.

Strix Unity SDK에서 StrixNetwork.instance.roomSessionClosed 이벤트를 이용하면 됩니다. 방 번호 연결이 닫히면 이 이벤트가 발생하지만 네트워크가 끊어졌을 때 탐지하는 용도로도 이 이벤트를 이용할 수 있습니다.

이 메서드를 이용할 때 RPC는 대상 GameObject의 소유자(원 GameObject를 인스턴스화한 클라이언트)와 무관하게 방장의 GameObject에서 실행됩니다.

Strix Unity SDK을 이용할 때 같은 방에 있지 않은 클라이언트에게 메시지를 보내고 싶다면 별도 서버가 필요합니다. 예를 들어, Strix Messenger 서버에서는 현재 있는 방과 상관 없이 메시지를 보낼 수 있고 더 많은 클라이언트에게 방송도 할 수 있습니다.

단, 지정 플레이어에 대해 RPC를 호출할 수 있기 때문에 그룹 내 플레이어가 소수라면 클라이언트에서 그룹 멤버십을 관리하고 각 그룹 멤버에 대해 RPC를 반복 호출하여 그 기능을 시뮬레이션할 수는 있습니다.

GameObject의 소유자가 예컨대 LeaveRoom을 호출하여 방을 떠나면 원 GameObject와 그 레플리카는 일반적으로 파기됩니다. 그러나 이 행동은 StrixReplicator에 있는 syncDestroy로 변경할 수 있습니다.

특정 GameObject에 있는 syncDestroy 필드를 거짓으로 설정하면 GameObject의 파기를 피할 수 있습니다.
예를 들어, 에디터에서 prefab을 만들 때 syncDestroy를 거짓으로 설정하면 그 prefab에서 인스턴스화된 최초 GameObject는 물론 그 레플리카도 파기되지 않습니다.

자세한 설명이 이어집니다.

(백그라운드로 갈 때 행동)

STRIX를 이용하는 모바일 앱이 백그라운드로 가면 대개 서버에서 연결이 끊어집니다. 실제 끊어지는 시간은 OS와 그 버전별로 다르며 안드로이드의 경우엔 제조사나 모델에 따라서도 다르지만, 대개 1초부터 2분 사이입니다. 지연이 긴 경우, 앱이 끊어지기 전에 다시 활성화되면 끊어짐이 중단되고 계속 실행됩니다.

방 안에 있을 때 앱이 백그라운드로 가고 서버에서 끊어지면 STRIX는 방을 떠난 것으로 간주합니다. 연결이 끊어지면 레플리카는 모두 다른 클라이언트에서 삭제됩니다. 백그라운드로 넘어간 기기는 복귀 후(즉 활성화된 후) 방을 떠나기와 같은 사건을 처리합니다.

(방장이 백그라운드로 가는 경우)

방장이 백그라운드로 가면 연결이 끊어져 방을 떠난 것으로 간주됩니다.

방장 이동에 관한 서버 설정이 있습니다. 이것을 끌 경우, 방장이 방을 떠나면 방이 삭제되고 다른 멤버들은 강제 퇴장당합니다. 방장 이동을 켤 경우, 방장이 방을 떠나면 다른 멤버가 자동으로 방장이 되고 다른 멤버들은 계속 플레이를 할 수 있습니다. 방장이 이동할 클라이언트는 방 서버에서 선택합니다. 선택은 무작위입니다.

STRIX를 이용하는 모바일 앱이 백그라운드로 가면 대개 서버에서 끊어지고 방을 떠납니다. 실제 끊어지는 시간은 OS와 그 버전별로 다르며 안드로이드의 경우엔 제조사나 모델에 따라서도 다르지만, 대개 1초부터 2분 사이입니다.

Unity는 OnApplicationPause라고 하는 콜백이 있어 모바일 앱이 백그라운드로 가거나 활성 상태로 되돌아오면 호출됩니다. 이것으로 떠나기 전 지연을 줄일 수 있습니다. 앱이 백그라운드로 갈 때 LeaveRoom을 호출하면 연결이 끊어지기를 기다리지 않고 방을 떠납니다.

백그라운드에서 활성 상태로 돌아올 때 클라이언트는 방에 있지 않고 레플리카는 삭제된 상태입니다. 플레이를 계속할 수 없습니다. 전과 같은 방에 다시 들어가거나 다른 장면(홈 장면)으로 이동하는 등 적당히 대응해야 합니다.

Unity에서 OnApplicationPause의 인수는 백그라운드로 가는지, 되돌아오는지를 나타냅니다. 자세한 내용은 Unity 설명서를 참조해 주십시오.

가변 동기화를 이용할 때는 동기화가 고정된 빈도(sendRate에서 지정한 것)로 일어납니다. 그러나 동기화를 할 때마다 변수의 값을 모두 다 보내는 것은 아니며 값이 변한 것만 보냅니다. 따라서 가변 동기화와 RPC는 모두 상태가 변했을 때만 정보를 보내는 것처럼 행동하므로 트래픽에 큰 차이는 없습니다.

사용설명서의 “성능 개선 방법”에 따르면 RPC가 가변 동기화보다 성능이 더 놓지만 그것은 트래픽이 아니라 내부 SDK 내 내부 처리를 기준으로 한 것입니다.

가변 동기화는 변수의 값이 변했는지 탐지하는 오버헤드가 있습니다. 이 오버헤드는 대개 문제가 안 되지만 동기화 변수가 많고 대부분 거의 변하지 않는다면 측정 가능한 수준이 될 수도 있습니다. 예컨대 동기화 변수를 줄이고 RPC를 호출하도록 코드를 다시 써 사용자 입력을 처리한다면 오버헤드를 줄일 수 있습니다.

단 Strix Unity SDK에서 StrixMovementSynchronizer의 속성 값이 변하면 자동으로 동기화되지는 않습니다. 속성을 바꿀 때 소유자(원 개체)에서도 바꿔 줘야 하고 레플리카에서도 바꿔 줘야 합니다.

서버(마스터, 방)를 모두 멈추면 클라이언트는 로그인할 수 없고 연결은 실패합니다. 연결 오류로 발생한 “정비 알림”을 마스터 서버에 보여줘도 되지만 그 사례를 다른 오류(재시도하면 다시 연결될 가능성이 높은 일시적인 네트워크 장애)와 구별하기는 어렵습니다.

서버를 모두 다 멈추면 플레이어가 다 끊어지지만 역시 다른 끊김과 구별하기는 어렵습니다. 그리고 그렇게 “갑자기 끊는 것은” 일부 게임에서는 바람직하지 않을 수도 있습니다.

따라서 STRIX 서버 기능만을 이용해 정비 상태로 진입하는 것은 쉽지 않다고 해야 할 것 같습니다.

단, 콘솔 게임 타이틀을 개발하기 위해서는 특정 개발 환경이 필요하며 그것은 Strix Unity SDK에 들어 있지 않습니다. 플랫폼 공급자에게 별도로 구매해야 합니다.

Unity는 한 플레이를 마치면 그 장면에 있는 GameObjects를 파기하는데 프로세스 후에도 파기되지 않은 GameObjects가 남아 있으면 이 오류를 보고하는 것입니다. 일반적으로, OnDestroy를 처리 중일 때 새 GameObject를 인스턴스화하면 이 오류가 자주 발생합니다.

오류 메시지 전문은 다음과 같습니다.

장면을 닫을 때 지우지 않은 개체가 있습니다. (OnDestroy에서 새 GameObject를 스폰하셨습니까?) 다음과 같은 장면 GameObject가 발견되었습니다.
StrixNetworkManager

StrixNetworkManager는 Strix Unity SDK가 내부에서 이용하는 GameObject입니다. C# 스크립트가 StrixNetwork라는 싱글톤 인스턴스(StrixNetwork.instance)를 참조하면 StrixNetworkManager가 인스턴스화됩니다. 이것은 플레이가 끝나면 StrixNetwork 싱글톤 인스턴스와 함께 파기됩니다.

이 오류 메시지 끝에 StrixNetworkManager가 나와 있는 경우, 문제의 오류는 플레이 말미에 OnDestroy()와 같은 콜백 내부에서 StrixNetwork.instance에 액세스한 것이 원인일 가능성이 높습니다. StrixNetwork in OnDestroy()를 참조하지 않거나 StrixNetwork.isInitialized가 참으로 돌아왔음을 확인한 후에 STRIX 관련 후처리를 실행하면 이 오류를 피할 수 있습니다. (이것은 StrixNetwork의 싱글톤 인스턴스가 있을 때만 참을 리턴합니다. 파기된 후에는 거짓을 리턴합니다)

StrixMovementSynchronizer의 MaxSpeed의 값은 1초 후 움직인 거리입니다. MaxSpeed는 GameObject의 최고 속도로 설정해 주십시오.

Strix Unity SDK 사용 설명서에서 움직임 동기화 매개변수를 조정하는 방법도 참조해 주십시오.

a) 방 속성값을 변경하려면 SetRoom법을 호출해야 합니다. Strix Unity SDK에서 제공하는 클래스에 값을 쓰는 것만으로는 방 서버가 보유한 방 속성값을 변경하기 어렵습니다. 특히 StrixNetwork.instance.room의 호출 메서드, 예컨대 SetName()으로는 방 속성을 업데이트할 수 없습니다.

b) 방장만 SetRoom 메서드를 호출할 수 있습니다. 다른 클라이언트(플레이어)가 호출하면 오류가 발생하고(장애 처리기 실행) 값은 변하지 않습니다.

c) 값을 설정하거나 참조할 때(예: 방 속성들이 IDictionary<string, object> type로 표시될 때) 방 속성의 이름이 문자열로 지정되기도 합니다. 속성 이름이 잘못되어도 오류가 발생하는 것은 아니며 정확한 이름의 사용자 지정 속성으로 간주됩니다. 다음 항목에 집중하여 속성 이름이 올바른 것인지 확인해야 합니다.

• 속성 이름에서는 대소문자 구별이 중요합니다. 공백의 여부도 중요합니다. 대소문자가 바르게 쓰였는지 확인해 주십시오. (STRIX가 정의하는 방 속성 이름은 모두 소문자로 시작합니다)

d) 방 속성에는 데이터 형식이 있습니다. API 중에는 어떤 형식의 값이든 다 허용하는 것도 있지만 잘못된 데이터 형식으로 방 속성에 액세스하면 액세스가 되지 않습니다. 단, 오류는 탐지되지 않습니다.

• 값을 기본 속성으로 설정할 때는 값이 올바른 데이터 형식으로 되어 있는지 확인해 주십시오.
• 기본 속성의 값을 참조할 때는 올바른 데이터 형식이 쓰였는지 확인해 주십시오.
• 사용자 지정 속성에 액세스할 때는 데이터 형식의 설정과 가져오기가 일정한지 확인해 주십시오.

마스터 서버에 연결하고 SearchRoom과 같은 메서드로 방을 찾고난 후 JoinRoom을 호출해 그 방에 들어갈 때 방 서버 대신 마스터 서버의 주소(호스트 이름이나 IP 주소와 포트 번호)를 잘못 지정하면 JoinRoom이 응답하지 않을 수도 있습니다. (실제로, 시간 만료 때문에 실패 처리기는 약 30초 후에 실행됩니다)

ID를 보내는 방법에는 여러 가지가 있지만 플레이어 아바타의 외관이 신경쓰인다면 방 번호 속성을 이용하는 것이 좋습니다. 사용자 지정 속성("avatarId")을 정의하고 ID를 그 속성의 값으로 설정해 주십시오. 레플리카는 메쉬가 만들어질 때 또 속성 변경 이벤트가 트리거되었을 때 메쉬를 바꿀 수 있습니다.

리드 플레이어가 방을 만들고 자체 사용자 관리 서버(STRIX와 다른 것)를 통해 친구들을 방에 초대한다고 가정해 보겠습니다.

이때 방을 고유하게 식별하는 데 필요한 정보는 방의 primaryKey 속성입니다. 또한 그것에 연결하기 위해서는 방 서버의 주소(IP 주소와 포트 번호)가 필요합니다. 리드 플레이어는 이 정보를 받아 친구들에게 전달해야 합니다. 그러면 각 친구는 받은 정보를 이용해 Join Room 기능을 호출, 방에 들어갑니다.

이 프로세스를 구체적으로 설명하면 다음과 같습니다.

Strix Room 스트럭트의 id 속성에서 primaryKey 속성을 받을 수 있습니다. id 속성은 방을 만든 후에 Get Currnt Room 기능을 호출하면 제공됩니다. 리드 플레이어도 Create Room 호출 시 지정한 방 서버의 주소를 보내야 합니다. 각 친구는 이 정보를 받고 방 서버 주소를 Connect To Room Server 기능으로 보내 방 서버에 연결하고 이어서 JoinRoom 기능에서 방 ID를 지정할 수 있습니다.

Strix Unreal SDK 사용설명서에서도 관련 정보를 더 확인할 수 있습니다.

다음과 같이 하시면 됩니다.
플레이어들에게 보여줄 정보가 방 속성에 저장되어 있다고 하겠습니다.
초대에서 가져온 주소로 지정된 방 서버에 연결하고 나면 지정된 primaryKey로 방을 찾아 방 정보를 확인할 수 있습니다. 단, primaryKey를 통해 방을 검색하려면 C++ 코드가 필요합니다.
방법은 Strix Unreal SDK 사용설명서를 참조해 주십시오.

미리 정의한 개체(Actor)가 동적으로 스폰될 때 미리 StrixReplicator가 연결되어 있다면 그 개체는 자동으로 복제되고 레플리카가 다른 클라이언트에 생성됩니다. 동시에, 동기화 대상이 되는 개체 속성의 값도 동기화됩니다. 레플리카가 생성되면 Unreal Engine의 일반 개체 인스턴스화 이벤트(예: Event Begin Play) 또는 STRIX의 동기화 이벤트(예: On Sync Begin)가 실행되므로 개체의 자동 생성으로 촉발되는 프로세싱은 무엇이든 이 이벤트를 이용하여 가능합니다.

반면, 동적으로 생성된 비복제 개체(StrixReplicator가 없는 Actors)는 통보가 불가능합니다. 아쉽게도 STRIX에는 그런 기능이 없습니다. 대신에, 클라이언트는 그 동적 개체를 만든 클라이언트에서 RPC 또는 메시지 전달 기능을 이용하여 다른 클라이언트로 커스텀 메시지를 보내는 방법으로 이 기능을 구현할 수 있습니다.

Strix Notification Listener 컴포넌트에는 Strix Room Join Notification Arrived와 Strix Room Leave Notification Arrived 등 두 가지 이벤트가 있습니다. Strix Room Join Notification Arrived는 누군가 방에 들어오면 알려주고, Strix Room Leave Notification Arrived는 누군가 방을 떠나면 알려줍니다.

Strix Unreal SDK에는 방장이 바뀌면 알려주는 이벤트가 있습니다. 이것은 Strix Notification Listener component의 Strix Room Owner Changed 이벤트입니다. 이 이벤트 처리기는 해당 프로세싱에 적합합니다.

클라이언트가 사용자 인증을 했고 사용자의 식별정보만 필요하다고 가정할 수 있다면 “name”이라고 하는 방 구성원 속성에 사용자의 신원을 설정할 수 있습니다. 타이틀이 플레이어에게 보여줄 사용자명과 프로그램이 내부에서만 이용할 사용자 ID를 구분한다면 일반적으로 사용자명은 “name” 속성에, 사용자 ID는 직접 정의하는 커스텀 속성에 저장합니다. 규칙은 “userid”를 원하는 목적에 맞추어 커스텀 속성의 이름으로 이용하는 것입니다.

서버를 통해 인증을 마친 사용자 정보를 받고 싶다면 토큰 인증 제도를 이용할 수 있습니다. 즉, 외부 인증 서버로 인증 토큰을 발급하면 클라이언트가 그것을 STRIX 서버로 전달하고 STRIX 서버는 사용자명과 사용자 ID를 인증 서버에서 받습니다. 이 구조에서, STRIX 서버가 인증 서버에서 받는 사용자명과 사용자 ID는 자동으로 “name” 방 구성원 속성과 “userId” 커스텀 방 구성원 속성으로 각각 설정됩니다.

토큰 인증 제도에 관해서는 Strix Unreal SDK 사용설명서를 참조해 주십시오. Strix Cloud에서 토큰 인증을 수행하도록 서버를 설정하는 방법은 Strix Cloud 사용자 가이드를 참조해 주십시오.

Strix Notification Listener의 Room Context Closed 이벤트를 이용하면 됩니다.
이 이벤트는 방이 삭제되었을 때, 플레이어가 방을 나갔을 때, 플레이어가 강퇴되었을 때 등 여러 상황에서 실행되지만 네트워크가 끊어졌을 때도 실행됩니다.

이 기능을 이용할 때 RPC는 대상 Actor의 소유자(원 Actor를 인스턴스화한 클라이언트)와 무관하게 방장의 Actor에서 실행됩니다.

Strix Unreal SDK로는 채널 기능을 이용해 여러 방에 동시에 입장할 수 있으므로 온라인 플레이어 모두가 항상 입장했을 때 방 구성원 전체에 RPC를 보내는 방을 만들 수 있습니다. 그러나 이렇게 하면 방의 용량 때문에 동시 연결자 수가 제한됩니다.

STRIX 게임 서버와 별도로 서버를 운영해 메시지를 보내도 됩니다. 예를 들어, Strix Messenger 서버에서는 현재 있는 방과 상관 없이 메시지를 보낼 수 있고 더 많은 클라이언트에게 방송도 할 수 있습니다.

단, 지정 플레이어에 대해 RPC를 호출할 수 있기 때문에 그룹 내 플레이어가 소수라면 클라이언트에서 그룹 멤버십을 관리하고 각 그룹 멤버에 대해 RPC를 반복 호출하여 그 기능을 시뮬레이션할 수는 있습니다.

Actor의 소유자가 예컨대 LeaveRoom을 호출하여 방을 떠나면 원 Actor와 그 레플리카는 일반적으로 파기됩니다. 그러나 이 동작은 Strix Replicator에서 Should Receive Destroy Events로 바꿀 수 있습니다.

특정 Actor에서 Should Receive Destroy Events 속성을 거짓으로 설정하면 Actor가 파기되지 않습니다.
예를 들어, Editor에서 Actor의 클래스를 정의할 때 Should Receive Destroy Events 속성을 거짓으로 설정하면 그 클래스에서 스폰된 최초 Actor와 그 레플리카는 파기되지 않습니다.

Strix Unreal SDK의 Blueprint 기능은 UStrixBlueprintFunctionLibrary 클래스에 정의되어 있습니다. Blueprint 기능의 일반 호출 규약에 따라 C++에서 이 기능을 호출할 수 있습니다. 또한 Blueprint 기능 대부분은 UStrixNetworkFacade 클래스에 상응하는 C++ API가 정의되어 있습니다. 따라서 그것을 대신 호출해도 됩니다.

또 사용자 지정 메시지를 정의해 Message Relay API를 통해 보내고 받아도 됩니다. 자세한 내용은 Strix Unreal SDK 사용설명서의 Relay Message 단원을 참조해 주십시오.

자세한 설명이 이어집니다.

(백그라운드로 갈 때 행동)

STRIX를 이용하는 모바일 앱이 백그라운드로 가면 대개 서버에서 연결이 끊어집니다. 실제 끊어지는 시간은 OS와 그 버전별로 다르며 안드로이드의 경우엔 제조사나 모델에 따라서도 다르지만, 대개 1초부터 2분 사이입니다. 지연이 긴 경우, 앱이 끊어지기 전에 다시 활성화되면 끊어짐이 중단되고 계속 실행됩니다.

방 안에 있을 때 앱이 백그라운드로 가고 서버에서 끊어지면 STRIX는 방을 떠난 것으로 간주합니다. 연결이 끊어지면 레플리카는 모두 다른 클라이언트에서 삭제됩니다. 백그라운드로 넘어간 기기는 복귀 후(즉 활성화된 후) 방을 떠나기와 같은 사건을 처리합니다.

(방장이 백그라운드로 가는 경우)

방장이 백그라운드로 가면 연결이 끊어져 방을 떠난 것으로 간주됩니다.

방장 이동에 관한 서버 설정이 있습니다. 이것을 끌 경우, 방장이 방을 떠나면 방이 삭제되고 다른 멤버들은 강제 퇴장당합니다. 방장 이동을 켤 경우, 방장이 방을 떠나면 다른 멤버가 자동으로 방장이 되고 다른 멤버들은 계속 플레이를 할 수 있습니다. 방장이 이동할 클라이언트는 방 서버에서 선택합니다. 선택은 무작위입니다.

STRIX를 이용하는 모바일 앱이 백그라운드로 가면 대개 서버에서 끊어지고 방을 떠납니다. 실제 끊어지는 시간은 OS와 그 버전별로 다르며 안드로이드의 경우엔 제조사나 모델에 따라서도 다르지만, 대개 1초부터 2분 사이입니다.

Unreal Engine에는 Platform Game Instance라고 하는 클래스가 있습니다. 이것(또는 거기서 유래한 클래스)을 이용해 백그라운드 상태 전환/탈전환을 탐지할 수 있습니다. 앱이 백그라운드로 가면 Application Will Enter Background Delegate가 실행되고, 다시 되돌아오면 Application Has Entered Foreground Delegate이 실행됩니다.

Application Will Enter Background Delegate를 이용하여 떠나기 전에 지연을 줄일 수 있습니다. 앱이 백그라운드로 갈 때 Leave Room을 호출하면 연결이 끊어지기를 기다리지 않고 방을 떠납니다.

백그라운드에서 활성 상태로 돌아올 때 클라이언트는 방에 있지 않고 레플리카는 삭제된 상태입니다. 플레이를 계속할 수 없습니다. Application Has Entered Foreground Delegate을 이용해 전과 같은 방에 다시 들어가거나 다른 장면(홈 장면)으로 이동는 등 적당히 대응해야 합니다.

Platform Game Instance에 관한 자세한 사항은 Unreal Engine 문서를 참조해 주십시오.

가변 동기화를 이용할 때는 동기화가 고정된 빈도(Ticks Per Second에서 지정한 것)로 일어납니다. 그러나 동기화를 할 때마다 변수의 값을 모두 다 보내는 것은 아니며 값이 변한 것만 보냅니다. 따라서 가변 동기화와 RPC는 모두 상태가 변했을 때만 정보를 보내는 것처럼 행동하므로 트래픽에 큰 차이는 없습니다.

사용설명서의 “성능 개선 방법”에 따르면 RPC가 가변 동기화보다 성능이 더 놓지만 그것은 트래픽이 아니라 내부 SDK 내 내부 처리를 기준으로 한 것입니다.

가변 동기화는 변수의 값이 변했는지 탐지하는 오버헤드가 있습니다. 이 오버헤드는 대개 문제가 안 되지만 동기화 변수가 많고 대부분 거의 변하지 않는다면 측정 가능한 수준이 될 수도 있습니다. 예컨대 동기화 변수를 줄이고 RPC를 호출하도록 코드를 다시 써 사용자 입력을 처리한다면 오버헤드를 줄일 수 있습니다.

Strix Unreal SDK에서는 Strix Movement Synchronizer가 동기화되므로 소유자(원 Actor)의 Strix Movement Synchronizer 값을 바꾸면 레플리카의 값도 바뀝니다. 반대로, 레플리카에서 속성 값을 바꾸면 그것이 소유자에게 반영되지는 않습니다. 속성값은 항상 소유자에서 바꿔야 합니다.

서버(마스터, 방)를 모두 멈추면 클라이언트는 로그인할 수 없고 연결은 실패합니다. 연결 오류로 발생한 “정비 알림”을 마스터 서버에 보여줘도 되지만 그 사례를 다른 오류(재시도하면 다시 연결될 가능성이 높은 일시적인 네트워크 장애)와 구별하기는 어렵습니다.

서버를 모두 다 멈추면 플레이어가 다 끊어지지만 역시 다른 끊김과 구별하기는 어렵습니다. 그리고 그렇게 “갑자기 끊는 것은” 일부 게임에서는 바람직하지 않을 수도 있습니다.

따라서 STRIX 서버 기능만을 이용해 정비 상태로 진입하는 것은 쉽지 않다고 해야 할 것 같습니다.

단, 콘솔 게임 타이틀을 개발하기 위해서는 특정 개발 환경이 필요하며 그것은 Strix Unreal SDK에 들어 있지 않습니다. 플랫폼 공급자에게 별도로 구매해야 합니다.

또한 플랫폼 공급자가 제공하는 개발 환경 외에 당사에서 공급하는 콘솔용 전용 STRIX 라이브러리도 필요합니다. 그러나 이 라이브러리는 Strix Unreal SDK에 들어 있지 않으며, Strix Cloud 사이트에서 다운로드 받아야 합니다. 필요하시다면 STRIX 지원팀에게 문의해 주십시오.

이것은 정상 행동입니다.

클라이언트가 일정 시간 요청을 하지 않으면 마스터 서버 연결은 자동으로 끊어지며 클라이언트가 다음 요청을 보내면 자동으로 다시 연결됩니다. Disconnect Master Server를 이용해 끊거나 SDK가 스스로 끊으면 Is Master Server Connected 기능이 거짓을 리턴합니다.

이 자동 끊김-재연결 사이클은 마스터 서버와 통신하는 기능의 거동에 영향을 주지 않습니다. 마스터 서버에 연결하기 전에 Is Master Server Connected를 이용하여 연결 상태를 확인할 필요가 없습니다.

다음과 같은 증상이 나타날 수도 있습니다. 즉 게임 프로그램을 시작한 후 방 입장, 게임 플레이, 방 나가기 단계가 처음에는 잘 작동했는데, 나중에 다른 방에 들어가려고 하니 “Room connection with id N already exists”라는 메시지와 함께 입장이 안 되는 것입니다. 이것은 클라이언트가 방 서버에 연결하려고 하는데 채널이 이미 방 서버와 연결된 상태일 때 나타납니다.

Leave Room 기능은 클라이언트가 방을 떠날 때만 작동합니다. 첫 게임이 끝난 후 Leave Room 기능을 호출하여 방을 떠나고 나면 방 서버 연결은 Strix Unreal SDK 내부에 남아 있습니다. 클라이언트가 다른 방에 들어가기 위해 Connect To Room Server를 호출하면 문제의 오류가 발생합니다. (Connect To Room Server를 호출하지 않고 NodeRoom 기능을 이용하면 내부적으로 방 서버에 연결하려는 시도가 일어나 같은 오류가 발생할 수도 있습니다.)

Strix Movement Synchronizer의 Max Speed의 값은 1초 후 움직인 거리입니다. MaxSpeed는 Actor의 최고 속도로 설정해 주십시오.

Strix Unity SDK 사용 설명서에서 움직임 동기화 매개변수를 조정하는 방법도 참조해 주십시오.

UStrixReplicatorComponent::IsReplicating 구성원 변수는 Blueprints가 쓰는 것이며 따로 가져오기 함수가 있습니다. 가져오기 함수 UStrixReplicatorComponent::GetIsReplicating()를 호출하면 C++ 코드로 이 플래그를 참조합니다.

a) 방 속성값을 변경하려면 SetRoom 기능을 호출해야 합니다. Strix Unreal SDK에서 제공하는 스트럭트에 값을 쓰는 것만으로는 방 서버가 보유한 방 속성값을 변경하기 어렵습니다.

b) 방장만 SetRoom 기능을 호출할 수 있습니다. 다른 클라이언트(플레이어)가 호출하면 오류가 발생하고(장애 콜백 실행) 값은 변하지 않습니다.

c) 값을 설정하거나 참조할 때(예: Strix Property Map이 쓰일 때) 방 속성의 이름이 문자열로 지정되기도 합니다. 속성 이름이 잘못되어도 오류가 발생하는 것은 아니며 정확한 이름의 사용자 지정 속성으로 간주됩니다. 다음 항목에 집중하여 속성 이름이 올바른 것인지 확인해야 합니다.

• 속성 이름에서는 대소문자 구별이 중요합니다. 공백의 여부도 중요합니다. 대소문자가 바르게 쓰였는지 확인해 주십시오. (STRIX가 정의하는 방 속성 이름은 모두 소문자로 시작합니다)
• Strix Unreal SDK에는 기본 속성을 구성원으로 액세스할 수 있는 스트럭트가 있지만 변수일 때 이름은 문자열로 나타내는 이름과는 다릅니다. 예를 들어 방의 이름을 나타내는 방 속성의 이름이 Strix Room 스트럭트에서는 Name이지만 문자열로 표시될 때는 “name”이 되는 것입니다.

d) 방 속성에는 데이터 형식이 있습니다. API 중에는 어떤 형식의 값이든 다 허용하는 것도 있지만 잘못된 데이터 형식으로 방 속성에 액세스하면 액세스가 되지 않습니다. 단, 오류는 탐지되지 않습니다.

• 값을 기본 속성으로 설정할 때는 값이 올바른 데이터 형식으로 되어 있는지 확인해 주십시오.
• 기본 속성의 값을 참조할 때는 올바른 데이터 형식이 쓰였는지 확인해 주십시오.
• 사용자 지정 속성에 액세스할 때는 데이터 형식의 설정과 가져오기가 일정한지 확인해 주십시오.

마스터 서버에 연결된 후 Connect To Room Server 기능을 호출하여 방 서버에 연결할 때 실수로 방 서버가 아니라 마스터 서버의 주소(호스트 이름 또는 IP 주소와 포트 번호)를 지정하면 성공 콜백이 실행되어 연결 성공이 표시될 수도 있지만, 방 서버 기능을 이용하는 후속 API가 응답하지 않게 됩니다. (실제로, 시간 만료 때문에 실패 콜백은 약 30초 후에 실행됩니다)

ID를 보내는 방법에는 여러 가지가 있지만 플레이어 아바타의 외관이 신경쓰인다면 방 번호 속성을 이용하는 것이 좋습니다. 사용자 지정 속성("avatarId")을 정의하고 ID를 그 속성의 값으로 설정해 주십시오. 레플리카는 메쉬가 만들어질 때 또 속성 변경 이벤트가 트리거되었을 때 메쉬를 바꿀 수 있습니다.

이런 증상이 나타난다면 다음 순서로 프로젝트에 C++ 클래스(아무것도 하지 않음)를 추가하여 문제를 우회할 수 있습니다.

1. Content Browser의 New Class에서 New C++ Class를 선택합니다.
2. Choose Parent Class에 None을 선택하고 Next를 클릭합니다.
3. 프로젝트에서 쓰이지 않는 이름(예: MyUnusedClass)을 Name Your New Class의 Name에 입력하고 Create Class를 클릭합니다. (Name 외에는 기본값을 변경할 필요가 없습니다.)
4. C++ 파일이 컴파일되는 동안 기다립니다.
5. Visual Studio IDE가 시작되고 C++ 소스 파일(MyUnusedClass.cpp)이 열립니다. 기다렸다가 Visual Studio를(아무것도 수정하지 않고) 닫습니다.
6. Unreal Editor도 종료합니다.
7. Unreal Editor를 다시 시작하고 프로젝트를 열면 패키지가 다시 만들어집니다.

위 단계를 마치고 나면 오류가 사라집니다.