• Welcome to the new COTI server. We've moved the Citizens to a new server. Please let us know in the COTI Website issue forum if you find any problems.

Non-Jump (Maneuver) space travel... How to?

I'll admit I'm still unclear on non-jump spaceship travel, and how to play this out in my group.
Assuming I use a hex battle mat (I know not 3D like space travel requires), and I want to show 2 ships, and their relative position to one another, how would I represent this. Rather how much distance should I set one hex equal to. I would also guess that during a movement phase a ship with a thrust of 5 would move 5 hexes, while a ship with a thrust of 3 would move 3.
If anyone could help me derive a better, and or more simple, or accurate solution I would sincerely appreciate it.
Thanks again,
Louis
 
Well, I don't have the rules in front of me, but I do know this off hand, the ship's maneuver rating isn't it's speed, that's the acceleration/deceleration. So a ship with a maneuver drive of 3 can travel at 18 hexes, or accelerate to 21 or decelerate to 15.

And I don't think they've invented the 3d battlemat for tabletop roleplaying yet, other than that Warhammer terrain stuff, and that don't work in space.
 
Well, I don't have the rules in front of me, but I do know this off hand, the ship's maneuver rating isn't it's speed, that's the acceleration/deceleration. So a ship with a maneuver drive of 3 can travel at 18 hexes, or accelerate to 21 or decelerate to 15.

And I don't think they've invented the 3d battlemat for tabletop roleplaying yet, other than that Warhammer terrain stuff, and that don't work in space.
Thanks Kilmore,
I've been reading the Core Rulebook, but either I'm missing something (probably) or I'm a bit numbskulled (definitely) but it's not clear to me how to truly conduct ship combat/movement.
Oh well, I'll keep reading, and come up with my own method if nothing pops out at me.
 
You're not numbskulled. You're playing Traveller. It's more fun than a college course with twice the information.
 
You're not numbskulled. You're playing Traveller. It's more fun than a college course with twice the information.

Looks like they are using "Range Bands" in Core rules, and the thrust points determine how they can close from one range to a closer one. Obviously very difficult to use a hex mat as the range of adjacent is <1K and medium range is 1250-10000km. I would need one heck of a battle mat not to mention the table size.
Perhaps I'll only use the mat at short ranges inward, mostly for piracy/boarding/docking activities.
 
Set your scale.

Find the hex size in meters, divide by 10. square root. This is seconds per turn if 1 hex per turn=1G for 1 turn.

Accepting a slight break in reality*, 1 G-turn is 1 hex per turn.

Use a 2.5 counter solution: Each ship has a current position marker, and a future position marker. A 3rd marker is used when moving the current & future markers.
Step 1: each ship adjusts future position by the number of G's it's capable of currently
Step 2: move 1 ship at a time
Step 2.1: Pick ship.
Step 2.2: place the temporary marker the same distance and direction from the future marker as the future marker is from the current marker.
Step 2.3: pick up the current marker, and put it in place under the future marker
Step 2.4: Pick up the future marker, and place under the temporary marker.
Step 2.5: repeat 2.2-2.4 for every other ship.
Step 3: combat and other actions.

This is a similar process to that in Mayday, which see; it's available at DTRPG or on the CT CDROM from FFE.

-=-=-=-=-=-=-
* The thing is, the turn you accelerate shouldn't actually move you a full 1-G-Burn vector, only half that, but it's really best ignored for simplicity.
 
Last edited:
Step 1: each ship adjusts future position by the number of G's it's capable of currently
Step 2: move 1 ship at a time
Step 2.1: Pick ship.
Step 2.2: place the temporary marker the same distance and direction from the future marker as the future marker is from the current marker.
Step 2.3: pick up the current marker, and put it in place under the future marker
Step 2.4: Pick up the future marker, and place under the temporary marker.
Step 2.5: repeat 2.2-2.4 for every other ship.
Step 3: combat and other actions.
Okay, just so I'm clear. The reason for the 3rd marker is so it plots a course 2 turns in the future, which is to assume without making any thrust changes (piloting) the ship will continue on the initial course?
 
I think before we can come up with suggestions, we should ask - what do you want to achieve with the positional information? What do you want to use it for that you can't do with rangebands?

One possibility that comes to mind is simply to 'zoom in' on a finer scale of rangebands, running from docking range to 1km, but I don't know if this will achieve what you want.
 
I think before we can come up with suggestions, we should ask - what do you want to achieve with the positional information? What do you want to use it for that you can't do with rangebands?

One possibility that comes to mind is simply to 'zoom in' on a finer scale of rangebands, running from docking range to 1km, but I don't know if this will achieve what you want.
I want to be able to simulate "Dog Fights" for lack of a better term. Or if the players decide to engage in piracy "encouraged" then I want to have them maneuver into position of the target vessel as they attempt to evade.
Taking into account variants of piloting ability etc...
Or perhaps the players are trying to evade police capture and I need to represent several police cutters and their various positions relative to the players trader ship.
 
At the start of the turn, you have 2 tokens. One representing the current ship position, the second representing the future ship position.

To move, you should take a 3rd token. Place that relative to the future position counter as the future position counter is to the current position. For short distances this is unnecessary but it prevents errors when you "forget" where the future position counter was originally.

Once the 3rd token is placed, move the current position token to the future position. Then take the future position and place it on top of the 3rd position token. Next, move the future position counter relative to the 3rd counter by as many G's of drive you wish/are capable of.

Once done, remove the 3rd token, and you remain with the current position and the future position counters.

It simply keeps you from losing track during movement, particularly if you have long vectors. People mess up when they move a single hex and have to track facing. Vector movement is complicated enough that the clarity of the 3rd token actually speeds up play. You can easily eyeball its correctness.
 
Assuming I use a hex battle mat (I know not 3D like space travel requires), and I want to show 2 ships, and their relative position to one another, how would I represent this.

In truth, 3d is not needed as long as you're playing with 3 ships or less, as those 3 points define a plane where you play on. If you're really changing the plane every turn because their maeouvering, that's fine and does not affect game, s the only true concern is relative positions, not real positions referred to anything else (as long as there are no more references, like a planet may be).

And even if you'd have more than 3 reference points, the complexity added by trying to play the 3dr dimension isn't (IMHO) worth de added reality.
 
Okay, just so I'm clear. The reason for the 3rd marker is so it plots a course 2 turns in the future, which is to assume without making any thrust changes (piloting) the ship will continue on the initial course?

No, wrong. The third marker is only for transitioning last turn's current and future to this turn's. Hence "Temporary." It enables not having to write down your vector

If the map looks like: (Capital is current, lc is future)

__A_____________
______a_________
________________
________________
_____b__________
__B_____________


Both accelerate 1 towards each other during the adjust future to get here:

__A_____________
_____a__________
________________
________________
____b___________
__B_____________


Then in 2.1 we pick A
2.2A looks like (* is temporary marker)
__A_____________
_____a__________
________*_______
________________
____b___________
__B_____________

2.3A looks like
________________
_____A__________
________*_______
________________
____b___________
__B_____________

2.4A looks like
________________
_____A__________
________*_______
________________
____b___________
__B_____________

2.5->2.2B
________________
_____A__________
________a_______
______*_________
____b___________
__B_____________

2.3B
________________
_____A__________
________a_______
______*_________
____B___________
________________

2.4B:
________________
_____A__________
________a_______
______b_________
____B___________
________________

2.5 Since all ships have moved their markers, you set the temporary marker aside until next turn, and Go to 3.
 
@Whartung - Thanks it's starting to sink in.

@McPerth - I can't imagine even trying to go for true realism 3D, and I agree with you, I have a feeling it isn't really worth it for what I'm doing.

@Aramis - Ok, I got it now!

Thanks everyone, for taking the time to help me out with what must seem really routine to you. Your advice here and in my other posts have been invaluable, and have already helped make a more fluid and enjoyable gaming experience for me and my players.
 
Oh, and for determining hex-size when using a turn of a given time:

(sec^2)*10=m/hex

For the 6 minute MGT turn, that's 360sec
(360^2)*10=129600*10=1,296,000m=1,296km

If using "real world" 9.8m/s/s G's, replace the 10 with 9.8, for a MGT turn hex size of 1,270km
 
High Guard has rules for this, starting on page 93. It wasn't meant for a hex grid, but the distances are in "units" which are usually centimeters or inches, but could just as easily be hexes.

And with those rules, 1 unit (so 1 hex, if you use a grid) is 1,250 kilometers.
 
Oh, and for determining hex-size when using a turn of a given time:

(sec^2)*10=m/hex

For the 6 minute MGT turn, that's 360sec
(360^2)*10=129600*10=1,296,000m=1,296km

If using "real world" 9.8m/s/s G's, replace the 10 with 9.8, for a MGT turn hex size of 1,270km

Thanks again! This is perfect, as I wanted to have it work in game terms too.
 
I've been running game in a low end TL-9 system with no jump tech.

I use the high guard rules, but instead of distances I use 1 hex = 1G of thrust for a day. I then have a hex map. Roughly every other hex ring contains one of the orbit of a planet. This means in normally takes 4-6 days to cross a system using a thrust 4-5 ship.

My planets have fixed positions, but I found this works very well.
 
When I use vector movement for CT spaceship battles I usually play on a table using card tokens and chalk to draw on the vectors, and I reduce the vector size from 1 inch per G to 1 cm per G which makes it actually more useable. But to be honest this is only fun playing with 2-5 ships, beyond that it becomes unfathonable. The only time vector combat is really fun is if you are in an asteroid belt (and by that I mean a highly unrealistic Star Wars type asteroid belt, not a real one) where the asteroids have vectors of their own and you have to maneuver to avoid the asteroids. That is great fun but unrealistic.

For most other space battles its best to just mark rough ship locations on paper using range bands and change them as the ships move.

There are other ship combat rules out there such as Mayday, Bits' Power Projection rules, Full Thrust and a few others, some of which try to make vector combat more interesting by introducing fields of fire etc.

If your players are really into large space battles Traveller isnt probably the best game to play. If you want to get into table top spaceship wargaming perhaps take a look at Full Thrust or Power Projection. Traveller is too realistic and ship combat too abstract to make starship combat visually aesthetic.

In a similar vein Traveller has always failed to do tabletop miniature personal and large unit combat. I think most people who like these aspects and want to stay with Traveller have adopted their own houserules systems to enhance the play. Although for large unit play the free Dirtside and Fast and Dirty combat rules can produce a pretty good system for playing large scale combat within Traveller.

IMO these miniature wargaming aspects have always been left wanting in Traveller and, other than Striker rules which were too complex, there has been little done to improve the situation. And certainly Mongoose havent made the situation any better - a great chance there has again been completely wasted by them. In fact it could be arged that they have actually made the situation worse.
 
Mayday IS gridded book two for most purposes. If you use CT Bk2, you'll find it very much just a boardgame version... including computer programming.
 
Triplanetary Rules for In-System Dogfights

For many campaigns I've used Triplanetary rules for ship-to-ship combat for the more critical encounters. As this is a pre-Traveller game by Marc Miller, there's some DNA in there that ended up in Traveller.

Project Rho has a good description of the mechanics. Beyond that, the most important elements are grease pencils and a sheet of acrylic. I no longer use the rolled-up sheet that came with the original game. Instead, I got a piece of "storm window" acrylic 1/8" thick from the hardware store and lay a sheet of D-size hex paper underneath. I'm also using dry-erase marker about as often as I use grease pencils any more. It's easier to rub off during the game without shifting things accidentally.

The basic rules are about as complex as the graph-paper racing games I played with friends in school, so it's easy to teach and remember. It's also easy to pull out and put away during a game session. And it adds a lot of drama to the dogfight, especially when there are a couple of convenient large masses to maneuver around. It can also be used in situations where there's a race to a goal, like the Triplanetary tutorial scenario of a three-planet race. Need to get to ground before the bad guys? Race it out!
 
Last edited:
Back
Top