> Close Combat is a generic skill. It's intended that, like Conan (or
> Luke Skywalker), you can pick up just about any weapon and be able to
> use it. It's also intended that you have some sort of combat
> specialization (see p.23).
My problem here is that this is completely redundant.Close combat (someone correct me if I'm wrong...) starts equal to your highest melee skill, and (in the rules) can be increased for the same cost as any 'normal' ability. You can then use this to fight with any weapon/style, but with an improvisational modifier if you don't have that style listed. Correct?
But the rules already allow you to do this - I use my Sword ability with an improvisational modifier to fight with an axe, mace, whatever. So other than the free boost for any secondary combat abilities you may have, what exactly is the point?
More complexity in the rules, with no great advantage other than to (arguably) reduce the realism of the system...
> Jane Williams wrote :
> > The way I understood Greg to explain this at Convulsion (and yes, it
> > made sense to me), having a Mastery means that under normal
> > circumstances, you don't fumble. Maybe if there are exceptional
> > circumstances, then yes, but not normally. So, he asked, in your nomral
> > everyday work, that you get paid for, how often do you fumble? How
> > often do you fail? Right. You're at about 10W.
>
> A bogus argument, since one fumble doesn't represent a botched job
> (my work at least takes all day, so it would be an extended contest).
> It's conceivable that I could suffer complete defeat without ever
> fumbling, of course.
>
This depends on whether your job is important to the story, not on how long it takes. One (slight) problem with the system is deciding whether to treat something as a simple or extended contest can effect the outcome. As David says, if its an extended contest, a fumble isn't necessarily a major disaster.
> Also, look at any Microsoft product. Presumably Microsoft can hire
> the best programmers in the business, and we know from reading books
> like McConnell's that they practice reasonable software management.
> By Greg's argument, wouldn't each bug correspond to a fumble? Yet
> this would limit the best programmers in the business to a 19.
>
Microsoft's ability to hire programmers is questionable, and then software engineering techniques even more so, but not really an argument for on list. Part of the problem is defining 'fumble'. Bugs in software are inevitable. There's even some evidence that you reach a point where fixing bugs introduces new bugs as quickly as old ones are cured. (I'll dig out a source for that if anyone really cares.) Therefore I'd argue that a bug isn't evidence of a fumble.
Most software engineers I know are engaged in a contest of their 'Meet Deadline' against the system's 'Be Buggy'...
Although I like this example - it is inherently difficult to represent under the Hero Wars rules - maybe we ought to switch to one which is more Gloranthan focused? How about : what exactly is a fumble in library research?
Cheers,
Graham
-- Graham Robinson gjrobinson_at_...
Powered by hypermail