Hi guys! I’m a new Roblox developer trying to understand how I can have 3 different versions of a project, and having all of them share the same pool of assets between each other.
In my current project Jetpackers, I experienced an issue where I have uploaded sound assets to the main project (everything working fine so far) - but then when I want to do inhouse testing, I want to publish this version as it’s own inhouse-testing-version only accessible to my friends - so I open up the main project - hit Publish To Roblox As → Create new game… → and complete the steps necessary. The problem that I encountered doing this is that the audio files cannot be accessed from this inhouse-testing-version, because they belong to the “main project”.
I figured out that you can edit each individual asset inside of your Roblox (inventory?) and manually allow the new inhouse-testing-version to access all of the assets - but this process is very long and tedious - not something I’d like to go through each time I upload a new asset.
So how do developers navigate this? I want 1 pool of assets accessed by 3 versions of the same game: Main, Testing, Public. Do I need to create a Roblox Dev group? - and if so, how do I ensure that other devs/users cannot access any of the project files?
Thank you for any insights, hope you have a great day
How I approached this for CrimeLogic is a bit technical, but with a bit of CLI knowledge you can figure it out.
I use lune to read from the Assets game and the Codebase (compiled by Rojo, but left that out in the example). Then it’s just a matter of replacing a set of services of the Assets game with the Codebase.
Simply put, you can do something like this:
-- build.luau
local remodel = require("./remodel")
local codeGame = remodel.readPlaceAsset(12079134889)
local assetsGame = remodel.readPlaceAsset(12857753286)
assetsGame.ServerScriptService:Destroy()
buildGame.ServerScriptService.Parent = assetsGame
remodel.writePlaceFile("dist/build.rbxlx", assetsGame)
Additional perks are that you can use Git hashes as version numbers, generate changelogs from commit/release data, etc.
You can create different places within the Asset Manager. This would make all assets accessible across the entire game.
One place as the released version (which should be the starter place, the starter place has a little spawner badge next to it), one for testing, and one for development.
I suggest enabling this feature so that you can instantly join each place without having to navigate through the released version first.
Of course, you should make sure to have some whitelist script to prevent random players from joining your test/development place
Thanks for your reply! Is code shared between “places” within an experience? Because I wouldn’t want code inside Main where I am currently working to affect Public.
What about saving to the cloud - will what I save via the “place” Main collide with what I save via the “place” Public and Testing? (If I want separate load/save for each of the workflows - perhaps I am testing a new method of saving inside of Main, or perhaps a player has acquired a super strong item through testing that is not meant for the Public version of the game.)
Is there any way to - through code - understand which “place” a player is currently playing?
Does each “place” have their own server or are the servers for the different places within an experience shared?
By default, nothing is shared between places, except the categories seen in the asset manager. And even those, “shared” means you can access the assets from the other place. It doesn’t mean there’s synchronized assets in this case, although that is possible too. Code isn’t shared.
As for saving to the cloud, it depends on how you manage your datastores. Generally, you just create a different datastore for test-server.
As for servers, every place within an experience has it’s own servers. In fact, one place can have many servers.
As for seeing what place someone is in, you can access that data through the DataModel, using things such as game.PlaceId
Thank you for the reply Exercitus and for clearing some things up for me!
I’ve learned that:
Places have their unique ID that can be accessed.
Every place within an experience has it’s own server/servers.
Since places have their unique ID, and since code is not shared, DataStore can be manipulated in whichever way I want.
So far, it seems that having one “place” per work-environment is the way to go - if anyone disagrees with this please let me know before I adapt to this structure
Another question - currently I have my Main project and I’d like to set up a testing environment for some Alpha testing with friends - 99% of the code and structure should be the same as Main - how can I easily create a new Alpha testing “place” based on my Main “place”? - That would be, how do I CTRL + C → CTRL + V a “place” into a new “place” ?
The simplest way would be to just create a new place in the experience, and then to publish your main place to the testing place (overwriting the default place)
Just to add to this - since, if I understand you correctly, I don’t publish Experiences, I publish Places, then I can determine the availability option of each of my places - such as the testing environment only being accessible for Friends meanwhile the Public place being available for everyone to join and play?
