What are some alternative options for saving level data for a game like Hurtworld?

Question

For a multiplayer building/crafting game like Hurtworld (where the player can build structures on the map), what are some alternative options or example data structures for saving the world data on the server?

Level data including:

• Grid of squares that foundations can be built on, with a flag to indicate whether the square is empty or already has a foundation
• Walls etc which have been built on the foundations, and multiple floors above
• Windows/doors which can be built on window frames/door frames
• Furniture/machines which can be placed on foundations/floors
• Other dynamic world data such as trees, animals, chests with items, etc

I feel like it's too much data to store in a database. Am I wrong?

If it can be stored in a database, how can I get my head around the data structure I would need to set up? Is there some simplified example?

Can each square in the world grid be represented by 1 row in the database? And should there be a new row for each structure built on a square, with that row referencing the square/structure that it was built on?

Answer 1

When trying to choose databases, or any method of saving information, the way the data should be saved should be dependant on its usage patterns, not on how the world is modeled.

Out of all of the information that describes your world, what information needs to be persistent and what doesn't? What information will be queried more often, what less? What information should be returned ASAP, and what could take a while without harming user experience? Are there some bits of data that are dependant on each other, and should be saved together, or is all of your data completely independent?

For example, if you have a round planet, the player will not be able to see all of its parts. Make sure that you model your data in a way that allows the player to query only the visible parts of the planet at each moment. If you have a LOD system that will show the building and only later minute details such as windows, make sure that getting the building data isn't blocked by getting windows data. If the player will not get closer, that data is irrelevant.

These questions and similar ones should determine your data structures and the way they are persistently saved. From the phrasing of the question it seems like you want to model your data the way you would model your world, and in general that tends to be less efficient. I advise you to learn about data-oriented design, and try to properly understand the constraints you should put on your data, in order to understand how your data should be structured and saved. Once you'll have that, you'll have the constraints that your data places on your DBs.