Hey readers! Today we’re going to talk about one of the newest features in our User-Generated Content ecosystem: Cloud Data Variables, which came out of beta this week! This is a huge step towards enabling our great Rec Room creators to create experiences with a greater sense of progression, replayability, and permanence.
This post is going to also dive into some bits of Circuits V2 terminology, and assumes you have some familiarity with Circuits V2 or have read The Circuits Handbook post from several months ago.
The Reason
Previously, creators have had two kinds of variables at their disposal: Instance and Synced variables. When using Instance variables, each player in the room has their own value for that variable. For example, if I had an Instance integer variable named Apples, my own value for it could be five, while another player’s is three. For Synced variables, all players in the room share the same value, and our networking system broadcasts any changes to the other players. Whenever a player leaves a room, the game no longer remembers any of the values that these two kinds of variables had.
We want to help people build the kind of games that players come back to over and over again, and bigger games that let you travel from room to room as you explore different corners of a world. Saved data is a natural part of that! We’ve been watching some of the most ambitious creators wring every drop they could out of Leaderboards to let people save their progress, so providing an official way to track things like quest gold, XP, or which rooms a player has visited was a natural next step.
We started out with this core idea: Saving values in rooms. Knowing that we’ll eventually make a leaderboard V2, we came up with two very different angles that we could approach this from: saving values to room instances (and giving players a way to manage their saved room instances, sort of like a save file in a Minecraft world), or saving room values to each player in them. Weighing the pros and cons of each, we decided that we saw more potential use cases and a better user experience for the latter, and started designing what started out as “Per-Player Persistent Variables,” and what would eventually be called Cloud Data Variables.
The Method
When designing a new feature, we focus on defining what the goals are for adding it to the game. These usually go through several iterations, and after such we landed on a few key driving goals and non-goals:
Goals:
Allow creators to build rooms with per-player data that persists between sessions and across subrooms
Persistence is implemented as low level building blocks that are agnostic about scenario
By default, players don’t have to think about loading their data (unless a room creator says so)
MVP approach: start with a small system upon which we can build later
Intuitive to use on room load (i.e. no weird timing issues with data becoming available)
Have data loaded by PlayerJoined event
Doesn’t contribute to crashing on room load
Avoid hammering the server with constant save requests
Creators can tell at a glance when something is persistent
Creators can see what persistent values exist in their room
Non-Goals:
This is not an attempt to replace leaderboards - that will be a separate effort later
We’re not solving things like “items persist across subrooms” directly, but instead giving creators the ability to do this themselves
Once we had gone through several iterations of those goals, dozens of rough sketches, and a ton of thought experiments, we were finally ready to start developing. One server engineer built the back-end, creating the databases needed to house both player save data and the data for each room to track their data across subrooms. A client engineer came through and then built up all of the in-game content, hooking into those saving and loading events and making sure that all of the data got properly piped through Circuits V2. The designer iterated with the UI team to go from the sketch that you see above, to the menu that’s in the game now.
After a couple months of hard work, iteration, testing, bug fixes, a beta release, and more bug fixes, we were finally ready to bring the feature out of beta!
The Result
Cloud Data Variables make it possible for creators to save the values of individual players for the next time they come back to the room. Once a variable is set to be a Cloud variable, at first it will behave just like an Instance variable; circuits can set the value just like any other Instance variable, and each player in the room will have their own personal value for it. The magic happens once the player leaves the room and comes back; when the player leaves the room, they will send up to the server a list of all of their values for variables in the room, and when they return to the room, they will load that list back up and put all the values in the right places. Let’s see what that looks like in action.
Here we’ve got a button that increments an integer variable. Every time the button is pressed, we increment the value by one, and send the user a notification about how many times they’ve pressed the button.
We also wanted it to be easy for creators to tell, at a glance, which of their variables are Cloud Data variables, so the variable will gain a small icon of a cloud in order to make it easy to tell without having to go into the config menu.
With Cloud Variables, we can now store this number, and know that when the player comes back to this room, their value will start at what it last was. There are so many exciting ways that creators can use these values: logging how much time you’ve spent in a particular hangout room, opponents knocked out in a PvP map, enemies defeated in a quest, and so many more that we haven’t thought of, but you will!
But that’s not all! Creators have been asking us for a way to share values like this across different subrooms, and these Cloud Data Variables do exactly that. When you create a new Cloud Data Variable, it not only gets defined for the current subroom that you are in, but it can be used across all the subrooms of your room. With our example above, that means that we can read out the number of times the button has been pressed in a different subroom!
In order to keep track of all the places that you are currently using a Cloud Data Variable, we even have this new handy-dandy settings page that you can access to manage your data!
This menu gives you a quick way to see where all of your Cloud Data Variables are currently in use. If you’re no longer using one of the variables in any of your subrooms, you’ll be given the option to delete it, clearing up space towards your limit of Cloud Data Variables for the whole room. If the variable is still in use, you can also Reset the variable. This will invalidate all existing data for that variable name, completely wiping all the data for all users of the room. Use these tools with care!
If you want to check out what it feels like to play in a room that uses Cloud Data Variables, check out ^GourmetGarden, which was built on top of this tech in order to allow you to plant your seeds, leave, and come back to progress having happened while you were away!
There are some limitations on Cloud Data Variables though. In particular, you can only use them for the same types that can currently be Sync Variables: booleans, floats, integers, quaternions, strings, and vector3. In addition, we ran into some interesting technical limitations on the Circuits V2 side; because of how we had built our previous systems for Variables and Circuit Boards, we realized during testing that there were a handful of bad states that you could get into by placing Cloud Data Variables inside of Circuit Boards, and had to limit Cloud Data Variables to only be used at the room level for now.
I’m so excited to release this new tool to all of you, and even more excited to see and experience what you build with them!
