Combat in the FG MnM system - which rolls are manual, which automatic?

Hi all,

A question about the system in general -- I'm working on FGU with the new build on the test server, but also getting to know the mechanics of FG and MnM in general. So I'm not sure what the anticipated behaviour should be, and whether I'm looking at a bug, or just don't understand how the back and forth of dice and rolling work.

In the combat tracker, I can have Avian Warrior target Bystander, then I drag Obsidian Hatchet +7 (Close Damage 5) to the chat box. I get:

[ATTACK] Obsidian Hatchet +7 (Close Damage 5)
D20 +7 (17+7 = 24)
Attack [24]-> [at Bystander] [2 Successes] [DC] 10

First, I'm not sure how 24 over DC 10 is 2 successes -- it should be 4, no?

Second, what should happen next?

Should the Bystander roll Toughness (D20 + 0) manually vs. DC 20 (Hatchet Damage 5 + 15 for a damage roll)?

Or should the system roll that check automatically?

The Test version will not force a toughness roll on a hit. This will take the dice out of the player/DM's hand. The ruleset wont automate the complete combat experience for that reason. So the player/DM will have to roll and track their bruises (toughness penalties to check) and health.

As for the 2 successes, The rulebook stated a degree of success/failure for every 5 (rounded down) from the DC. If this is incorrect, then it can be changed.

Thanks -- I think I need some help learning how successes / failures work; on p. 14 of the DHH it looks like DC +10 should be three successes, and then at DC +15 four successes. So Attack 24 over DC 10 should be +14, and three successes -- or am I wrong?

You know, I might have not added in the beginning success/failure into the equation. So yeah you received 3 successes plus the original success. I can try and sort that out. Good call.

Quote:

---

Originally Posted by superteddy57

You know, I might have not added in the beginning success/failure into the equation. So yeah you received 3 successes plus the original success. I can try and sort that out. Good call.

---

Hey guys, here to chime in. So, in the above example, 10 through 14 is one degree. 15-19 is two, 20-24 is three degrees.

Normally, degrees of success on attack rolls are not needed. With Multiattack being the most common exception. Normally just meeting your DC is enough, but it's good to have the functionality in, just in case.

As for the Toughness roll in response, it absolutely needs to be manual. One reason being the one superteddy mentioned, that it keeps the players engaged. But, also, M&M has soon many exceptions to its formula, that it's impossible to account for all the possible variables in a static system.

Finally, your math on the Toughness Resistance roll is correct.

:)

I wanted to reply directly Matt, so you got a notification. Three successes in that example is correct.

Gotcha -- 25 would have been the four-success threshold?

I'm still getting the hang of it. For attacks, then, it's kind of binary success/fail, and the true roll is the damage resistance (Toughness) on the defender's end?

Quote:

---

Originally Posted by MattShepherd

Gotcha -- 25 would have been the four-success threshold?

I'm still getting the hang of it. For attacks, then, it's kind of binary success/fail, and the true roll is the damage resistance (Toughness) on the defender's end?

---

Yes to 25 being the 4 degree threshold in that example.

As for attack rolls being most binary, in most cases, yes. The Resistance Rolls (of which Toughness is one) are the ones that require knowing degrees of success every time.

Correct, I added the degree of success to attacks, for expansion in case of any house rules that I saw floating out there. I try to code for every eventuality. Sorry for the confusion.

I am really hoping for some intrepid hero to update the Conditions system so the conditions that affect defenses are automatically factored into resistance roll.

10 out of 16 of the Basic Conditions directly and predictably impact stats on the Character Sheet, like defenses, perception checks, or movement speeds. So they should be relatively straight forward to implement.

Combined Conditions are a little more tricky, but they are just multiple Basic Conditions. Technically, rules as written say you only recover from Basic Conditions, so programming the Combined ones to let you pick which Basic component to recover from and leaving behind the rest would be super nice, but I shouldn't hold my breath. :)