vector database for save system

[Brahmbir]

Hey everyone,

I've been thinking about the massive challenge of creating a save system for a big open-world game in Godot. You know, saving the position of thousands of NPCs, what state they're in, which trees have been cut down, where a dropped sword is... it's a huge pain. The typical approach of saving everything to a giant file gets slow and messy fast.

So, here's a wild idea I've been kicking around: what if we used a vector database?

---

The Big Idea: Spatial Saving

The core problem with traditional saving is that we're treating the entire game world as a flat file of data. My idea is to use a database that's built for geometry and location. Think of it like a super-smart librarian for our game world.

Instead of saving every single detail of every object, we'd only save the stuff that changes. For each of those changed objects, we'd store its unique ID and its exact position as a vector.

For example, if you move a crate, we'd just send a tiny bit of data to the database: "Crate_001 is now at this new position (x, y, z)."

---

Why This Approach Is Awesome
Using a vector database for a Godot game is a game-changer for open worlds.

Fast Loading: The database's built-in spatial queries let you instantly find and load only the objects in the player's immediate area. This means no more long waits and much smoother gameplay.

Tiny Save Files: Since you're only saving the changes to the world (like a moved crate or a dropped weapon), your save files stay small and fast.

Powerful Logic: You can run flexible queries for in-game events, like finding all "low-health enemies" or "unopened chests" in a specific area.

Range Triggers: You can set up a "trigger" that constantly checks the database for new objects entering a specific range around the player. As the player moves, the system unloads distant objects and seamlessly loads new ones coming into range. This dynamic loading and unloading is perfect for creating a truly massive, uninterrupted open world without performance issues.

i know that is create massive save file but its interesting idea

[sockeye-d]

This is better handled as an add-on so users who don't need this complexity can avoid it, in my opinion.

[tomsterBG]

I'm very sorry to deviate, but i know AI style writing when i read it.

The core problem with traditional saving is that we're treating the entire game world as a flat file of data. My idea is to use a database that's built for geometry and location. Think of it like a super-smart librarian for our game world.

Gemini gives me so many of those. Think of it like gives an example analogy. The wording is always very similar.
Nonetheless, what you're saying is more important than what you're using to help you say it.

Then the list of "Something: explanation". Typical Gemini 2.5. Also Gemini has the quirk of constantly giving me health examples which is exactly what i see here. And some of the points are like "why say this, the other system allows it as well", well the AI tries to make up all the content it can even if that's not such a big deal to care about, it'll mention it.

Let me give you a solution to look at. Quadtree. Then a custom system to know what you'll be saving and what are its defaults and perhaps use chunks instead of quadtree. You can look at Minecraft-y systems or Factorio, they are similar except Factorio is smarter with copied entities and they infer some data instead of saving it. You can subdivide the quadtree when more than x entries need to be saved. Still all of that is not to be added to the engine, it's your own or for a plugin.

[sockeye-d]

Ah yeah I noticed that too, I'm glad I'm not the only one. Also I agree that a quadtree can be used. Another solution would be a spatial hash grid (basically a dictionary indexed by a Vector2i, which has a near constant lookup time if you choose a cell size such that each cell has about one element contained.

[sockeye-d]

I think the fact that there are at least two equally good solutions points to why this shouldn't be a core part of the engine. Different games have different needs, and it's impossible to solve them all with one solution. Including more than one bloats the engine, and it probably would only fit a certain use case where it works, and everyone else who doesn't have that use case would have to make their own anyway.

[AThousandShips]

Save systems, and data systems in general that aren't specific protocols like JSON or low level access like binary data writing, are necessarily "one size fits none", generic systems inherently add overhead, both in performance and storage

For simpler systems JSON is generally sufficient, it's more flexible, but has more overhead, and directly writing values in binary is not very complex, though it has the drawback of having to ensure compatibility when modifying your game

In the end this is best handled by multiple different add-ons to fit your specific needs