chrusion said:SDK analysis leads me to believe that deriving from the CivGlobals class is the best place to start. The objects of the derived class will each represent a Sub-Map. Only persistant changes need to be stored. All other data can be shared.
CivGlobals is a Singleton but a derived class could have a dynamic datastructure to hold multiple object instances of the class and still maintain a pseudo-Singleton appearance.
I have designed a datastructure that may be perfect for this implementation.
Can I see what you made so far?
I had the same idea which is why I started with downloading the SDK in the first place. Do you have resources about the SDK to get into more quickly?
Making sub-maps would require that recursive data structure to appear to outside classes as one map, the one which is currently selected. I can imagine two situations:
1. The submap is entered by user action, i.e. a combat map is created at the start of a combat. Then there are several sub-turns inside the map with different tiles, different units, different ai, different users (only those involved in the battle). So you would have a complete little sub-game.
Questions:
- how are the elements (xml+python) of that sub-game initialized? I think it should be able to mod submap rules independently. (subfolders ?)
- how do you perform several turns inside the submap and then return to the main game at the point where you left it? Do we control the main turn loop?
2. There are persistent submaps, i.e. city submaps or planet submaps. They would be recursively travelled each turn, as if they were areas of one big map.
- AI would need to know about submaps and how to make use of them. Also how to deal with different rules inside submaps. Modders should be able to add python code to extend AI into using a specific submap mod.
Great thing, really. I hope we see it all working. I'm far behind in my knowledge about the system, but I'll try to catch up.
Albert