This page was last updated on 1 January 2008.

Vector Movement System

by Christopher Weuve and Arius Kaufmann (c)1997-2007. Permission granted to copy for non-commerical purposes.
Contents

Purpose

Why use VMS with B5 Wars?
Introduction to the Vector Movement System
VMS Components and Files

Purpose

The Vector Movement System is a generic set of realistic, vector-based movement rules designed to replace the non-vector movement rules in hex-based tactical space combat games (although it will work with non hex-based games as well). It was originally inspired by the problems we encountered while playtesting Babylon 5 Wars, Agents of Gaming's new tactical space combat game based on J. Michael Straczynski's Babylon 5.

Please note that this system is not derived from the AoG movement system; while the problems with that system inspired us to create a better replacement, and while we strove to come up with a version of VMS that would work smoothly with the other AoG components, the AoG system did not serve as the foundation for our efforts. Similiarly, VMS is not limited to the AoG system; it is a fundamentally appropriate addition to most tactical space combat games.

Why use the Vector Movement System with Babylon 5 Wars?

Background

In late 1996 and early 1997, I was one of a small number of people who had the privilege of playtesting Babylon 5 Wars, Agents of Gaming's upcoming Babylon 5 tactical space combat game. We played it about ten times total, read the rules about five times each, and submitted two 20-page playtest reports. Despite the fact that AoG had clearly put a lot of effort into the system, the group concluded that there were a couple of problems that were serious enough to make it unenjoyable to play in its present form. (At that time, though, we would still have bought it, as Chameleon Eclectic's excellent tabletop game, found in the Babylon Project Earthforce Sourcebook, had not yet been released.) The most serious of these problems involved the movement system. When Agents of Gaming responded that they didn't share our opinions, we decided to take matters into our own hands and design our own substitute movement system.

For the record, please note the release version of the game is much superior to the playtest version. While the movement system has not been fixed, both the Sequence of Play and the Combat Procedure have been greatly streamlined. Note that Chameleon Eclectic's Earthforce Sourcebook for their Babylon Project roleplaying game integrated vector movementbased on the Full Thrust system. Sadly, both these games are out of print.

Note also that early on, when we decided to develop the Vector Movement System further, we also decided to limit the changes to the AoG game as much of possible. Our goal was not to replace the AoG game in its entirety, but to replace the part which is the most seriously broken: the movement system. We don't want to be in the business of, for example, publishing VMS stats for every AoG designed ships, nor converting all their Hit Location charts from a four-sided world to a six-sided world. This is for three reasons:

First, we don't want the legal hassle. AoG had the license to do the game. Period. We were not producing a separate game, we were not deriving a game from their game, without using their ship names or infringing on their trademarks or copyrights in any way.

Second, the more we change, the more work we have to do. We could spend a lot of time tweaking the sequence of play, for example, but at this time we are not particularly interested in writing our own B5 game (even without the legal prohibition), although several people have suggested building a game using VMS.

Finally, we wanted a system that would work if AoG ever included a ship design system; players would need to be able to convert their own designs into VMS-capable ships.

For these reason, we decided to use existing AoG ship characteristics and statistics either to generate VMS stats or as surrogates for VMS systems. Please note that this means that the numbers coming out of the conversions are highly suspect in any real-world sense; they are SWAGs at best. They do seem consistant with our gut feelings, however, and given our goal of using the AoG numbers, I think they are the best that we can do.

Problems with the AoG System

The most serious of the problems my playtest group discovered involves the movement system. The Agents of Gaming system is of the standard "move forward X number of hexes and then turn 60 degrees" variety often found in most hex-based tactical space combat games. 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").

We found this problematic for two reasons: First, it's a gross violation of simple physics. Yes, many tactical space games have this problem, and yes, even the TV show isn't immune to scientific inaccuracy along these lines. JMS has clearly shown a desire to promote scientific accuracy, however, and although TV imposes certain restrictions, we strongly believe that any Babylon 5 game should be as scientifically accurate as possible while maintaining the spirit of the television show. And that, at least for the Earth Alliance and the other lower tech races, means a vector movement system.

In this context, a vector is a description of the course and speed of an object. Vectors are often represented graphically by "vector arrows"; the length of the arrow indicates the force acting upon the object (be it a force imparted at that moment, like rocket thrust, or the simple tendency of an object in motion to stay in motion), with the direction of the arrow indicating the direction of movement. One of the neat features of vector arrows is that by placing all the vector arrows acting on an object head-to-tail in a chain, you can draw a new vector arrow describing the sum total of those forces directly from the tail of the first arrow to the head of the last arrow.

The second problem is independent of the question of whether a vector-based movement system is necessary for a good Babylon 5 game: the AoG system is is not only unrealistic but complicated, unecessarily restrictive, and difficult to use as well. This is largely because it is a laundry list of procedures used to produce certain maneuvers; as a result, the procedure for each manuever must be memorized, and some maneuvers are prohibited because they would cause other parts of the movement system to break:

Example #1: 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.

Example #2: Ships may only coast along hex rows. 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. (In other words, in most cases 30 degree course changes cost much more energy than 60 degree course changes, which is non-sensical.) 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. (See Figure 1, below.)

Figure 1
In the top example, the ship using the AoG movement system must spend thrust every turn to maintain the horizontal course. A realistic movement system would require the ship to only expend thrust on Turn 1 -- after that, the ship would be able to coast.

Note that any attempts to fix the sliding problem will make the complexity problem worse; since the problem is with the core concepts of the movement system, attempts to fix the system without replacing the core concepts will necessitate adding rules to a system that already has too many. This reminds me of the Ptolemaic astronomers who constructed ever-more unwieldy models to explain the Sun's orbit around the Earth, in the process ignoring the simple answer -- that the Earth revolves around the Sun.

The playtest group suggested (twice) that Agents of Gaming replace their movement system with a vector-based movement system. We included a detailed analysis of the problems with the current system (some of which I have included above) and why we thought that fixes to the current system not only wouldn't work, but would actually make some of the problems even worse. We also provided them with several examples of very playable games which used such a system. Finally, to prove it could be done, we even created for them a sample vector movement system that was designed to work with the existing AoG system without any increase in paperwork.

AoG rejected the notion on both occasions, stating that they had already playtested a vector movement system early in the design process and had rejected it as too complicated and liable to scare off customers. That's their prerogative, of course -- it's their game, presumably they have an idea of what type of game they want to produce, and not every idea from every playtester will fit into that vision. This is a shame, as I think they have based their decision on one flawed implementation and a lot of mistaken assumptions.

VMS, AoG, and ease of play

Okay, so the movement system is unrealistic, but at least it is simpler than a vector movement system, which by its very nature is complicated -- right? Actually, the answer is "No": a vector movement system would be much simpler (and, I would argue, more fun) because the rules would be easier to remember yet cover all possible situations, without artificial constraints designed to prevent players from attempting maneuvers the system doesn't support. This is born out by the several games which use a simple vector movement system. GDW's Triplanetary, for example, has one of the simplest movement systems ever designed -- one-half of one 8.5x11 inch page, including three illustrations -- yet accurately depicts vector movement in the inner solar system. (In fact, the movement system is so much fun that the relatively weapons-free Grand Race scenario is by far the most popular scenario for the game among our group.)

For the record, there are some maneuvers that are possibile in the AoG system that are not possible in a vector system. However, since all of those maneuvers are impossible with real physics and are solely an artifact of the unrealistic nature of the AoG system (e.g., turns without regard to your current vector), the inability to do them in a vector system should be considered a feature and not a bug.

By this point you are probably saying to yourself that this guy is really good at criticizing other people's work, but unless he can come up with something better, he should just sit down and shut up.

That's where the Vector Movement System comes in.

Introduction to the Vector Movement System

Just what are vectors, and why do we need them in our movement system?

In simplest terms, a vector is a course and speed. In space, vectors are fairly straightforward -- an object moving on a particular vector will continue moving on that vector forever, until another force acts upon it. We rarely see pure vectors on Earth, however, because other forces -- such as friction, aerodynamic lift, and gravity -- dominate our frame of reference. If you throw a baseball on the Earth, for example, it will generally arc into the air, until gravity pulls it to the ground. A baseball "thrown" in deep space, on the other hand, will continue to move in exactly the direction thrown at exactly the speed thrown until another force acts upon it. The same is true of a spacecraft.

Vectors are often represented graphically by "vector arrows"; the length of the arrow indicates the force acting upon the object (be it a force imparted at that moment, like rocket thrust, or the simple tendency of an object in motion to stay in motion), and the direction of the arrow indicating the direction of movement. One of the neat features of vector arrows is that by placing all the vector arrows acting on an object head-to-tail in a chain, you can draw a new vector arrow describing the sum total of those forces directly from the tail of the first arrow to the head of the last arrow.

Most tactical space combat games use movement systems that are somehow derived from the behavior of airplanes or surface ships. As a result, spacecraft in these games behave like aircraft or surface ships, performing all sorts of radical course changes that are only possible by interacting with a medium such as air or water. Some game systems, such as that used in Agents of Gaming's Babylon 5 Wars or FASA's Renegade Legion games, have a layer added onto their non-vector movement systems in an attempt to emulate the results of a vector system, which begs the question of why the designer didn't just use a vector-based system in the first place.

If you want to play a game where the spacecraft maneuver like airplanes or surface ships, that's fine -- I've played many of them, and have found some of them to be a real hoot. In general, though, I play tactical space combat games because the situation is different than historical games; if I wanted to recreate what is essentially a WW1 naval battle, for example, I would probably just play a WW1 naval game.

Principles and Assumptions

There are three basic principles in the Vector Movement System. All ship movement flows as a direct consequence of these three core concepts. They are:
  1. An object at rest will tend to stay at rest. An object in motion will tend to stay in motion.
  2. The course of a spaceship (hereafter "ship") is the sum of all the forces which have acted upon it. To impart a force on the ship in a particular direction, you fire a thruster pointed in the opposite direction;
  3. To point a thruster in the correct direction, you rotate the ship.
Once the rules for doing the above (and recording the information) are understood, the movement system as a whole is understood. All the possible maneuvers come directly from the movement system.

The Vector Movement System makes two key assumptions:
  • Thrust during a turn occurs in one impulse, rather than being spread out over the course of the turn;
  • The mass of the ship remains constant during a battle (i.e., the expenditure of fuel or ordnance does not effect the mass of the ship).
While these are approximations, we feel that they are necessary approximations, and are much smaller violations of the laws of physics than alternative, non-vector movement systems.

Overview of the Vector Movement System

Most of the published vector movement systems use either markings on a laminated hexmap or three counters per ship (tracking the ships past, present and future positions) to keep track of the ship's course. Two systems (LNL and Freefall by Bone Games) replace the counters for the past and present positions with numbered counters representing the ships speed and direction; unfortunately, in most cases this keeps the number of counters at three per ship.

VMS uses the best facets of all these systems. Rather than recording the information for the ship's course on the map, which at best clutters the display and at worse is vulnerable to disruption by a careless jostling of the table, VMS pulls the information off the map and onto individual ship sheets. These laminated sheets contain a display allowing the players to quickly and accurately record a ship's current course, rotation, and course changes. The size and composition of these sheets is really dependent on the type of game being played. Small games with one movement phase per turn and little other information to keep track of may be able to fit several ships on a single 8.5 x 11 inch sheet of paper. With games that use a "ship sheet" and preplotted movement for each ship, the new displays simply replace redundant portions of the existing ship sheet with no increase in the amount of paperwork.

The example below is based on the generic version of the Vector Movement System, with each ship having six sides. Most games use ships with four sides, but this isn't a problem.

Preparation: Before play can begin, it is necessary to create a ship sheet for each ship. Depending on the level of detail in the system, one sheet may be able to control several ships.

The movement of each ship is plotted through the use of two graphics, labelled "Even" and "Odd". Each graphic consists of an empty hex surrounded by six hexes (which are split by a verical line), below which is a line of four small boxes labelled" Left Previous", Left This Phase", "Right Previous", and" Right This Phase". [See Figure 1, below.]

To add the graphics, simply photocopy the ship sheet, and cut and paste the graphics onto a new ship sheet.
Procedure: During the movement phase for each ship, the owner of the ship performs the following actions:
  1. Plot movement for the ship.
  2. Excute thrust for the ship.
  3. Excute rotation for the ship.
Movement is simultaneous for a particular movement subphase, meaning that all ship movement for ships moving in that subphase is plotted then executed by all players simultaneously. Initiative can affect what subphase a ship moves in, potentially causing it to move one phase earlier or later, as explained below.

The two new graphics are for recording the direction the ship is facing, the direction and speed the ship is moving, the direction and speed with which the ship is rotating, and the thrust applied each turn. Each graphic consists of a cluster of six hexes surrounding a center hex, with four boxes arranged horizontally below. Each of the six outer hexes is split down the center by a vertical line. The labels indicate whether the graphic is used for Even or Odd-numbered turns.

Each graphic is considered "fixed" relative to one of the map edges, i.e., if the top of the graphic is "north" at the start of the game, then it is always "north". For sake of illustration, the hexes are marked "A" through "F", beginning with the hex on top and proceeding clockwise. These graphics are illustrated below.

During the course of play, information regarding the ships current velocity and direction is recorded on the left hand side of the hexes; information regarding the ship's expenditure of thrust is recorded on the right hand side of the hexes.A similar procedure is followed with the rotation boxes at the bottom of the graphic, with the outside boxes recording information about the ships current rotational speed, and the inside boxes being recording information recording information regarding the rotational thrust applied that turn. The facing of the ship (which may be different than it's direction of travel) is recorded by drawing an arrow in the center hex. For odd-numbered turns, information regarding the current expenditure of thrust (e.g., "right hexside" information) is recorded on the Odd graphic, while information regarding the outcome of those thrust expenditures (e.g., "left hexside" information) is recorded on the Even graphic. For even-numbered turns, this sequence is reveresed.

The exact procedure is as follows:
  1. Calculate thrust levels;
  2. Record current thrust in the appropriate right hex sides on the Current Turn graphic ("Odd" if an odd turn, "Even" if an even turn);
  3. Record the result of those thrust allocations on the left hex sides of the approrpiate hexes of the Next Turn graphic ("Even" is an odd turn, "Odd" if an even turn);
  4. Record current rotational thrust in the appropriate inside boxes on the Current Turn graphic ("Odd" if an odd turn, "Even" if an even turn);
  5. Record the result of those rotational thrust allocations in the appropriate outside boxes on the Next Turn graphic ("Even" is an odd turn, "Odd" if an even turn);
  6. Execute the move.
We recommend that at first you follow the steps in exactly this order, to avoid confusion.

Note the following:
  • Since the relative position of the graphic is fixed vis-a-vis the map and the ship rotates, this means that the location of individual thrusters changes from turn to turn as the ship rotates.
  • The ability of a particular ship to maneuver is limited by two things -- the capability and location(s) of the thrusters and the ships ability to rotate to point a thruster in the required direction.

Example: Assuming it is turn #3, an Odd turn, and the course is marked as A=4, B=2 (in the left hand sides of the A and B hexes), with the ship facing direction B (i.e., direction arrow in the center hex pointing to B), and I want to accelerate 2 hexes in direction B and rotate one facing clockwise to point in direction C, I would:

  1. Calculate thrust levels, etc. [let's assume everything is fine, for illustration's sake];
  2. Write "4" in the left hand side of hex A on the Even graphic (because this value is not being changed this turn, and hence will be the same at the start of the next turn);
  3. Write "2" in the right hand side of hex B on the Odd graphic;
  4. Write "4" in the left hand side of hex B on the Even graphic (because the current "2" plus the "2" acceleration equals "4"), indicating that next turn the ship will have a vector of "4" in direction B (in addition to the "4" in direction A, per #2);
  5. Write "1" in the "Right This" rotation box on the Odd graphic, indicating I am expending rotational thrust to start rotating clockwise at a rate of 1 hex per turn;
  6. Write "1" in the "Right Prev" rotation box of the Even box, indicating that the ship will start the next turn rotating clockwise at the rate of 1 hex per turn;
  7. Write the facing arrow in the center hex, pointing to direction C.

Okay, now I want to stop the clockwise rotation, and accelerate by another "2" in direction B. I would do the folowing:

  1. Wipe/erase the Odd graphic; since it is now an Even turn (turn 4), the Even graphic is the current turn graphic, and the Odd graphic is the future turn graphic;
  2. Calculate thrust levels, etc. [Let's assume everything is fine, for illustration's sake];
  3. Write "4" in the left hand side of hex A on the Odd graphic (because this value is not being changed this turn, and hence will be the same at the start of the next turn);
  4. Write "2" in the right hand side of hex B on the Even graphic;
  5. Write "6" in the left hand side of hex B on the Odd graphic (because the current "4" plus the "2" acceleration equals "6"), indicating that next turn the ship will have a vector of "6" in direction B (in addition to the "4" in direction A, per #3);
  6. Write "1" in the "Left This" rotation box on the Even graphic, indicating I am expending rotational thrust in the counterclockwise clockwise direction. [If the ship were not rotating, this would be sufficient to start a counterclockwise rotation at a rate of 1 hex per turn. Since the ship is already rotating clockwise, it is sufficient to STOP the current rotation, levaing the ship facing direction C.];
  7. Write *nothing* in the rotation boxes of the Odd box, indicating that the ship will start the next turn with no rotation;
  8. Write the facing arrow in the center hex, pointing to direction C (because rotation stopped in #6).


Advanced Rotation Variant: In the above examples, rotation is recorded as facing changes per turn, with a "1" meaning a rotational speed of one hexside per turn, etc.. There is no reason, however, why rotatational thrust has to be applied it neat little bundles equivalent to the amount needed to turn a full hexside. Instead, players could record the amount of thrust applied, and allow fractional increments.

For example, if it takes "10" thrust to start the ship rotating at a speed of one hexside per turn, a player allocating "15" thrust would start the ship rotating at a speed of 1.5 hexes per turn. The facing of the ship would change for only when the amount of rotation accumulated was equal to or greater than "10"; the first turn the ship would rotate 1 hexiside (with "5" left over), but the next turn the ship would rotate 2 hexsides (because 5+15=20, and 20/10=2).


What games can VMS be used with?

Due to differences of time and distance scales, some systems are better candidates for using the VMS than others. There are two things to keep in mind:

  1. Is facing important in the game? If no, then the rotation part of Vector Movement System is unnecessary, although the course notation system may still be useful.
  2. Does the background of the game suggest that vector movement is appropriate?
In the Star Trek universe, for example, ships are equipped with warp drives which do not work on Newtonian principles of thrust and inertia. Whether or not you believe in the likelihood of a warp drive ever being developed, Star Trek ships wouldn't be expected to use vector-type movement, so the lack of vector movement for a Star Trek game is not a problem.

Similarly, I see no reason to adopt vector movement in a Star Wars game, either. While George Lucas has not presented us with a (pseudo-)scientific rationale such as "warp drive" for the lack of vector movement in Star Wars, it is clear that the "look and feel" of the Star Wars universe is such that vector movement is inappropriate.

There are several games, however, that I think are good candidates for use with the Vector Movement System. They are:

  • Agents of Gaming Babylon 5 Wars, both because the attempt (albeit sometimes failed) at scientific accuracy on the show suggests vector movement, and because the extremely short time scale (5-10 seconds per turn) and short distance scale (each hex is a couple of kilometers) mean that facing changes are both extremely important and last the entire phase.
  • Two of FASA's Renegade Legion games, Interceptor and Leviathan. It is clear from the background essays and the movement rules that ships in the RL universe are intended to move according to the principles of vector movement -- I suspect FASA thought that a true vector movement system would be too complicated.
  • GDW's Battle Rider and Brilliant Lances. These games already use vector movement, but I think that the VMS would be easier, especially with Brilliant Lances. Note that facing is not an issue in these games, because of the large timescale (half-hour turns, plenty of time to change orientation and get off some shots), and because the ships are assumed to be slowly rotating about their axis of flight, allowing all batteries to bear. This means that the VMS rotation rules would not be needed.

What's next?

While we haven't worked on it in a while, I still consider this to be a work in progress. I'd like to improve the quality of the rules, prose, and HTML as time permits.

Note that it would be easy to add 12 position facing (e.g., hex corners as well as hex sides), because the facing is handled independently of movement. 12 position thrust expenditures, however, would take some careful thought.

Arius and I are not sure what our next VMS project will be. There are plenty of games out there that could be made better by adding vector movement to them. Some I have already mentioned, such as GDW's Brilliant Lances or FASA's Renegade Legion games. A couple of other FASA games, such as Aerotech and Battlespace), also are good candidates. Or, we might take a shot of designing a game from the ground up -- Arius would like us to develop our own background, while I'm particularly interested in doing a tactical game based on either Steve Gallacci's Albedo or C. J. Cherryh's Downbelow Station. [These are, of course, copyrighted works, of course, and we could not and would not distribute any games based on them without permission from the authors.]

VMS Components and Files

Download the VMS variant for B5W [PDF (143k)], last updated 8/25/97.

Playtesters

Arius and I would like to thank Michael Brown, Mark Everhart, Carl Harris, and Josh Wise for their input and playtesting on the Babylon 5 Wars variant of the Vector Movement System.
Disclaimer Many of the products mentioned on my web pages are Registered Trademark of their respective owners. Original material Copyright by their respective owners. All Rights Reserved. Used without permission. Any use of copyrighted material or trademarks in this file should not be viewed as a challenge to those copyrights or trademarks, and is done for the purpose in increasing the attention (and hopefully sales) of those products. The Vector Movement System is a replacement for, not a derivation of, parts of the works presented on this page.


NOTE: Feedback is always welcome, including questions about VMS: caw@kentaurus.com.