Breaking stats - some ideas on a re-work

[IBBoard]

Ideally, I want every final release of WarFoundry to be forward and backward compatible. In general I think I've been sensible enough to manage that, but multiple stat lines may be a place where I haven't. As mentioned in another thread, this is my ideas thread about it so that people can point out problems and see what they think of the way they'd have to write files.

Basically, rather than having a single "<stats>" block as it is now, what I'm thinking of is moving the unit's stats out to a common block of "unit member type" (e.g. "High Elf Warrior"). The member types would then be referenced from the main unit type entry, which a) reduces duplication of stats and b) makes things like the "what you need" list modules easier to work with.

The main problem is that I'd have to break the current stats layout to do it, or leave a lot of duplication. What I did consider doing was leaving the current stats as an "override" option so you can reference the unit type as "this unit contains them" and then say "but their stats are slightly different to normal". That should (if done properly) allow all existing data files to work properly, but it would mean that existing beta versions wouldn't be compatible with later data files. The final v0.1 release would be properly forward/backward compatible, though.

I'll add more detail tomorrow

[IBBoard]

Okay, here's a brief example of what I might go with (pseudo-file - please ignore any tag name typos etc):

Code: Select all

<race>
  <units>
    <unit id="spearmen" name="High Elf Spearmen">
      <stats><!-- Override stats go here still -->
        <stat name="m">5</stat>
        ...
      </stats>
      ...
      <unitMemberTypes><!-- optional -->
        <unitMember typeID="type1" />
      </unitMemberTypes>
    </unit>
    <unit id="archers" name="High Elf Archers">
      <!--no overrides for this unit, we're just going to reference the member type -->
      ...
      <unitMemberTypes>
        <unitMember typeID="type1" />
      </unitMemberTypes>
    </unit>
    ...
  </units>
  ...
  <memberTypes>
    <memberType id="type1">
      <stats>...</stats>
    </memberType>
  </memberTypes>
</race>

Having both stats and member types optional will a) allow for 'units' that don't have stats (e.g. container units/detachments) and b) allow existing files to keep working without change. The only problem is that any future files that rely on just the memberType wouldn't work in v0.1b7 and earlier, but they would work in v0.1 final (whenever it is released).

Thoughts? Opinions? Glazed looks?

[snowblizz]

I'm going to go with "glazed look" I think.

As a practical example here's some stuff we'll need to handle.

Chariot stats lines. Has 3 separate parts which forms a "composite".
Chariot------------S-T-W----As---
Crew ----Ws-Bs-S------A-I---Ld
Steeds Mv-Ws-Bs-S------A-I-----

Cavalry units with steeds, 2 separate statlines. Which is always visible.
Rider Mv-Ws-Bs-S-T-W-A-I-Ld
Mount Mv-Ws-Bs-S-T-W-A-I-Ld

Champion (and other character-like) upgrades as options (and costs, so stated "equipment") with different stats and optionally visible. I guess steed options would count as this as well. This might rather be a <containedUnit> thing though?
Unit Mv-Ws-Bs-S-T-W-A-I-Ld
Champ Mv-Ws-Bs-S-T-W-A-I-Ld
Steed Mv-Ws-Bs-S-T-W-A-I-Ld

"Collection units" say Imperial Guard Platoons. Probably <containedUnit> again.
HQ option1 Mv-Ws-Bs-S-T-W-A-I-Ld
HQ option2 Mv-Ws-Bs-S-T-W-A-I-Ld
HQ option3 Mv-Ws-Bs-S-T-W-A-I-Ld
Regular Joe Mv-Ws-Bs-S-T-W-A-I-Ld
Optional Unit Mv-Ws-Bs-S-T-W-A-I-Ld
Special char option Mv-Ws-Bs-S-T-W-A-I-Ld
Transport Mv-Ws-Bs-S-T-W-A-I-Ld

[IBBoard]

Using the snippet above, chariot and cavalry would generally have two/three "member type" references - one for each sub-element that has a stat line. In terms of the partial stat-lines, I'd be inclined to do what Rollcall did and just have a full stat line with blanks in it. Steeds are likely to be equipment with stat lines rather than units in their own right.

Champions will normally be handled as separate "unit types" that are linked in a special way (like Warhammer used to do). If your champion is an 'upgrade' (e.g. newer Warhammer and 40K) then you just need to have him cost his whole price rather than his upgrade price. Visibility has yet to be decided - it might be included or it might be that the "unit" dialog just shows that he exists and then you customise him and see his stats in his own dialog.

Imperial Guard platoons will, if I remember them correctly, be one of the examples of a zero-price container unit with non-zero-price units within it (the squads). Special HQ characters (captains, medics, etc) will then probably be handled in a similar way to champions, although it does mean that we need to allow for multiple "champions".

[Frostlee]

let me see if i understand correctly.
we will have units that works as they work in v0.1b7 but with multiple stat-line?
we will have units that can contain other units (like champions)?

well it is this way i think it's something good, you'll just have to check number requirements i think...
i mean container-contained units min and max limits could be ralative to each other...
also i cannot think to a easy usable GUI for container-contained units...

[IBBoard]

Units containing other units (e.g. Nobz Mob being a container for multiple Nobz so that you can customise each) would be separate from multiple stat lines. As long as I write it correctly then units that work in v0.1b7 will work in future versions, but future files might not work with v0.1b7 (although they will work with v0.1 final). The incompatibility with existing beta releases would come when people started using the "member type" links but not the "stats" blocks within the "unit".

Having actually thought about the situation, I'm wondering how many of these examples would actually be multi-stat line units and how many would just be units with equipment that has stat lines (e.g. mounts). I guess if I add multi-stat lines then it gives the author the option of treating mounts as an extra stat line rather than equipment.

[furrie]

For warhammer, all the chariots and mounted troops will be multi stat lines, where the unit champions will be equipment. Will it be possible to make a equipments one use only (warhammer has special unit champions that can only be used once)

[IBBoard]

I think Rollcall data files used to treat chariots and mounts as "required equipment", but multi-stat line objects probably are just as good if not better.

As for equipment, do you mean once per army? I'm not sure whether it'll make it into the first release that has requirement handling, but I had considered that some equipment would have requirements in the same way that units do so it should be possible.

[furrie]

Yes I that is what I mean.

[snowblizz]

Been finding a lot of non-optional squad-leaders in Space Marines, another job for multi-statlines.
Come to think of Regiments of Renown would also use them combined with the baseCost attribute.

If I understand you correctly then technically almost all things could be made as stated-equipment or contained units.


Are we getting anywhere with Multi-category units? I'm piggybacking it here because it kinda matters in the intertwined web of how/what to make the units. Is there any reason why a unit couldn't belong to multiple categories simultaneously? Of course validation would be problematic I suspect. I ran into this as Space Marines have about 4 different "dedicated transports" that show up in virtually all categories of the armylist. A lot of duplication.

[Frostlee]

actually if you think to transports as equipment-with-stats this should avoid duplication, anyway we could make category attribute something like "at least one".

[snowblizz]

actually if you think to transports as equipment-with-stats this should avoid duplication, anyway we could make category attribute something like "at least one".

Well duh! Simple and elegant. That's a pretty nifty idea actually. Of course that means we need to be able to give equipment equipment options and special rules... ok I dunno maybe it's not THAT easy then.

Hah! I knew there had to be some practical problem I subconsciously sensed with making transports equipment.

[furrie]

programming wise it shouldn't be a problem to give equipment equipment, it will probably give some troubles in the user interface.

[IBBoard]

I'll address the multi-category stuff in another topic.

Non-optional items can still be handled as equipment/options, but set to be "required". I guess it might look a bit odd to have the champion in the list, though. Looks like it is necessary.

As far as all of the examples go that I've seen so far then they should all either be able to be handled as equipment with a stat line or a contained unit (once I get it properly implemented). In some situations then "contained" is perhaps the wrong word - more "attached" (e.g. transporters would be attached to a unit rather than contained, and either one is descriptive for champions).

[Frostlee]

maybe a more gereral idea is "options" which could include bith the equipmentd and the attached/contained units...