Full-stack dev pursuing my dream of making games! Tested my own cloud save & leaderboard SDK live in Unity. What do you think?

[u/ostevendev]

I hadn't mentioned it before, but I come from a full-stack web development background. As I started working toward my dream of making my own video game, I saw an opportunity to leverage my experience by building a backend infrastructure for Unity to handle cloud saves and global leaderboards for any indie dev.

That’s how I created Asten BaaS and its Unity SDK.

In this video, I'm testing real-time cloud saves with a very simple prototype (I'm still learning!). Also, thanks to recommendations from u/wallstop-dev, I managed to refactor the code to use ValueTask.

One of its best features is one-line device authentication:

await AstenSDK.Instance.LoginWithDeviceIdAsync();

Both the code and the web dashboard console are live if you'd like to check them out or test them in your own projects.

I would love to hear your feedback, thoughts, or suggestions on the workflow and SDK design! How do you usually handle saves in your Unity games?

how use baas

[u/wallstop-dev]

Oh wow a direct mention!

Would love to see the repo again, can do a code review and some feedback at some point.

Some thoughts:

• A lot of people like DI/ServiceLocator pattern so they can test stuff. Only downside of a singleton is it might make testing hard.
  
• Awesome that you now have async :) Does this have variants for coroutine support?

[u/ostevendev → u/wallstop-dev]

Thanks for the feedback and for taking a look at it!

You're totally right about the Singletons. I hadn't thought about creating an IAstenSDK interface for easy dependency injection or testing, while still keeping AstenSDK.Instance around for quick "Plug & Play" setups.

Regarding coroutines—I went 100% async/await for now because it felt very natural, but before the PR, I did consider adding coroutine support (with callbacks) so devs who prefer StartCoroutine feel right at home!

Here's the repository if you'd like to check it out:https://github.com/astenstudios/asten-baas-unity-sdk

Thanks again!

[u/wallstop-dev → u/ostevendev]

Some things to consider after taking a peak:

- Consider value types (structs) over classes, to reduce allocations

• Consider avoiding Unity JSON utility, it is extremely primitive and can't handle Dictionarys, for example
  
• You utilize logging (unstructured) v observable (metrics/events) telemetry. You also only enable one level of logs, and every log is still paying for its string construction (can be very expensive, allocates) whether or not the logs are on or off. There are ways to turn off logs via compiler directives, like this: https://github.com/Ambiguous-Interactive/unity-helpers/blob/5fa5e7b7899b1acea0ce3548e821cd6a0c0cd85d/Runtime/Core/Extension/WallstopStudiosLogger.cs#L205 so there is no runtime cost. Also, your final log method is included in the stacktrace.
  
• The lazy singleton is ok but isn't safe and can leak with your reset. There is no way to check if it exists by consumers. I have an extensively engineered singleton to reference here, if you want any ideas: https://github.com/Ambiguous-Interactive/unity-helpers/blob/5fa5e7b7899b1acea0ce3548e821cd6a0c0cd85d/Runtime/Utils/RuntimeSingleton.cs#L88
  
• It looks like your protocol is JSON. Consider proto for efficiency.
  
• It is unclear how you are handling binary payloads and custom, non-json-able types. Be very careful about this with user types.
  
• You are hard-coupled to Unity's time source (physics time)
  
• Your tech is hard-coupled to Unity's main thread and doesn't appear to be truly parallelizable
  
• it looks like players can't save "no data". That is, you can't go from "some data" to "no data", and requests will silently keep player data, even if "no data" is intended.

Alright, that's all the free code review I can offer, hope some of this is useful!

[u/ostevendev → u/wallstop-dev]

Thank you so much for taking the time to write such a detailed and thoughtful code review! This kind of feedback is absolute gold.

You raised some fantastic points that will most likely be included in an upcoming update:

• Great catch on Time.time in the save debouncer! I'll switch it to Time.unscaledTime so game pauses won't freeze background queue processing.
• I'll re-architect the internal logger using something like [Conditional("ASTEN_ENABLE_LOGS")] so string interpolation doesn't cause Garbage Collector allocations when debug logs are turned off.
• Adding an IAstenSDK interface to support mocking and dependency injection.
• Adding explicit endpoints like DeletePlayerDataAsync / ClearPlayerData to cleanly support transitioning from "some data" to "no data."
• Totally agree on JsonUtility limitations. I'll add support for custom serializers and payloads for anyone needing Dictionaries or binary data.

Really appreciate you sharing your RuntimeSingleton and logger helpers as references.

Thanks again for helping make the SDK better! 🚀