Which is what I meant by a 'normally difficult task' - one which would be an unopposed roll. Obviously, more difficult problems are opposed rolls.
> The other thing this discussion has brought out is the understanding
> of "Fumble" - It's fine to say that a character with 1
> Mastery "Never Fumbles", but without knowing what a fumble is, it is
> fairly meaningless (Is it, in the cooking example, Inedible food,
> Dangerous food, or merely unappitizing food? - As a software
> engineer, is it a fumble if you write a program that fails to do what
> you intended, or only if it does the opposite of what you wanted it
> to do? - If you Quit from an edit without saving first, is that a
> fumble or a failure? Delete the wrong version of a file? Run the
> wrong program, or the right program on the wrong machine? Copy a
> file to the wrong directory? I wouldn't say I make these sort of
> errors 5% of the time, but I don't think I could honestly claim
> to "never fumble")
>
This of course is the big question. Software Engineers expect to produce
code with bugs, mistakes, etc. If they can be found in a reasonable time
frame, we would regard this as a 'successful' day. Fumbles are a game
construct and don't really map terribly well into real life. Personally, I'd
use
fail as roughly 'minor bad thing happens' and fumble as 'major bad thing
happens'. So a shepherd failing is "the sheep scatter, and it takes you an
hour to get them back together" while a fumble is "one of the sheep just
wandered off the edge of a cliff in the fog." The problem is the rules are
so
vague, that someone else might have losing only one sheep as a fail, losing
half the flock as a fumble, and are just as 'correct'.
Whether this matters is another matter entirely.
Cheers,
Graham
-- Graham Robinson gjrobinson_at_...
Powered by hypermail