In the spirit of openness, I would prefer people distribute maps as xml files, rather than as saved games.
There are some practical reasons for using xml. xml is compatible with different versions (saved games can only be loaded by the same version of TripleA as saved the game) and xml files are easier for people to install.
The main reason to use xml though is to encourage people to modify the game, and contribute back to TripleA. Everything in TripleA is open source, and easily modifiable (for those with the right skills at least).
Distributing maps as saved games doesn't really prevent other people from modifying them anyway, as it's pretty easy to write a utility that dumps a saved game as an xml file.
can you release the actual map now?
we have a new unstable triplea (1.3) up, and more will follow soon,
it would be great if people could play your map on this triplea too,
not to mention all the other good reasons why there should be a map rather than a savegame.
One thing I wish was possible, is that you can save a game as an xml. I would really prefer doing unit placements via the actual map, because it is instantly reflected and much easier than manual, and a little more better than the way that the triplea map creator handles unit placements. The xml would only change the unit placements of the original xml and would save it as a different copy. The techs, units, etc would all be the same as the last. Not really sure how easy this would be to do, or if it is even that important.
Just presure Veq into adding it to the SVN and integrating it with UI and make someone volunteer to test/debug it and upgrade it to 18.104.22.168
... or wait for me to do it.
Ok... I integrated it with the UI and trying to fix it for 22.214.171.124 (darn Veq, you made the xml somewhat more complex in the 1.3 branch - fun to reverse back to your your 1-3,4,7,9-+ values in the rule attachment)
Which made me revert to use the private m_??? fields of the class which of course are private and not guaranteed to be clean either and need to use some workaround setting them accessible through reflection.
Then look at how Capital and VictoryCity is handled in the TerritoryAttachment
So there are 4 different ways of storing boolean values in attachments.
4) You can't get a list of ProductionRules from the Rulelist. You have to first get a FrontierList from the gameData and then extract all FrontierNames and then get all ProductionRules from all Frontiers before you can write them back to the XML.
5) You can't get the delegate from a GameStep, have to access m_delegate field.
6) You can't get the connections from the gamedata, only possible to iterate through all territories and then through their neighbors and then create the connections, which results in double connections (but not a big deal I guess)
I guess if I am allowed to tweak some attachments/properties I can do the Exporter much cleaner and thereby more maintainable.