• 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.

Five Things About High Guard

I think we've heard that Sandcasters are like giant shotguns? If so, turrets spread over an 100 meters or so of ship could act as point defense. One fires at a beam and another to a separate beam hitting 50 meters way?

Also, assuming the cloud screen analogy, the moment the target ship maneuvers, to ANY degree, it moves away from it's protective screen. The moment you use agility to zig, zag or jog, you lose the screen effect. Under HG2 I'd rather use agility rather than a sandcaster!

And how do you aim it at a pulse laser (an enervy pulse that hits you before you can even detect it, as it goes at light speed).

TO b effective, the cloud must be more or less complete.

You don't fire a single shoot with them, but maintain the cloud protecting your ship.

In at least one of the rulesets (I think it might have been MT, or maybe GT?) it was suggested that sandcasters also employed a combination of magnetic and/or gravitic fields to shape and "hold" the cloud in place. (Seems a little bit far-fetched for a maneuvering vessel, though - it would have to be a very strong field).

Also (to borrow another idea) in the original 2300AD game, ships used a "sandscreen" of magnetized particulates which flowed out along a hull grid. That might be more feasible in concept, but I always imagined that it would interfere with sensors and other ship's systems mounted on the hull surface.

Could something be devised that makes use of elements of both of these concepts?
 
Considering that the majority of HG warships are throwing themselves around at 6g evading being hit a sand cloud deployed in the LBB2/Mayday manner is totally unfeasible.

So how do we reconcile turret mounted sand batteries being used agains one incoming beam/missile battery?

Another thing to consider is that the manoeuvre drive generates a protective screen against stellar radiation - is this a magnetic field or plasma based?

A sandcaster could be pictured as a vrf grenade launcher, with each sand canister actually being a few thousand rounds of ammo which is designed to interfere with beam weapons/missiles.

Alternatively the sand caster fires its sand canister into the protective field around the ship to "thicken" parts of it.
 
Ah! An how exactly does this occur when you fire one canister at a time from the launcher (holding three ready rounds)? Therein lies the rub...

Wll, you have several of them (up to 30) in a battery, and can fire them sequentially. It would also depend on the rate of fire they have.

In any case, as sandcaster barels are as magically produced as missiles are...

That does make a strong case for bigger, better, computers.

And curiously enough the computer is one of the main modifiers to the to hit and to penetrate rolls...
 
Another thing to consider is that the manoeuvre drive generates a protective screen against stellar radiation - is this a magnetic field or plasma based?

I like the idea. Is this an "IMTU" concept, or is it stated explicitly in canon somewhere that I have missed?

Alternatively the sand caster fires its sand canister into the protective field around the ship to "thicken" parts of it.

I would go with this interpretation, personally. The field and sand form a "cloud-screen" that moves with the ship. At least, this seems to me to be the most feasible/plausible.

It also seems to mesh well with the sandcaster concept as discussed in the Proto-High Guard 5 thread.
 
The radiation screen element of the manoeuvre drive is mentioned in the CT boxed adventure Beltstrike.

They also have a basis in the real world. Search plasma shield and look for the real world science articles.
 
I like the idea. Is this an "IMTU" concept, or is it stated explicitly in canon somewhere that I have missed?
Canon. Beltstrike, Folder 1, page 2:
(Ships under power are not affected — part of
the M-drive generates a low-power screen against radiation and
meteorite impact — but a power failure during approach within a few
a million kilometers of the gas giant would be fatal.)​
 
The radiation screen element of the manoeuvre drive is mentioned in the CT boxed adventure Beltstrike.

[FONT=arial,helvetica]Canon. Beltstrike, Folder 1, page 2:
(Ships under power are not affected — part of
the M-drive generates a low-power screen against radiation and
meteorite impact — but a power failure during approach within a few
a million kilometers of the gas giant would be fatal.)​
[/FONT]

[FONT=arial,helvetica]Thanks for the reference. [/FONT]
 
Both Striker and MT allow sand casters to be used as a super shotgun - which favours the VRF grenade launcher model.

I can't help liking the hardened plasma screen model though :)
 
Both Striker and MT allow sand casters to be used as a super shotgun - which favours the VRF grenade launcher model.

I can't help liking the hardened plasma screen model though :)


Might it be possible to use the sandcaster as super-shotgun when the plasma/rad-screen is not operating? Presumably a "super-shotgun" is not going to be used while a ship is maneuvering.
 
It sounds as if you're wanting a tactical war game, with movement plot and such. (I'm sure you know that there's a JTAS article that brings Mayday hexes to High Guard, combining HG combat with MD movement).

With Book 2, all that matters is when a ship crosses a range band (or range limit)--when Medium Range becomes Short Range. It doesn't matter, for the combat, if ships move around and reposition themselves but still within the same range band.

High Guard was, I think, hamstrung by an over-simplification of Book 2.

By making ship turrets scale with total volume (tonnage), rather than another option, which would be surface area (i.e., 2/3 root of tonnage), it gave big ships a much too linear advantage over smaller craft that greatly exceeds the equivalent in real navies. A Tigress with 300 turret-equivalents vs. 5,000 turret-equivalents would have better fitted the semi-logarithmic abstract approach to combat that the system ended up using, I think.

My major problem with most Traveller vector-based implementations that operate on maps, of which Mayday was a prime offender, is that:

(a) If you aren't moving missiles on the map, then maneuver is largely pointless (except for "run away if you're faster"), as ships tend to have 360 degree firing arcs. If you have multiple ships, stack 'em all in the same hex.

(b) If you are moving missiles on the map, the counter crush becomes unplayable real fast.
 
My major problem with most Traveller vector-based implementations that operate on maps, of which Mayday was a prime offender, is that:

(a) If you aren't moving missiles on the map, then maneuver is largely pointless (except for "run away if you're faster"), as ships tend to have 360 degree firing arcs. If you have multiple ships, stack 'em all in the same hex.

If you're wanting firing arcs, try _Power Projection_.

(b) If you are moving missiles on the map, the counter crush becomes unplayable real fast.

Agreed. In every system I can think of.

*BUT*

One possibility is to rule that you are using missiles that are faster than the ships. I designed a turret-based civilian missile that does 20G for 1 turn, and a naval missile that does 20G for 5 turns using my "Mayday Missiles Modified" rules.

You'll find that if you introduce these missiles, there will be very few actual missile counters needed... ;)
 
David: that 20G 1Turn missile goes half the distance of the 10G 2Turn missile, and 1/4 the distance of the 5G 4 turn missile. Longer burn for the same ∆V is always more efficient in microgravity. Not to mention needing less engine mass.
 
David: that 20G 1Turn missile goes half the distance of the 10G 2Turn missile, and 1/4 the distance of the 5G 4 turn missile. Longer burn for the same ∆V is always more efficient in microgravity. Not to mention needing less engine mass.

More efficient isn't always better. There can be a tactical advantage in having the missile close the distance faster, even if the result is reduced range. For one thing, the target has less time to react. Consider for example that a target within 14 hexes of a ship launching that hypothetical 20g missile is not be able to get out of that missile's effective range before it comes time for that missile to move, while the target within 14 hexes and facing a 5G4 is likely to have some time to build up a vector away from the missile and - given adequate drives and enough distance - might outrun the missile.
 
More efficient isn't always better. There can be a tactical advantage in having the missile close the distance faster, even if the result is reduced range. For one thing, the target has less time to react. Consider for example that a target within 14 hexes of a ship launching that hypothetical 20g missile is not be able to get out of that missile's effective range before it comes time for that missile to move, while the target within 14 hexes and facing a 5G4 is likely to have some time to build up a vector away from the missile and - given adequate drives and enough distance - might outrun the missile.

Your example 14 hex target is out of range of the 20G missile. Which only gets 10 hexes of range. Ironically, a 14G missile misses, too, at 14 hexes. (unless, of course, you ignore the 0.5 term in D=0.5AT2.
 
Your example 14 hex target is out of range of the 20G missile. Which only gets 10 hexes of range. Ironically, a 14G missile misses, too, at 14 hexes. (unless, of course, you ignore the 0.5 term in D=0.5AT2.

He was talking Mayday, right? That whole business about a past position counter, present position counter, future position counter? Missiles appear on the board in the ordnance launch phase - present position counter at the location of the launching ship, future position counter at the future position of the launching ship since it has the ship's vector, and then you can move the future position counter up to 1 hex per G rating. Then the other player gets his turn. Then your turn comes around, starting with movement: missile past position counter goes where the missile is, present position counter goes to the future position, future position is calculated based on the vector and then (if you still have fuel) changed based on your G's. "The future position counter may be moved one hex for every G-factor which the ship has," and missiles move the same as ships.

If the opponent's future position counter was within one turn's movement of your missile at the ordnance launch phase, you put your missile's future position counter atop his ship's future position counter, he was obliged to move his ship's present position counter to that point in his movement turn, and your missile would follow suit on your turn - wham! (Whups! That means the 20G hits everything within 20 hexes, not 14.)

Mayday had a 100 minute turn and a 1 light-second hex; a body accelerating at 1G from a stop would cover a bit over half a light-second distance in that time and end with a 1-hex vector, which Mayday simulated with that three-counter business which left you declaring the vector this turn and arriving next turn. It was a simple but imperfect emulation of the physics, as the missile example shows: a 20G missile is suddenly 20 hexes away on the turn after launch. What the rules did not simulate was the missile running out of fuel before it actually arrived in that hex (if it only had one turn's fuel).

You were left to choose between a literal reading of the rule, which has the missile arriving and intercepting the target when physics suggests it's been reduced to coasting by that point, or coming up with a house rule that more accurately emulated the physics. For example, allowing a launched object only half its allowed moves on the turn of launch.
 
Heh.

You're both right, BTW.

(I think Wil & I have had this discussion before.)

If you use strict s = ut + 0.5at^2, then Wil is right: in zero gravity, a vehicle only moves half it's acceleration.

However, as Carlobrand points out, Mayday (and many other hex-based systems) ignores this in favour of simplicity. GOTCHA!

(Really, my 20G missile is a great example of min-maxing to take advantage of a rules anomaly.) ;) ;)
 
HG2 with a streamlined resolution for number of batteries firing and a better manoeuvring system = instant operational/system scale war-game.

[...]

Move fleet cards around sub sector maps as the strategic element (FFWish), move squadron cards around a system map and resolve the battles when squadrons encounter squadrons at the initial ship level of HG (although I would change the rules about how only 1 ship is present from your battle line at a time so that escorts can actually support the ships they are escorting).

McPerth said:
[FONT=arial,helvetica]
[/FONT][FONT=arial,helvetica][FONT=arial,helvetica]just a few ... rolls [of the dice] to determine the full effect [of a round of battle, or even a full battle]...
.
[/FONT]..provision for crew quality...
[/FONT]

I see possibilities here.

On a "Mayday"-like scale, I can see one simple rule to accommodate firing arcs unintrusively: keep batteries bearing, but restrict the spine to forward-line-of-fire-only. It's harsh, but I think for Traveller the spine is what arcs are all about.
 
Last edited:
I see possibilities here.

On a "Mayday"-like scale, I can see one simple rule to accommodate firing arcs unintrusively: keep batteries bearing, but restrict the spine to forward-line-of-fire-only. It's harsh, but I think for Traveller the spine is what arcs are all about.

Mmmm - depends on how you see detection, maneuver, and fire inter-relating. Consider: on a Mayday scale it's a 100 minute turn, in High Guard a 20 minute turn. During that time the ship is trying to point drives in some random direction so you can't just hit him based on his last known position and vector - expressed in High Guard by agility and in Mayday by a computer-controlled Maneuver/Evade program. During that time, it nonetheless finds an opportunity to train and fire its spinal mount and to fire its turret and bay weapons (up to a percentage dictated by size in High Guard) irrespective of where they happen to be located on the ship.

During that turn, it appears to get off one shot. If we take the view that the sensors are taking in information during that turn, trying to calculate the best possible firing solution, then it's all about the sensors and computer for most of that turn, and the ship spends only a brief moment training its turrets, bay weapons, and spinal mounts on the exact angle dictated by the firing solution. Under that model, the ship cold be pivoting, turning about and accelerating, trying to make sure it's not where you think it is when your shot arrives, and then do a quick 180, spend a moment training and firing the spinal weapon, and then get back to the business of pivoting and turning so that you can't hit it by just firing at the point from which his fire originated.

The other view, the one which might invoke a firing arc for the spinal mount, has the ship spending much of its turn trying to precisely train the weapon. In that model, it can't both train its weapon in one direction and be accelerating in another. However, in that model, it also cannot get the full benefit of agility when training its weapon: its movements are dictated by the need to spend much of the turn training and firing its weapon, rendering it more predictable than a ship using turret weapons. While there's nothing specifically wrong with that view, it just doesn't line up with High Guard rules: ships do not receive a penalty to agility while firing the spinal mount. (Interesting idea though.)
 
[.....]While there's nothing specifically wrong with that view, it just doesn't line up with High Guard rules: ships do not receive a penalty to agility while firing the spinal mount. (Interesting idea though.)

Excellent point - this is the wrong thread for my previous post.
 
Back
Top