Improbable Icon

Player persistence between sessions


#1

I’m a newbie with Spatial so forgive me if this topic is covered in either the docs or a previous post.

It seems to me that the goal Spatial is seeking to solve is persistent world simulation; So when a player logs back in they see the world has moved on - both from the actions of other players and the actions of NPCs.

However, where to store the state of the player who logged out?

Seems to me it’d be an unnecessary overhead to store it somewhere in the Spatial world - consuming memory and resources when the player might not log in for a week - and not useful or safe to store it on the local client machine; So would the answer be to pair Spatial with something like Playfab for this purpose? Then not only could the persistence of player stats, inventory etc. be offloaded out of Spatial, but Playfab could effect login authentication, in-app purchases and so on.

However, by introducing a third party framework in this way, it allows the possibility of a hacked client to connect to the game with arbitrary god stats. So really there needs to be a some kind of secure authentication directly between this third party framework and Spatial.

Is there a recommended pathway here? How are other games utilising Spatial handling this issue?


#3

Hello @philg!

You are indeed right on many points: storing data while people are logged out can indeed be offloaded to a third-party service.

Those points have also indeed been somewhat covered in past posts (no blame on you though, they are quite old):

These two posts contain already quite a lot of information but there is definitely more to be said so do not hesitate to ask any other questions that you have or that might come up!

Best regards,
Duco


#4

Excellent.

Thanks, your reply has led me down a very fruitful path. It actually seems very straightforward but I’d like to just double-check I haven’t missed anything important. Here is how I think I could implement it:

  • The client logs into PlayFab and receives their PlayFabId and SessionTicket
  • The client stores this in a component which only workers (and not other clients) have read access to
  • Using the PlayFabID, a worker requests critical player state from PlayFab (eg. player level) and stores this in a component the client has read access to
  • Once the player state is fully refreshed, the client can go ahead and render the game
  • If desirable, the client could go ahead and make PlayFab Client API calls to directly request non-critical player state (like visuals, say)

If set up correctly, no other clients will have access to this player’s Id and ticket, and no client would have the ability to unilaterally alter or spoof his (or anyone else’s) player state - not in any way that actually affects anyone else’s game at least.

Then, as the game continues on:

  • The worker levels up the player, say
  • To do this he makes a PlayFab Server API call, followed by updating the component
  • The client sees the change in level and renders the appropriate visuals etc.

This seems pretty rock solid - and actually rather more straightforward than integrating PlayFab with Photon - but I’d just like to double-check one technical detail:

For PlayFab Server API calls the worker needs to have knowledge of the DeveloperSecretKey. Is it ok to assign this in the UnityWorker Scene? If built into this scene and this scene only, no client will end up with this key in their assembly available for viewing under disassembly, right?


#5

Hey again @philg!

Sorry for the late follow-up. The flows that you are describing do definitely make sense and are along the lines of what I would suggest myself as a setup. Regarding your last question: you should be able to include it in the managed worker’s code (i.e the UnityWorker) as it would only end up in that workers binary (which the players would not have access too) and not in the client worker’s one.

As I am not entirely familiar with the effect of assigning it in the UnityWorker Scene in the editor from a resulting code perspective I will double check this with someone who has more expertise here.

Best regards,
Duco


#6

Hi @philg,

Yes, that is correct.

If you have a component for example:

using UnityEngine;

public class BehaviourWithSecrets : MonoBehaviour
{
    public string dataForWorker;

    void Start () {
        Debug.Log("my data is " + dataForWorker);
    }
}

You can attach it to a GameObject in your UnityWorker scene, and set a value for it through the inspector.

image

This way, the “THIS IS SECRET STUFF” string will get saved into the scene data only for builds that include that scene.

If you have the secret string within prefabs, code, asset bundles or other non-scene resources it increases the chances of builds including them.

I hope this helps,

Firtina


#7

Also @philg, with the release of 12.0 we have actually introduced a tutorial about integrating Playfab in a SpatialOS Unity project.

Hope this will help confirming your thoughts!
Duco


#8

Thanks for pointing to that. Glad to see my instincts were correct.

As always, your tutorials are very thorough and easy to digest - which is sadly all too rare amongst cutting-edge frameworks! (Or even mature ones for that matter…)