#yeah, exactly. I want to 1) Make it
rough ridge
I don't necessarily think that you would need scriptable objects or cloud code for that.
I would suggest to you to look at transforming the sample in a way that you send out RPCs from the client to the server for reporting progress.
The Server side can run verifications, and apply the changes on the player specific quest instance (you can represent the quest as a ScriptableObject if you want to, but you can also serialize it to any format, or commit to a data base).
Server then sends back an RPC to the Client with the result that can be used to update the progress tracker on the Client side.
I'll try to whip up something for you to demo this approach as soon as I have a few minutes to spare.
regal musk
Hey, thank you Kalman!
I guess i was trying to use cloud code as a replacement for RPCs as I dont really like to write server-side code and client-side code in the same place. feels spaghetti to me.
But yeah, there might be no escaping that
regal musk
But yes, im unsure why use cloud code in the first place now
rough ridge
This might be a bit simplified explanation, but: Cloud Code enables you to change your game logic without the need of updating the client build, at any given point.
It lives as a separate codebase that runs through server less functions. Think of it along the terms of AWS Lambdas. Note that Cloud Code modules cannot use classes from the UnityEngine namespace or anything else in the Unity's scripting API, so none of the convenience functions that you might be familiar on the Engine's side is available to you in Cloud Code.
rough ridge
Hey @regal musk,
Looked at this a bit today, sorry for the late follow up 😉
Cloud Code is not my area of expertise yet, but the Quest System seems to be server authoritative already. Yes the client sends requests, but those requests are just bindings through the cloud code interface, meaning
Unity under the hood will still send web requests to a remote server, to actually perform all actions (assign and progress in this case).
The example seems to accept that requests almost blindly but you can add any validation check as you would need, besides the progress per minute constraint that is already implemented in it.
The example uses the Remote Config service as the "database" for your quests, any quest added to it could be picked up from it.
Instead of Scriptable Objects the Quest system uses Cloud Save to save the quests assigned to players into their player specific instances on Cloud Save. Outside of Unity Scriptable Objects are just yaml files on disk and have no actual function. Since cloud code is actually a serverless function execution engine it knows little to nothing about Unity and it's ecosystem, and JSON is an easy to edit file format.
You can easily edit your quest database in the Remote Config instance of your project on the cloud dashboard.
But if you want to see them in the Unity Editor, or author them locally you would have to look at the Remote Config window.
One thing that I did not like in the Quest system glossary, was the part about setting up cloud code modules, as it is not really straight forward to newcomers. I suggest to check out this (and related) documentation:
https://docs.unity.com/ugs/en-us/manual/cloud-code/manual/modules/how-to-guides/write-modules/unity-editor it should help you to understand more about the way cloud code hosts your server code and how the Unity Runtime is communicating with the deployed modules.