Is it possible to check at runtime whether or not Lobby is enabled for a given project? If so, how?

So, long story short, making a game for a client, using Unity Gaming Services as matchmaking infrastructure (and offering the ability to join/host by entering IP addresses as a fallback), however, the client has said that they only want to run the UGS relay/lobby stuff for a fixed period of time.

Considering this, I want to be able to make the game itself able to detect whether or not Lobby (and Relay) are currently enabled/disabled at runtime, so I can pre-emptively disable the UI elements that the player uses to do things that use these services (and show a warning that the services are currently disabled), to ensure that players do not get greeted with unhelpful error messages after attempting to start/join a game via the Relay/Lobby matchmaking services, by preventing them from attempting to use these services in the first place when they aren’t currently enabled.

So, is ‘checking if Relay/Lobby are currently enabled when the game is launched’ doable, and, if so, how would one go about doing that?

(and yes, I’ve just asked the same question in the Relay subforum, but I figured I may as well ask it in this subforum too seeing as this question applies to both services)

Your best bet for something like this is to use the Remote Config service to pass a flag to your clients and tweak the behavior based on the value. This is quick and easy to change, and also has the ability for you to use different configuration for different users/clients so that you could have a subset of clients that can still use Lobby/Relay for testing purposes without allowing everyone in.

If you need to actively PREVENT clients from using the APIs (or maybe prevent malicious users from bypassing the config check and using them anyway), you could use an Access Policy in parallel with the config value. You can construct an access policy to prevent all calls to specific APIs for a given project. See the Access Control API docs for more detail.

Well, that isn’t exactly the solution I was hoping for.

I’m looking for a fail-fast ‘is this service currently usable yes or no’ sort of thing, ideally without requiring the remote config to be edited (I know that the clients aren’t exactly technologically-competent, I can trust them to “hit the obvious off buttons on the dashboard for this project when you’ve used up the money you budgeted for the running costs”, but I doubt that they would remember to edit the config file as well, even if I tell them to do that). That, and I don’t want them to encounter unexpected esoteric error messages if they’re trying to use the relay/lobby bits when relay or lobby go down (even if the remote config might still say ‘yeah sure they’re usable I promise’)

Actively preventing a subset of users from using the API isn’t a concern (the scope of the project isn’t that ambitious, in terms of user subsets there are no subsets). All I am trying to do is to make the UX for the deliverable (along with the UX of using the deliverable) as idiotproof as possible.

Anyway, stupid idea, I just want to double-check something with you: specifically, the exceptions thrown by RelayService.Instance.JoinAllocationByCodeAsync(string joinCode):

If I were to call it after UGS gets initialized with a fixed incorrect (but not erroneous) join code (for example, "DDDDDD"), will that only throw a 403 Forbidden error if Relay is currently disabled (throwing a different error if Relay is enabled)?

Wondering if that could work as a fail-fast ‘is the relay service enabled’ check in lieu of a non-hacky way of checking ‘is the relay service enabled’ at runtime

Okay, just to clarify there are two things you want to check:

  • Is the service enabled/disabled for this project
  • Is the service currently properly functioning (I think you’re asking about this too, but I may have misunderstood your message)

We don’t have anything specific for the second option right now, so focusing on the first.

We are currently removing the On/Off toggle in Lobby and Relay because Access Policies work for ALL services as opposed to the on/off switches which are specific to those services.

Using Access Policies would be the prefered way to disable use of the service moving forward. You would just create an access policy that applies to the whole project if you don’t care about subsets of users. It sounds like it would be beneficial for you to have a dead-easy way for your clients to add or remove a policy of the correct type, right? The UGS CLI can be used to add/remove policies. Would it be feasible for you to have a script that did the right thing that your clients could use?

As for the Relay API, if you pass in an unknown Relay Join Code, you should get a 404 if the service is enabled. You would get a 403 if you had an Access Policy in place (or if you had the service disabled, which is the functionality we’re removing). So this would technically work, but I’ll try to get someone from the Relay team to comment on how they feel about the API being used this way. :smile:

Currently waiting for it to be enabled (long story short, it’s an update to my dissertation project (but this week I re-registered it to a different unity organization so the clients will foot the bill for any running costs instead of me - and the only reason why we used that approach was the lack of per-project billing breakdowns for UGS)), trying to walk them through the process of ‘you need to either give me permissions to turn it on or turn it on yourself’ though (they have attached payment info already), but I know that the UGS-based code which I do have definitely does work (as it was working perfectly earlier on this week, back when it was associated with my own Unity project organization which did have those services turned on).

oh, nice to know I suppose

I’m not sure if they’d be able to run the script or not (and I don’t really know what I’m doing with 'making scripts that jst call some other CLI thing ')

Anywho, is there any way of changing the active User Access Policy via the Unity Gaming Services dashboard? And, if so, where is it hidden?

I don’t really have much time in which to get this deliverable finished (They need it to be done before April 1 (financial year reasons), and of course thanks to bureaucracy, I was unable to properly start on it until a couple of weeks ago), and there are a few requested changes that I’m still working on, so the sooner I can get this unexpected roadblock addressed, the better.

aight.

Also, just to double-check, what permissions are needed for me to actually start editing the policies?

If ‘having a service account’ is definitely a requirement for being able to get started with Access Policies, will I definitely need ‘Organization Owner’ (instead of ‘Organization Manager’, ‘Project Owner’, or ‘Project Manager’) permissions in order to create a service account for that particular project and then use it to update the Access Policy for that particular project?

(Just figured I should double-check that the information about permissions here was correct so I could forward the correct info across)

Not yet, there will be something added to the dashboard eventually (not before April though). I spoke too soon about the CLI. That should be getting released this month, but until then the only way to access it is via the HTTP APIs.

And yes, a service account is the only mechanism for calling the HTTP APIs at the moment. I believe the linked documenation is correct regarding permissions.

As a side note, the free-tier for Lobby and Relay are reasonably generous. Unless this is something you think might become some sort of viral success, it is very likely that you’ll stay well below the caps.

There are two roles that your Service Account needs to modify policies - Player Resource Policy Editor and/or Project Resource Policy Editor - depending on which type of policy you’re using. In you case, it’d probably just be a Project Policy.