Multi-category units

[IBBoard]

Taken from a different topic:

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.

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.

Multi-category units was something that I considered early on, but dropped because of complications and the limited cases in which it was used. I had thought that requirements could be used so that the unit would be duplicated in each category and the requirement limits the total number (if applicable).

The main problem was correctly allocating it to the right category - currently everything is from one category and so you know exactly which category its points are deducted from. If a unit becomes a potential member of multiple categories then you've got to work out which of those potentials it is actually in. If a unit is an actual member of multiple categories then a) you've got to make sure you don't deduct its costs twice, b) you've got to be able to distinguish it from the other use case of "potential categories" and c) you've got to make sure you don't do a confusing rendering of which category it is part of.

I had considered that some Warhammer units (mainly expensive champions) can take both Lord and Hero slots, but they're generally Lord characters and so should be shown as such. The use of Lord and Hero slots was then going to be covered using requirements and extra data on the unit, since the conventional army structure has no concept of "slots", only points values.

If this is going to be a problem and something that we need then I need to think about it more and get more input on examples of what people need. Any other obscure and less frequently encountered use cases in their own discussion topics would also be greatly appreciated.

[furrie]

The fits thing that comes to mind, is the centigors in the wfb beastmen (the new rule book), there you have a special champion, which makes centigors core. But normaly they ae special. I know its not exacly what you meant, but still something to think about.

[snowblizz]

The fits thing that comes to mind, is the centigors in the wfb beastmen (the new rule book), there you have a special champion, which makes centigors core. But normaly they ae special. I know its not exacly what you meant, but still something to think about.

There are several examples of similar things. I know we've talked about it as I found lots of these in the Ork codex. Warbosses make Nobz Troops, Big Meks make Dreadnaughts Troops and then some special characters that modify unit categories. It is becoming more and more common in WHFB with these things and 40k is already rife with them.

So far the solution was to create a duplicate entry for an option. Orks e.g. had Battlewagons in Elite and Heavy Support. Also creating an extra unit that would then Require the enabling unit is of course possible. This is how The Program That Shall Not Be Named does at least in some cases, but it seems to have somekind of "clone this unit" ability, but that's courtesy of their multitude of complex internal links. But IMHO it's not very elegant, and it disturbs my sensibilities that the same exact unit is entered 4 times in the data file. Takes up unnecessary space and makes updating error prone. For Space Marines that's 16+ unit entries where theoretically only 4 are required (4 dedicated transports * 5 possible categories and several are in all of them).

This is where my question about "object orientation" earlier also applies. Could it be possible to "inherit" a unit category for a contained unit, but optionally (generally any time two units belong together they'd have the same category but I can see that there might be an instance where you don't want this).

From my POV unit categories do not seem to have any impact beyond which button they reside under in the GUI. Though I bet they do. Of course that leads me to another bugbear of mine where those units that are only supposed to be <contained> show up in the unit list.

[IBBoard]

From my POV unit categories do not seem to have any impact beyond which button they reside under in the GUI. Though I bet they do.

At the moment it kind of does have extra purpose, but only in line with the GUI. Basically, when it gets added to the army then the unit is added to the category that it is listed against. The problem with multi-category units is that you'd have to define which category it was put in against rather than just using the unit type definition. Not a major thing, but a little more info to move around (another value).

Things like special characters making certain troop types move from some "support/special" to a "core" category was something I had expected to do the "duplicate unit and put requirements on it so that one is only allowed when the character exists and the other is excluded when the character exists". If that's not what people want (and if other ways can be more flexible and are obviously less error prone) then I'm happy to do another way - I just need to know the requirements of various game systems

"Inheriting" Categories was the way I was thinking of doing it. It'd probably be a breaking change again (at least we're not at v0.1 yet!) but multiple categories could be added as elements, with the potential to nest requirements within them (Unit Type X being in Cat1 is only possible when ...), and then the current "cat" element could be used as a "default cat" with a blank value meaning that it inherits from its parent. That'd let you put in one Rhino against all categories and have its points cost come out of the right category.

Of course that leads me to another bugbear of mine where those units that are only supposed to be <contained> show up in the unit list.

We'll get to that in due course. Rollcall had a special "requirement" that said "must be champion" that hid it from the list. Given the flexibility that we want, I'm not sure what the best option is and I need user input on how best to present it in the UI (that'll be yet another thread)

Now, the question is, do we need to have a unit being part of multiple categories (being listed under each) or is it enough to list it under a primary one and have validation plugins check for things like Warhammer "Lord who takes Hero slots" limits? The latter seems more sensible for most cases (to differentiate "an identical looking unit in two categories" from "the same actual unit showing up twice even though it is one unit") and the former is being discounted because I don't know of any use cases that require it.

Maybe I should look at these Starship Trooper rosters again to see how other game systems do it...

[IBBoard]

In case people missed it, multiple categories will be in the next release (hopefully this weekend). If you want to try it out sooner then grab the code from Subversion. Requirements that constrain the category will come later (e.g. "X can only be in category A when you take Y"), so you've got to trust your users for now.

[snowblizz]

How would I define the code for multi-categories?

Got a couple of files waiting for this you see.

[IBBoard]

I'm getting a bit better with actually writing unit tests now, so as well as the schema definition we've also got an example data file I'll try to update the online documentation soon, since it is a little behind by now.