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.

 

[phavoc]

Movement is a complex thing. And the rules themselves contradict things. Since it's not a true simulation I'm fine with 2D thrust w/o vector movement. It actually makes things easier if you take out the concept of inertia and just use ships thrust as their total speed and call it a day. The SFB game made that relatively easy in that your speed was reset to zero at the start of every round and depending on how many points of energy you applied you got that many movement points that turn. Traveller really isn't setup as a wargame-style game, and there are better movement systems out there for modeling starship combat.

I think that's where Traveller could benefit greatly from - having a set of rules created to better model starship combat - keeping it relatively straightforward but also allowing some RPG elements.

 

[Sigtrygg]

Take out inertia and you have Star Wars handbrake turns... innn ssppaaaccceeee

no, just no.

 

[MonsterX]

Take out inertia and you have Star Wars handbrake turns... innn ssppaaaccceeee

no, just no.

Changes the travel time too. Alot. Interplanetary travel becomes impossible with m drives. Even travel to 100d starts to take a long time.

 

[collins355]

Rangeband combat is fine when you have the players' ship and one pirate or patrol vessel duking it out and either closing or receeding.

Rangeband combat rapidly becomes ridiculous when you have multiple vessels, all wanting to head in different directions, from different factions.

Hence, I'm fine if MGT3.0 wants to put rangeband combat in the corebook. For many that will be all they use.

But I still advocate for a different, vector and hexgrid system to be in High Guard for squadron and fleet combat. That way, if you want to resolve the naval combat in Pirates of Drinax, for example, or from the Fifth Frontier War, you've got a toolkit to do it.

 

[NOLATrav]

Siggtrygg’s comments about Starter Trav upthread are well taken, range bands should be consistent, not just arbitrary ever-increasing distances and momentum should carry over.

Also I’ll say again, GURPS Traveller instituted a system of varying turn length based on range. Longer range, longer turn. I’ve built my own home rules for it that stretch from hour-long turns after emerging from jump to personal scale turn lengths at the shortest ranges. Works for us, we’ve had some really great engagements that go from achingly long submarine hunt turns to all out pew-pew-pew shootouts.

 

[Endie]

I love the varying size of the range bands. It opens up the possibility of very short range weapons with tiny engagement envelopes, and those require ships that use them to make other compromises (devote more resources and cost to speed or stealth, for instance), as well as enabling the special-case dogfight rules. It allows stealthy ships to dip in and out of range bands close-in by extending and closing range in order to confuse enemy sensors in the same kind of way that submarines use layers. That may not be instinctively simulationary but it's a game and it is fun. It adds scalability and the good sort of complexity (the sort involving interaction of systems, not "difficult to read"). It helps make for a good game, as proved by the sales.

That said, there are very good reasons to do with both tracking speed and varying sensor ranges why the range bands can be argued to not be equal in size: I find the idea of a set of equal range bands just as arbitrary: what are the odds that one sort of sensor has 5,000km range, another 10,000km, a third 15,000 km etc?

 

[MarcusIII]

There isn't one system that works well or easily for all situations. Range band doesn't work for multiple combatants going all over the place. Nothing works easily with different ships at very high velocities on different vectors. It comes down to GM judgement of which tool to use depending on the situation.

 

[Yatima]

Also I’ll say again, GURPS Traveller instituted a system of varying turn length based on range. Longer range, longer turn.

Where can I read that? Looking at the GURPs Traveller book (second edition) I see a fixed turn length of 20 mins.

 

[NOLATrav]

Where can I read that? Looking at the GURPs Traveller book (second edition) I see a fixed turn length of 20 mins.

Hmm, I may have been thinking of GURPS Space, my apologies. I’ll try to find and let you know.

 

[Yatima]

Hmm, I may have been thinking of GURPS Space, my apologies. I’ll try to find and let you know.

Thanks, it sounds like an interesting concept, especially for games involving lower technology ships and drives than we typically see with Traveller. Ships using chemical rockets or even fusion drives on closing trajectories might see each other coming for days and be past each other in seconds with brief and horribly destructive consequences. This type of mechanic could be interesting for combat that follows that sort of cadence.

Looking in GURPS space 3rd Ed. I see:

Space combat is fought in space combat turns, each representing perhaps 10 seconds of engagement time. Space combat turns are the final dramatic moments of an engagement that may have involved several minutes or even hours of slow positional maneuvering before the ships entered weapons range and started shooting.

So they are simulating that long dance by just focusing on the passing destructive seconds here. Is that what you had in mind perhaps? I can't find my copy of 4th Ed. at the moment to see if that's different, it may be in storage. If this is not what you recalled, I'd appreciate if you could track that reference down, wherever you came across it.

J

 

[Anstett]

Thanks, it sounds like an interesting concept, especially for games involving lower technology ships and drives than we typically see with Traveller. Ships using chemical rockets or even fusion drives on closing trajectories might see each other coming for days and be past each other in seconds with brief and horribly destructive consequences. This type of mechanic could be interesting for combat that follows that sort of cadence.

That is how Geir writes it in his set of novels.

Geir Lanesskog: books, biography, latest update

Follow Geir Lanesskog and explore their bibliography from Amazon's Geir Lanesskog Author Page.

www.amazon.com