Maker Pen Workshop #2: Gourmet Garden

It’s important for us developers to stay on top of how all the UGC systems come together to make compelling content. We do this through multiple avenues, and one of them is Maker Pen Workshops!

Wait, what’s a Maker Pen Workshop again?

Maker Pen Workshop is the term we use to describe internal projects that push the bounds of the creative tools in Rec Room. With a Maker Pen Workshop, we dream up a game idea and then set out to make it using the Maker Pen. Along the way, we add new features to the in-game tools and improve the most frustrating parts of the workflow. In short, Maker Pen Workshop gives us a great way to be in-game creators and choose exciting new creative tools to add to Rec Room. This is different from an #RRO where we primarily use C# to build new experiences.  

Gourmet Garden 

The team working on Gourmet Garden was all really excited about making a game about growing crops, and more importantly, creating an experience you can come back to, and continue where you left off.

This is the elevator pitch for Gourmet Garden:

Gourmet Garden is a multiplayer gardening game where you and your friends will take care of your plants from planting the seed, all the way to harvest in a shared greenhouse. Your end goal is to harvest and sell enough plants to afford a mysterious seed that caught your eye in the market.

Concept art for the greenhouse

Projects

We identified several areas where we wanted to improve our UGC tools to meet the goals of the original game design.

• Unsynced Lights/Text

  • We wanted to display the only gold quantity that matters in our game. Yours.

• Set Position

  • Creating the contraption necessary to move all the crops around was out of the question both from an ink standpoint and an editing sanity standpoint. Adding the ability to set the position of arbitrary things was pivotal.

• Cloud Variables

  • This is how we were going to achieve any sort of saving with our game.

• Room notifications

  • We wanted to experiment with sending players notifications on their mobile devices when their plant finished growing.

Progress Pics

How It Started

How It Ended

Behind the scenes look at all the circuitry that makes the game work!

Learnings

The most important part about Maker Pen Workshops to us are the learnings that come out of them. We identified several major pain points while building and these are aspects we are actively looking to improve. We believe these pain points are not only limited to Gourmet Garden, but all the games you are all trying to make.

Ink/Heat Limits

This isn't a new problem by any means, but we really felt the pain here. Most of the room comments we have seen so far have been people asking for more areas to grow plants/upgrades/more kinds of plants which are all completely valid asks. We originally wanted to have three spots per player that could each have a plant, but we quickly ran out of ink/heat trying to manage just one for each player. The live version of the room currently sits at max ink, which means we're out of room to add new things. We can’t promise a timeline on when improvements here will be made, but know it's on our radar.

Dynamically Spawning Objects

Sort of related to the above point, but currently, in the room we needed to account for the worst case scenario which was any player in the room could be growing the same plant which means we needed three copies of each plant at edit time. If we take a step back, really the worst case should be three plants total. If we could have spawned plants as we needed them the ink for the room would have been drastically reduced.

X-Plat Interactions

Early on we really wanted to have a watering can that you could use to water your plants...If you’ve played, you could see that we instead landed on throwing water balloons at them. This was more using what we had instead of being an intentional decision. Two reasons we backed off from the watering can idea:

1. Not enough ink

2. We couldn’t get the interaction to feel good on all the platforms we support

In a world where we had infinite ink, we probably still would have gone with throwing water balloons because we really wanted the game to feel decent on screens platforms. This sparked some conversations around interactions in UGC, and how we could improve these all up. Something that touches on this problem, and is shipping soon, is the Trigger Handle. With the Trigger Handle, no matter which platform you are on, it’s used the same exact way. You can press the button you use to fire a paintball gun to fire CV2 events that are inside its object board. There is more to come in this area of the tools as there are many more problems to solve here!

CV2 Debugging/Comments

The live room sits at around 1800 chips total which is a lot! Whenever something went wrong in the room, the errors helped identify what the issue could be, but the issue was finding which chip was producing the error. We believe there are some low hanging fruit improvements here we can make like actively displaying on a chip itself that it produced an error, in addition to the error logged to the palette.

On a similar note, early on we had text components with information on how the circuits functioned which were very helpful. However, as time went on and we needed more ink we needed to remove all of our descriptive text which made it difficult to remember how the systems we built meshed together. 

CV2 Functions/Properties

Early on in CV2’s development, before it was even released from beta, we identified a really powerful part of the system that we are working towards. There are two parts to this, one of them is essentially having the ability to fire exec ports on boards without having physical access to the ports. There are many reasons you might want to do this, but a very common one would be if you’re expecting different objects that you don’t yet have, like with a trigger zone.

The other side of this is what we’d call “properties”. Take a point light for example. You can currently set the light’s intensity via the config menu or by using a very specific “Set Light Intensity” chip. Intensity is really just a float value, like any other float variable. We would like for values like this to both:

• Be accessible via a set of chips (Get/Set Property) with just a reference to the object that has those properties.

• Any variable chip has the ability to have it’s value bubbled up to the config menu just like the light intensity value (which should help a ton with invention usability)

Properties are a type of function which is why they are grouped together. We need functions before we can get properties.

Bugs

We encountered a number of bugs while actively building the room. Some of these we had logged in our bug tracking software, and others were brand new. We are actively working on fixing a bunch of bugs in the coming weeks. If you have any that are really hindering your building experience we would love to hear what they are, and how to reproduce them. Reach out to us on discord or leave a comment here if you have any!

Conclusion

These of course aren’t the only learnings we had, but more the broad strokes of where we had issues, and where we think improvements could help all creators create their dream rooms. We’re all very excited to see what creators make with the latest tools we’ve added with this Maker Pen Workshop. If you have an idea for what we could build for the next Maker Pen Workshop leave a comment below!

All About Cloud Data!

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!

A Real Pane in the Glass

Glass!

Glass is something we’ve talked about a whole lot over the years. It’s been one of the most consistent requests from creators, brought up in every Q&A, and is something we’ve wished for on the team as well. We’re super excited to finally give our creators an easy and fully-supported way to make windows and water and more, without a giant martini glass or hacky strings of CSS.

For more info on how to use the new glass prop, check out:

We put a lot of love into this little cube, and we can’t wait to see what you make with it! But I know glass has been a long time coming, and it looks a little different than what we said we were shooting for, so I wanted to talk a little bit about why we’ve made the decisions we have, and what we hope for in the future.  

Under the hood

We’re doing a little bit of movie magic here to make sure the glass looks nice and shiny everywhere. Some of our base rooms have lush, detailed reflection information built into them from their RRO days...and some of them don’t, because we don’t know what you’re going to build! But a reflective material only looks as nice as what it’s reflecting, so the glass was looking pretty flat in the Maker Room at first. 

We don’t want a reflection that’s blatantly fake - but we don’t want it to be empty, either. So as part of our fancy shader, we’re piping in a little bit of nonsense data that will mix with the colors from the SkyDome chip in the Maker Room. Just enough noise to give it some gleam! 

Accurate reflection, and fake, respectively!

Why isn’t it a material?

We’ve had a lot of people ask us for glass as a material, and in fact that was our initial approach! Unfortunately, we ran into some issues with it.

When we were talking about glass last fall, we were also exploring ways to make our maker pen geometry render faster. We had high hopes for this work, and among other things, we were trying to solve one of the most pernicious problems with transparent shapes: sort order. (Bet you thought I was going to say performance!)

Roughly speaking, objects are drawn each frame in order from furthest away to nearest, based on their center, so that you see closer objects “in front.” Thanks to some shader magic, merging a bunch of maker pen shapes into one shape container makes them all count as one object for this purpose. That’s why it saves you ink! 

Drawing things from back to front isn’t always perfect, especially with really big objects. Let’s say you’ve got a house that’s been merged into one shape container, and you make a little table to go inside it. For most of the places inside that house, the center of the house is closer to you than the center of the table. If the “further away” table rendered first, and the “closer” house rendered on top of it, you wouldn’t see the table at all. It might flicker in and out depending on where you walked. The results would be weird and really obviously wrong! 

For opaque objects, there’s a “depth buffer” to make sure that if half of an object is hidden by something else, the stuff that’s hidden doesn’t get drawn, no matter which object is actually closer to you. This depth data means that it doesn’t really matter what order things get drawn in, except for optimization. 

However, you can’t use this for transparent objects. They have to be drawn back-to-front or they look wrong - since you can see through them, there’s no faking it with a depth buffer. We found ourselves in the situation of having a house with glass windows, with a glass table inside it, and being unable to ensure that they’d draw in the right order.

There are ways to solve this, but unfortunately, we haven’t found a solution yet that runs well on all of our platforms. We aren’t finished exploring rendering options, but it’s a long term effort, and it became clear that waiting would mean you guys had to go much longer without glass. And we really wanted to get you something fun and useful sooner than that! 

What’s next for glass?

A real glass material is still on our wishlist! We’re also starting to discuss ways to let creators set up custom reflection information for their rooms, which will improve the accuracy of glass reflections and metallic surfaces, and generally make all of the lighting look nicer. We hope to continue to make glass more expressive, and to that end, expanded configuration options are coming very soon to let you enable decoration mode and remove the collision. And if you have any other glass-related requests, we would love to hear them!

Audio FX zones!

But wait, there’s even more! Also introducing: Audio FX Zones! A resizable gadget that modifies sound within its invisible volume. 

One of the delights we’ve had in creating Rec Room quests is the environmental storytelling we get to do. Sound plays a critical role in immersing you in these rooms. We wanted to give you the same power to bring players into special audio environments in your rooms, like how we take you into space in ‘The Rise of JumboTron’ or take you underwater in ‘The Isle of Lost Skulls’.

You now have the ability to make a great throne room with heavy echoes, or a misty field with muffled sounds, or a partially flooded submarine where you move in and out of underwater sections and metal corridors with creepy reverb. 

To enable this, we’ve included our first implementation of Audio FX zones. Using the maker pen you can find Audio FX Zones in the ‘gadgets’ and then ‘other gadgets’ section. One of our use cases for the Audio FX Zones has been to let you tell the story of a complex place through how it sounds, which means you need lots of capability with the shape of the volume.

You can use all of your regular tools to scale, move, and rotate volumes to fit most spaces. We’ve also added in the ability to make spherical Audio FX zones so you can fit curved spaces as well.

Sometimes, you’ll find yourself overlapping these zones, which is why we’ve also included a priority section. This will let you set some zones to higher priorities, so in case you’re standing in an overlap, you’ll hear the effects of that zone, over others. 

We’re excited to see how you use the different effects, and want to hear what you’d like next! 

Learn how to add extra character to your rooms with audio effects by watching a quick tutorial here!

As always, thanks for playing!