I am making a game that uses persistent worlds, and each world is split into a 63x63 grid, each square is a different place. I would rather have one server per world but if you teleport a player to (0, 0, 1000000) you’ll see the issue. Though, that’s not what I’m here to ask.
Each square of the world will probably be created with CreatePlaceAsync if there’s no better method, but since the world is persistent, it would be a disaster if 2 servers were to exist for the same square and kept trying to save over each other.
Is there any way to make it so that each place can only have a single server and will simply reject players if they try to enter while it’s full? Any method is fine as long as each place is copied from the template place and is able to be teleported to, and each server is able to know which square it’s on, most likely using a datastore with the place ID.
Also note that the worlds are made by the developers, not the players, which is why they are so large.
Not possible. Roblox automatic matchmaking applies to places which means creating new instances if existing ones are full or the join request can’t be met (e.g. teleporting too many players to an instance with not enough open slots).
Depending on the extent of persistence you need, the only way you can maintain a single-server design controlled fully by you is the use of reserved servers. Reserved servers allow you to issue a ticket for one server removed from automatic matchmaking.
Realistically you’ll have to let your server automatically generate reserved servers if the player’s world bounds are within the scope of your map or you can handle this sharding yourself. Each reserved server would represent a piece of the grid instead of a whole place and then you’d save persistent states according to that reserved server’s information.
You will have to manually load and handle information when the instance becomes alive again (minimum 1 player in the server) but for the most part you shouldn’t have any save collisions since you can update the instance’s state when it begins to close (BindToClose). The question then is how much persistence you need. You can easily just fragment into multiple DataStores if it’s that heavy and you need deep persistence on even the most minute details.