Using Admin API calls from within Unity build scripts (-batchmode -executeMethod)

Question

question

Brian Jordan asked Jan 24, '18

Using Admin API calls from within Unity build scripts (-batchmode -executeMethod)

(First off, wanted to say it's been a pleasure using the PlayFab APIs/SDKs so far, and in addition to the docs, @Brendan's consistent posting of quality Q&A on here has been one of the driving factors to why it's been such a great experience, so thanks!)

Motivation

I'm hoping to use the C#/Unity Server Admin API on our CI server in order to upload a new server build, give it a game mode, and deprecate (most) older server builds

I've got most of that working over cURL calls, but since the Admin API has wonderful typed helpers and since I'd like to also allow uploading of servers via a Unity Editor menu, it would be ideal if I could make that all a shared code path.

Problem

I seem to run up against an issue where Enumerators are not run within the editor, and indeed Update()s do not end up getting called.

Supporting async within these batch Unity scripts is possible by running:

MakeSomePlayFabAPICalls();
while(!_isDone) 
{
    Thread.Sleep(100);
}
EditorApplication.Exit(0);

// Set _isDone at some point in a final callback

I've played a tiny bit with trying to add in calls after the Thread.Sleep like:

EditorApplication.update();

PlayFabHttp.instance.Update(); // made public to test

but to no avail, as the _apiCallQueue in PlayFabHTTP starts empty and ends being null after the first call.

In short, is it possible to make Admin API calls work while running within a Unity build script (-batchmode -executeMethod)?

Alternatively, would you recommend a nice CI-friendly PlayFab library to use instead of cURL calls to manage servers?

apis Custom Game Servers

10 |1200

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 1 · 2018-01-24T23:50:32Z

1807605288 answered Jan 24, '18

All of our internal testing is done with the command line, in one form or another.

Accepting your goal as "Make PlayFab API calls from a command line application", there's a handful of ways to accomplish this, some are more "hack/workaround" than others.

First, fast and most straightforward:
Our CSharpSDK is pretty much perfect for making API calls from the command line.
Make a VS solution, import nuget package, make API calls.
https://api.playfab.com/docs/getting-started/csharp-getting-started

Second, good, but takes lots of build time and steps:
Our build system makes PlayFab API calls from Unity using the command line.
We do this by making a unity build, which produces an exe file, which we can then use to make api calls. We use the -batchmode on that unity exe to avoid popping up a window, but it's running "like a normal game", with GameObjects/MonoBehaviors, start/update functions, etc. It reads the command line inputs, does the intended work and then shuts down.

Third, hacky, workaroundy, and probably unstable:
Our SDK has a RequestType mode called HttpWebRequest. This mode is fully multithreaded in Unity, so you can do your thread.sleep and spinlock for API calls to resolve.
However, UnitySDK API calls still rely on the internal monobehavior Update() functions to actually "resolve", which means you would have to really dig into the guts of our SDK and hack your way around.
I don't suggest this, as we change those internals often enough that it'll probably just break in a few months.

I suggest you just make a console program using CSharpSDK. Based on what you've said, it's almost certainly exactly what you want.

2

10 |1200

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Brian Jordan commented · Jan 25, 2018 at 02:01 AM

Thanks Paul, this is a very helpful overview!

The first (standalone CSharpSDK util) sounds quite nice, though we're targeting OS X for our build server (due to signing needs) -- as we haven't done much C# development outside of the Unity build ecosystem I'm not sure what challenges that might present, unless it's known pretty straightforward to build & run VS Solutions with nuget packages from an OS X build script?

Second option sounds nice in its ability to share a code path between an editor script and the game, though as you mention the expense of another build step. Another option would be including that as as launch flag for our Server executable build, but I take it including the ENABLE_PLAYFABADMIN_API code in the compiled build might slightly increase the security value if a server binary were to become compromised (though they share the same key, so would only be a difference of convenience).

Was initially looking at the third option and you're right -- maintaining modifications to the library sounds more trouble than it's worth.

For a balance of build-time speed & some amount of API parsing handiness, may end up giving the Node SDK a shot.

Thanks very much for your help!

0 ·

1807605288 ♦ Brian Jordan commented · Jan 26, 2018 at 06:15 PM

Yes, NodeSDK is a good solution that is cross platform.

I've built CSharp applications to Mac before, and one way to do that is to compile with MonoDevelop.

You should use whatever you're most comfortable with.

0 ·

question