Re: Designer's Notes: Vector Movement

Seconded.

Re: Designer's Notes: Vector Movement

Not sure I understand why this does not constitute "vector" movement.

A vector is a mathematical expression of magnitude and direction. In this system, every ship has a speed (magnitude) and heading (direction). The limitations on a ship's movement are based on the amount of thrust required to change from one vector to another. (e.g. if a ship starts the turn traveling 3 hexes/turn to the "north" and ends moving 4 hexes/turn to the "south", the amount of thrust applied was 3 + 4 = 7.)

The fact that the actual math is hidden from players, or that for simplicity's sake a ship's facing always equals its heading (absent the optional "pivot" rule), doesn't mean the system is any less vector-based (which is typically how I refer to it). But to call it "momentum-based" or "airplanes in space" doesn't really encompass what's going on -- IMHO, of course.

Regarding the 30* changes in heading/facing, I think it could be done -- it would, however, wreak havoc on firing arcs...

Daniel Kast
Majestic Twelve Games
cricket@mj12games.com

Re: Designer's Notes: Vector Movement

cricket wrote:

Not sure I understand why this does not constitute "vector" movement.

Technically the way airplanes move is vector mechanics too - there's a thrust vector, a lift vector, a gravity vector, and drag, which is effectively a negative modifier applied to the first two.  (This is a simplification that makes my aeronautical engineering friends reach for something strong to drink...)

A vector is a mathematical expression of magnitude and direction. In this system, every ship has a speed (magnitude) and heading (direction). The limitations on a ship's movement are based on the amount of thrust required to change from one vector to another. (e.g. if a ship starts the turn traveling 3 hexes/turn to the "north" and ends moving 4 hexes/turn to the "south", the amount of thrust applied was 3 + 4 = 7.)

In the context of space combat games, a vector movement system is a system where the vectors of travel are completely independent of the ship's facing.  A ship's direction of thrust IS tied to its facing (usually), and changing facing is used to rotate the ship, generate thrust, and create a vector in a different direction, with those vectors being added together and consolidated.

Your system conflates direction of thrust-and-facing to direction-of-travel as a simplification, as a way to minimize record keeping, and does not produce an actual Newtonian vector solution.  It does teach players how to maneuver with momentum.

(Your system is like Mode 1 movement in Squadron Strike, vector movement is Mode 2.  Your original, momentum-less movement system is equal to Mode 0 movement in SS.  AV:T would be Mode 3, since it's vectors, plus continuous thrust over time scales less than a turn, and tracks fuel mass fractions and their impact on thrust.)

The fact that the actual math is hidden from players, or that for simplicity's sake a ship's facing always equals its heading (absent the optional "pivot" rule), doesn't mean the system is any less vector-based (which is typically how I refer to it). But to call it "momentum-based" or "airplanes in space" doesn't really encompass what's going on -- IMHO, of course.

If someone can add or subtract their thrust rating from their current velocity by using the STRAIGHT AHEAD maneuver, why can't they move backwards?  This is something that a vector movement system WOULD allow. 

If I have a vector of 12 in map direction A and apply a thrust of 3 in direction C (120 degrees off), I will end up with a vector of 9 in A and 3 in B....and my ship (assuming I have one thrust direction capable of moving the ship), will be facing direction C while I do this.  This is another thing a vector movement system allows, and yours does not.

Vector movement with Newton's laws is a different experience from what you're providing; you're doing a momentum based movement system.  All I'm quibbling on is the terminology; you're using a privileged frame of reference where the ship's facing directs its momentum, hence momentum-based movement.

By the way - consider renaming your STRAIGHT AHEAD maneuver to APPLY THRUST and SLOW DOWN, while moving the "subtract your thrust from your current speed" to SLOW DOWN and make it a fourth maneuver order.  I say this because it took my third read through the rules to realize that STRAIGHT AHEAD would slow me down before I caught it, and I was actively looking for "OK, so I can't turn when my speed is higher than my thrust, how the hell do I slow down?" 

Regarding the 30* changes in heading/facing, I think it could be done -- it would, however, wreak havoc on firing arcs...

Not really - your old 12-point firing arc system where you listed arc letters is 30 degree firing arc resolution.  Your nomenclature was interesting; I'd done it as 12-o-clock-is-forward and going clockwise around the base, because most people remember "He's on your 6!  He's on your 6!" from WWII movies. smile

It does add an extra hex counting step - is the target 3x as far away in one map direction as its adjacent one.  If so it's in a cardinal map direction, otherwise it's on a spine. 

You could be referring to the firing arc penalty that's part of yourcolumn shift dice system, but I strongly suspect that that's solvable.

I'd also seriously think about referring to these not as -1 and -2 modifiers, but as "column shifts".  I'd also set your convention to the base shift as the left most column and make all the shifts go in the same direction, rather than your current minus-and-plus system.  It saves a type of math step at the table.

Re: Designer's Notes: Vector Movement

Ken_Burnside wrote:
cricket wrote:

Not sure I understand why this does not constitute "vector" movement.

Technically the way airplanes move is vector mechanics too - there's a thrust vector, a lift vector, a gravity vector, and drag, which is effectively a negative modifier applied to the first two.  (This is a simplification that makes my aeronautical engineering friends reach for something strong to drink...)

A vector is a mathematical expression of magnitude and direction. In this system, every ship has a speed (magnitude) and heading (direction). The limitations on a ship's movement are based on the amount of thrust required to change from one vector to another. (e.g. if a ship starts the turn traveling 3 hexes/turn to the "north" and ends moving 4 hexes/turn to the "south", the amount of thrust applied was 3 + 4 = 7.)

In the context of space combat games, a vector movement system is a system where the vectors of travel are completely independent of the ship's facing.  A ship's direction of thrust IS tied to its facing (usually), and changing facing is used to rotate the ship, generate thrust, and create a vector in a different direction, with those vectors being added together and consolidated.

Your system conflates direction of thrust-and-facing to direction-of-travel as a simplification, as a way to minimize record keeping, and does not produce an actual Newtonian vector solution.  It does teach players how to maneuver with momentum.

(Your system is like Mode 1 movement in Squadron Strike, vector movement is Mode 2.  Your original, momentum-less movement system is equal to Mode 0 movement in SS.  AV:T would be Mode 3, since it's vectors, plus continuous thrust over time scales less than a turn, and tracks fuel mass fractions and their impact on thrust.)

The fact that the actual math is hidden from players, or that for simplicity's sake a ship's facing always equals its heading (absent the optional "pivot" rule), doesn't mean the system is any less vector-based (which is typically how I refer to it). But to call it "momentum-based" or "airplanes in space" doesn't really encompass what's going on -- IMHO, of course.

If someone can add or subtract their thrust rating from their current velocity by using the STRAIGHT AHEAD maneuver, why can't they move backwards?  This is something that a vector movement system WOULD allow. 

If I have a vector of 12 in map direction A and apply a thrust of 3 in direction C (120 degrees off), I will end up with a vector of 9 in A and 3 in B....and my ship (assuming I have one thrust direction capable of moving the ship), will be facing direction C while I do this.  This is another thing a vector movement system allows, and yours does not.

Vector movement with Newton's laws is a different experience from what you're providing; you're doing a momentum based movement system.  All I'm quibbling on is the terminology; you're using a privileged frame of reference where the ship's facing directs its momentum, hence momentum-based movement.

By the way - consider renaming your STRAIGHT AHEAD maneuver to APPLY THRUST and SLOW DOWN, while moving the "subtract your thrust from your current speed" to SLOW DOWN and make it a fourth maneuver order.  I say this because it took my third read through the rules to realize that STRAIGHT AHEAD would slow me down before I caught it, and I was actively looking for "OK, so I can't turn when my speed is higher than my thrust, how the hell do I slow down?" 

Regarding the 30* changes in heading/facing, I think it could be done -- it would, however, wreak havoc on firing arcs...

Not really - your old 12-point firing arc system where you listed arc letters is 30 degree firing arc resolution.  Your nomenclature was interesting; I'd done it as 12-o-clock-is-forward and going clockwise around the base, because most people remember "He's on your 6!  He's on your 6!" from WWII movies. smile

It does add an extra hex counting step - is the target 3x as far away in one map direction as its adjacent one.  If so it's in a cardinal map direction, otherwise it's on a spine. 

You could be referring to the firing arc penalty that's part of yourcolumn shift dice system, but I strongly suspect that that's solvable.

I'd also seriously think about referring to these not as -1 and -2 modifiers, but as "column shifts".  I'd also set your convention to the base shift as the left most column and make all the shifts go in the same direction, rather than your current minus-and-plus system.  It saves a type of math step at the table.

Dan, it may be pure semantics, but in my experience people either love or hate "Vector" movement as Ken has defined (and I for what it's worth agree with). I think if you say that Starmada:Whateverthehellthenexteditioniscalled has a Vector-based movement system, there are some people who will A.) Find reason to complain that Starmada doesn't use Vector movement as they know it, so they are upset, or B.) I don't like Vector movement, so I will continue to use the "old" rules from S:AE, or maybe even C.) I don't like Vector based games so I'm not going to buy that Starmada thing.
On the other hand, omit the term "Vector" and insert "Momentum", and I think there is something different for people to check out. I'm sure there will still be people that implement their own "true vector" system within the rules or don't buy it because it's not "their kind of game", but to me it just sound more right.
Course, I'm probably wrong smile
Cheers,
Erik

Re: Designer's Notes: Vector Movement

Blacklancer99 wrote:

Dan, it may be pure semantics, but in my experience people either love or hate "Vector" movement as Ken has defined (and I for what it's worth agree with). I think if you say that Starmada:Whateverthehellthenexteditioniscalled has a Vector-based movement system, there are some people who will A.) Find reason to complain that Starmada doesn't use Vector movement as they know it, so they are upset, or B.) I don't like Vector movement, so I will continue to use the "old" rules from S:AE, or maybe even C.) I don't like Vector based games so I'm not going to buy that Starmada thing.

Worse, they could think it's => http://www.adastragames.com/products/adastra/av.html and hate when they discover Starmada is simple and easy to play.  big_smile

Marc

Re: Designer's Notes: Vector Movement

madpax wrote:
Blacklancer99 wrote:

Dan, it may be pure semantics, but in my experience people either love or hate "Vector" movement as Ken has defined (and I for what it's worth agree with). I think if you say that Starmada:Whateverthehellthenexteditioniscalled has a Vector-based movement system, there are some people who will A.) Find reason to complain that Starmada doesn't use Vector movement as they know it, so they are upset, or B.) I don't like Vector movement, so I will continue to use the "old" rules from S:AE, or maybe even C.) I don't like Vector based games so I'm not going to buy that Starmada thing.

Worse, they could think it's => http://www.adastragames.com/products/adastra/av.html and hate when they discover Starmada is simple and easy to play.  big_smile

Marc

lol Nice picture on that page. lol
What happens when you get Three Cruiser Houses or a Destroyer Hotel on Fleet Street?

Paul

Re: Designer's Notes: Vector Movement

Marc, I've been very careful to be friendly and polite, and not knock other people's choices in games.  I'm offering my opinions to help Dan make the best version of HIS game that he can, including clarifying terminology.

I hear from people who come to Squadron Strike from Starmada.  Indeed, I first heard about this re-design from customers who said "Well, it looks like your only competition for "Design everything in the game" product space is abandoning it."  I'm glad that's not the case.

No single game can meet the needs of every gamer.  I direct people to Starmada and Colonial Battlefleet on a regular basis on TMP and SCN, even though I publish a competing product.  As long as we're all blowing up spaceships, we all win.  I try to encourage everyone to play everything.

I'm pleased by the streamlining Dan is doing on the repetitive die rolling.  It's a nice, elegant out-of-the-box solution.  I hope that the people who've come to me worried that he's gutting the design engine are proven wrong; Dan's pretty good at this, and the more people playing these games, the more minis (and games) I sell.

May I get the same courtesy in return, please?

Re: Designer's Notes: Vector Movement

Ken_Burnside wrote:

Marc, I've been very careful to be friendly and polite, and not knock other people's choices in games.  I'm offering my opinions to help Dan make the best version of HIS game that he can, including clarifying terminology.

And the effort is appreciated.

I first heard about this re-design from customers who said "Well, it looks like your only competition for "Design everything in the game" product space is abandoning it."  ... I hope that the people who've come to me worried that he's gutting the design engine are proven wrong;

I find this odd... certainly, I expected there would be those who disagree with some of the choices being made in the new edition. But I'm at a loss to figure out where people would get the impression that I'm "abandoning" the design-anything-you-want approach... ?

As long as we're all blowing up spaceships, we all win.  I try to encourage everyone to play everything ...
May I get the same courtesy in return, please?

Hear,  hear.

Daniel Kast
Majestic Twelve Games
cricket@mj12games.com

Re: Designer's Notes: Vector Movement

Any vague guess at a release date?

And I've been thinking of getting some of the Starmada/ADB stuff.  How will this be impacted by the new rules?

Re: Designer's Notes: Vector Movement

Sorry Ken, I really don't understand why you reacted to my message this way. I was just joking about the term 'vector', not about what you said, and surely not about you, G.od forbids.

And I agree with you, what Dan presented to us currently is very interesting. Other than that, I've been reading what you wrote, neither agreeing nor disagreeing (neither understanding a lot too  big_smile ), but what Dan designed with the new edition is very neat and simple. Of course, it could be improved, but at what cost.

Marc

Re: Designer's Notes: Vector Movement

Ken_Burnside wrote:

Your system conflates direction of thrust-and-facing to direction-of-travel as a simplification, as a way to minimize record keeping, and does not produce an actual Newtonian vector solution.  It does teach players how to maneuver with momentum.

Point taken. In the end, I have no quibbles really with what it's called, since in the actual rules, it's just "Movement". smile

If someone can add or subtract their thrust rating from their current velocity by using the STRAIGHT AHEAD maneuver, why can't they move backwards?  This is something that a vector movement system WOULD allow.

A ship could move "backwards" with a negative speed value and the rules would remain unchanged. It would require an allowance for what happens when a ship switches from a negative to a positive speed. Perhaps this:

A ship with a negative speed value moves backwards, instead of forwards. In all other respects, its movement is unchanged. A ship may switch from negative to positive speed (or vice versa) only when executing a "Straight Ahead" maneuver. When doing so, the difference between the starting speed and ending speed cannot exceed the ship's thrust rating.

For example, a ship with a thrust rating of 5 and a current speed of -2 carries out a "Straight Ahead" maneuver. It can either (a) remain motionless, with a speed of zero; (b) move backwards between 1 and 7 hexes, or (c) move forward between 1 and 3 hexes.

Regarding the 30* changes in heading/facing, I think it could be done -- it would, however, wreak havoc on firing arcs...

Not really - your old 12-point firing arc system where you listed arc letters is 30 degree firing arc resolution.  Your nomenclature was interesting; I'd done it as 12-o-clock-is-forward and going clockwise around the base, because most people remember "He's on your 6!  He's on your 6!" from WWII movies. smile

I think what I meant was, what the "FF" arc looks like when a ship is facing a hex side is different than what it looks like when facing a hex corner.

I'd also seriously think about referring to these not as -1 and -2 modifiers, but as "column shifts".  I'd also set your convention to the base shift as the left most column and make all the shifts go in the same direction, rather than your current minus-and-plus system.  It saves a type of math step at the table.

Not sure I follow the  "set your convention to the base shift" part of your suggestion...

Daniel Kast
Majestic Twelve Games
cricket@mj12games.com

Re: Designer's Notes: Vector Movement

cricket wrote:
Ken_Burnside wrote:

I'd also seriously think about referring to these not as -1 and -2 modifiers, but as "column shifts".  I'd also set your convention to the base shift as the left most column and make all the shifts go in the same direction, rather than your current minus-and-plus system.  It saves a type of math step at the table.

Not sure I follow the  "set your convention to the base shift" part of your suggestion...

I think what he may mean is have it so most, if not all shifts, are one direction.
At a bare minimum you could have close range be the default column, with medium range being -1, and long range being -2.
Instead of the +1, 0, and -1 mods that they are now.
Kevin

Re: Designer's Notes: Vector Movement

Your clever 1/SQRT2 method lays out your dice in columns, like this:

8-6-4-3-2-1-1-1

You refer to things as having a -N modifier, where -N determines how many columns you shift to the right.  A -2 shift takes a weapon/battery with 6 dice and moves them down to 3 dice.  It is not subtracting two dice (which is what I'd think of first), nor is it subtracting 2 from the total on the dice (which is what I'd think of second), nor is it subtracting 2 from the result of each die (which is what I'd think of third).

It's saying "Shift 2 columns right."  I'd be tempted to make the convention N> for right shifts, and N< for left shifts, and explicitly call them column shifts. 

I would also try to make sure that the unmodified use of the weapon used the leftmost column, and make sure that ALL of the column shifts went right.

So instead of this:

Medium Range is just the arc modifier, short range is the arc modifier plus 1, and long is the arc modifier minus 1

I'd make it like this:

Short range is the arc modifier, medium range is the arc modifier with a shift of 1>, and long range is the arc modifier with a shift of 2>

While it's a small amount of overhead to shift left by one, and shift right by two, rather than shift right by one, having only one kind of shift to think of ("all modifiers shift to the right") is less overhead overall.

I make more complicated games than you do, so I tend to focus on every bit of player aid and mental overhead reduction that I can get.   

We went to the "always shift right" nomenclature for SITS and its missile defenses, which uses a "tally up modifiers, add die roll, to find column header, cross reference missiles with column to see what's still alive." system for dealing with David Weber's umpteen zillion missiles blotting out the sun combat scenes, and your attack roll system is thematically similar.

Did you consider using the Decibel/Richter scale for this for increased granularity?  That one has the advantage that +3 steps is a factor of 2 and +10 steps is a factor of 10.  If you're not familiar with it and are interested, I'll walk you through the numbers.  (I use it for population level mapping in Squadron Strike campaign games.)  It would probably multiply the length of your tracks by 50%; I'm not certain, given the scale of game you're making, that the granularity it gives is worth the extra printed space on the ship sheet.

Re: Designer's Notes: Vector Movement

madpax wrote:

Sorry Ken, I really don't understand why you reacted to my message this way. I was just joking about the term 'vector', not about what you said, and surely not about you, G.od forbids.

Y'all are aware that I wrote that game that you claim isn't fun and enjoyable? smile   It still sells well. smile

And I agree with you, what Dan presented to us currently is very interesting. Other than that, I've been reading what you wrote, neither agreeing nor disagreeing (neither understanding a lot too  big_smile ), but what Dan designed with the new edition is very neat and simple. Of course, it could be improved, but at what cost.

I'm not even suggesting he change the movement mechanics - I'm just suggesting some terminology differences, both in the name of the system, and in terms for movement orders.

I'm also possibly pointing out a way to let ships move in reverse if he wants them to - I'm not sure he does.  I know that movement in reverse in SFB (with a larger map to play in) is a balance problem, and I explicitly forbid it in Mode 1 movement in SS for that reason specifically.

Re: Designer's Notes: Vector Movement

cricket wrote:
Ken_Burnside wrote:

Marc, I've been very careful to be friendly and polite, and not knock other people's choices in games.  I'm offering my opinions to help Dan make the best version of HIS game that he can, including clarifying terminology.

And the effort is appreciated.

One of your ardent fans turned discussions about my products into a flame war about how Starmada renders every other form of entertainment not related to the propagation of the species obsolete...in about four forums in 2005.  This irritated me enough to write Squadron Strike, rather than say "With FT and Starmada, there's no real reason to go after that market segment."  Turns out there is a market there, and it's made me some money.

Least I can do is pay it forward and try to help you make better games.  These are games, not religions.

Though I did have a campaign game that ran Mode 2 versus Mode 1, where the three Mode 2 players formed a grand alliance, called the Newtonian Jihad. 

"We must cleanse the universe of those who do not follow our holy laws.  Of physics."

I first heard about this re-design from customers who said "Well, it looks like your only competition for "Design everything in the game" product space is abandoning it."  ... I hope that the people who've come to me worried that he's gutting the design engine are proven wrong;

I find this odd... certainly, I expected there would be those who disagree with some of the choices being made in the new edition. But I'm at a loss to figure out where people would get the impression that I'm "abandoning" the design-anything-you-want approach... ?

Starmada was really the first game that made a useable "design your own weapons" system.  The discussion on your modification of attack and damage rolls really does read like "We're throwing out all the nifty crunchy weapon design abilities" for someone on a casual read through.  I look forward to the final result when you're done.

As long as we're all blowing up spaceships, we all win.  I try to encourage everyone to play everything ...
May I get the same courtesy in return, please?

Hear,  hear.