UE4 Blueprint SDK Conversion

Question

question

Montana Tuska asked Aug 11, '17

UE4 Blueprint SDK Conversion

Since SDK Update Blog Feedback doesn't actually allow feedback, by comments or answers, I made this nice little thread. Now, your Unreal Cpp - BP Upgrade Guide is not very good. This is because of many reasons. There are huge differences in the two SDKs and you never discuss them. Without searching through your test actor that luckily was provided, I wouldn't have realised you're using the PlayFabSettings to store the logged in user. You don't speak of the CustomData parameter for each call. I could take some more time to learn about it, but I jsut don't understand why it's not something you discuss.

In the guide you say, "The C++ SDK contained no blueprint interaction" When in fact, it had the PlayFabProxy module that provided exactly that. I understand that UE4 isn't a big part of your user base and that you don't have anyone particularly experienced in UE4, but saying something completely off about the SDK makes me really wonder if you know what you're providing.

In the end of the guide you say you can't do much for the C++ users without doubling the size of the plugin. Why does the size of the plugin matter so much? It's not that big to begin with and using the SDK Generator you have, you can just create a simply C++ friendly wrapper. Sure it might increase the size some, but that would have no realistic effect as far as I am aware.

As always, thanks for your time. Looking forward to some responses. Sorry about being so bashful, just trying to be critical.

sdks

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 · 2017-08-11T23:21:41Z

1807605288 answered Aug 11, '17

Hi M.T., thanks for your feedback.

I made sure to provide two pieces of working code that do identical steps, specifically for the reasons you're pointing out: A guide written by me will almost certainly lack one or many details that either I have overlooked because I'm too familiar, or that I've simply missed. Still, it happened, so I apologize.

Settings & TitleId: Yes, both SDKs could input the titleId and devSecretKey from C++ code, but the C++ SDK had an integrated menu in the Unreal settings where you could also put those values. I forgot about that. The Blueprint SDK requires that the titleId be set from C++ code, or a blueprint. Phoenix Labs built the C++ SDK, and we initially tried to discourage them from using that settings option, because it was very easy to accidentally publish your devSecretKey with your client. In the end, if there is significant customer interest, it's possible the integrated menu can be ported over to the Blueprint SDK.

As far as the logged in user itself: Where and how the user credentials are stored should be invisible to essentially everybody (players and devs). The two SDKs generated by Phoenix Labs both had the capability of keeping multiple logged in players at the same time, but that is not typical behavior, and it's something we greatly discourage (and since our billing is based on MAU, it could also cost you more money). The Blueprint SDK was built in our typical style where the SDK can only track 1 user at a time. That is a difference between those SDKs, but it's not a difference we encourage or support. It also contributed to which one we kept and which one we discontinued.

C++ SDK Blueprints: The discussions I had with the authors led me to believe that those were incomplete and not guaranteed to work. I was certainly never informed that those were tested and working, and we had no testing of our own to verify them.

Size doubling: That is a serious concern for some customers, particularly for Android, where there's a limited number of functions (65k). Others just care how big the executables are and such. I mention it because customers have mentioned it to us.

CustomData: This is a pattern that exists undocumented in almost every PlayFab SDK. It would be more accurately named "callContext" or something similar, but it's a way for you to pass *something/anything* into the call, so that the callback can read or apply some in-game context that may not be available in the result itself.

It was intended that everybody can post in those feedback pages, so clearly there's an error. Sorry about that, we'll get it sorted.

4

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.

Montana Tuska commented · Aug 11, 2017 at 11:49 PM

As always, thanks for the response Paul. I just like have a clear understanding of things that I use, and I will probably come up with more questions/statements later as I start converting. Those all were just my initial look over. Overall though the blueprint SDK does look more feature complete.

Settings: Having it in the Project Settings would be preferred. It doesn't make much sense to set something that will be static at runtime.

Logged in user: I personally was going to make use of the possibility of multiple active users with the C++ SDK, I plan to enable split screen playing so having 2 players logged in on one machine would be preferred. Since they would still be joining a server with the same max players etc. The only reason I see the MAU getting affected by this is because more people decided to play with their friends. That wouldn't be that bad of a thing though.

As for the feedback page, I assumed that was the case, but there wasn't a better way to tell you guys.

0 ·

1807605288 ♦ Montana Tuska commented · Aug 12, 2017 at 12:22 AM

Settings: Ok. I'll add a task for this. I'm not sure when we'll get to it, but it'll be somewhere in the backlog.

Multiple logged in players: This has come up enough that we (PlayFab) need to come up with an answer for this. Unfortunately, it' means a pretty significant breaking change in almost every SDK that needs to change, AND we have to make sure to present it in a way that won't let any novice users shoot themselves in the foot. It's a BIG change though, so it's not going to happen soon. Whatever workaround you come up with in the meantime will have to suffice.

0 ·

Montana Tuska 1807605288 ♦ commented · Aug 12, 2017 at 01:02 AM

Multiple logged in players: It wouldn't necessarily have to be breaking. I'll use the C++ SDK as example since that's what I know, and it won't work with how the Blueprint SDK works, but nonetheless... In the C++ SDK, at runtime it created an object for the client, and you could just get the local singleton client and calls your functions. So I created a custom function that would either get or create a new client object and I just got the client based on their local id(0, 1, 2, based on the splitscreen user). Maybe that is a logic you could possibly use elsewhere.

0 ·

Show more comments

question