Archived

This topic is now archived and is closed to further replies.

Idea for persistant game state and game object storage system

This topic is 4948 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I just wanted to ping-pong this idea off of people and see what they thought: I want to design an system for storing / manipulating massive amounts of game data (hundreds of square miles). A custom database system would be responsible for storing objects in a heirarchy (scene graph). It would be an outdoor game, so things would be layed out for the mostpart in a grid. Rather than having a single root node for the grid, there would be numerous root nodes, where each root would the base of a square area or region of the grid. A quicky lookup of grid position would find the key for one of these root nodes, from here the rest of the tree traversal is straightfoward. Each node would be the same size, containing the key values (not memory pointers since this id database driven) for the child, sibling, and parent nodes on the tree, its own copy of its key, a string for some arbitrary label, a matrix, and and offset to the actuall data of the object which is kept in a seprate file/system in which same sized data blocks are managed. Each node of the tree would need to be the same size in order to be kept in a b-tree for fast searches/additions/deletions. the actuall data content of the node could be variable length, and hence would be stored in a seprate system. The idea is to achieve state persistance of game objects in a huge world (but not neccessarily a MMOG). This system could be implemented server side with object views to distribute game state to clients. So far, some issues of mine would be to store items such as terrain data which could have other data associated to it such as alpha maps for texture splatting, and terrain layer attributes. since each region patch could have a varying number of alpha maps, would these be stored as seperate entities in scene graph? if there are stored as one unit, how could such an object be effieciently parsed from the raw database and serialized. C++ serialization of more complex data types is quite a monster to deal with. Any thoughts? BTW, I have the b-tree implemented already, so try not post responses pointing out the difficulty of implementing such a system, cause i''m well aware of the nature of the beast.

Share this post


Link to post
Share on other sites