Hello. I am working on a game and am confused about the correct way to go about publishing updates. Right now, I work on the main place of a game (the live one) and publish it when I’m finished (and I occasionally soft shut down the servers after an update).
The issue with this though is that It’s not entirely scalable. Whenever I need to test our datastores or want to get testers into a private game, it’s either impossible or too much of a hassle. It would also be extremely bad if I were to accidentally publish a broken version of the game to the live version, potentially losing a lot of players.
Right now I’ve made a separate “Development” game aside from the main game. I’m wondering how I would be able to make changes to that game and be able to publish them to the live game.
For example, If I wanted to add a part into the live game somewhere on the map, I would like to be able to:
- Load into the development test game.
- Add the part somewhere on the map.
- Test for bugs (you get the idea).
- Update the live version with the changes from the development game and keep the development game as it is.
I would also greatly appreciate it if anyone can give me good tips on how to go about releasing updates, bug fixes, and other things to a live game with players in it.
1 Like
There’s no correct way to publish updates. You’re free to choose a workflow that best suits your own needs as well as that of any collaborators. As for pushing to production environments preferably choose something that visitors are fine with.
Whether large or small, I’ve seen experiences do any number of the following in order to ensure that their updates make it through to their community:
-
Soft shutdown. All visitors are forced out of current servers and held temporarily for an amount of time, usually 30 seconds, so that old servers can fully close (max allotted BindToClose time). Visitors are then sent back, generally guaranteeing the presence of a new server.
-
Hard shutdown. When the experience is updated all servers are closed down with no migration of users. These kinds of shutdowns usually assume large community presence in a Discord where they send the update announcement, thus no interaction via the website.
-
Temporary closure. Like server maintenance in non-Roblox games, some developers may prevent users from joining their experience for a few hours until they can ensure that there was no issue in migrating features between branches and for a final live test. This, like hard shutdowns, usually assumes Discord presence to be informed of why the experience is down.
-
Natural phasing. Some developers may allow servers running on old versions to naturally phase out and, for the duration of their uptime, coexist with new servers. This is typically done for experiences that have a framework that can manage this occurrence (old versions are still supported by updates on a new version) or because the update doesn’t warrant interrupting a visitor’s playtime. New and returning visitors will naturally try to enter servers with newer versions; especially helpful for experiences that display a server list.
The workflow that I’m currently used to and what’s been working great for me is dividing my experience between development and production places, the same way you’ve tried doing recently. Generally it’s understood that a live place should never be touched; all development always happens on the test branches of the experience and I focus either on a group of updates or a single feature. When I’m sure that the feature works and has been tested by people other than me, I just republish the working development place to the corresponding live place.
Here’s a picture that shows how our places are listed:
In terms of how we release the update we just rely on soft shutdowns mostly. Visitors don’t spend much time in any place enough to warrant any rigorous release framework. The experience above is a dungeon crawling RPG game so users automatically get the latest updates when they host a new party, so the only exception where a shutdown may be in order is direct changes to maps themselves that affect gameplay. The only place of concern for releasing updates is the lobby or anything that is shared across the whole experience (e.g. data structure). Soft shutdowns have been taking care of that so far, haven’t been met with any cases where I need to hard restart.
12 Likes
I think you can publish changes between places/games with file>publish to roblox to… (alt+shift+P)
1 Like
