Topic: Designer's Notes: Vector Movement

In this second mini-article related to design choices in the new edition of Starmada, we'll take a look at the movement system, and how it reflects the "reality" of movement in a frictionless environment. Technically, the movement system is unchanged from Starmada: The Admiralty Edition. Ships will still be able to maneuver in exactly the same ways as they could in SAE. However, the process by which players determine the movement of their ships has been streamlined, hopefully making the game more fluid and easier to understand.

There are a few assumptions underlying this system:

1) A thrust of 1 represents enough force to accelerate a ship by one hex per turn. Also, thrust is applied immediately, meaning that a ship accelerating from stop to 3 hexes/turn moves three hexes. (If thrust were applied evenly throughout the turn, a ship that accelerates from 3 to 7 hexes/turn would only move five hexes.)

2) The direction in which a ship is facing indicates the direction of travel. Strictly speaking (as anyone who watched fighters zip about in the Babylon 5 TV show could tell you) it is possible for spacecraft to apply thrust in one direction and then spin around to face the opposite direction. However, to simplify record-keeping, it is assumed that a ship's heading and its facing are always the same. (The "Pivots" optional rule changes this.)

3) The amount of thrust required for a ship to complete a given maneuver is determined by comparing its vector at the start of the turn with its vector at the end of the turn. (A ship's "vector" is the combination of its speed and its heading.)

So much for the philosophical underpinnings -- let's get to the actual process. In order for this to work, it is necessary to keep track of each ship's speed. This was done in SAE by writing it on each ship's data card; in the new edition, we introduce "speed markers". Either method works fine.

To determine a ship's movement options, compare its speed to its thrust rating. There are three possible types of move, or "Maneuvers". If the ship's speed exceeds its thrust, it may only perform a "Straight Ahead" maneuver; otherwise it can perform any of the three:

1) STRAIGHT AHEAD: The ship MUST move a number of hexes equal to its speed minus its thrust (to a minimum of zero), and MAY move a number of hexes equal to its speed plus its thrust. The ship cannot turn.

2) COME ABOUT: The ship has no minimum move requirement, and MAY move a number of hexes equal to its thrust. The ship must turn once during its move.

3) REVERSE COURSE: The ship has no minimum move requirement, and MAY move a number of hexes equal to its thrust minus its speed. The ship must turn two or three times during its move.

As an example, if a ship has a speed of 3 and a thrust of 5, it can do one of three things:

STRAIGHT AHEAD: Move between zero and 8 hexes, making no turns.
COME ABOUT: Move between zero and 5 hexes, making one turn.
REVERSE COURSE: Move between zero and 2 hexes, making two or three turns.

However, if the ship has a speed of 5 and a thrust of 3, it can only do one thing:

STRAIGHT AHEAD: Move between 2 and 8 hexes, making no turns.

A ship's new speed is equal to the number of hexes moved. That's it!

Daniel Kast
Majestic Twelve Games
cricket@mj12games.com

Re: Designer's Notes: Vector Movement

I like it sounds great, love the new movement system.

Will there be optional rules for cinematic movement?
This method, is best for new players at conventions.

Re: Designer's Notes: Vector Movement

Inari7 wrote:

Will there be optional rules for cinematic movement?

Yes.

Daniel Kast
Majestic Twelve Games
cricket@mj12games.com

Re: Designer's Notes: Vector Movement

PERFECT!

Re: Designer's Notes: Vector Movement

I had the opportunity to play this afternoon.
Although I played with SAE combat rules (I don't enough about S NE to play with anything than movement rules as exposed here), AFAIK, it should look like the S NE movement rules.
Before saying anything else, THEY ARE FINE!
A bit arduous to explain to my friend; she has already played wargames, mainly with ancien/fantaisy armies, but never space battle so was a bit wondering what to do with ships, rules, sheets.. but she just needed to play to understand how it worked.
For the information, We used my personnal SFU ship sheets, and it looked very fine. 1500 points of ships each (the price are different from Klingon Armada), meaning 1 fed DN, BC, CA, CC, CF, DD and a kzinti FF for her, 1 klingon BC, D7C, 2 D7, 2 F5 (renamed E5), 2 rom Sparrowhawk, one skyhawk and one seahawk.
We didn't track the number of turns played, ended with both our fleets retraiting (more than 750 points of ships dead at the end of the same turn). We played on a hex-less map and not having to write order was a plus. Movements were done easily and fast.

I supose that we could save a lot of play time with the  S NE combat rules.

Just for the info (especially for the problem for moving invisible units), as we played on a hex-less map without writing orders, I played cloaked ships like this:
- They always move last.
- They may not fire nor may they be fired upon.
Of course, the opponent can track their move, but romulan ships need to cloak only during the turn they may not fire their plasma. Of course, they could cloak just to move closer to the enemy, but they usually have longer ranged weapons and shouldn't need to do that.

I didn't take photos, but I will try to do that whenever there will be sun.

Marc

Re: Designer's Notes: Vector Movement

Awesome!
I like the ability to turn at any part of the movement; that all ships in a line-ahead formation can turn in the same spot, not have to turn at the same time.  This allows ships in a Line-ahead formation to turn and maintain the line-ahead formation.  When I use my naval-style ships this will great.

Re: Designer's Notes: Vector Movement

(Some of this is restated from a previous email conversation with Dan.)

I REALLY like this system.

I will argue for a slight modification: allow 2 OR MORE turns in the third category (what you've called "reverse course"). This would give a ship with plenty of engines a much wider range of ending hexes and allow for fancy weaving around any terrain.

Is it realistic? Hard to say -- this system doesn't really model what happens within a turn.

Also, I have concerns about the term "come about". It's not really accurate either the way it was used before (which is common in sci fi) or the new way; it has to do with the direction of the wind. Changing it from the old meaning could confuse some players. If you're going to use it incorrectly, you should at least be consistent. Alternately, you could simply not introduce any terminology.

So I'd argue for:

TURNS     MIN     MAX
0         s-t     t+s
1         0       t
2+        0       t-s

where s is speed and t is thrust. A ship may not turn if s > t.

Re: Designer's Notes: Vector Movement

This doesn't sound like vector movement at all. Why must a ship exceeding its thrust only go in a straight line? It would turn widely if it was going so fast relative to its thrust, but it certainly would not be limited to a straight line.

I don't think I like the idea  of a ship having to spend an entire turn doing nothing but decelerate before it can make even a minor course adjustment.

Re: Designer's Notes: Vector Movement

Ozymandias wrote:

This doesn't sound like vector movement at all. Why must a ship exceeding its thrust only go in a straight line? It would turn widely if it was going so fast relative to its thrust, but it certainly would not be limited to a straight line.

True, but such a wide turn is impossible to (simply) model on a hexgrid. See below.

I don't think I like the idea  of a ship having to spend an entire turn doing nothing but decelerate before it can make even a minor course adjustment.

The problem is the hexgrid, which sets the minimum course adjustment at 60*. If a ship is traveling 500m/s, and wants to alter its course by 60*, it must expend enough thrust to accelerate to 500m/s in a direction 120* off of its current course. Thus, if a ship's speed exceeds its current thrust, it cannot accelerate fast enough to complete a 60* turn in a single movement phase.

This is the same principle that underlies the existing movement system, and can be offset with the Delayed Turns option (D.2).

Daniel Kast
Majestic Twelve Games
cricket@mj12games.com

Re: Designer's Notes: Vector Movement

One problem about that comes from the fact that in the game, contrary to 'in space' movement and direction are tied and identical. But Pivot from S AE were used to 'counter' a bit that. On the other hand, I never fully understand how pivot (with overthrusters or not) were applied...

Marc

Re: Designer's Notes: Vector Movement

Hmm I see the problem.

How's about this for an alternative: ship would move forward equal to its velocity, and then could use its thrust to move itself  anywhere within its thrust rating of that end point. This wouldn't have to change its facing if you're set on ships facing their direction of travel. The current velocity would be equal to the distance from the final end point to the start point, and the facing could snap to the nearest hex facing along the vector between origin and end point.

This would let us perform those wide sweeping turns at high velocity and sounds almost as simple?

Re: Designer's Notes: Vector Movement

Ozymandias wrote:

Hmm I see the problem.
How's about this for an alternative: ship would move forward equal to its velocity, and then could use its thrust to move itself  anywhere within its thrust rating of that end point. This wouldn't have to change its facing if you're set on ships facing their direction of travel. The current velocity would be equal to the distance from the final end point to the start point, and the facing could snap to the nearest hex facing along the vector between origin and end point.
This would let us perform those wide sweeping turns at high velocity and sounds almost as simple?

Have you actually played any games using the new movement system?
If not, I'd urge you to actually try using it before offering any "fixes."  wink
There's nothing broken about it.

From my perspective, I didn't play much S:AE, so I never really developed an appreciation for the movement system in that edition. It seemed kind of convoluted, and not easy to understand.
This one, on the other hand, is so simple to use, the more I play the more I like it.
We've still not found it easy to make high thrust work as a primary factor in ship design, but I wouldn't play the game using any other movement system.
Kevin

Re: Designer's Notes: Vector Movement

mundungus wrote:

(Some of this is restated from a previous email conversation with Dan.)
I REALLY like this system.
I will argue for a slight modification: allow 2 OR MORE turns in the third category (what you've called "reverse course"). This would give a ship with plenty of engines a much wider range of ending hexes and allow for fancy weaving around any terrain.
Is it realistic? Hard to say -- this system doesn't really model what happens within a turn.
Also, I have concerns about the term "come about". It's not really accurate either the way it was used before (which is common in sci fi) or the new way; it has to do with the direction of the wind. Changing it from the old meaning could confuse some players. If you're going to use it incorrectly, you should at least be consistent. Alternately, you could simply not introduce any terminology.
So I'd argue for:

TURNS     MIN     MAX
0         s-t     t+s
1         0       t
2+        0       t-s

where s is speed and t is thrust. A ship may not turn if s > t.

I really like it also, and based on our playtesting, we've found that needing more than three turns in any given movement phase is fairly rare.
Mostly becuse you're (usually) not wanting to do a lot of maneuvering above a ship's thrust rating.
It's just not very efficient.
Kevin

Re: Designer's Notes: Vector Movement

cricket wrote:

The problem is the hexgrid, which sets the minimum course adjustment at 60*.

Oh, I dunno. Saganami Island, Attack Vector: Tactical and Birds of Prey do 30* turns. smile

Re: Designer's Notes: Vector Movement

Have you actually played any games using the new movement system?
If not, I'd urge you to actually try using it before offering any "fixes."   
There's nothing broken about it.

I'm pretty sure he expects comments, criticism and concerns about these new changes, as there are many in all of these threads. Obviously 90% of the people commenting haven't played with them, as they are not out yet.

All I can do is compare the rules as described to the many movement rules I've used in the past and point out things that seem problematic to me.

There isn't anything "broken" about the movement system as proposed, but all vector movement rules lie somewhere on the spectrum between ease of play and realism. I happen to not like where on the line being completely unable to turn at even relatively low speeds lands on that line.

Just as an example, in a recent game of full thrust I played I had thrust 4 ships going at 14 velocity. In these rules as I understand them (from what's written in OP) I'd have to spend 3 entire turns decelerating before I could deviate from a straight line a single hex.

Re: Designer's Notes: Vector Movement

Dan -- any plans to account for (or allow) side-slips?

Re: Designer's Notes: Vector Movement

Based on conversations I've had, I believe the new movement system duplicates the system currently used in S:AE.
So nothing is really changing.

I typically have always prefered cinematic movement systems over vector-based systems, as they're simply easier and less cumbersome to use. I've found this new one to be really easy. I guess we can debate just how fast a ship needs to be going before it can't turn, based on the time scale of a game turn, but that probably won't matter. As again, I believe the new system is trying to model the existing system.

Your observations about not being able to turn in the Full Thrust game are true, if the ships would have had a thrust of four or less. I use the basic cinematic movement in my Full Thrust games, so I can't vouch for how the vector system in More Thrust works. But the bottom line is that, in the new Starmada system, any kind of effective maneuvering is going to need to be done at speeds of thrust rating or slower.
I think this is a neat effect, and introduces a certain amount of maneuvering tactics, but may be a little too slow for some people.
Kevin

Re: Designer's Notes: Vector Movement

KDLadage wrote:

Dan -- any plans to account for (or allow) side-slips?

I'm not intending to be the answer man here, but I believe they're currently in the "Advanced Rules."  smile

Re: Designer's Notes: Vector Movement

Ozymandias wrote:

Hmm I see the problem.

How's about this for an alternative: ship would move forward equal to its velocity, and then could use its thrust to move itself  anywhere within its thrust rating of that end point. This wouldn't have to change its facing if you're set on ships facing their direction of travel. The current velocity would be equal to the distance from the final end point to the start point, and the facing could snap to the nearest hex facing along the vector between origin and end point.

This would let us perform those wide sweeping turns at high velocity and sounds almost as simple?

I rather like this.

Re: Designer's Notes: Vector Movement

I'm going to try this out in my next Klingon Armada game with the kids, give a feel of inertia without a lot of record keeping overhead. They'll appreciate not writing movement orders.

Re: Designer's Notes: Vector Movement

Ozymandias wrote:

How's about this for an alternative: ship would move forward equal to its velocity, and then could use its thrust to move itself  anywhere within its thrust rating of that end point.

Actually did toy with this for a bit before drifting back to a modification of the existing AE movement rules.

Perhaps this is an easier solution than the optional "pivot" and "delayed turn" rules.

Daniel Kast
Majestic Twelve Games
cricket@mj12games.com

Re: Designer's Notes: Vector Movement

At first, I didn't understand what Ozylmandias proposed. Then I understood.  big_smile
But, in the end, do you have a table large enough to accomodate this kind of movement?
Usually, when my ship moves faster than its engine value, it doesn't have a lot of time to decelerate and then maneuver. Sometimes, even moving at a speed equal to its engine is dangerous. A single hit on the engine and you lose one turn to maneuver. If ever the ship continues to lose engine points, it can even move outside the table and be lost.

I played with the movement rules proposed here, and they are not only simple, they work!

Marc

Re: Designer's Notes: Vector Movement

Taking a lunch break from our first game using these movement rules bolted on to SAE. The kids have taken to them quickly and not writing move orders has sped things up well. Has made sabre dancing with the Klingons easier to do. (Keep in mind that when playing with the kids  we had been using the simplified movement optional rule)

My oldest son has just learned, rather painfully, that just because his frigates can move most of the way across the board it doesn't mean it is a good idea. My dreadnought just took one out with less than it full complement of weapons and the heavy cruisers will at a minimum put a hurt on the second one.

Re: Designer's Notes: Vector Movement

Could you call this "Momentum-Based Movement" rather than "Vector Movement"?

"Vector Movement" means something fairly specific in this genre of game, and what this is is a nice "Airplanes in space" movement engine, not vector based, where your facing is independent of your direction of travel, and your ability to change velocity doesn't really require you to spin around 180 degrees and slow down.

I don't see anything in this movement rule system that would prevent you from using 30 degree angular resolution for movement if you wanted to.  Perhaps as an option?

Re: Designer's Notes: Vector Movement

Ken_Burnside wrote:

Could you call this "Momentum-Based Movement" rather than "Vector Movement"?

I think this is a great suggestion. Not only would it be a more accurate terminology,  I think it would prevent some confusion as Ken suggests.
Erik