Improvements to Updating Experiences

[tareyza]

Hi Developers,

As we announced in RDC, our team has been hard at work making improvements to the way you update your experiences. Today we’re happy to announce a number of changes and features we’ve made in the past few months to make releasing updates a better experience for you and less disruptive to your users.

Clearer text & documentation

We’ve heard feedback from the community that there’s been confusion around the update options available and what they do (and even whether they’ve taken effect). We’ve released new updated text, starting on Creator Hub, that better conveys what’s going on, which includes the renaming of “migrate to latest update” to “restart servers for updates.” We’ve also updated our documentation to more clearly convey what’s happening.

Experience-wide Migrate to Latest Update

We added the ability to use “migrate to latest update” to update an entire experience, not just a single place within an experience.

To access this, you can navigate to your experience thumbnail on the Creator Hub homepage:

Faster Updates

The “migrate to latest update” option has taken up to 6 minutes to complete an update. We’ve now optimized this so that for the large majority of your experiences, this will complete in less than 1 minute. Now, only the largest of experiences on the platform will take closer to 6 minutes. Servers running older versions will stop being considered during matchmaking the moment you start the update.

Prewarming Updated Servers

As we’ve announced at RDC and the creator roadmap, when players are kicked out of a server due to an update we save the state of the server so that players are able to stay with the same set of players when they rejoin. We also will start replacement servers in advance for these players, allowing them to rejoin almost immediately.

Privating Experiences

Privating your experience now closes all places within your experience, not just the root place.

Consolidating Update Options

For the past few years we’ve had two different options for updating games: “shut down all servers” and “migrate to latest update.” We’ve seen developers repeatedly getting confused about the differences between the two. We’ve even seen top developers press both buttons just to be sure their updates are working.

With prewarming, “migrate to latest update” has become the better option for players - our data shows they get back into the game faster, play longer, and quit after rejoining to find a new server less frequently. On top of that, it doesn’t unnecessarily kick players that are already playing on the latest version.

We’ve heard concerns about this feature though - the feature was not well documented, it launched with some bugs, it was only available for individual places, and took a long time even if you only have a few instances to update.

We’ve heard you loud and clear, and we’ve now corrected these drawbacks through the improvements described above. In order to remove the confusion around these two features and simplify development going forward, we will be consolidating to “migrate to latest update” as the primary update option to improve clarity on what is happening.

We’re releasing auto-reconnect (described below) after the holiday season in early 2024, at which time “Shut down all servers” will be retired.

Moving forward you will have the following options to close servers for updates:

1. Restart Servers for Updates - Used for normal game updates. Updates your experience or place in less than 1 min for most experiences. Players get to rejoin with a new server ready and with the same set of players. Servers running older versions will stop being considered during matchmaking the moment you start the update.
2. Make private - Used to stop game-breaking bugs. Immediately kicks all players at the same speed as “shut down all servers” and prevents new servers from starting and players from reconnecting.

If these options are not sufficient for how your experiences are updated please share your feedback with us so that we can ensure all use cases are accounted for.

Auto-Reconnect - Coming Soon

One of the most requested features around game updates is to have Roblox automatically reconnect players instead of just disconnecting them. While we aren’t ready to release this yet, a lot of the work that’s gone into “migrate to latest update” has moved us closer to being able to do this.

As we shared in the creator roadmap, we are continuing to work on making this happen, and we expect this will be released after the holiday season in early 2024.

Please let us know if you have any questions.

Thank you.

[SuperPat77]

Hey everyone! I’ve worked on the backend implementation of all of these features. I’ll be watching this thread and answering any questions that come up!

Also, the new “Experience-wide Migrate” is rolling out right now and should be available in the next hour or so (EDIT: it’s live!)

[scaryzane]

This is great! One really useful addition to “migrate to latest update” would be “auto-migrate old servers”. Perhaps something like:

Whenever the creator hits auto-migrate, old servers are not considered for matchmaking anymore, as stated here, and those old servers have an event fired to them. When the old server receives that event, they can do a variety of things such as:

1. Start a countdown to give players in the old server a couple of minutes to finish up what they’re doing before it automatically migrates them.

2. Automatically migrate everyone in old servers to newer servers with the new update instantly, effectively removing all trace of old servers.

[yoolurs]

If these options are not sufficient for how your experiences are updated please share your feedback with us so that we can ensure all use cases are accounted for.

Something I think would be extremely useful is having multi-place scripts.
For example lets say I have a dungeon fighter game and to reduce lag every dungeon is split into a separate place within the experience. Lets say I have 20 dungeons.

Now lets say my game has various swords and I store the damage values in a ModuleScript. If I want to change a swords damage I have to edit the Module Script in ALL 20 places and if I forget just one of those places then that sword will deal less damage in that dungeon. Also fixing a bug will be super annoying when I have to patch it in every single place.

If there was a way to update the same script globally across all places that’d be SUPER useful. A good way it could work is if two scripts can be tagged with a tag name. All scripts that share the same tag name will be updated together. Please consider this and thank you guys for all the updates nothing but approval from me.

[asimo3089]

Fantastic. You don’t know how much confusion we’ve had when updating Jailbreak. It took us a few updates to learn that places within the experience don’t shutdown with the main place.

Auto-Reconnect is gonna be a game changer and I love that you’re saving data involving who was in the server.

If I had any feedback, seeing a graph displaying old and new server counts would give me confidence the button was clicked and possibly inform my decision on when to push the button. For example, I could push the button immediately after an update drops, or push it when ~50% of servers are already new.

[SixEightJakey]

@tareyza

Auto-Reconnect - Coming Soon

Highly recommend all developers to be using Quenty’s Soft Shutdown while Auto-Reconnect is being worked on. I use it in my games and have seen nearly zero loss in CCU when I push updates.

Quenty's soft shutdown - Roblox

[Alex645ca]

I’m not 100% sure if this would fall under the same umbrella, but some improvements to the Version History page would be nice to have - a month or two ago I decided to make local backups of a bunch of ancient games of mine (circa 2010-2013) when overwriting older projects with newer ones was the norm, and each one took a very long time on account of having to go back pages and pages over and over to find the last version of each particular place. A button on each version to immediately open it in Studio directly from the archive servers would be nice, or at least the name of the place at the time (if such data exists)

[plaincamron666]

Do you know if this would have also resolved this bug: TeleportService.TeleportAsync doesn't work after a shutdown has been performed - #4 by 0xFE0F

[SuperPat77]

You can almost do this today. When functions are called as part of BindToClose they have 30 seconds to complete before the server shuts down. You could use that time to display a message to users that they will be migrating to a new server for an update soon. It’s not perfect - 30 seconds won’t be enough in all cases and you need to be careful that you don’t do something important right at the end of the 30 seconds that could get interrupted (e.g. updating a datastore). But, it’s something you could try doing right now

[SuperPat77]

That’s a bit out of scope for the server update process. Are you able to file a separate feature request for this?

[SuperPat77]

(Sorry for the spam, will consolidate replies now )

@asimo3089 glad we can clear up the confusion! Thanks for the feedback. Giving more information about the current running servers as well as in-progress migrations is something we’ve been thinking about. Might make for a good hack week project

@SixEightJakey Great resource! Another good one is EverCyan’s SoftShutdown2. I noticed Quenty’s does an extra reserved server teleport to keep players together. That’s not required when using Migrate - you can just instantly teleport back to the same place and we’ll keep everyone together. Another note: even after we ship auto-reconnect you might still want to use a SoftShutdown script in order to customize the teleport behavior (i.e. pass some extra teleport data)

@Alex645ca There’s a feature request for that over here!

@plaincamron666 That bug is independent, but should be fixed with today’s new Engine release. Let’s follow up in that post

[PeZsmistic]

To confirm, we will still retain the ability to shut down specific servers? It’s important to be able to cherrypick and kill servers in a bad state (either that way through rare bugs or command misfires).

[SuperPat77]

Correct. This is all about Place/Experience-wide server shutdowns. We’re not changing anything about shutting down specific servers

EDIT: Also, if you think any of the “servers in a bad state” are caused by issues on our end and not in your own scripts, please make sure to file a bug report!

[Mimi_Dev]

This all sounds pretty good. Glad to see migrate to latest update is finally working the way its supposed to!

Just a suggestion I’d like to add… in the case of one of these update shutdowns it would be really cool to have a way to store data from the shut down server and send it over to the new server. This could allow us to restart gameplay wherever the players left off before the update occurred. A feature like this would reduce player anger and disappointment, for instance if they are interrupted in the middle of a winning match or just about to finish a difficult boss fight.

I’m thinking something along the lines of how we can send data with the player when we teleport them to a different place in our experience (but server side).

[SuperPat77]

Oh, interesting! Haven’t heard this request before. With Prewarming + Migrate it might be possible for us to tell the server what the replacement GameId is (maybe in the BindToClose callbacks?) and then you could use datastores to transfer some data around. If you’re able to, could you file a Feature Request for this?

An alternative would be to pass it as part of teleport data (which you can do today) but it might not be as reliable since it’s coming through the player instead of the server. Also, there might be information you don’t want to expose to your clients

[heedicalking]

It would be nice if we had an actual way to shutdown servers and reserve public servers. I don’t want to disrupt people in the middle of a match and I’d rather transfer them to a new server after. The problem is the old server often stays up longer as it gets bombarded by new join requests and I also don’t want to transfer players to a reserved server because they can only be private, which leads to the server dying out quickly.
My ideal method would be to flag the server for an update, transfer all the players to a fresh reserved updated server, and shutdown the old one/disable it from being considered in join requests from both the website and teleportservice.

[Mimi_Dev]

I think the only issue with using datastores is if Roblox gets load times down, theres a chance the data wont be saved from the previous server before players land in the new one.

Will we be able to pass teleport data for this though? Is that exposed to scripts? Because it sounds like Roblox is in control of moving players to the updated servers. Teleport data could work for anything simulated on the client + single player games where it doesn’t matter if the client is in control.

I’ll try to remember to file a feature request!

[BillB1ox (Will)]

The only feedback I have is that it should be documented and show the difference between shutting down and migrating, because they both seem the same to me.

[yoolurs]

Where is the best place to file one?