RMU Attack Tables

I have spent my down time over Christmas working on a spreadsheet to create attack tables in the most usable format we have seen so far.

The biggest issue with RMU for me has been the size rules. There were two issues really, firstly, in incessant math required to even work out how much damage an attack does. It may be relatively simple math but it is a mechanical step that slows down almost every attack. In fact it is more than one step as a quick calculation is needed to work out the size of the attack before the attack roll and then a calculation after the attack roll to calculate the damage. Size also still effects the OB and DB of the targets, according to Beta 2 but that may have changed and it then adjusts the critical.

My second issue with the size rules is that it looks like a solution looking for a problem. The same progression that is being applied via the size rules is being applied every which where regardless of whether it works or not.

On one hand the proponents that like the size rules are seeing this as an elegant solution unifying many disparate game mechanics. Those, like me that do not like the rules just see a bad rule wrongly applied.

It is possible that I am wrong, according to Mrs R that has happened before.

To that end, the game I am going to run this year is going to use the size rules but there are some attack chart layouts that have been suggested on the forums that precalculate the size shifts.

So stating in the bottom left with Diminutive, then tiny, small, the bold result is the medium, then the top row, right to left is big, large and huge.

That image is from the spreadsheet I am working on. Merkir from the forums has shared a Google Sheet that will generate attack tables on the fly for any of the standard weapons. If I paste that into my spreadsheet it then explodes every individual result into the seven displayed sizes. That takes away one of the game slowing steps.

Another option is that once you paste the Merkir table into the spreadsheet you can apply adjustments to it. So Rather than a short sword being a Dagger +1 size I can apply a +10OB shift to the Dagger table and then generate a dedicated Short Sword table. I can do the same for two handed swords so they are no longer Broadswords +1 size. This takes away one more size calculation.

I accept that magic and things like charging will always involve a size shift. I do not have a problem with that. I personally feel that +1 size for charging is a retrograde step that harks all the way back to D&D basic rules where a charge just gave you double damage. +1 size does basically the same thing and ignores 40 years of increasing sophistication and any attempt to model what happens in the real world. I am happy to accept the size solution as it fits nicely with my desire for fast and simple rules.

The sizes of the damage shifts in my tables do not follow the RAW in beta 2. As Hurin has pointed out the RAW favours smaller attackers by giving them disproportionate amounts of damage. The result being that rabbits being overly dangerous.

My tables will diverge slightly from the standard tables and it is all down to rounding. Normally if you were doing 0.4 of a hit in damage you would expect that to be rounded down to nothing. The problem with this is that all touch magic requires a successful unarmed attack that delivers 1 hit. If you have a small or diminutive spell caster it is impossible for them to cast any magic against a foe in AT 9 or 10. For that reason I have chosen to always round up to the next whole hit in damage. So if the Medium attack did at least 1 hit then at all sizes at least 1 hit will be delivered.

This puts my charts mostly towards Hurin’s toned down charts, without the killer rabbits, but fractionally above them so a bit from a rabbit will still do 1 hit if it hits where the Hurin formula would have rounded down to zero.

What I have left to do is mostly donkey work of copy and pasting my spreadsheet formula into hundreds if not thousands of cells. I cannot just fill the spreadsheet as the formula has too many nested functions that Excel cannot cope with updating all the references to the look up tables. As soon as I have something to show I will share some finished tables with you. How much I can share is a different question as I think I am really on the edge of the Beta NDA if I start sharing complete sets of attack tables!