Hi, I like to work on own games, but with own engines. Or better I like to create those engines for games :D I am working on Xcode, with C++ and OpenGL. My question is, How can I efficiently store the data of a hole open world with all objects, persons and so on in it.

I mean, I could imagine that the world is split in certain areas, and you load only near by areas. But if every map has also a few hundred objects on it, with maybe buildings, cities, ... that would be a hole buch of loading, than when I image it is a flat area, so I could actually see pretty far, than I must have really big areas with a lot more objects on it, than maybe AI that is calculated the hole time for those areas.

And than second thing, let's say I am able to change the world, like in Minecraft, remove certain parts of the world and add it some where else. I must save and load this again to that area. Is there a nice and good way to load, save and store such worlds, for an open world.

I would just write everything to an textfile. And store each area in a Textfile. When loading an area, I would create an 2D array, store all informations in that, build out of that array an Vertexbuffer, load it on to the GPU and render the hole area. But that don't seem to be good.

Honestly... you're over thinking this. And I learned this myself as I started building my own engine.

Morrowind, Oblivion, Skrim, Fallout 1, 2, 3,4 and New Vegas, most games made with Cryengine 3 and 4, and Minecraft actually just stores data that defines the world in the ram. That includes object placement (including the f*cking trees), the whole item database, characters, particles, shaders, and quest data in memory. It generally does not take more than 50 megabytes to store that data.

You don't need an efficient way to store game and map data. You just need a way that WORKS. It should not be difficult to implement, or get data at all. The implementation details do not need to be overly complex. You just need it to work. This is where a lot of people get tied up.

The second is knowing what actually needs to be streamed. Usually this is Path-finding data, models, textures, and sounds. Most likely you'll keep some of the data in memory at all times as it's that common.

The third part is knowing WHEN to stream, and when to load an entire level.

Finally...DO NOT... for the love of frickin GOD... absolutely DO NOT build an open world for the sake of building an open world. It takes several years to get anything that is actually memorable, and populated enough for it to be interesting. If you are trying to build a game that is "OPEN WORLD" consider doing so in the fashion of The Legend of Zelda, Gothic, or Pokemon, where the map and story is linear enough to keep the player going in the right direction without getting bored.

Highly agree with Tangletail's reply. Keep it simple. Also point 4 slayemin's reply. I did something similar for Castle World for example. I split the world into AABB cells. Each cell has a terrain mesh and game objects. Start with the cell that the camera point is in, and recursively traverse neighbor cells. Collide their bound boxes with the camera's view frustum to see if they are visible. Then for that cell, draw the terrain mesh and all objects whose bound boxes intersect that cell. This information is cached of course. It works and it is very fast. This is just an example. There is no one solution.

ok, thank you, that helped ^^