I would like to store data which needs to be maintained while the game is being played or when level change occurs. Currently, the game structure is such that each level is treated as a state. When a level change occurs, the state is changed and the current objects are released. When loading the new level, the objects are recreated and reinitialized. The problem is that data such as combat level is lost during level change. Like in level 1, if the player object's ammunition is increased by 10 bullets, this change is not reflected in level 2 because the player object is recreated again. I have thought of a few ways but am not sure which to choose. One is not to destroy the player object. However it seems to violate the existing game state structure. The other is to create a global, persistent class to store whatever data needs to be maintained between levels. It looks easier although it could quickly become a huge messy class file. The third is to do object serialization and store whatever needs to be stored in a text/binary file. Then when the new level is loaded and the objects are recreated, read from the file and assign the data saved to the object's member variables. This approach seems to be the cleanest although i am not sure if reading and writing to file will slow down the process significantly. In game development, what is the better method to use? Besides game saving, is object serialization to file used during level loading as well?

Extraneous disk access is almost always avoided as it's universally slow on just about every platform. So you don't want to be saving out data between every level, unless you happen to implement autosaving or some other feature that absolutely requires it.

The better solution is to persist that data at a higher scope. You mention that your game is split into a series of states, and that each state manages the resources it will need, RAII style. But there's no reason why you can't have the states be hierarchical. For instance, "initializing the game", "running the game", and "shutting down the game" are three states that exist at the highest level. You're either loading globally used resources, using those resources, or freeing them again. The "running the game" state is where everything interesting happens. Inside that state, you might have sub-states "single player game" and "multiplayer game". These are the states that will manage your player data. The "single player game" can then be split into different levels, each being its own self-contained sub-state. Those states contain level-specific data like monsters, world items, map geometry, etc. As long as you stay in the "single player state", you can switch levels at much as you want and not worry about player data because that data is being persisted by a higher-level state. At the highest level, your graphics system, network system, and audio system are around for the whole game, since they aren't freed until the shutdown phase, which is application exit. At the lowest level, you aren't holding on the monster and item data that isn't needed between levels. Essentially, the combination of states at different levels of the hierarchy, like "running the game/single-player/level01", make up your single discrete state. It's just managed different than a flat state system. If you can come up with and manage an appropriate state hierarchy, you can ensure your data will stick around just as long as you need it and no longer [smile]

I hope that helped a bit!

Thanks for the comprehensive explanation :)

So if a hierarchial state machine is used, there would be 1 more level above the level 1 state called perhaps MainGamePlay state. Then for objects like the player object which needs data to be persisted through level changes, they will be created in the MainGamePlay state.

Then when the level changes, only the objects in the states like level 1, level 2 etc... below the MainGamePlay state hierachy will be released. The player object in the higher level state will still be maintained.

Then when the game is about to exit, there will be a ExitMainGamePlay state to release the player object.

Is this understanding correct?

I handle level change in my current project by not destroying the player object. But my levels load fast enough to not even need a level transition state.

The slowness of file save/load method doesn't matter if it is only done during level load. Also, for saving large files during game play you can spawn a worker thread to save and have no effect on framerate.

It's not the speed that's the issue here (although it really is still an issue in general since disk I/O is one of the slowest possible things you can do). It's that you shouldn't use the disk as a means of patching design limitations and temporarily storing data that you could just as easily be keeping in memory through a simple re-structuring of your states. You already have a state-based system in place that you understand, so all you need to do is make it layered and the proper resource scopes fall out naturally.

Another solution could be to have a singleton class that contains the struct with the players state data, so the struct is allocated once at the game begin and you need only to set the value in it, befor change the levels, this method avoid fragmentation problem, and speed problem like the read and write in a file.

Ok that don't is the more elegant solution, but this assure that the data persist also when all the levels are unloaded, you can also freed the resource, and this work well for the single and multiplayers too. So at the higher level the levels handler class could be the singleton, that know the current level, and contains the data, of the player(s) and about the level. But this is only another solution, the one from Zipster is valid too.