where to put the data in a game engine

Started by
3 comments, last by corrington_j 20 years, 1 month ago
currently I am working on a game engine with the componts of a graphics class, input class, and sound class. I also have a state manager, which uses base states, and then I derive the new ones. I am wondering where to put the data, I thought about just putting the appropriate data in the derived state, say playState, but then this data is only accessable to that state, and it would need to be loaded everytime that state was created. Also if I wanted to have a load state, it would not have access to the data it needed to load. Should i have a seperate class that was just a data manager, and how would the states access this, or would the data manager handle all the data itself. Say it might have an update and render members. Or would I make accesor members for the states to accesss the data. Thanks for the help Jesse
Advertisement
A data / file / memory manager is very common and is a great way to abstract away the data loading, to keep track of your files and memory usage, and to give you a single place to optimize memory usage. I would recommend to write a file manager as a singleton and then use it everywhere in your code where you need to use and load files. If the file manager is a singleton everyone can access it and it ensures that there is only one file manager in existance in your program.

technic
ok, well how would i access the data in this file manager. If the data was public, and the states had a pointer to the file manager, how would they actually access the data.
can people give me some help with a little bit more specific example. I have the idea in my head, i just need some more specifics. thanks
something like this maybe:

DataManager->getBitmap("bitmapFileName.bmp")DataManager::getBitmap( const char * fileName ){    if ( isAlreadyLoaded( fileName ) )        return internalGetBitmap( fileName );    else        return loadFile( fileName );}


that''s kind of inefficient in that it loads files only when they are needed. kind of a just in time algorithm. a better way to do it is to build your level files such that they contain a list of all files needed for the level. then those files get loaded into memory (by the DataManager class) when the level loads. if you have really big levels, you can build in a compartment system whereby you break the level into various areas and only load the files for the current area. when the player is approaching the border between 2 areas you begin to load the next area so that when he/she reached the border there''s no wait for loading time. as soon as the player is safely within the next area, you unload the last area from memory. obviously this requires that the levels be designed such that you can''t see one area from another (perhaps there''s a narrow mountain pass, or a door/doglegged hallway). this is how Halo does things, but then that''s also a console game where memory is a lot tighter..

-me

This topic is closed to new replies.

Advertisement