Hi!
I can see some problems with this rule:
Different detachment sizes. An IG grunt detachment can afford to loose many
more units than f. ex. a chaos marine detachment. It is a bad loss for a
chaos player to losse two stands, but its quite managable for an IG player
to loose four. In fact, in this case it would seem unfair that either of the
detachments should retreat.
Morale and breakpoint should have something to do with this also.
Eivind
-----Original Message-----
From: Peter Ramos [mailto:primarch_at_...]
Sent: 16. mai 2003 10:53
To: netepic_at_yahoogroups.com
Subject: RE: [NetEpic ML] Digest Number 1216
Hi!
I agree Jyrki, since you been around as long as I, you'll remember
discussing this before, but I cant remember what the problems were to
incorporate such a rule. Do you?
Peter
-----Original Message-----
From: jyrki.saari_at_... [mailto:jyrki.saari@...]
Sent: Friday, May 16, 2003 9:02 AM
To: netepic_at_yahoogroups.com
Subject: RE: [NetEpic ML] Digest Number 1216
> -----Original Message-----
> From: ext Jervis Johnson [mailto:jervisj_at_...]
> Sent: 16 May, 2003 15:13
> To: 'netepic_at_yahoogroups.com'
> Subject: RE: [NetEpic ML] Digest Number 1216
>
>
> <<LURK MODE DEACTIVATED>>
>
> > Date: Fri, 16 May 2003 05:50:39 -0000
> > From: "Gustavius Q Knackerthrasha"
> <justin.hewlett_at_...>
> > Subject: Close combat..
> >
> > This simply prompted a long discussion about close combat..
> In the next
> > few weeks we hope to test a few of the rules to try and make you
> > carefully choose where and when you initiate Close Combat.. <snip>
> >
> I know I shouldn't really get involved on this,
Ah HA! Now we got you!! ;o)
> but this
> emaail peaked my
> interest as it touches on one of the areas where I feel that
> the SM/TL is
> really rather weak. Basically, SM/TL relies almost completely
> on attrition
> as a method of deciding who wins a close combat (i.e. it's
> pretty much 'last
> mand standing').
I didn't think about this whe the CC rules were discussed, but both you
and the original poster are IMO right about this.
> This can make them drag on for a bit. On the
> other hand if
> you read books on modern warfare, one of the things that they
> emphasise is
> that assaults tend to be bloody but brief, and that one side
> or the other
> will either run off or surrender very quickly. Both E40K and
> now E:A try to
> address this problem by ensuring that after a round of combat has been
> fought there will always be a result, and this result will
> force one side to
> fall back away from the combat. In E:A this is done by having
> _each_ side
> roll 2D6. Then each player takes the higher of their two dice
> rolls and adds
> modifiers from the following chart. Why two dice? It makes
> the result less
> random than using a straaigh D6 while still allowing for some extreme
> results.
>
> The player with the lower roll has to fall back (make a
> double move away
> from the enemy). If there is a tie then another round is fought
> _immediately_ (very bloody ; )). I'm not sure how easily such
> rules would
> translate to the NetEpic, but you might want to give them a try...
>
> > 1.12.7 Assault Modifiers
> > (cumulative)
> > For each kill you have inflicted during the assault
> > +1
> > You have more units than the opposing formation
> > +1
> > You have more than twice as many units as the opposing
> formation +1
> <Snip modifiers for blast markers, perhaps give a +1 for having charge
> orders?>
>
Elite: +1
Fearless: +1
Causes terror: +1
This is IM(NSH)O worth testing; and I don't think it would be too hard
to incorporate. Just make the roll after the first round has been
fought, add the modifiers and apply result. Maybe as an optional rule?
> Best regards,
>
> Jervis Johnson
> Head Fanatic
>
Jyrki Saari
> <<<LURK MODE RESTORED>>
P.S. Thanks for the plastics!
To unsubscribe send e-mail to: netepic-unsubscribe_at_egroups.com
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
To unsubscribe send e-mail to: netepic-unsubscribe_at_egroups.com
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
Received on Fri May 16 2003 - 21:10:05 UTC