High Guard Update - Comments Needed!
- Thread starter MongooseMatt
- Start date
Melbourne Accords
Mongoose
Sorry about the late post.
Our groups really enjoy vector-based space combat (based on Mayday). It would be great to see this as an option in the revised version of High Guard.
Our groups really enjoy vector-based space combat (based on Mayday). It would be great to see this as an option in the revised version of High Guard.
cunningrat
Banded Mongoose
MongooseMatt said:
If it hasn't been mentioned yet -- would it be possible to roll in the Base construction rules from the Drinaxian Companion?
I started creating a quick reference page (Using VTT Fantasy Grounds) combining text from core and high guard book with some house rules (mostly fill in the blanks and range band difficulties) to speed things up when playing and not have to flip thru several books and pages when rolling for seensor checks.
Could be a good update to include something similar in core or high guard book.
(work in progress)
Also don't know someone mention already but someone drop the ball on EM (Electromagnetic) in core book and high guard.
EM is in the Sensor Details page 150 but not in the Sensor types on page 151 in core book and not mention at all in high guard book when installing sensors page 19.
Could be a good update to include something similar in core or high guard book.
(work in progress)
Also don't know someone mention already but someone drop the ball on EM (Electromagnetic) in core book and high guard.
EM is in the Sensor Details page 150 but not in the Sensor types on page 151 in core book and not mention at all in high guard book when installing sensors page 19.
adzling
Banded Mongoose
Better space combat rules.
What we have currently is ok for two ships duking it out but what happens when you have three or more?
There is no way to judge relative position/ range.
Our table would prefer a simplified vector-based system as we could then have meaningful space battles with more than two ships...
What we have currently is ok for two ships duking it out but what happens when you have three or more?
There is no way to judge relative position/ range.
Our table would prefer a simplified vector-based system as we could then have meaningful space battles with more than two ships...
I use a combat range tabel. it helps alot and helps the players visalus the action. Fun to see the missiles getting closer and closer.
But i'm still new to handling space combat and mostly used the core books and not used the fleet battle rules
Can't remember where i found this one but know there is similar but simel one on drivethrurpg TAS section
But i'm still new to handling space combat and mostly used the core books and not used the fleet battle rules
Can't remember where i found this one but know there is similar but simel one on drivethrurpg TAS section
adzling
Banded Mongoose
i use the same one, also in fgu ;-)
however it doesn't solve the problem of multiple ships in combat and their relative positions.
all it does is tell you relative position to one ship (the one in the center) all other ships have no position relative to one another.
so therefore it's useless in any situation where you have more than one ship on both sides of the combat (or multiple factions for that matter).
vector movement and real positioning would solve this
however it doesn't solve the problem of multiple ships in combat and their relative positions.
all it does is tell you relative position to one ship (the one in the center) all other ships have no position relative to one another.
so therefore it's useless in any situation where you have more than one ship on both sides of the combat (or multiple factions for that matter).
vector movement and real positioning would solve this
Cleon_Entun
Mongoose
I don't really feel that vector movement would work ; I mean, it's an entire wargame altogether, and even if Traveller is already a important resource managements game, I feel that throwing vectorial movements around would lose the "Rules-light" side of this edition. I haven't really sudied the matter, but I think it would be too much math or bogging down for the average role-players.
TrippyHippy
Emperor Mongoose
I’d love to include vectors as an advanced system in space movement. It elevates the game from bog-standard space opera into a game that actually celebrates real physical science - and I love that.
paltrysum
Emperor Mongoose
Cleon_Entun said:
Exactly this. Vector-based space combat games are cool, but not in the context of an RPG. I’ve played Brilliant Lances. I enjoyed it quite a bit. In the TNE era, we used it to run space combat, but here’s the thing: those sessions had near zero role playing. There wasn’t time. I’ve heard others here point out that vector is simple: just use the Mayday or Triplanetary rules, failing to note that those, too, are separate games.
High Guard does not contain the space combat rules; the Core Rulebook does. It will contain fleet combat rules, but the design of these rules — much like those in the CRB — will be to enhance role playing, not hinder it. Vector-based movement is implied, just as it is in the CRB, but it is abstracted to enhance speed of play.
Sigtrygg
Emperor Mongoose
Instead of turning MgT into a cartoon physics cinematic game there needs to be the harder option of a vector movement system, if LBB:2 could do it then there is no reason MgT HG 2.1 can't offer it. Take a look at GURPS Spaceships, the various iterations of Full Thrust as just two examples. A vector movement option doesn't need to be Attack Vector in detail, there are plenty of concise variants of vector movement rules for inspiration.
High Guard, being the spaceship expansion for the core rules needs to include it, the roleplaying encounter combat is, as you have already stated, covered by the core rulebook (and even that is too complicated for a role playing encounter for which I turn to my house rules based on the CT ship's boat skill combat system and the CT Starter edition range band rules).
High Guard, being the spaceship expansion for the core rules needs to include it, the roleplaying encounter combat is, as you have already stated, covered by the core rulebook (and even that is too complicated for a role playing encounter for which I turn to my house rules based on the CT ship's boat skill combat system and the CT Starter edition range band rules).
TrippyHippy
Emperor Mongoose
In the context of the possible inclusion of basic ship construction rules in the Traveller Core Update, I don’t think it would be out of context to make advanced space combat rules somewhere, and an updated High Guard could be it.
Basic vector-based rules needn’t be any more complex than suggesting the use of a grid-map and direction markers. The basic idea is simply the Newtonian idea that an object continues to move at a given velocity - which has a magnitude and direction - unless another force accelerates it somehow. Then you simply add the new vector quality to the existing one. Obviously, it is a step up from total abstraction, but I think it makes space combat a real strategy game just to get the maneuvers right and that becomes absorbing for a gamer like me.
If you really want to make it complex, you could acknowledge that an acceleration ought to be calculated as a vector subtraction not an addition based on ∆v = vi +(- vf), and calculate the results with trigonometry (and probably a calculator). This might be a step too far...
Basic vector-based rules needn’t be any more complex than suggesting the use of a grid-map and direction markers. The basic idea is simply the Newtonian idea that an object continues to move at a given velocity - which has a magnitude and direction - unless another force accelerates it somehow. Then you simply add the new vector quality to the existing one. Obviously, it is a step up from total abstraction, but I think it makes space combat a real strategy game just to get the maneuvers right and that becomes absorbing for a gamer like me.
If you really want to make it complex, you could acknowledge that an acceleration ought to be calculated as a vector subtraction not an addition based on ∆v = vi +(- vf), and calculate the results with trigonometry (and probably a calculator). This might be a step too far...
Condottiere
Emperor Mongoose
This probably requires an eventual software solution, to simplify it to point and click.
Geir
Emperor Mongoose
paltrysum said:
Gee, asking me to remember what I was thinking two months ago. Okay, here goes an abstract hex system:
This is not vector-based, but a 2D hex grid. But first, let’s consider a 1D grid: numbers 0 to whatever, with 1 interval = 1 thrust unit, so you have ranges on that grid:
Adjacent: Range 0, same location
Close: Range 1
Short: Range 2-3
Medium: Range 4-8
Long: Range 9-18
Very Long: Range 19-43
Distant: Range 44-93
Very Distant: Range 94+ (or to about 3800, anyway)
Using the standard thrust rules, 1 Range = 1 g for 1 turn. You can either move in a positive direction or a negative direction. Missiles move at their G rating instead of arbitrarily, but move the missiles during the Attack step instead of the Maneuver step. This has been done by others, and I’ve used it. It’s essentially the standard combat system, with record-keeping and added definition for missile movement. This 1D grid works fine if there are only two ‘sides’. It even works fine if there are multiple ships, as long as they’re all linearly lined up. All you need to do is keep track of the arbitrary numbered location of each ship, missile, or obstacle, and the range is the difference between these values.
The 2D hex grid version of this allows for the placing of multiple ship groups at different hex locations, based on the initial tactical situation. Planets or other ‘obstacles’ can be placed, sized to 1 hex = 1250km, or about 10 hexes across for a size 8 world. The center of the map can be arbitrary and if the battle ‘falls off the side’ you can shift the entire battle back onto the map, though this could push ‘obstacles’ off to the side. Features like a 100D line are a bit hard to justify in this setup, because, without vectors, it would take too long to get to there from, say, an orbital start.
During each maneuver phase, a ship can move up to its thrust in any direction. Range is determined in the Attack phase as are missile runs. All you have to do is count the hexes from the attacker to the target (or measure and round up – how depends on the scale of your hex paper).
A vector-based version of this method (which I would prefer) would ‘remember’ how you moved a ship last turn and keep that movement vector. During the maneuver phase, the ship would move its old vector, then add any new movement to that vector, ‘remembering’ the entire old+new movement vector as the basis for the following turn’s maneuver phase:
If you went three down and one to the right last turn, you would start the movement phase by moving three down and one to the right, then add any new movement as a shift in placement – say two up – so the following turn you would start with one down and one to the right before applying any new maneuvering thrust.
(Technically, you should only apply half the new move during the initial movement phase, but that leads to additional record keeping and ‘half moves’ followed by ‘full moves’ which makes it much more complicated without electronic aids, plus, you would probably want to half the scale to 625km per hex, to keep it at full hex moves).
This vector-based system can also work on the 1D grid, but wouldn’t allow for ‘sideways’ movement.
