When creating a game in ROBLOX Studio, the scope, playability, and overall enjoyment of it is entirely in your hands. We’re here to give you the tools you need to build, and ensure that you can share your games with others. But hitting the “publish” button kicks off a series of events that are remarkable. And, like our “Play Button” article we wrote previously, we’d like to share with you the complexities behind publishing a game using ROBLOX.

So you’ve finished your game, and you’re ready to share it with the ROBLOX community. You hit “Publish”. Now two parts of our system–the web side, and the client side–begin working together to rocket your game into our cloud based storage system, backed ultimately by Amazon S3.

The web side does the following: It takes whatever file you’re working on and uploads it to one of our secure web servers with additional data, like the asset ID (the address of the level being updated) and the user ID (otherwise known as the guy who uploaded the level).

We fingerprint the level with a technique known as “hashing“, which lets us recognize if the level file being uploaded is identical to one we’ve already stored. It’s important that we do this for every single game, as we want to avoid storing redundant data. The “hashing” process applies to images and models as well. If there is no instance of the hash, the system recognizes and imports the file contents and uploads it to S3, the cloud storage database that our games populate.

The client side of the equation is a bit more complex. Once you’ve built your place inside ROBLOX Studio, when you hit publish, immediately the file is compressed. Then a call goes out to our web servers, specifically, our “upload farm” of computers, and the data is processed through our “upload handler”.

If you’ll recall from our previous article, we have different “farms” of computers to handle different tasks. We have an exclusive “upload farm” because the kind of requests you make in terms of bandwidth are different depending on the task you want ROBLOX to accomplish. The upload farm is tuned for larger pieces of content and longer communication times.

Once your data hits the upload handler, a five-step process begins, culminating in your game being securely stored on our content storage cloud.

1. The upload handler decides whether or not the data can be saved.

2. The data is validated.

3. The data is saved to our temporary content store. Our temporary content store is a safeguard of sorts–it’s where we park the data so that if there are any problems (like a web server crashing) moving forward, none of the files will be lost. It’s like a digital insurance policy.

4. Records the meta data in the data base. At this point, your game is playable, even though it hasn’t yet reached our content storage cloud. If somebody requests to play your game, we can run instances of it from our temporary content store. When you hit publish, we want your game to be available to play as soon as possible.

5. Pushes the data to permanent content storage on our S3 web storage cloud. The important thing to gather from these five steps is the notion that your published games live both on a temporary cloud, then a permanent one. This is done not just to get your game out to users as quickly as possible, but also for security purposes. We back up every instance of every place you ever make.

Once your game hits our permanent cloud storage, that’s where it stays until you choose to update it, where the entire process repeats itself.