Re: Babylon 5 Wars (LONG)

On Fri, Mar 14, 1997 at 11:58:49 AM, "Phillip E. Pournelle" wrote:

> Has anyone played the new Babylon 5 Wars game?  I'd like to hear how 
> well its written.  Hopefully I'll be able to find some folks to play
> it with. 

I was one of the playtesters for the game.  My game group played it
about ten 
times total, and filed a 20-page playtest report for each of the two
rounds of 
playtesting.  The consensus of opinion was that there were some serious 
problems with it (detailed below), and that the more we played it, the
less we 
liked it.  Unfortunately, preliminary indications are that AoG doesn't
think 
these problems are issues, so they probably won't get fixed.  CAVEAT: I 
haven't seen the final rules yet, so I can't comment authoritatively on
them.

There were three main problems that we identified:
1) The movement system is seriously broken, in two ways:  

First, the movement system they use is inappropriate for a hex-based
game.  
The system is somewhat simliar to (but more complicated than) _Full
Thrust_, 
i.e., "move forward X number of hexes and then turn X degrees". ("X" in
this 
case is 60, because a hex has six sides and 360/6=60.) Each ship is
given two 
stats which affect course changes: a "turn rating", usually expressed in
the 
number of "thrust points" that a ship must expend in relation to its
current 
speed (e.g., "1/2 times current speed") before it may turn 60 degrees,
and a 
"turn delay", usually expressed in the number of hexes that a ship must
travel 
forward in relation to its current speed before it may turn (e.g., "1/3
times 
current speed").  Ships may only coast along hex rows.

Okay, so what's wrong with this?  Nothing -- in a miniatures game.  B5W
isn't 
a miniatures game, though, it is intended for play on a hex map, and the
hex 
map distorts the movement.  For example, ships may "slide" into hexes
not 
along the same hex row, but sliding costs thrust points equal to 20% of
the 
ship's current speed every other hex. This leads to an extremely odd 
phenomenon: A player who wants to conduct a 60-degree course change
(from a 
hex row to a hex row) can do so by paying the turn cost and then
coasting. A 
player who wants to conduct a 30-degree course change (from a hex row to
a hex 
spine), however, must expend thrust points equal to 20% of the ship's
current 
coasting speed every other hex for the duration of this course,
potentially 
forever. If the player is unable or unwilling to continue paying this 
expenditure (e.g., the ship is damaged by enemy fire), the ship then 
spontaneously returns to it's original course, without expending any
thrust.  
A system like this works well in _Full Thrust_, when the map doesn't
force you 
along particular paths, but not very well in a hex-based system.

As a result of this distortion, every different maneuver requires its
own 
procedure, make the game much more complicated than it should be.  For 
example, pivoting (i.e., rotating the ship) while coasting at speed zero

(i.e., dead stop) uses a different procedure than pivoting at speeds
greater 
than zero, although from a physics standpoint the two maneuvers are
identical. 
The speed zero procedure allows you to change your facing to point in
any 
direction; the other procedure limits you to a pivot of exactly 180
degrees 
(which takes exactly three turns). Why? Because if a moving ship changed

facing other than 180 degrees, the movement system couldn't handle it;
you 
literally could not move using the current system. Patching the current
system 
would involve adding yet more special-case rules to the system.

The second problem with the movement system is that it is non-Newtonian,
and 
doesn't even fake it well.  _Full Thrust_ isn't either, but it fakes it
well, 
because it doesn't have the hex distortion effect.  While this type of 
movement system may be proper for a WW2 naval miniatures game or even 
acceptable in the context of, say, BattleTech, its gross violations of
simple 
physics make it inappropriate for a space combat game based on a series
whose 
creator prides himself on scientific accuracy. Although TV imposes
certain 
restrictions, I very strongly believe that any Babylon 5 game should be
as 
scientifically accurate as possible while maintaining the spirit of the 
television show. And that, of course, means a vector movement system.

We felt so strongly about this, that after AoG told us that they had
rejected 
vector movement before they started drafting the rules ("because it
would be 
too difficult"), that fellow playtester Arius Kaufmann and I took a
draft 
system that we had proposed to AoG and developed it further.  It is
available 
at http://www.wizard.net/~caw/vms.htm, and will be updated when the B5W
game 
is released.

2) One energy point produces one thrust point regardless of ship type.

Why is this a problem? It implies that all the ships are the same mass. 
This 
is because, in all the various types of ships, an undamaged thruster
produces 
one thrust point for each energy point run through it, and each thrust
point 
can produce an acceleration of one.  

Since the amount of acceleration any one thrust point can produce is
dependent 
not only on the thrust of the thruster it is run through but also the
mass of 
the ship the thruster is attempting to move, the fact that one energy
point 
has the same effect whether it is spent by one ship or another implies
either 
that all ships mass exactly the same amount (obviously false), or energy

points are relative, valid only within the context of a single ship
class, 
e.g., an energy point in a Centauri heavy war cruiser is different
(represents 
more or less energy) than an energy point in an Omega class destroyer.	

This has profound effects on the rest of the game -- especially ship
design.  
It means that at some point energy points would have to be converted
between 
the "relative" energy points valid only for a particular ship-class, and
some 
"absolute" energy unit which would be used when picking weapons systems,

thrusters, etc. for a ship.

They may be planning on fixing this in the final rules, by creating some
sort 
of energy-point transaction system to convert between the different
ships.	
They indicated that they were going to make some changes after the first

playtest round, but as of the second round we didn't see any.

3) The combat system is really vague.

The more we played the game, the more uneasy we felt about the combat
system.  
We made certain assumptions about what the various values (defensive
ratings, 
damage ratings, fire control, etc.) are intended to represent.	The more
we 
played, however, the more we ran into specific instances that seemed to
not 
fit in with the implicit model we had constructed.  Therefore,	either
our 
understanding of what the values represent was wrong, or the value
itself was 
wrong, or both.  Next, we realized that not only had we not determined
if the 
system and/or values made sense, but that we _could not_ do so without
more 
information.  At best, we would have only a vague feeling that this or
that 
value is wrong -- oftentimes it seems that different ships are different

solely for the sake of being different, or that the values were assigned
in a 
totally arbitrary manner.

Now, this being science fiction, these values are fictional, but that
doesn't 
mean they have to be arbitrary.  If the defensive rating, for example,
is a 
rough idea of how hard the ship is to hit based on the size of its
profile (a 
la GDW's _Star Cruiser_), then small ships should be harder to hit than
large 
ships.	This wasn't always the case, which led us to wonder what factors
_are_ 
included.  On several occasions it seemed like someone had decided to
change 
values without thinking through exactly what the values represent.

While bad enough in itself, this will potentially become intolerable
when the 
ship design system is introduced, for two reasons.  First, if there is
no 
method by which a ship's ratings are determined, it will be difficult if
not 
impossible to devise a system which will allow you to design the ship's 
included in the game.  Second, even if the original ships do not become 
illegal, it promises to make them suboptimal designs.  There should
always be 
room for players to improve on the efforts of the naval architects of
the 
fictional setting, but care needs to be taken not to invalidate all the 
designs which came before.

Mark Seifert's web page has a proposed d20 damage system which
potentially 
could streamline the combat procedure considerably.  While the combat
system 
was a little complicated at times, we didn't think that complication was
the 
real issue.  I don't know what they will do.

There is also a more minor nit:  The Omega-class destroyers don't have a

rotating section.  We thought this was important, because this is an
extra 
mechanism which can be damaged, and the commanders of these ships (in
'Severed 
Dreams', for example) certainly seemed to think that damage to these 
components would be bad, and because it is one of the things which
illustrates 
the general inferiority of Earth Alliance technology versus some of the
other 
major races.

All-in-all, it was about what I expected when I discovered that the
designer 
had been Stephen Cole's hand-picked successor to take over the
stewardship of 
the Star Fleet Battles universe.  [This isn't intended as a jab at SFB,
just a 
note that SFB suffers from most, if not all, of the same problems --
except, 
of course, that vector movement is not an integral part of the
background on 
which the game is based.]  I don't really expect any of the above
problems to 
have been fixed (although the movement system is the only one that AoG
has 
flatly declared was not going to change).  

That having been said, I have already reserved a copy from my local game

store, and I'll be the first one in line to buy it.  It's Babylon 5, and
even 
if it's unlikelty that I'll play it as-is (unless there have been some
major 
changes), it will still be a valuable reference and a good basis for 
modification.  Aside from the movement system, there is a lot of good
stuff in 
there which can be salvaged.

-- Chris Weuve	 [My opinions, not my employer's.]
------------------------------------------------------------------------
------
mailto:caw@wizard.net (h)		http://www.wizard.net/~caw 
mailto:caw@intercon.com (w)		Fixes for AoG's B5 game, books,
mailto:chrisweuve@usa.net (perm)	stuff for sale and more