Game Data loading/serializing

Started by
4 comments, last by Matt_D 14 years, 10 months ago
Hi all, I've been working on my c++ game for quite a while and up until now, I let each class load its own data from disk. So each class that corresponds with some game asset on disk has a class::Load( inputStream ) method for loading. Having used this for a while, I came under the impression that having your load/store from disk methods within your classes degrades the re-usability of the code. Also I noticed that many libraries have separate loading and serialization classes/methods alongside their usual library classes as sort of helper functionality (For example DirectX and NVidia PhysX). Does it, in your opinion, improve re-usability to separate loading/storing from the actual classes, or is this just my miss perception? What is your experience on the matter? Thanks, Dietger
Advertisement
I don't think it alters your chances of using the code again. "Again" is the key here. If you keep changing your mind about the way your code looks you'll never finish the game, and the "again" becomes academic. Finish your game already! That way you'll know for sure.
Also, if it is the "wrong way around", it's not that big a deal to change it when you start on your next game.
You are probably right, but I was not intending to change the engine. I was mostly interested in your opinions on my findings. After all, I am hoping to learn form this project as much as possible.
Quote:Original post by dietepiet

Also I noticed that many libraries have separate loading and serialization classes/methods alongside their usual library classes as sort of helper functionality (For example DirectX and NVidia PhysX).


The reason for this is that serialization mechanisms must frequently support third-party classes which cannot be modified, thereby making intrusive approach impossible.

MortenB has a good point there, but generally speaking I think loading code does not belong into the asset's class. Your model/texture/wave stores some data, so it should be able to construct itself from data, regardless of where the data actually came from.
so, in any commercial engine ever, data loading is handled in large sequential blocks to maximise sequential throughput of storage media. so, your resource system will pull in your entire level file in one go. it will then go through the data that has been pulled in, and do one of two things.

a) it will step through the data, creating new instances of required classes, and giving them their block of data (from the streamed data thats been loaded) to initalise from. The new instances will pretty much always be allocated out of pre-defined pools for specific resource types (eg: texture pool, mesh pool)

b) it will step through the data, fixing up vtable information such that the data can be used in place (for class types that have virtual functions).

Doing loading this way will also require you to "fix up" any pointers that you have within your serialised data (this is typically done by serialising offsets which can be easily patched back up by the resource manager as you load the data).

so, back to your question. no one loads data on an individual case by case basis. using a resource manager which pulls in a large amount of data in one go, and returns the runtime data ready to go is the way to go about managing your resources. :)

of course this means writing a data packer which creates the files to load :)
your never as good as they say you were, never as bad as they say you was.

This topic is closed to new replies.

Advertisement