Platform Toolkit - Official cross platform API - now available for 6.3

Unity Engine
, , , ,
62

This needs to be reconsidered. I understand consoles need pro, but I think unity needs to reconsider its business model for this toolkit.

Not being able to use steam without pro with platform toolkit is like meh then I rather not use it at all, and just use steamworks.

3 Likes
63

yeah no indy game dev is going to use this now, sad really as its such a great tool in itself being held back by a expense licence.

2 Likes
64

I think there should be a warning front and center on the packages home page that the package is essentially just a no-op shell unless you own a license. The package sells itself as ‘unified api, implement once and don’t worry about specific platform details’ and with that in mind its easy to image a scenario where a solo indie dev goes through with implementing it, testing it locally, and then realizing there is a (minimum) $2400/year license cost to actually use the thing. That would really sting!

5 Likes
65

Sorry - I mean is there a way to fetch the underlying tokens/etc so we can authenticate the users claim on our backend ie https://developer.android.com/games/pgs/android/server-access

I guess more broadly speaking is there some way to ‘dig down’ to the platform implementations for platform-specific stuff like this? Or if not, can it ‘co-exist’ with a ‘copy’ of the platform sdk’s (ie GitHub - playgameservices/play-games-plugin-for-unity: Google Play Games plugin for Unity) so we can side-step Platform Toolkit for whatever is missing?

1 Like
66

Thanks for all your work so far on this – very happy to see Unity adding features like this, and this is a great foundation.

I have some early feedback based on a quick look so far. In its current form it’s not suitable for us to adopt, even for the feature sets currently supported.

  • Platform backends are configured based on the build target, instead of build profile, or developer-selectable. For example, Windows builds might need to use the Steam backend or the local backend. In the future you may want to add support for the Epic Games Store; or for GameKit and Steam support on Mac. Ideally, default platforms are configured per build profile, and additional platforms can be runtime-selected by the game at startup.
  • The default iOS save system should be using CloudKit, not GameKit, as GameKit is not portable to tvOS. This will inevitably create compatibility problems down the line when a game developer tries to add tvOS as a platform in the future and finds that their existing save games can’t be migrated easily.
  • While it’s convenient to link platform capabilities such as the Saving and Achievements systems together into an umbrella platform, ideally these can also be individually selected and used independently. For example, an iOS game may need to use the GameKit achievements system but with an iCloud save system. Or two save systems may need to be loaded simultaneously in order to migrate saves from one platform to another.
  • The current implementation of the save systems using GenericLocalStorageSystem has a pretty high overhead for small incremental autosaves. The entire save archive is loaded into memory, updated, and then written out in full. Since the archive is disposed after writing, the whole file must be read in again to make the next change. Developers reading the documentation may be unaware that the performance cost of updating and committing a single file in the archive scales with the total size of the entire save.
  • Additionally, the current local storage system does not provide the atomic commit guarantee as documented. The changes to the zip are buffered in memory, but are then written out with File.WriteAllBytes, which may be interrupted/truncated.
  • I recommend switching the generic storage backend to sqlite to address both of the above problems, which are tricky to solve on a generic filesystem otherwise.
  • Small bug: PlatformToolkit.Initialize should guard its reentrancy check before awaiting async.
  • Documentation: I would love for the documentation to be clearer on platform limitations, rather than “Platforms might have different size limitations and capabilities” and “Platforms have different maximum name length restrictions, so it’s recommended to keep the name short.” – specify exactly the maximum common length that is supported by all known platforms, this avoids developers encountering headaches down the line when they port their game to a new platform. Additionally, there are case-sensitivity issues that affect some platforms that should be documented. Even better if the platform toolkit asserts if these limits are exceeded in play mode.

Thanks again for sharing the package in its current state, I once again reiterate how pleased I am to be seeing work done in this direction, and hope that these issues can be addressed in the next version.

14 Likes
67

Was excited for this, but now it’s completely useless to me. Swing and a miss, Unity.

13 Likes
68

If core API is free, it means we can implement our own drivers ?

1 Like
69

I feel I’ve been played; at Unite no one mentioned it required a “pro” license … even speaking to the “Experts” about it !

I understand the price to entry for console but … steam ? really ?!

What’s the point of announcing something that no one can even test out.

You need to fix this, asap. This is not acceptable.

Make it free for mobile and Steam. Period.

Thank you.

8 Likes
70

kinda agree with that too, I didnt expect any platform other than consoles to be requiring pro

5 Likes
71

Nothing against closed implementations, plus adding the value of updating to platform guidelines. On the other hand opened this, let’s contribute to a Steam open source alternative, the API is there, that’s fair.

I can see a world where people will go on this for releasing early access or demos and then when the game is stable you go for unity’s solution. Especially if dev team has moved on and can’t go into the details of maintaining and needs plug-and-play solutions.

1 Like
72

The toolkit is a terrific start.

Agreed. It would make much more sense if Steam integration were free. If and when an independent developer wants to scale out to consoles, that’s the right time to charge for gated access.

I’m also very interested in this. Authoritative game servers typically perform their own server-side authentication. Never trust what the game client sends you.

Right now I’m using the Steam auth endpoint
https://partner.steam-api.com/ISteamUserAuth/AuthenticateUserTicket/v1/
to authenticate users on the server side. My game servers are not compiled Unity builds.

For secure multiplayer, the Platform toolkit probably needs either…

  • A web service endpoint, or
  • A cross-platform API that can be used directly on game servers

Unity, am I understanding this limitation correctly? Does it have this capability, or is it planned?

1 Like
73

I like the idea. However the price for Steam is a bit high. If the package for Steam was available on a student licence, or in the asset store, I’d be much, much happier. As it is, it just seems unaffordable.

1 Like
74

Honestly, if Unity could somehow abstract this away from us and let us authenticate a users claim on our backend with a token generated by the Platform Toolkit package.. man that would be pretty awesome.

  1. On client, ask the PTK for a server side access token
  2. PTK gathers the information it needs, return a payload of platform specific data
  3. We’re expected to pass this payload to our backend
  4. Our backend pings Unity’s API with the payload to authenticate the claim
  5. Unitys backend unpacks the payload and actually validates it with the appropriate backend.
  6. Unity returns ie the users ID so we can associate that with their account on our backend with full confidence that they are who they say they are.

It is probably unrealistic, but man it would be cool (though for something with a $2,400/year cost attached its not an unreasonable request :slight_smile: )

1 Like
75

JWT is doing that kind of. If the payload is signed against the unity backend (on the client), then we can trust it by just verifying the claim ourselves. No reason to ping unity for that. UserId can already part of the package which got signed

2 Likes
77

I was also excited for this as an indie, but I will not use the package due to the paywall. I already handle Steam on my own and was hoping to ease future porting to consoles by migrating to this package. However, since Steam is behind a $2400/year license, this won’t happen.

I guess the target audience here is studios coming fresh into the Unity ecosystem without developed publishing pipelines from other engines, or perhaps newly formed studios. To be fair, I understand that indies don’t make any meaningful money for Unity, but once again I’m reminded that I’m not the target audience of the engine anymore.

5 Likes
78

Unity has a Building Block for Leaderboards and it is a Package in the Dashboard that seems pretty good. Are you saying these will not work on Mobile? (https://assetstore.unity.com/packages/essentials/tutorial-projects/unity-building-block-leaderboards-341926). Confused in general on what this adds for mobile as well.

80

First let me thank you for this great feedback. I will share this with the team to make sure it’s all digested internally. Now let me answer where I can.

Ideally, default platforms are configured per build profile, and additional platforms can be runtime-selected by the game at startup.

Yes, you’re totally right on this point, and we’re working to get a build profile settings override component to support this exact workflow.

In the future you may want to add support for the Epic Games Store; or for GameKit and Steam support on Mac.

We’ve had lots of feedback on EGS and we’re looking into that, it’s clearly a priority for developers and we will make sure to take that into account.

For Mac support, we’ve done less testing there so we didn’t want to claim support out of the gate but the existing support packages should work. We will update the docs as we do more testing around those platforms.

The default iOS save system should be using CloudKit, not GameKit, as GameKit is not portable to tvOS. This will inevitably create compatibility problems down the line when a game developer tries to add tvOS as a platform in the future and finds that their existing save games can’t be migrated easily.

I don’t have an answer for this right now. I’ll make sure to talk with the team about this point.

While it’s convenient to link platform capabilities such as the Saving and Achievements systems together into an umbrella platform, ideally these can also be individually selected and used independently. For example, an iOS game may need to use the GameKit achievements system but with an iCloud save system. Or two save systems may need to be loaded simultaneously in order to migrate saves from one platform to another.

We do support getting save systems from different places. You can for example get two saves systems on mobile to support moving of saves between local storage and cloud storage.

The current implementation of the save systems using GenericLocalStorageSystem has a pretty high overhead for small incremental autosaves.

I’ve passed this on to the dev team to take a look at.

Small bug: PlatformToolkit.Initialize should guard its reentrancy check before awaiting async

I have forwarded this to the dev team to take a look at.

Documentation: I would love for the documentation to be clearer on platform limitations, rather than “Platforms might have different size limitations and capabilities” and “Platforms have different maximum name length restrictions, so it’s recommended to keep the name short.” – specify exactly the maximum common length that is supported by all known platforms, this avoids developers encountering headaches down the line when they port their game to a new platform. Additionally, there are case-sensitivity issues that affect some platforms that should be documented. Even better if the platform toolkit asserts if these limits are exceeded in play mode.

We have to be quite careful about making specific claims regarding behaviours and capabilities of NDA platforms as I’m sure you understand. The platform specific documentation goes into more detail than the core package documentation, but I agree that this isn’t idea.

In the cases where we’re able to enforce a common minimum capability, such as in the case of case sensitivity of file names across platforms, we actually do that. Which is why the save file name character set is so restrictive.

We are working on editor-time validation features that will warn where common platform limits are breached, for example read/write frequencies. To hopefully ensure that poor read/write discipline is discovered as early as possible in development.

Thanks again for the great feedback! I hope this is helpful, and that we can keep improving the toolkit to meet your needs!

81

Hi crawfis,

The building block here you’ve linked is not a platform abstraction, it’s a leaderboard example built using unity’s cloud Authentication, Cloud Code, and Leaderboards services.

So while it will work across platforms (because it runs in the cloud) it’s not a platform abstraction.

Cheers,

82

Thanks for getting back to me on all of these! I think there are a couple of points where the intended functionality doesn’t match what shipped:

  • GameKit is currently only available on iOS, as GameKitBuilder specifically checks for UNITY_IOS, so it can’t be evaluated on Mac/tvOS/visionOS.
  • I’m not sure about getting save systems from two different places. As far as I’ve seen, all the ways of constructing/initializing a save system are marked internal, except for using the default platform init. Marking some public constructors would definitely fix this issue.
  • The name validation in SaveNameValidator is exactly what I was proposing – great! Only thing is it’s not used in a bunch of entry points (e.g., it’s used in GenericLocalStorageSystem.EnumerateArchives, but not GetWriteOnlyArchive).

Thanks!
Alex.

83

I agree that this should have a note in documentation, we’ll add that.
The archive-based implementations are intended as a simple baseline implementation that should have easier-to-check integrity than loose files. We are discussing an option to allow loose files which will help with the overheads here, with the understanding that it’ll require the developer to do some more work to check integrity.

That guarantee should only apply as far as a platform can provide it, so we should be more specific in the docs there. That said, I think we can improve how the local storage system handles this for archive-based commits. Something like a write-to-temporary and rename.

We want to be careful in putting any specific formats in place since it could hurt portability of savedata. Our aim was to have the API be close to ‘files on a filesystem’, but if there does end up being a lot of demand for more specific backends we can look at them.

It absolutely should, thanks for the report!