Is it possible to create servers that stay up 24/7? I am making a survival game and I’d like to add a base building mechanism so you can build bases that stay on the server and you can raid other people’s bases.
I would only create 3 or 4servers maximum that would get wiped every so often so everyone’s progress gets reset.
Is it possible to do this? And how could I achieve this?
I don’t think that’s Possible as a Server Closes by either:
Everybody Leaving
When Everybody leaves, The Server will Automatically Shutdown.
Developer Shuts down all Servers
Potentially for Updates, Or just to annoy people.
Roblox closing for maintenance
The Average Roblox Thing, Roblox sometimes goes down for a few hours on the weekends.
If anything, you can just Afk in the game and have the same effect.
Or, People would have to be Joining after Players Leave so the Server doesnt close.
This may help:
Hm
Is it possible to only have 3 servers with specific server id’s and the data on each server gets saved to the specific id without overlapping to the other servers?
And would it be possible to name them within a menu gui so that you can keep track of what server you played on?
Also I’m pretty sure those functions are sadly all depricated
What you could possibly do is create a menu game, or where the players would start and then create a separate game they could teleport to. This would allow only one server to be up at a time per map. Then, instead of having one person in the server 24/7, everytime the last person leaves, use datastores to save all the building and reload the buildings when someone rejoins and the server reboots.
How would I do that? How would I be able able to make a datastore that automatically loads up the specific server that was being saved?
There would be a bit of a process but what you could do is when a player creates a server (or you create a preset server which makes this easier), give that created server an ID, can be anything as long as its identifiable for you when scripting.
Then when a player teleports using that ID you just use that ID to access the datastore and load in that progress (yes datastores isn’t limited to just player IDs, lol), however…
The only issue I could see from doing it this way is what happens when a player tries to join using that ID but creates a new server? How will that data be saved across places and also updated? It also wouldn’t work because you’d want full player to player interaction.
This of course is true unless there is a way to teleport players to a very specifically created server and also prevent teleportation when that server is full. Honestly I haven’t done enough research on the teleporting system since I never had to extensively use it yet so correct me if I’m wrong 
That makes sense, I think I’ll give it a go.
As for preventing the creation of other servers, I think I’m gonna make a system that physically prevents you from joining or even adding a queue system.
This is exactly what I meant! Thank you for putting it into greater detail. Im not 100% sure but I think you can prevent server overfill like you said.
Heres a post for blocking server overfill. It’s not a perfect solution but it looks like it might be a bit helpful.
The question is how would I be able to save the exact location of bases and stuff?
In the datastore would I do a script that would save everything in workspace and load it in once the server restarts or is there a way to track the location in a value system for each base part that would be saved into a datastore and loaded?
You would need to have a way to identify each building block, be it a number ID or name so you can reference back to it when you try to load it in. You would need to use this ID to save it in your datastore which would have its position, scale and orientation attached. Then use this information to put this building block back to its original spot.
If you give your players full customization on how their building blocks look like (for example a single part that they can color, set the material, etc…) then you would need to save almost all visual aspects of that building block along with its position, scale and orientation.
As long as you believe that people won’t be able to go crazy with hundreds of thousands of parts you should be fine in storing all this data since the data limit is quite large now.
I did some research and there is a way to save everything in workspace via serialization.
Serialization looks like its not hard to make as its using tables and stuff for values.
The problem is though I have no idea how to make the datastores recognize which world the serialization values belong to.
All the videos and articles I saw had it working on only one server. I guess I could make a queue system so it doesn’t overflow to more than 1 server and cause corruption, but that idea seems kind of tedious and might bring down player count.
Yup, that’s why I mentioned earlier that you need to give these pre-determined (or player created) servers a name or ID that you can pull from in the database.
I don’t think persistent servers are the way to go here, because they’re not native, any method to having them would be a weird workaround if not a bug. Maybe make a datastore system that stores information about all the bases, then when another server loads, load that datastore’s information into the world.
In order to make it so it gets wiped every so often, maybe make a value that says how many servers this can be replicated to, then increment that value by 1 each time a server loads those bases, and if it reaches a certain threshold, just get rid of the data for those bases.
I would store this a couple of different ways.