I’d like to have different terrain and maps across different places but have a basic structure of my FPS framework synced across all of them, similar to Entry Point or Notoriety so that I can easily update the framework without having to open every place and copypaste them in.
My guy, it’s called Packages. Just turn your framework into a package (either having most logic as 1 drop-in package, or only the modules or core assets) and there you go, you have a system synced across all places
That or you can use 1 place but load different levels by checking what level name the server got using TeleportData, this way you can specify a default game data like
local DefaultData = {
level_name = "LobbyScene",
is_menu = true,
}
-- inside of PlayerAdded event, you can retrieve player join data and then the teleport data should they have that, then replace the DefaultData table with the teleportdata
Doing this is bit more complicated but gives more control over updates but also this might not work for multi-scripts, but for starters i recommend Packages
1 Like
Make no mistake: unless you have an automated deployment workflow which you will not get with native tooling, you will still have to open every place and publish it when you make changes to your common components (whether you’re using packages or Rojo). It’ll save you the trouble of copy-pasting, but it will not remove the need for you to open places and update the synced copy or publish a place after making an update to a package.
Then i guess just have 1 place but load load maps depending on TeleportData (so if teleport data has value with level = “MainMap” then clone and spawn the map corresponding with that name), using a default table would allow you to have your lobby/main menu and other maps share the same codebase without creating multiple places.
You basically listen for when a player joins, get their join data and teleportdata from that (or use the default table you made if they don’t have that)
Now multiplayer might be tricky, but generally if your main menu is GUI-based, no one would see eachother anyway and singleplayer mode can be just a reserved server teleporting the 1 player who triggered the event.
It’s not really that deep; there’s really no trouble in opening your places and making sure all the necessary components exist, as long as you primarily have the sync behaviour. A single place is too difficult to manage depending on the context, and in some cases you actually can’t - for example, my experience is several GB and will fatally error during publishing if I put everything in one place.
1 Like
I mean you will never come to a point to ever need to code everything in 1 single place unless it’s not something complicated (like an Obby, Tycoon or Jailbreak or smth idfk). I was kinda just talking out of my ass.
In-fact if you cram too much shit into 1 place, the game will not run. Either the server will hang or if you code everything on the client, your computer will blow up (or just the Roblox client will crash)
So yeah, i’m sorry for recommending coding everything in 1 place thing.
The only issue with this is that my codebase is a bit big and spread across several scripts cluttered everywhere which would be a massive pain to convert into a package. Should’ve probably mentioned it in the original post, oops.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.