Axis & Allies XML

@djensen:

I’d actually like the main XML file to represent the state of the game between turns. Purely a representation of the map after you finish your turn and before your opponent begins their turn.

Good call. Much simpler, and all you need to play/save a game.

@djensen:

I’d actually like the main XML file to represent the state of the game between turns. Purely a representation of the map after you finish your turn and before your opponent begins their turn.

I’m going to gather all of these suggestions and formulate an example.

I’m inclined to think there might be advantages to refining that time period from a turn to a phase given the mechanics of A&A.  I know I’d want to see the combat moves and the non-combat moves.

I think the document should have a few sections:

1.  An initial state (locations, unit quantities, players IPCs, turn number, phase of turn, etc).
2.  An end state, again locations, unit quantities, players IPCs, turn number, phase of turn, etc.
3.  The actions taken to get from the initial state to the end state.  (Combat Move 3 Inf From Eastern Europe To Karelia)

(The initial and end stat should be discrete and well defined points.  There is no need to create a snapshot in the middle a unit’s move.  This helps eliminate a lot of the tiny bits of information that might be program-specific).

All this above should be placed into a parent node such that all of these “turns” (which is not a good name because it will actually hold info about less than  turn) can be accumulated for the length of the game.Â

The goal should be to capture all the information in a generic way.  Whether any current or new program can use that information doesn’t matter.  They can ignore pieces that are not meaningful to them.Â

I think I’m up to 4 cents now ;)
Mot

Again, I’d just make the implementation of some of the sections of the xml document option, not break it into seperate document files.  The whole point of the self-describing nature of XML is that you can put them into the same file without harming programs that consume them.  Fuller, richer implementations will need them both, so no point in splitting them out.

Mot

Perhaps I should take a step back…what is the exact goal that is trying to be accomplished?  I came in late to this so I could be trying to accomplish something different.  I apologize for not asking this sooner!

I was trying to capture everything needed to play the game via an exchange of the XML document.  This obviously includes the “end state” of a turn, but you cannot use the end state alone to actually play a game.  If I was playing against someone and it was their turn and they just tried to just send me their end-of-turn game state I’d balk immediately.  I’d want to know what they did to create that state.  What units performed a comabt move, which ones retreated and where, what were the purchases and where did they get placed.  You get the idea.

If the goal is to model the end-of-turn state then it is definately an easier task (and you should ignore a lot of the more advanced suggestions), but the usefulness of such a format gets reduced.

So to sum up, what is the “mssion statement”, the objective we are laboring towards?

Mot

Right now the mapping utils seem to only be used for end of state descriptions.  But if all the transformations were included in the XML document, you could actually have the mapping util generate your move descriptions (combat movement description, combat description, non-combat movement description, etc.)

We are using TripleA to do this very thing right now, (since it already captures transformations) and I’ll tell you it works really well.  Not having to type up your moves every turn leaves a lot more time to actually think about strategy.

Rob

I wonder whether the map utilities that currently exist can utilize the new formats well enough.

I’m sure most can be made to render the information, but I don’t know if the infrastructure exists to capture some of the things we are talking about.

This really does come down to what the goal is.  There is merit in doing a bare-bones standard to facilite a kind of map conversion and then supplament that information with an outside source as is done today with a lot of the utilities.  It’s a tough call.

I suggest we focus on defining the goals first.

Mot

Yeah, if you’re not careful you’ll end up re-inventing tripleA, only with a different file format. Or would the idea be to have TripleA start using this file format?

A universal format would be cool. Some players say they can’t use TripleA for whatever reason so if you could save the file and have the other player use MapView to open it, change and save it and send it back - but that would mean a lot of work on Mapview.

Yes, it would mean work on Mapview, work on TripleA, and work on any other util that people wanted to use.  But it would also mean that everything would be compatible.  I think that’s the goal, that I could use TripleA and you could use a physical gameboard and just type in your moves (maybe using a text XML generator).

Yea all you really need is a decent map and pieces to shift around. Players can access the dice roller and then delete the units that died and add units they built. The “snapshot” of each players turn could be added to the existing text inventory of movement/combat actions. That way other could follow the game. In some manner the game could be downloaded to view like a slide show turn by turn?

The idea would be to eliminate the need to have a physical board set up.

As a triplea user, I can say that I would not bother “importing” an xml file from my opponent unless it included all state transitions.  Instead, I would use my new “Edit mode” features to play out my opponents turn using the game engine.  The advantage to doing the latter (other than that it is more fun) is that TripleA has a really nice visual history function that allows you to go back and replay an entire game or portion of a game.
However, I could still “export” an end-of-turn xml file for my opponent.

So, I agree mostly with motdc.  I think we want a single XML file, that optionally can contain state transition information for every phase of every turn.

Hmm, with that having been said maybe it should be required to have the FULL implementation from the start and not allow the partial implementation.

I think it’s wise to prototype the whole shebang as early as possible in the development effort.  I also think its wise to keep the end-of-turn states separate from the state transitions in the XML file.  If this is done properly, then we don’t have to make a decision to NOT support state-only clients.  We should be able to support both, regardless of whether anyone cares to write a state-only client.

I might volunteer to do the tripleA integration (only for the whole shebang) if someone else volunteers to do integration for another “popular” client.  That’s not a promise at this point though.

Could have a file specification that allows for either just a static state description, or additionally all the move info etc.

@djensen:

That’s going to be a huge file. Personally, for this website, I’d like the files to be as small as possible.

Another goal should be:

• Small file sizes

One of the things that TripleA does is compress saved games (using gzip).  xml files usually compress by over 90%.

Yes, the files will be much bigger if they include state transitions, the price to pay for more data is larger files.
Reasonably terse XML could help with that.
Sean raises a good point that gzip should make quick work of these files.

Perhaps a gzipped-xml format should also be supported by all tools that implement it.

Likewise, MapView game files also store the entire game history and with compression (zlib) they come in under the size of a typical screenshot jpg.

Am I suggesting the XML file should always be compressed?  Absolutely not.  It defeats a lot of the reasons for using XML.  But it could be an option for transport and storage of the files.  It depends on where these files would “live”.  If they are getting emailed between two players, then zip them up before attaching them.  If there is roller server integration (which to me seems like a big potentional benefit of a standard game format is that you can then create standardization of rollers) where the master file is “owned” by the server then active games can be in XML format and completed games can be compressed.

In a roller-controlled situation, I see the roller actually able to inject the rolls into the XML file, which would have a well-defined URL.  Players can then point their map programs or utilites at the XML file and import into their own format.  This is probably pie-in-the-sky as compared to the original idea.

Mot