My hobby game, Hexolus, just had its first fully functional live update, where it published its own changelog and updated a running server to the latest version, which, I’m genuinely super super excited about. 
This has been the product of several months’ worth of work so far, and its one of my most exciting accomplishments for Hexolus.
The game is still a huge work in progress, and, its nowhere near being in a fully playable state, however, the game is starting to get to a point where I think getting some real feedback is super important, and, honestly I couldn’t pass up an opportunity to share my excitement over the update as well, which I go into some technical details at the bottom if my post if you’re interested in how it works.
About the game
Generally the goal of this project is that you’re going to automate lots of things through code (or not through code) in the game and there’ll be a lot of PVP and PVE and such.
What the game is about, what my plans are, etc
The game itself is a sci-fi sandbox/survival style game set on a remote planet called Hexol, and its currently in its very very early stages of development, and I’m really excited to hear positive or negative feedback on the game. You can press R to open up the object placer in newer versions of the game if you want to view any of the game’s current models & entities and such.
The idea is that you’ll be able to explore infinite terrain, and find different resources and such, and find AIs and civilizations that roam the world and function on their own. I have a lot of lore I want to show up in the game as well, sort of taking Minecraft’s storytelling approach to an extreme. The game is going to be a lot like Factorio in some ways, but also a lot like Minecraft’s 2b2t, and will probably have modes similar to Eclipsis’ style of building a base and eliminating other teams. Eventually I want to make it possible for players to use Roblox lua (and a visual block language to generate code) to program AIs in their base as well and create little robots and stuff. That’ll be a long while off, and, it’s sort of the end goal for my project.
I’d love to hear suggestions for my concepts, UI, models, etc, I really really want to know what I am doing right and what I am doing wrong. This project is a massive hobby project of mine, and, I really want to create something high quality that a lot of people will really enjoy playing.
Screenshots from the game
Shield animation video (has an old transition effect, I’d recommend checking out the shields in game to see what they look like when they turn on/off) https://twitter.com/i/status/1350306604353286144
Testing older versions
(If you want to see how things have improved over time)
There are a few commands in the game that let you test old and WIP versions, /flag [flags...] and /deploy <version>-<states>. The flag command can be used to reload the server with some additional flags, such as the CRAZY_ISLANDS flag that generates 100x the regular terrain (warning, it sometimes crashes the server in newer Roblox versions 
). You can go all the way back to version 1.6-TA before the old TeleportService transition method is used.
By the way, if you’re stuck in an old version that’s missing the commands, use the command /88mph to load the latest version (Get it because you’re going back to the future)
I’d recommend just using /flag with nothing extra if you wanna see what it would look like when the server updates, otherwise if you wanna see what the game has looked like in the past, use /deploy <version>:
Loadable versions
1.1-TA
1.2-TA
1.2.1-TA
1.2.2-TA
1.3-TA
1.3.1-TA
1.3.2-TA
1.3.3-TA
1.3.4-TA
1.3.4-TA (Anticheat Test)
1.3.5-TA (Anticheat Test) These both require a special flag, ANTICHEAT_TEST and were the first versions that the anticheat was introduced in
1.4-TA
1.5-TA
1.6-TA
1.7-TA
1.7.1-TA (WIP, do not use)
Live updates?
(Muhaha! They said it couldn’t be done! 
)
This is a really exciting (imo) feat taking advantage of packages, a huge overhaul of my game’s framework, and months of work. Effectively, one game server will do a periodic check to see if an update is available (and if it gets shut down, or hard crashes, another server will take its place, effectively “psuedo-universe scripts”, if you remember universe scripts). When the game’s package is published, which contains all of its current and previous versions, that server will take notice, and tell all other active servers to perform an update, as well as updating itself.
The update itself simply loads the latest version of the package and kills the old version of the game, cleaning up anything and everything. The complex part comes down to actually transitioning between versions. Obviously, you can’t make edits to a running script, so, you might be wondering how the game can continue to function. Well, essentially, the game will completely shut down the old version, taking a snapshot of the game’s entire state in the form of something I call “grave data.” And much like a zombie rising from its grave, the newly loaded version of the game adapts its own internal state to that of the previous version of the game that just ceased to exist.
This is a prerequisite to another of the game’s planned ambitions, which will be persistent servers. The structure of the game is intentionally designed in such a way that it will always know what it needs to be doing by its state alone. For persistent servers to work, the game server will need to save its state to a DataStore periodically and upon shutdown, and then upon its start up it will need to be able to reconstruct its original state from the saved data and be able to continue running as if nothing ever happened.
By far one of the biggest technical obstacles besides the whole transition thing for this was the question of actually shutting down an entire code base at once. This was super difficult, and, I had tackled this in a prior version with good success, but, now its all a fully coherent feature. Basically, any event connections, loops, etc the game uses must register themselves. When the game tells the central Deployments module to load a deployment, the central module will tell it to stop running and collect any state information it needs to transition to the version (“Sending it to its grave”), and the central module will activate the new version, passing it the state info the previous version collected for the new version to handle.