Proposal to consolidate Unit options into UnitList & Make explicit which units are available to which players

[alkexr]

@LaFayette What I meant is that to my knowledge variables can only be used within the attachmentList right now. Also, colon delimited lists are a lot more convenient right now (they accept variables). So I'm approaching this from a baby steps perspective. And yes, I'm prefectly well aware what the ideal xml structure is: it's a remarkably horrible way of representing the newer generations of TripleA maps, even if it used to be just fine for A&A et al. Even the concept of variableList is more or less just an outside hack that I originally implemented as a standalone script to generate the xml file, because I couldn't bear its clumsiness. The ultimate solution would of course be a script language for TripleA, but yeah, I'm not going to create that either (or not at the moment anyway).

[LaFayette]

@wc_sumpton I think you might be pointing to a problem regardless of how it's done with this proposal. It might be cleaner with the explicit list, but it's probably equivalent.

Either:

<playerList>
   <player name="German">
        <units>
            <unit>GermanTank</unit>
        </units>
   </player>
<playerList>

Or:

<unitList>
   <unit name="GermanTank">
       <allowedPlayers>
             <player>German</player>
       </allowedPlayers>
 </unitList>

In either case IMO the special attribute or unit behavior is not allowed to be player specific, so create a specific unit for it seems to be the core problem. For either modeling variant it's kinda equal.

One difference in the above is how the production rule would be nested (or not nested). That would make the latter more attractive.

[LaFayette]

@alkexr I'm wondering if actually maybe a grand re-write is actually the way to go. Supporting many small XML spec variants would not be that easy.

RE: colon lists

I'm on the fence here. On the one side it is convenient, on the other it's debatable and there is so much less than ideal structuring that it would be nice to draw a line and start doing canonical XML. Canonical XML is quite verbose, but it "keeps you out of trouble" and keeps parsing more sane and generally more performant. The encoding of attributes via colons makes for not great code and there are numerous places where you don't get any error message at all for invalid configuration. A more canonical structure would get us there.

[LaFayette]

Here is an example of latest proposal:

Example of current:

  <unitList>
    <unit name="Stuka"/>
  </unitList>

  <production>
    <productionRule name="buyStuka">
      <cost resource="PUs" quantity="8"/>
      <result resourceOrUnit="Stuka" quantity="1"/>
    </productionRule>
  <production>

  <productionFrontier name="GermansFrontier">
    <frontierRules name="buyInfantry"/>
  </productionFrontier>

  <playerProduction player="Germans" frontier="GermansFrontier"/>


  <attachmentList>
    <attachment name="unitAttachment" attachTo="Stuka" javaClass="games.strategy.triplea.attachments.UnitAttachment" type="unitType">
      <option name="movement" value="4"/>
      <option name="attack" value="3"/>
      <option name="defense" value="1"/>
      <option name="artillery" value="true"/>
      <option name="isAir" value="true"/>
    </attachment>
  </attachmentList>

Example of proposed:

  <unitList>
    <unit name="Stuka">
        <allowedPlayers*>
           <player>Germany</player>
           <playerList>Axis<playerList>
        </allowedPlayers>

        <productionRules>
            <productionRule>
               <costs>
                  <cost resource="PUs">8</cost>
               </costs>
               <players*>
                 <player>Germany</player>
                 <playerList>Axis<playerList>
               </players>
            </productionRule>
        </productionRules>

        <stats>
          <movement>4</movement>
          <attack>4</attack>
          <defense>1</attack>
        </stats>

        <options*>
           <option name="artillery"/>
           <option name="isAir"/>
        </options>

    </unit>
  </unitList>

(* = optional attributes)

Comments/notes:

• using player list we can consolidate all production rules to just the above, the current example would more properly bring in every player that has the production frontier
• the above has a lot less cross-references, no need to name frontiers and then link them. No need to cross-reference the name of a unit.
• we do have cross-references to players and the playerlist. I suspect the above would scale pretty okay if you add either a player or a unit (notably, adding a unit, it's just a single block of XML that is added).

If we go with the grand re-write, YAML is an option. In YAML the equivalent configuration would be:

unitList:
  - name: stuka
    allowedPlayers*:
       players: [Germany]
       playerLists: [axis]
    productionRules:
      - name: stukaPurchase
        costs: 
           - {resource: PUs, quantity 8}
        players*: [Germany]
        playerLists*: [axis]
    stats: {movement: 4, attack: 4, defense: 1}
    options*: [ isArtillery, isAir ]

[Cernel]

@LaFayette You should also be able to purchase resources or a mix of units and resources.

For example, with 1 PUs you purchase a "stuka" unit and 1 "a" resource. You can also purchase 2 PUs with 1 PUs, that would equal an investment with a 100% interest rate over 1 round.

[alkexr]

@LaFayette The YAML is about ten times more readable. Stats or options being in a single line isn't that great though. Think some unit with AA attacks and AA attack max dice sides and bombing damage and all that, I'd definitely want to group AA related stats/options or bombing related ones or construction related ones together.

Also consider that some maps use multiple production frontiers and swap them during game using triggers.

[LaFayette]

@Cernel Costs being a list allowed for multiple cost elements, eg:

      costs: 
        - {resource: PUs, quantity: 8}
        - {resource: Oil, quantity: 2}

For purchases resources, good consideration if we are going to remove the production frontier tag. To replace it we'd want to update the resource list and add a similar production rule to that.

@All/

At this point, despite my earlier reservation, I think there are two larger questions at play now:

• 1. Do we do a grand update of the map spec? Is a much larger project in order?
• 2. Do we consider using YAML as the updated spec? Splitting the game engine parsing logic to keep the existing XMLs the same and to have a new parsing logic module for YAML would arguably be easier than having multiple XML versions.

[LaFayette]

@alkexr good considerations. We can certainly add/create attributes for AA, eg:

   attributes: [ artillery, air ]
   aa_attacks: { count: 3, dice_sides: 6 }
   bombing_damage: {dice_sides: 10, number_rolls: 3}

It's a bit limited to make all attributes just be an 'option' tag. The XML doctype makes that kind of move attractive. Moving to YAML makes that a lot more fluid, we could model options much more accurately.

For frontiers being turned on and off, we could add a triggers attribute to the production rule, and/or add a name field to it so it can still be referenced from triggers.

[Cernel]

@LaFayette said in Proposal to consolidate Unit options into UnitList & Make explicit which units are available to which players:

Splitting the game engine parsing logic to keep the existing XMLs the same and to have a new parsing logic module for YAML would arguably be easier than having multiple XML versions.

This seems the best solution to me. Hopefully the YAML would be faster to parse and load (also for the battlecalculator)?

As long as all that it is possible to do now with the XML will still be possible in the new format, it should be fine for me.

[Cernel]

@LaFayette As I said, I would advice any such things working like the support attachments currently do (this way you could also have multiple different AA abilities per unit). Meaning you have the ability that you define and give it to a list of units and a list of players.

[LaFayette]

If we are going to seriously consider YAML, I suppose it deserves its own discussion thread.

We'd have to be sure we would want to do that. I think there is a lot of good flexibility it gives us. Though we'd probably want to 'freeze' the XML spec of maps and just keep that working while the YAML version gets new attributes over time.

[wc_sumpton]

@LaFayette

I would give YAML a try, gives me a chance to learn something new. (Been trying JAVA, just can't seem to get this old head around it.:anguished_face: )

Cheers...