Question

I'm currently working on a Mobile C#-based RPG, it's going well but I'm just thinking about how to optimise the loading of data.

Currently the game has around 20 or so units with each unit having 50 different levels with different stats at each level. These stats are stored in an XML doc, grouped by unit. So Unit1.xml contains all of the stats for a level1, level 2, level 3….level 50 Unit which is parsed and the results cached into a dictionary the first time a Unit 1 is used in a play session.

My problem is that this seems like massive overkill, the doc is hundreds of lines long and it seems crazy to parse all 50 levels even if I might only need a say "Level 5 Unit 1". Clearly one way I could optimise this would be to split the doc into 50 different docs, each containing the data of a specific level but that too seems a bit crazy.

Does anyone have a good way to approach this? Perhaps a binary search could be performed on the doc to find the specific level and then only that could be parsed, though I'm not sure how easy that would be to do when using XML?

Was it helpful?

Solution

You've just found out another reason why XML is by default a quite bad storage format. The problem is that you need to read everything up to that one line you're interested in, because you have to parse and understand the structure of the file.

The only way to improve on this is to give yourself hints, eg. saving indices of where each of the rows start and then jumping right ahead. However, that's no longer XML and it might be tricky getting .NET to read those fragments.

So, if you can't afford to keep all the parsed XMLs in memory, and you don't want to separate the XML files, perhaps you could use a trick of saving each of the entities you want to take as a separate XML document (with declaration, root element etc.), and saving them inside one file, along with indices of where each of these documents actually starts.

Of course, this is only useful if you're generating the XMLs automatically. It's no longer a valid XML, which means noone else can read or write it.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top