As I plan out a system that saves server data, including player inventories and bases built by the player in the game world, I’ve hit a fork in the road. My aim is to make servers accessible via a list in-game. Since I want servers to persist, players should be able to rejoin them, even after the actual server has shut down, with all of their things including their bases and inventories reloaded.
I’m faced with two options. My partner @AIasdair suggests using AssetService to save entire places. Since AssetService allows me to use CreatePlaceAsync() to create a new place from a template place and SavePlaceAsync() to save everything in that place, it seems to be the easiest option to support such a system. However, the more instances there are in a world, the slower this would undoubtedly be. I know that Datastore is likely the more efficient option, as I would only have to save the placed building models and their positions & orientations (in addition to an attribution value for who placed the models).
Is my reasoning valid? I think that Datastore would be faster and less prone to failure. I believe that SavePlaceAsync() could take up to 30 seconds or more to perform one save operation; I think this because when I publish an update, it can take about that long with the amount of terrain I have in my game at the moment. My partner sees SavePlaceAsync as the better solution because “servers won’t shut down until saving is complete,” and he thinks that it wouldn’t be slow at all.
I’m not so sure, and so I ask you: What is the best solution for this use case? Am I correct in assuming that SavePlaceAsync() is far too slow?
1.) I already have a functional artificial server saving system working. It works well for the purposes needed.
2.) Datastore isn’t built for saving parts. You would have to create an entire API to pack the information into savable values for the datastore. Could it not overload the datastore limits?
3.) SavePlaceAsync would be called periodically during server run time, as well as at server shutdown, limiting data loss.
For point 2, developers already currently use DataStores to store massive sets of parts. When saving a major amount of parts to DataStores, you’ll want to ensure that you’re breaking things down as much as possible into bare minimums so that you can fit more into DataStores. For example, if you don’t have arbitrary building and you instead have placeable presets (pre-made assets), save those assets as ids and save only their rotation and orientation. Other preferences can also be broken into numbers.
e.g. Potted plant can be saved in a DataStore as 1. When you unload fetched data and need to place them down, do a lookup from the id 1 where the value is the potted plant asset.
For sure. I’m not saying you absolutely can’t save player made structures using Datastore.
But for our case, there’s simply an enormous amount of data to be saved. It could range from player made bases, to the location of vehicles on the map.
I just don’t see anything wrong with using SavePlaceAsync() to do that, as long as it’s done properly.
Datastore works well with smaller sections of building area, such as a plot in a tycoon game. Once you get into larger sections, you raise the potential of overflowing Datastore causing a loss of data. I recommend using SavePlaceAsync() as long as you can create a proper system of saving and restoring information.