Re: B5 Wars Designer Comments Part 2

On Wed, Jul 30, 1997 at 9:53:55 PM, Jim Bell wrote:

> Well Chris (Weuve) maybe your constant questions about hexless based 
> movement for B5 Wars did work. We'll have to see what the rules are
like 
> but Roberts response (attached) indicates that the rules will be in
the 
> Narn-Centauri War Supplement. 
>  
> Score one for Chris and everyone else who asked for a none hex based 
> movement system for B5 Wars. 

Except that's not what I said! <grin>  Although I'm a big fan of hexless

gaming (I play naval minis all the time, in addition to SF), the point I
was 
basically trying to get at was that you should try to minimize the
distortions 
caused by the hex grid, rather than simply say oh well, there's a hex
grid so 
we have to move down hex rows...

I am VERY pleased to hear that there will be minis rules from AoG -- I
look 
forward to comparing them to CE _Earthforce Sourcebook_.

Now, regarding Mr. Glass' comments:

> Pivoting... 
>  
> The restrictions we place on capital ships while in a pivoted state
was a 
> play-balance issue, not a reality issue.  At one point we played with
the 
> idea of allowing ships to turn while in a pivoted state and found 
> (through playtests at local stores) that it was highly abused and
allowed 
> for much greater maneuverability than these large ships should have.	

A couple of points come to mind:
1) Was this in the context of a vector system, or was it in the context
of the 
current movement system, which already gives much greater turning
ability than 
it should?  It wouldn't surprise me to learn that a pivoting system
grafted 
onto the current system would cause such problems -- which is more of an

indictment of the current movement system than the idea of pivoting.

2) Was this with the previous high-thrust ships, or the released
low-thrust 
ships?	The release version adds two concepts that the playtest ships
did not 
have:  an Acceleration/Deceleration Cost, which determines how many
thrust 
points are needed for each hex/turn change in speed, and an engine which

converts surplus energy into thrust points.  This has the effect of
greatly 
decreasing delta vee changes possible for ships -- 7 thrust points used
to 
produce up to a 7 hex/turn difference in speed, now (for an Omega) it
produces 
2.3 hex/turn.

3) Sounds more like the problem was that the pivot cost wasn't high
enough, 
rather than the concept of pivoting was flawed.

> All playtesters which tested this system agreed and requested that the
rules 
> be reinstated back to their former system.  There was also a number of

> additional rules which we were going to have to create to prevent
ships 
> from effectively changing their direction by 120 degrees simply by 
> pivoting 120 degrees and then turning.  This is something that yes, a 
> ship could do in reality but did not match with what we see in the
show, 
> thus we would not allow it.  It also blurred the line between an agile

> ship and a normal ship. 

Sounds like the problem was with the SYSTEM and not the theory -- if you
allow 
ships to pay a cost and change course based on where they are AT THAT
MOMENT, 
as opposed to changing the final destination hex of the path they will
travel 
from the beginning of the movement phase, you will have distortions like
that.

> On the issue of the ships which can not pivot we actually only have
one 
> ship in mind for this restriction and that is the EA Explorer class 
> vessel.  It is structurally very fragile compared to other ship and
must 
> be handled with great care when maneuvering it.  The restriction is
just 
> our way of showing it's fragility in maneuvering within the mechanics
of 
> the game. 

Not a problem -- I assumed (and still do) that the ship can't pivot *in
the 
scale of the turn*, rather than they can't pivot at all.

> On the issue of sideslips... 
>  
> I see what you are talking about at this point.  However, I think you 
> miss the whole point of allowing sideslips in a hex-based game.  It is

> simply a way to give players an additional option during movement
since 
> the hexes restrict what a ship can do during a turn.	You can find the

> same basic principals in any number of other hex based games.  This
was 
> not intended as another way to turn a vessel.  

Whether it was intended that way or not, that's the effect it has.  I
don't 
know about other people, but what I find turns one of the 26 tactical
space 
games I own into a game I will actually play more than once are elegant
rules 
which hold together under reasonable conditions of play.  It is hardly 
unreasonable to expect a player to want to turn 30 degrees (or stop the
pivot 
at something other than a 180 degree increment), and hence players are
going 
to want to do it and use what mechnism they see presented.  Saying
"other 
games are unrealistic and limited, too" does nothing to give me a reason
to 
play this game over the many other games I own.  

> When the table-top rules come out side-slips will not even be allowed
> as the restrictions of the hexes goes away and side-slips are not
needed.  
> (You can achieve the same effect by pivoting your ship in a table-top
game.)
> Side-slips should never been seen as a turn because they are not a
turn in
> any way, shape or form. 

Webster's defines "turn" as:
"To be deflected; to take a different direction or tendency; to be
directed 
otherwise; to be differently applied; to be transferred; as, to
turn from the road."
[http://work.ucsd.edu:5141/cgi-bin/http_webster?turn]

If at the end of the maneuver I am moving along a different direction
than at 
the end of the maneuver, it certainly functions as a turn.

> In September when the first supplement is release there will be a full

> set of table-top rules (hexless).  These rules allow for extremely
minute 
> course corrections,(more so than FT as you must change your course by
30 
> degrees).  This means that many of the restrictions felt on a hex-map
are 
> lifted and players have a great amount of freedom when maneuvering
their 
> ships.  I personally prefer a hexless system as I don't like the 
> restrictions which must be dealt with on a hex grid, yet at the same
time 
> I understand why they are there. 

I am very pleased to hear this.  The most egregious of the flaws in the 
movement system come from the interaction of the movement system on the
hexmap 
-- removing the hexes is certainly a good first step towards fixing the 
system.

> As for the vector movement rules... 
>  
> The decision we came to was arrived at from several view points... 
>  
> 1)An overwhelming majority of our playtesters (remember, we had over
180 
> playtesters on this project) preferred a non-vector system. 

What sort of option were they presented with?  From the descriptions
above, it 
sounds like a lot of test rules didn't pan out -- did they reject these
test 
rules, or did they reject the _idea_ of a vector movement system?  I ask
at 
least in part because both Mr. Glass and Mr. Graw have both commented
that a 
vector movement system was a frequent request.

> 2)We tested several vector systems and while some of them were fine
when 
> you are dealing with only one or two ship, all of them became much too

> clunky and cumbersom when you have 15 capital ships plus their
fighters 
> on the board.  Can you imagine keeping track of vectors on two hundred

> plus ships? (We had a playtest game with this many ships, it took us 
> around eight hours to play to a conclusion, a vectored system would
have 
> taken much longer). 

Aside from the question of whether the game system should be optimized
for 
battles much larger than the vast majority of players will ever
experience, I 
can't help but remember that the system involves a sheet of paper for
each 
ship (except fighters, which are 6 to a sheet) and predetermination of 
acceleration and deceleration for each ship.  This means, for the
200-ship 
scenario mentioned above, 83-200 pieces of paper, and 83-200
acceleration/
deceleration announcements to be made each turn.  Given that you must
announce 
the accel/decel before movement, that is in effect preplotted.	I would 
suggest that preplotting the vector and then moving simultaneously is no
more 
work and probably LESS paperwork and effort -- perhaps *much* less --
than the 
current system.  [The playtest version, which had two movement phases
per 
turn, was much worse.  AoG should be commending for streamlining the
process.]  

The effort threshold was passed when the ship sheet was created.  The
user has 
to check the sheet each turn to determine mark of thrust and check
thruster 
ratings.  If find the prospect of keeping track of the vectors for 200
ships 
no more daunting with a vector movement system than the system that came
out 
of the box.

> This was not an abritrary decision.  We thought long and hard about
this 
> issue as there were a number of people who requested it, but not a 
> majority by far.  I should note that the CE combat system is a 
> vector-based system and from a designers point it seems to have been
done 
> very well.  However, from a players point of view it was lacking in
some 
> elements and not very exciting.  This was a common problem we found in

> all of the vector based systems which we read and/or tested and seems
to 
> be inherent to that style of system. (Note: this is a personal
opinion,
> not one of the company's).  

Since the CE system is not out yet -- it's coming out in the _Earthforce

Sourcebook_ -- I can't comment on what it will and won't have. 
Regarding the 
other vector movement systems, what was it that made them unexciting? 
The 
movement systems they used, or the combat system they used?  I can
certainly 
understand the argument that some of these systems involve combat
systems that 
are not as detailed, but that is hardly an indictment of the movement
system 
itself.

Oh well, I don't expect to convince either Mr. Glass or Mr. Graw -- that
was 
not and is not the purpose of my responses. I merely want everyone to 
understand why I reject Mr. Glass' assertions that "a true vector
movement 
system as a system like this is simply too complex for the average
gamer" and 
"the movement system is as realistic as you can get in a simple system".
 Both 
_Mayday_ and _Triplanetary_ have movement systems that are about a page
long 
(including illustrations), as opposed to the AoG system.  Admittedly,
neither 
has a detailed combat system which uses facing -- adding such a system
to take 
use with the AoG system is about another page.	This brings the total to
two 
pages, and results in a movement system which is simpler and more
realistic 
than the AoG system, at a quarter of the length.

Once again, AoG's efforts are to be commended.	Everyone should buy the
game. 
If you like it as is, then play it as is.  If you don't like the
movement 
system, then don't play with it -- devise your own, adapt something from

something else (_Full Thrust_ is an obvious source of inspiration, as
are the 
_Renegade Legion_ games, which are not vector movement but, IIRC, at
least 
make an effort at getting pivoting right), or download VMS when it's
ready 
(the prose currently sucks, but I hope to have a new version up by
Monday).  

Buy the game, compare the options, and judge for yourself.

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