SV: SV: What makes a Capital ship Capital?
From: "Oerjan Ohlson" <oerjan.ohlson@n...>
Date: Fri, 5 Dec 1997 23:23:16 +0100
Subject: SV: SV: What makes a Capital ship Capital?
Mikko wrote:
> > It should be, yes. In FTII, at least for smaller battles (up to a
few
> > thousand points or so) this isn't necessarily true - it depends a
bit
on
> > board size (and thus the speeds involved).
>
> Board size does NOT determine what speeds can be used. It does
determine
> what speeds can be used *conveniently* but if you are concerned about
> winning only (as in a tournament you should be), convenience is not a
factor.
But convenience tends to have great impact <g> Especially since it is
much
more comfortable (and thus convenient) to win with your designs rather
than
your tactics! ;-) In a tournament, it is _very_ inconvenient to have to
relocate the entire board due to the time involved...
> I would really like to see the design team play out some battles
> with three-digit speeds, post a blow-by-blow account and say with a
> straight face: "Yes, the game works with unlimited speeds."
Sure - but I'll have to measure in mm to do it :-)
More seriously, I _have_ played a battle where the speeds eventually
approached 100 even for the battle-wagons. (Starting speeds were in the
10-20 range.) It used the vector movement rules though, and the general
direction of travel was the same for most of the ships - so after a
while
we did a Galileic coordinate transformation and made the table move with
the ships... Great fun, that was. Had we used the standard movement
rules
we'd have been in trouble <g>
...
> Agreed, but scanning rules are optional anyway. I personally stopped
> using them because they simply slowed the game down too much.
How much info do you give on the size of the various ships? (This is not
defined anywhere in the rules... they just assume that the size of the
model has some sort of relationship to the size of the ship it
represents
:-/ )
> In general, I don't think one should take such a dim view of
> "design-optimizers". Heck, the entire modern battleship concept was
born
> when someone decided to optimize the 19th century battlewagon designs.
> And it died when later "optimization" of fleet design made it
obsolete.
>
> There is over-optimization born of game abstractions and rule flaws I
do
not
> like. But logical optimizations should not looked down upon.
>
> E.g. giving all ships odd thrusts, or giving all K'V ships Level 2
armor
> are IMHO bad optimizations born of bad rules. The first exploits a
> abstracted rounding point, the second the rule flaw that armor does
not
> have mass (and that bigger ships really have less surface area to
armor).
>
> OTOH, mounting only A-batteries for beams is a valid optimization.
It's
> very boring, true, but valid because a viable alternative does not
exist
But this is IMO the same thing as your other examples above - an
optimization stemming from a bad rule (in this case, the too-low mass of
the A). And thus, IMO, a bad optimization.
The problem as I see it, or at least part of it, is that FT lacks the
kind
of "tech development" which forces new designs. This means that in order
to
encourage design variety, all weapons present in the game need one area
where they are better than the others. As the A was without a shadow of
doubt the best of the beam batteries prior to the mass change (to 4),
the
other beam sizes simply weren't needed.
> -- which may very well be true even if it is boring. Would you call
> someone an optimizer in a modern skirmish game if he gave all his
troops
> assault rifles instead of bolt-action ones?
No. However, if he gave all his troops bolt-action ones instead of
breach-loaders in a mid-19th century skirmish I might, though.
> It is a fault of the rules not to offer viable alternatives, not a
fault
> of the player not to use the non-viable ones, IMHO.
Exactly. Which is why the non-viable ones need some strengthening -
enough
to make them viable once more.
Later,
Oerjan Ohlson
"Life is like a sewer.
What you get out of it, depends on what you put into it."
- Hen3ry