Posts made by Motdc

@Jennifer:

I hate, no, I despise, no, wait, I’d rather Kiss Hillary Roddham Clinton full on the lips then use MapView again.Â

Don’t hold back, tell us what you really think  :wink:

Jennifer, any chance I can ask you to put together a complete list of things you think would make MapView a better tool?  Maybe in another thread, or even better here:  http://p078.ezboard.com/fmotcreationsgamingcommunityfrm9Â

I’m working on the next release (after being away for 2 years) and constructive feedback is desired.

Thanks,
Mot

Yeah, it was pretty much realtime or play VS the computer AI (which was not great).

I don’t think people are looking for another program to play A&A with (though that is really, really great for you to potentially offer up aid in that regard).

As it happens, A&A PBEM utilities have been around for years, with McD’s being a DOS based one I believe.  There are probably three or four that are widely used, and this fragmentation of the leads to a lot of grief.  Everyone has a favorite and resists using a different utility.  It harms interoperability.

So the thought was to create a common XML format for the game data that the existing utilities can read and write.

Mot

@guildofblades:

I guess one real question is, what would you be trying to achieve that is not already achieved with the A&A computer game that Hasbro did a few years back?

Hi Ryan.  To answer your question in a word…PBEM!!!

Mot :)

Not to answer my own question, but couldn’t this be a feature of the dice roller?

If the XML spec was used by the dice roller to keep a consistant and universally readable (because of XML format) master copy of the game then the various utilities just need to be able to render that XML document.

Manual entry into a dice server as is done by most of the clubs just needs to modify the XML document in the correct way (including storing the actions).  Automated entry from utilities can also be implemented as long as it conforms to the standard.

This seems like the right place to focus and refine the efforts towards.

Mot

I’d like to talk about this:

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.

This is a realistic situation.  We know we can probably export at least a static borad state for any particular phase or turn from the three popular propgrams.  But I think the technical hurdle is the importing.  AAWinMap doesn’t capture all the information MapView does.  MapView doesn’t capture all the information TripleA does.  If someone improts from MapView to TripleA there will be information loss, right?  Can this problem be overcome?

Mot

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

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

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

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

@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

Hi guys, just poking my head in here.  It was suggested that I stop by to possibly add my two cents.

Here it goes:

First, I suggest that the A&A XML file (henceforth called AAX file in this post to save me some typing :) ) be used in an “export/import” format as opposed to the native game storage for currenet and future programs.  This will increase adoption and remove any burden an “outside” format may have on future developement.  (Imagine not being able to add a feature because it might break the AAX format.  That won’t go over well).

Second, I suggest identifying the common/required pieces of data.  These should be the basis of your format.Â

Additionally, we must make allowances for additional game-specific data to ride along in the document.  So if there is an XML element for a particular infantry unit that contains just a “location” as a territory, games like TripleA can include extensions such as number-of-spaces-moved and TripleA and MapView both can attach things like X/Y coordinates.  This data should be maintained through the import/export process.  An example:  For MapView, a game id is required because MapView supports many types of games.  So if a MapView game is exported into an AAX file and then imported into a TripleA game, that game id should be re-outputed when the game exported.Â

(It’s worth noting that the “game id” mebtioned above might not actually be needed since other header information in the “generic/common” sections of the AAX are likely to be enough to identify the game as an A&A game.  But it illustrates the concept).

Feedback to these ideas?

Mot

That’s a good idea, considering everyone seems to use something different.  It would allow you to write converters and/or include that functionality into current and future map programs.

Where are you working on the project?

Mot

With the groupings I think it would be great if you could specifiy text titles for the groups.

Something like this

;dice “Infantry” 5d6 “Fighters” 2d6;

And the the oputput would be something like this (on multiple lines)

Rolling 5d6 2d6:
Infantry 1, 1, 2, 6, 6
Fighters 5, 6

Mot

How does this work?  This looks like a neat idea!

;dice 5d6 2d6;

Rolling 5d6 2d6:
(1, 1, 2, 6, 6)  (5, 6)

Just a quick notice. The MotCreations website is undergoing a complete
restructuring and rewrite. The MapView sections will focus on the modules
from cooperating partners such as Imp Games, Deer Valley Game Company, and
others. It will also include a large focus on User-Defined Modules with
a catalog of player-submitted games. Some other projects beyond MapView
will be also be available, such as an AI for the civil war game “SQUARES”.

Along with all of this will be a forum to provide a single place to have
all of your MapView (and other MotCreations) questions answered. As it
stands right now, there are bits of information spread all over the web on
half a dozen different forums. I think it will be a great service to
consolidate these into a central place. While the website is still being
worked on, you can at least get access to the rough draft of the new forum
here:

http://pub60.ezboard.com/bmotcreationsgamingcommunity

I will be trying to replicate any MapView threads located on other forums
in our new forum so that new visitors can learn from the old questions.

Thanks to everyone who has supported MapView over past two years!

Mot :)

Just bumping this thread to keep it alive…

Mot

I’d be happy to address any problems as best I can.

Also, here are some screen shots for those new to MapView:

http://www.motcreations.com/mapview/overview/screenshots.html

Mot

Hello all,

I just came across this board and noticed there are a few people who use
MapView here. Since I always try to keep up on the forums that MapView
users frequent, I thought I’d just start a thread to provide any help using
MapView etc and of course get any feedback along the way.

(Since MapView supports alot of different games, I thought this forum
was the most appropriate. If not, I can re-open this thread in another
of these forums).

Thomas Carvin (AKA Mot)
MotCreations.com