In a game with multiple places, is there anyway to have a shared code base that all the places can use?
For example, I would like each place in my game to essentially be a separate map, where only the map appearance is different, but the gameplay is the same in each place. So I would like all my places to have a single shared code base.
This is an interesting challenge that is not easy to solve… so let me tell you how our team solved it!
For our Incubator project, Polymoprhic, sk3let0n and I are creating a massive explorable RPG composed of many places with a shared codebase. We brainstormed a lot of potential ways to have this shared codebase… here’s what we ultimately did:
Create a place within your game that is dedicated to testing your code base BEFORE you sync it with the rest of your game. This is super important for two reasons:
Instead of saving the entire game into a single model and then re-parenting everything, which would take a lot of time, we instead save the children of each service into their own model:
Instead of grouping up each service into a model, which would again take time and would disrupt the hierarchy of our place, we literally right-click the service that we want to save, click Select Children and then immediately Publish to Roblox without grouping them.
Finally, to be able to “insert” your game into a place and then never have to edit that place again, write a script that inserts your entire game into whatever place you are in. Save it as a LinkedSource within your game so that if you ever need to edit the script, you don’t have to re-open every place to do so.
“But won’t inserting 10 models into your game be worse than just inserting 1??”
This was a concern of ours too, but some engineers assured us that InsertService is the same way that the client loads in games normally, and there isn’t much overhead in loading several models at once.
There’s also some other hacky stuff you need to do to get this working, like disabling character auto-loading until everything is packaged in, clearing the children of StarterPlayerScripts (if you need to override default Roblox scripts), locally parenting the contents of StarterPlayerScripts into PlayerScripts for the first player or two to join, etc.
Overall, once you get a system like this set up though, it makes game development a thousand times easier. We’re able to efficiently deploy updates to dozens of places instantly now, and it makes our team way more efficient.
Think of that as like a external website that the game servers can communicate with, but in roblox lua itself
@berezaa Thank you so much for your post - amazingly helpful!
When you save a service as a model via Publish to Roblox, will the resulting model be private to my account? I wouldn’t want others to see the source code.
I did not even realize that you can save a service as a model, and then use InsertService to replace an existing service with a game.
I do have a StarterCharacter, and several StarterPlayerScripts, so I will have to figure out some of those caveats you mentioned.
You wouldn’t happen to have a skeleton demo place that illustrates some of these techniques? A concrete example would help me wrap my head around this.
Another option would be to use a plugin like Rojo (thanks LPChatGuy) or rbxmx (thanks Anaminus). These tools are designed to help break the filesystem - Roblox hierarchy boundary, allowing you to use regular source control tools to keep your filesystem up to date, and then use the plugins to keep each place up to date.
Also, a package manager is currently in production as shown on the roadmap to address this very issue.
Yes, as long as you do NOT select “allow copying” when saving as a model.
You can still use InsertService on a model if it is private, as long as the account (or group) that owns the game also owns the model.
You can’t save the service directly. What you do is “Select Children” of the service and then directly save that as a model without actually grouping them into a model object. When you later insert that model via InsertService, you re-parent everything into the original service
You will want to save StarterCharacter under “StarterPlayer”, but you will have to save StarterCharacterScripts and StarterPlayerScripts as their own models (see the screenshot in my original post)
p.s. if my original post was helpful to you, consider marking it as a solution 
(correct me if I’m wrong) but this still requires you to open up every place in your universe (or save local copies and re-publish) in order to update your place.
My solution is a “fire and forget” system. Once you insert the script into the places, you never have to open them again to ensure they are on the newest version of your game.
From how Packages have been explained to me, a system using packages will be easier to set up than my existing system (which requires a script), but once the script is in place, my system will make updating your game as fast (if not faster) than using actual Packages.
You can just store everything in one script and make it re-parent everything to it’s proper place that way you can just drag and drop the script, but Berezaa’s method is not bad.
I just don’t like the idea of importing stuff from Roblox without it being absolutely necessary, and also using multiple models when you can use just 1.
Perhaps you can combine both methods together but I am not sure if you can add Children to a LinkedSorce (You can still add Children to the Script Linked to the LinkedSorce tho).
Alternatively you can upload a MainModule (Can store children) and require that with your LinkedSorce instead.
But how do you handle making changes and testing them? Once you make a change to one of the models and publish it, then doesn’t that change automatically get loaded into all the other places (since the LoadAsset calls within the LinkedSource will load the updated module).
Easy! You test inside of the template build testing place… just click Play! You don’t have to publish any of the models to test them. Since you are changing code/assets that appear in all places, you should be able to properly test everything inside of your testing place. With this method, you can test before publishing to the rest of your game
bonus: me testing a feature in our testing environment (using Play Solo in studio)
edit: to clarify, your package handler script would NOT load from InsertService inside of your template place. The template place is, by definition, the newest version of your game.
Do you have any similar recommendations for instances in ReplicatedFirst? I sometimes find if I’m one of the first players in a new server, for a multi-place game, that the scripts don’t execute.
berezza is a pretty good hacker. Has some of the whackiest-but-coolest ways of using the API.
Also, universe scripts/services should be coming soon, no? Maybe that’s something different. It was a topic on the roadmap regarding universal assets of some kind.
Universe scripts are designed to run on the game itself as opposed to individual servers. Game services I assume would be able to do things across different places or servers.
There are indeed the following two items (below) on the roadmap which may make something like this easier. There is no documentation on these, so it is hard to say if they will work for this use case.
Packages
Scripts and other assets can be packaged together as libraries to be shared between different places, games, and other developers.
Universe Script & Game Services
New type of scripts that can run at a universe level to allow for matchmaking, leaderboards, etc.
Just submitted a feature request since I think the Roblox system should support an easier way to do this.
Hi, I’m writing here after a while because I found this topic while looking for solutions on how to manage code for multiple places in one experience. Has anything changed during this time? Are there other better/easier solutions to manage codes between multiple places? Or maybe @berezaa solution still looks the best?
From other solutions that I was able to find there are two:
a) usage of Rojo plugin
b) usage of Packages future.
But now I have to decide which one of them is the best and leave me as little work as possible.
Commenting for visibility. Is there any changes to how this approach is done today?
