Best Movement System for Starships in Traveller is CORE RAW: Change my Mind.

[Yenaldlooshi]

Back in the day, I tried using the Law of Inertia in old school Mayday by GDW.
I have tried using this same 2D movement on paper maps from Brilliant Lances by GDW
I have tried companion's vectored movement in 2D and the Law of Inertia
I have tried using this same 2D movement using an near infinite map on Roll20.com
I have tried 3D movement using Squadron Strike for Traveller and the Law of Inertia.

After years of trying to make this gameable in the Traveller RPG context, these are my conclusions:

The Z axis realism of 3D is a whole lot of games mechanics-calculating for very little game-joy. Also, your players will probably need to attend a whole-ass clinic hosted by Ad Astra (which they will do in discord) to figure out their system, and theirs is the best system if you want to do this.

2D using the Law of Inertia is fine but here is the paradox; as you make the way the ships move due to inertia more realistic, you make your ability to control their movement less realistic because even an old 1980's PC or your cell phone could calculate intercepts and movements and where to be on the board better than you can by hand on the tabletop. Your Ship's Computer would absolutely do a massively better job of navigating your ship than you. Missile intercepts are next to impossible if you try to include missiles in these movement rules and if you don't include them, then why bother with the ships? Your missiles may be SMART but you will be moving them dumb if you try to just fly them at 10G to their targets which can, with just use a few G's thrust, side step your missiles. Perhaps with TONS of experience from you and your players you can overcome some of these short comings, but in so doing, you stop being RPG players and become full-time miniatures players.

My bottom line: Thrust counting is good enough. A chart with 92 boxes to represent all the thrust counts from Adjacent to Distant range is fine. There typically is no terrain in most of space anyway.

Best to think of the drives not as 1G or 6G drives, but 1 "thrust" or 6 "thrust" drives and say that a "thrust" is an abstract of various types of movement that can either be used for going a certain distance, changing direction, or other fine movement details and just use Core RAW beyond that. I still like to keep missiles and torpedos under this same ruleset though and not just count flight time in the air.


Btw SS:Traveller looks like it is fun, but not for your average RPG'ers.

 

[Arkathan]

My group is used to playing StarFleet A Call to Arms, so they want ships on a table.
I use 1 inch per thrust, and "no inertia." For a smaller table, cm's would work too.
No inertia in quotations, because starting velocity is selected at the start, and thrust is used to change that, depending on the scenario.

Each inch is approximately 1000km, so the range bands convert to inches reasonably well with fudging on short, close and adjacent in order to allow maneuvering to be visible to the players at those ranges.
Missiles travel 10 or 12 inches a turn.

Some tasks involve sneaking past a patrol when going towards an objective, so they choose a direction and speed based on what they have from sensors at long range and move that each turn unless they use thrust, which may alert the patrol.

In Standard engagements the ships move their thrust each turn.

They enjoy the illusion of crunch without the math, while secretly mostly using the change in range band mechanic in a round-about way.

It works for us. Whatever works for you.

 

[collins355]

For me anything similar to the past-present-future position marker vector movement system of Mayday on a hexgrid is the sweetspot.
There is no maths involved. Players soon learn that too big a vector means a long time to slow down and a wide turning circle. High thrust ships are demonstrably more useful.

 

[AnotherDilbert]

My bottom line: Thrust counting is good enough. A chart with 92 boxes to represent all the thrust counts from Adjacent to Distant range is fine. There typically is no terrain in most of space anyway.

Agreed, the characters with Pilot skill are experts in 3D vector math, the players are generally not.

2D vector movement is over the top, unless the players are interested in maths.
1D vector might work, if the players want the feel of inertia.

 

[Sigtrygg]

1D vector pretty much sums up the far superior CT Starter edition range band movement system, you get to keep momentum.

The one pseudo house rule I add is that maneuver g is reduced by the evasion rating chosen,

A 1g ship may accelerate at 1 or evade for 1 but not both.

A 2g ship may accelerate up to 2, or evade up to 2, or split is at 1 acceleration and 1 to evade.

 

[MarcusIII]

For me the 3 markers & hex grid from Mayday is the best I've seen. Mongoose should hire a programmer and make a simple system, No fancy graphics. It can look like Asteroids or the Spacewar! from the early 1960's on a PDP-1.

 

[rinku]

I'm with the OP. Range bands and thrust do the job, which is mostly determining what range two ships or small groups of ships are at.

If a planet is involved, maybe make it a range plane. But that's pretty much as far as you need to go.

In any case, vector systems are themselves oversimplifications of orbital mechanics.

 

[Sigtrygg]

The CT Starter set range band system is far superior to the Mongoose system and is a drop in replacement. The issues I have with the MgT system

variable sized range bands

incorrectly modelling acceleration

momentum is ignored

 

[MonsterX]

I'm with the OP. Range bands and thrust do the job, which is mostly determining what range two ships or small groups of ships are at.

If a planet is involved, maybe make it a range plane. But that's pretty much as far as you need to go.

In any case, vector systems are themselves oversimplifications of orbital mechanics.

Vector systems are simplifications of orbital mechanics, but when you have a ship that can thrust at 1G or more for weeks at a time, the detail you lose is a rounding error. Vector movement is about as close as you need to be to simulate the tactical options available to Traveller spacecraft. (of course, 3D also has some fans, but we live in a flat galaxy, as you can plainly see from Travellermap, and it is just a galaxy wide conspiracy of astronomers that assert that out by us the Milky Way is actually 3000 light years thick. Astrogators know differently)

If ships are all clustered together, all you need is the range between the two clusters, but it doesn't always work that way.

One planet is likely all you get on the map if there are no moons but there are often more around - in a gas giant moon system for example - but also terrestrial planets often have lots of moons. Gas giants are a place where encounters are likely to happen. Being the watering holes of the Traveller universe, it's where pirates hide out waiting for their prey, and in a naval campaign controlling the gas giants is a part of controlling the star system. These maps get really big, which is a problem for manageability - it is ok with VTT but requires a lot of scrolling in and out to see what is going on.

Tactical options in encounters often depend on the vectors of the groups involved - they don't usually start at zero relative to each other - in fact they rarely do.

If ship A is moving towards a planet at 100k/s, while ship B that wants to intercept is in orbit around the planet, do you just suddenly decide that they are now moving zero to do that encounter RAW? Depending on its M drive Ship A could choose to continue decelerating and engage for a longer period before breezing by - or hit the gas instead, and flash by limiting combat to 1 turn and giving Ship A the choice to jump away, accelerate away or assess the battle damage and maybe return to fight more. As Ship A brakes Ship B could hide behind the planet as Ship A flashes by delaying the encounter until Ship A slows down and returns, maybe giving time to build up acceleration to run to 100D. It changes the tactical options a lot, what the starting vectors are and how much thrust the ships have to change those vectors.

The possibilities are so variable that what is the easiest and best way to do it depends a lot on the circumstances of the encounter - and on whether or not this is an encounter you want to representing with a drawn out detailed tactical fight - or whether your game would be better served by rolling a few dice and telling the players whether they've won or lost . Two ship encounters can always be done theater of the mind, IMO, and the set up time means that is usually best. Maybe draw a quick pen and paper picture and explain to the players their options. If there are lots of ships on the map and think the fight's details will advance the game action, I put it on a VTT hex map and use a sort of modified May Day method.