Un-nesting Rules: Height and Type

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

The latest issue of the 9th Scroll is available! You can read all about it in the news.

The brand new army book for Infernal Dwarves is finally available, along with a small surprise! Remember that it is a beta version, and provide us your feedback!

  • Un-nesting Rules: Height and Type

    New

    I discovered a whole load of rules - and exceptions to rules - when playing the Engine recently. ID are a new army to me, and this is a new book, so my opponents aren't familiar with it either yet, so we're relying more than ever on the books rather than memory. This state also makes us more akin to completely new gamers, coming to 9th from other systems or as a first wargame, who might have put together a list using the AB and then start to learn by playing (rather than necessarily reading the rulebook cover to cover). I think therefore the suggestions below could hugely improve clarity and accessability of the game.

    "Does the engine cause terror?" my friend asked.
    "I don't think so, let me check"

    So I check the profile (below). Nope, doesn't say it does, so nope.




    "Hang on," says he. "It's Gigantic"
    "Yeah, so?"
    "So, gigantic has a bunch of rules with it..."

    Gigantic size models have Fear, Massive Bulk, Stomp Attacks (1D6), Terror, and Towering Presence.


    Why is all this information nested in the Height code? Height is listed as be a codifier for ranks, supporting attacks and DTs, but doesn't actually make any reference to Cover - a rule which references directly to height, and the most intuitive thing it would code for. Height makes sense to interact with Cover (see the graphics with the stacked cubes). I'll come back to that, the immediate issue is why does it have 1.2.3.4...5! specific rulebook rules associated with it, hidden away?

    Suggestion:
    Add these rules to the relevant line of each gigantic model unit entry.
    This does not require the 'gold' rulebook to be changed - for those who know the nesting of Gigantic, it can be shorthand for all these rules. But for players who are gaming directly from the army books, it would be much clearer and cleaner (and in-line with the policy of removing nesting) to have these rules with the model.

    So then the conversation continues:
    "Hang on," says I. "I also have stomps! Look, Gigantic models have D6 stomps..."
    "What, that doesn't sound right? I'm sure I've never had anyone play it with stomps."
    "OK then, it wasn't immediately obvious they had it - why might they not have it...?" I ask

    Type: Construct
    Constructs Cannot use Stomp Attacks and have Chariot

    So we have one nested rule (Height) which gives the model Stomps and a second nested rule (Type) which removes it - and neither "stomps" nor "Cannot Stomp" are shown on the profile!

    Suggestion:
    In the army books, for gigantic models which are Constructs, include Fear, Massive Bulk, Terror, and Towering Presence in the relevant line of the model entry, but do not include "Stomp (D6)".

    It gets even better though...nested within the Type: Construct rule is another rule - "Chariot".
    "Aha," says I. "I bet that gives the unit 'Swiftstride'. I'd better look it up."

    Chariot:
    The model must roll an additional D6 when taking Dangerous Terrain Tests.
    A model with Chariot can only be part of a unit consisting entirely of models with Chariot, unless specifically stated otherwise.


    Oh, OK. So no swiftstride (which one might intuit chariots have, and wouldn't be surprising for a tank, this gigantic construct of a chariot). But we do have a modifier to the DT rolls which it makes - something which isn't referenced in the model profile but which is already covered by "Height". So here we have a feature (DTs) which is given in one category (height) and then modified not by another (Type) but by a rule itself nested within it.

    So, coming back to "Height", which not only codes for cover (which isn't mentioned in the lexicon for height), but also for DTs, supporting attacks, and ranks (although this latter is then removed if the model also has fly!). Given that it is apparent these features can be modified by other rules, to remove the nesting:

    Suggestion:
    The DTs, maximum supporting attacks and ranks be listed on the model profile, just as Attacks, Agility and Leadership are (for example).
    That way you don't need to reference the height, cross reference the unit type, and look up a nested rule within it.

    Question:
    All constructs are chariots, but are all chariots constructs (thereby gaining the "cannot stomp" rule? Are there any chariots which can stomp? If not:

    Suggestion:
    Remove the Chariot rule and place its rules directly into construct. Optionally, rename "construct" to "chariot".
    This looks like a completely unnecessary additional level of nesting.

    @RCT @youngseward @Eisenheinrich
    Join us on Ulthuan.net
  • New

    Nice way to use the lexicon screenshots! Very helpful having that picture with the rules right there showing the example.

    I, more or less, totally agree with your post. T9A's ruleset is very "indirect" with how they layer their rules, which creates a very demanding barrier to entry.

    The only challenge is that if you gave most of the units the full text that covers them, you're looking at like a solid page or two for most units.

    For example, the chariot +1d6 dangerous terrain doesn't really address the actual dangerous terrain roll required. As a Gigantic Creature it rolls 3 dice normally, as gigantic construct it rolls 4 dice. Now, the actual test is rolling over the number for the dangerous terrain type on each die. Failure (per die) is an auto-hit+auto-wound at ap10

    And there's another one. Nothing has 10 armour. AP 10 means "with no armour saves allowed." AP10 is fine, but it implies another meaning if you aren't aware that Armor 10 isn't obtainable.
    For Lexicon-team Project Blog:
    Updated lexicons

    Friend me on Pokemon Go: 4753 8292 4177
  • New

    There's a lot of things to unpack, I'll focus on one thing:
    The aim of the Construct was to broaden the category to a mechanical contraptions that wouldn't necessarily be chariots, which I thought was kind of a misnomer for a lot of potential concepts, like the ID model you present here. You can think of the Infernal Bastion too. War machines are now constructs too which was a simplification they didn't need anything extra to be merged in, as they cannot charge or march.
    It is just unfortunate that they named the rule for extra DT "Chariot", really.
  • New

    It is way too much to unpack.

    Like for Characters, rather than listing the base size as an indirect way to establish which units it can join. Each character with a list of each unit it can join, if it counts as mismatched or matched to each join-able unit, and how many models it counts as when joined for the purpose of counting ranks.
    For Lexicon-team Project Blog:
    Updated lexicons

    Friend me on Pokemon Go: 4753 8292 4177
  • New

    Chronocide wrote:

    It is way too much to unpack.

    Like for Characters, rather than listing the base size as an indirect way to establish which units it can join. Each character with a list of each unit it can join, if it counts as mismatched or matched to each join-able unit, and how many models it counts as when joined for the purpose of counting ranks.
    Is it really less complex to give people a general rule in the BRB, as opposed to listing every single possible combination? I would need to look up the latter for every case, while the former gives you the logic of the rule. For me the former has a higher learning cost, but it takes up significantly less bits of information to store in my memory, which means among other things that I'm less likely to screw up the rule.
  • New

    Chronocide wrote:

    It is way too much to unpack.

    Like for Characters, rather than listing the base size as an indirect way to establish which units it can join. Each character with a list of each unit it can join, if it counts as mismatched or matched to each join-able unit, and how many models it counts as when joined for the purpose of counting ranks.
    I mean, I'm not sure that is simpler tbh. But let's shelve that example for another thread so as not to detail this one, as I've got some clear proposals for solutions and I'm hoping RCT can feed back on them.

    Kudos with the lexicon, as you noticed, it made this very easy to write!
    Join us on Ulthuan.net
  • New

    First off, I totally agree that how the Chariot rule is implemented is not great. We missed this when we prepared the BRB for 2.0, so unfortunately now it is here to stay.
    And no, there is not a single non-contruct unit that uses this model rule that I'm aware of ;) .

    As for nesting in general, there are pros and cons to both nesting and unnesting, just like there are players that would like as many rules as possible unnested (I take it you are one of them :) ) while others would prefer to have as much nested as possible (and of course there are those who prefer some sort of middle way).
    If it was entirely up to me and my personal preferences, I would nest as much as possible. For instance, if each single unit entry in an army book has the same two or three identical model rules, for me it would be totally sufficient to state this once e.g. in the army-specific rules at the beginning of the book. Or if 99% of all magical weapons and damage spells have magical attacks, I'd prefer to state this once in the BRB and then add exceptions to the 2 or 3 instances in the entire game for which this is not the case.

    As it is, we need to try to cater for the needs of all players, which is why we implemented sort of a middle way, with model rules not nested within other model rules as far as possible, while maintaining the nesting for height/type. One of the main reasons is that without that nesting, some unit profiles would become very cluttered, featuring 20 or so model rules. In that case, model rules arguably would be missed just as easily as if they were nested within e.g. gigantic and cavalry.
  • New

    There are different approaches.

    - An already experienced player will find neted rules clear and easy. He knows that gigantic means stomp, constructs can´t stomp etc.

    - A new player (and basically we need also new players) will find these nested rules very complicated and hard to learn. More so when a player group starts this game new and not some experienced players are already present.
  • New

    Thanks @Eisenheinrich

    So it sounds like the chariot sub-nest was just an oversight, so could easily be changed when we get the next brb update (albeit a long way away), but in principle not controversial or problematic. That's good.

    In light of your feedback I've had a closer look at the rules nested within gigantic and have a refined suggestion whixh reduces the number of rules which would need to be written with the model:

    for gigantic models include Fear, Terror, and Stomp (D6) in the relevant line of the model entry, unless it is a construct, in which case exclude stomp. If it is a mount add massive bulk. If it is a mount for a model which can have commanding presence/rally around the flag (so usually just bsb and general, but also applies to all ID Dwarfs because of bound or broken), also add towering presence.

    This way it is clear right from the profile whixh models have fear, terror and stomp - all attributes whixh would normally be listed in their profile.

    What are your thoughts on this suggestion?

    I'll shelve the suggestion re DTs, ranks and supporting attacks because that's more radical.
    Join us on Ulthuan.net
  • New

    ferny wrote:

    So it sounds like the chariot sub-nest was just an oversight, so could easily be changed when we get the next brb update (albeit a long way away), but in principle not controversial or problematic. That's good.
    Exactly. I very much doubt that this will be maintained in 3.0 ;) .

    ferny wrote:

    for gigantic models include Fear, Terror, and Stomp (D6) in the relevant line of the model entry, unless it is a construct, in which case exclude stomp. If it is a mount add massive bulk. If it is a mount for a model which can have commanding presence/rally around the flag (so usually just bsb and general, but also applies to all ID Dwarfs because of bound or broken), also add towering presence.

    This way it is clear right from the profile whixh models have fear, terror and stomp - all attributes whixh would normally be listed in their profile.

    What are your thoughts on this suggestion?
    Technically possible, from my personal (non-RCT) point of view too much unnesting.
    From my RCT point of view, we did discuss this option (or at least similar solutions) back when the decision was made to perform the great unnesting ;) , but we decided against it because overall we deemed the added complexity of rules nested in height and type acceptable iirc (I'd have to dig up the discussion on that topic for the exact reasons).
  • New

    ferny wrote:

    for gigantic models include Fear, Terror, and Stomp (D6) in the relevant line of the model entry, unless it is a construct, in which case exclude stomp. If it is a mount add massive bulk. If it is a mount for a model which can have commanding presence/rally around the flag (so usually just bsb and general, but also applies to all ID Dwarfs because of bound or broken), also add towering presence.
    On the Unesting note, Towering Presence is on every Gigantic model. The main thing that Towering Presence does is prevent characters from joining the unit (or from it joining other units, if it's a character).

    War Platform somewhat overrides Towering Presence in this respect, though War Platform can only join units of "Matching bases" and only 1x War Platform per unit (so ID can't put two bastions in the same unit).

    Without Towering Presence, my ID Prophet on Kadim Chariot, for example, could be joined to my ID Infernal Engine. T9A doesn't have WHFB's rule where single model units can't be joined by characters, it's Towering Presence that prevents this.

    And another note of unnesting Stomp should mention that it only applies vs standard size, non-Cavalry models.
    For Lexicon-team Project Blog:
    Updated lexicons

    Friend me on Pokemon Go: 4753 8292 4177