Proto-High Guard

[robject]

Why was HG1 so bad it was replaced almost immediately by HG2?

So I sat down last weekend and compared HG1 with HG2, and found some interesting differences, which may explain the what better than the why for me. I found a lot of good information in both; some of the descriptive text from HG1, and missing from HG2, appeals to me.

I assume Mike knows the changes better than I.

Some of the interesting changes escape me at the moment.

EXECUTIVE SUMMARY

Proto-High Guard was originally a scattered collection of specialized fuel, power, and maneuver drive rules for CT small craft, and some various additions such as drop tanks and barbettes (Gazelle) and Black Globes, the first actual screen (Kinunir).

Armor was probably added later, at the same time as bay weapons and spines, along with an expanded set of screens, and marked the break between Proto-High Guard and Book 2 (because now you really need new combat rules). After the break was clear, the drive percentages could be ratified (with a clear note that the Book 2 drives were prefab). Hull configuration was added solely from a need to defend against the meson spine.

Thus armor and the meson spine formed the backbone of the new combat rules, and are therefore the essence of High Guard 1.

I suggest that HG1 was a kind of draft: it was produced knowing that it would change, but GDW decided that getting something out earlier and then producing a wholesale revision was better than delaying. That sort of decision sounds like the kind of thing Marc would do, even as a semi-retired publisher (T5.00).

HG2 is the result of two angles of attack: first, the rules of HG1 were deemed deficient. Second, the layout of HG1 was also deemed deficient.


LONG-WINDED VERSION

Proto-High Guard Existed Before HG1

Proto-High Guard was probably a set of house rules already in use for small craft, as well as specifically military craft (Gazelle) and, eventually, ships-as-adventure-settings, too big for a small group of players to own and operate (Azhanti High Lightning).

These house rules, brought together and organized, clearly became a separate rule system from standard, small ship design (that is, Book 2) when they created the rules for armor.

Who Wrote the Rules?

Rules corrections and layout corrections are two different works, and may or may not point to two individuals; my first assumption is that the person laying out HG1 is not the same person as the one laying out HG2. I could be wrong.

My second assumption (from the credits in the books) is that Marc wrote High Guard 1, but (from the list of author credits for HG2) he had help revising it into HG2 (Marc William Miller, Frank Chadwick, and John Harshman).

The Need For A More Challenging Design Process

A clear indication that HG1 was considered "so bad" is in the power rules.

The major difference between HG1 and HG2 is an added complication: the creation of power balancing rules. HG1 and Book 2 both assumed that the drives were the critical power considerations. This was clearly deemed inadequate for warships, bristling with major weapons, including the power-hungry spine.

HG is for War; Book 2 is for Commerce. And thus we see that HG2 itself is a poor system for non-warships: power rules are overkill if your ship isn't designed for war. Since this is not a deficiency, it doesn't require another rules edit. Since both HG1 and HG2 clearly state the preference of place of Book 2, this is largely a non-issue.

Note that High Guard 1 is fine for building non-starships, exactly because of the lack of power rules. Presumably, Proto-High Guard was similar.

Design Tables in One Place (and the missing ten-ton bay)

I clearly remember one minor difference: the design tables were reformatted to fit cleanly in the exact center of HG2, for easy pull-out reference. That intentional center-pull-out item is explicitly mentioned in the text.

I suggest that the ten-ton bays found in HG1 are a casualty of that layout goal.

Combat Tables

It appears to me that the combat tables for non-spines were streamlined a bit. In HG1 it looks as though weapons had to roll to penetrate hull armor in every case, whereas in HG2 it seems to me that armor becomes a DM on two damage tables (and for reducing crits from spines). With one less dice roll to make for every battery, HG2 is faster than HG1.

The text flow and directions seem clearer, as well.

Also interesting is that the spines in HG1 don't get extra hits, and don't automatically roll crits... And by the way, the crit table is more deadly in HG1.

Hull Configurations Changed

At first, Proto-High Guard probably only dealt with three configurations: Unstreamlined, Streamlined, and Planetoid. The change to basic hull shape was complete by HG1. The essential use case for hull configuration in High Guard is not streamlining, however: it's for defense against the meson spine. Thus, hull configuration was born at the same time as the meson spine.

While configuration names, streamlining, and cost mods didn't change between HG1 and HG2, the most important element about them did: how they protected a ship from meson gun attacks. In HG1, the configuration number was in effect a direct negative DM to hit.

The designers then decided they made some mistakes there, and reordered their effectiveness without changing their actual number. Thus the to-hit table was no longer a simple task roll with a hull config DM (in effect). This theoretically makes HG2 a bit slower than HG1, since in HG1 meson spine attacks could be represented as a task roll with a hull configuration DM.

It seems to me that, if the configurations were re-numbered properly, then the meson attack could once again be a task with a DM. More interestingly, however, the meson attack could bypass the attack roll entirely: go straight to rolling on the internal hits table, using the hull configuration as a DM. Reformat the table so that there are "no damage" results. This streamlines combat further.

 

[robject]

I suggest that High Guard 1 with a few minor tweaks (e.g. M-drive cannot be used as a weapon) and Book 2-normalized drive percentage rules could be considered a type of "Book 2 Plus".

 

[boomslang]

I also think, from the perspective of the combat rules as they influence the design rules, you pretty much need the balance provided by the battery rules from HG2 imported into HG1, but in turn, the idea that a ship of the line could have, for example, both a PAW spinal and PAW bays is worth preserving from HG1. (Or distinct bay and turret missile batteries, as another example. And maybe even beam and pulse lasers in separately-rated batteries while you're at it.)

 

[Whipsnade]

Thank you, Robject, for that extremely interesting read through.

I've got to get off my duff and order that FFE CD...

... the idea that a ship of the line could have, for example, both a PAW spinal and PAW bays is worth preserving from HG1.

Boom - Always viewed the "Spines, Bays, and Turrets Must Be Different" rules as one inserted for ease of play and nothing else. It's akin to FFW's "lack" of jump fuel regulators or Kilemall recently spotting how Striker gives all BD wearers the same strength.

Everything is crammed into that relatively tiny USP with each weapon type limited to a three position column listing battery factor, number of batteries, and number of batteries bearing. Requiring that spines, bays, and turrets use different weapons keeps the USP "tidy" and speeds play.

 

[mike wightman]

One thing I prefer in HG1 to HG2 is that there was an attempt to bake the number of weapons into the USP factor rather than having a massive number of batteries.
The latter means either a lot of dice to roll or use statistical resolution.
If you have to resort to statistical resolution than the maths should be calculated ahead of time and written down, in which case it may as well be baked into an 'attack factor' which brings you full circle to just a single number as per HG1.

I long ago solved the spine/bay/turret problem by just adding extra data blocks to the USP.

Aside - for a future version of HG I would go back to a minimum number of dice rolls, so weapon factors should have batteries bearing built into them
spine/bay/turret should be a bit like rock paper scissors too
spinal - good vs capital, hard to hit escort class, useless vs smallcraft/missiles
bay - moderate vs capital, good vs escort class, hard to hit smallcraft/missiles
turrets - useless vs capital, moderate vs escort, good vs smallcraft/missiles.

 

[Whipsnade]

One thing I prefer in HG1 to HG2 is that there was an attempt to bake the number of weapons into the USP factor rather than having a massive number of batteries.

A single number is easier and speeds play. It doesn't easily allow for multiple targets however.

The latter means either a lot of dice to roll or use statistical resolution.
If you have to resort to statistical resolution than the maths should be calculated ahead of time and written down, in which case it may as well be baked into an 'attack factor' which brings you full circle to just a single number as per HG1.

Have you looked at Battlerider? It's system may be a nice middle ground between one number and too many numbers.

I long ago solved the spine/bay/turret problem by just adding extra data blocks to the USP.

Me too. I sometimes allowed for flexible battery assignments which further slowed play.

 

[robject]

I long ago solved the spine/bay/turret problem by just adding extra data blocks to the USP.

And Wil/Aramis (only recently?) came up with a handy HG-friendly long format that fits on a 3x5 card.

MM-SCMJ NAME AND MISSION xxxxxxxxx  BCr xxxx xxxk tons  TL xx
NOTES xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Offense      USP  Batt   Bear       Defense             UCP           
------------ ---  ----   ----       ------------------- ---
Ortillery     xx    x      x        Armor <TYPE>         x
PA            xx    x      x        Nuclear Damper       x
Meson Gun     xx    x      x        <TYPE> Screen        x
Beams         xx    x      x        <TYPE> Sand          x       
<TYPE> Salvo  xx    x      x        Anti-Missile Def.    x
Jump Damper   xx    x      x        <TYPE> Globe         x
Trac./Pres.   xx    x      x        Grav Scrambler       x
Inducer       xx    x      x        Mag Scrambler        x
Disruptor     xx    x      x        Elec Scrambler       x
Stasis        xx    x      x        
DataCaster    xx    x      x        
Rail Gun      xx    x      x

 

[robject]

One thing I prefer in HG1 to HG2 is that there was an attempt to bake the number of weapons into the USP factor rather than having a massive number of batteries.

The latter means either a lot of dice to roll or use statistical resolution [which can be pre-computed, which in turn suggests just using an attack factor, which is back to HG1].

Aside - for a future version of HG I would go back to a minimum number of dice rolls, so weapon factors should have batteries bearing built into them

I like the more straightforward aspects of HG1. I understand Batteries Bearing has two purposes (limiting attacks and damage resistance), but it does seem to 'cost' too much.

If I have time, I'll dive into the HG1 USP. I seem to recall something that looked like a battery factor table in HG1, but maybe that was something else! If it was not actually that, and the USP instead recorded the rough number of guns, then was it pseudo logarithmic like battery factors, or something else?

I do recall that bays required a certain number of guns to fill them, based on the weapon type, but (I THINK) the bays were simply receptacles like a gigantic megaturret. What mattered was the number of guns of a type (is that correct?).

Looks like the fun problem was not on how to provide mass fire, but rather how to divide fire.

 

[robject]

A single number is easier and speeds play. It doesn't easily allow for multiple targets however.

Potential solution and its associated new problem: allowing batteries to fire multiple times.

Have you looked at Battlerider? Its system may be a nice middle ground between one number and too many numbers.

Yes. It's like an upgunned Mayday, and it is compelling.

Me too. I sometimes allowed for flexible battery assignments which further slowed play.

Problem noted. What's the best way to divide fire with massed weapons?

 

[mike wightman]

Let's say you can come up with a battery factor based on number of bays - it could be any number between 1 and 9.
If you want to fire at more than one target you reduce the battery factor by 1 for two targets, by 2 for up to four targets, by 3 for up to eight etc - note I am picking these numbers out of my derriere and they would need testing and codifying, but those are my initial thoughts.

BR is very good, but ships in BR do not have the same number of weapon systems as HG2 designed ships thanks to the surface area limitation.

 

[flykiller]

What's the best way to divide fire with massed weapons?

by energy equivalence.

failing that, by battery disaggregation. a normal 10-turret factor 9 battery is divided up into 6-turret factor whatever and a 4-turret factor whatever, etc.

failing that, by a simple step-down. one shot at full design factor 9, or two shots at factor 8, or three shots at factor 7, etc. one may vary the step by 1, or 2, or 3, etc.

this slows gameplay. one may restore original gameplay speed by mandating that firing decisions be made immediately (perhaps within 5 seconds) or the original design configuration is used by default. this rewards competent players. one may vary this by adding, say, 5 seconds for each level of ship tactics possessed by the player character.

 

[robject]

by energy equivalence.

I think this is the key point to consider. Because all solutions, including yours and the one Mike suggested, are approximations of it, or failing that, a nod of acknowledgement to it.

this slows gameplay. one may restore original gameplay speed by mandating that firing decisions be made immediately (perhaps within 5 seconds) or the original design configuration is used by default. this rewards competent players. one may vary this by adding, say, 5 seconds for each level of ship tactics possessed by the player character.

A 'default mandate' is a nice touch.

It would be nice if competent players were able to do clever things, and handicapping simplifications were available to even the odds against inexperienced players.

 

[mike wightman]

If energy point allocation could be made organic to the decisions made during combat without slowing down play I would be all in favour.

I have never liked the EP rules in HG2 as they are not tracked as damage accrues. Without an easy tracking system you would be better off just getting rid.

 

[robject]

What about the nonexistent power rules for HG1? It seems to me that a spine will indeed need power. However, it seems to me that the spinal weapon in HG1 is not nearly as powerful as it is in HG2 (I could be wrong though). The main reason I think so is that it does not get automatic critical hits, ever.

Thus weapons in HG1 could be seen as low power. Alternately, HG1 weapons might be self-powered; this is certainly the way we went with MegaTraveller, even while keeping a High Guard combat model.

 

[flykiller]

I think this is the key point to consider.

well, one key point.

a weapon requires energy to operate. it also requires time. e.g. consider a factor 9 beam laser battery opposing a pair of factor 3 missile attacks. if one views this as an ongoing engagement rather than as a "aim,point,fire,done" event then it is very reasonable to presume that the single beam laser battery can engage both factor 3 missile attacks at (say) factor 7. such an approach allows 1) player tactical decisions with consequences 2) without breaking open the books and calculators and listening to the players spend the next half-hour of game time hashing out optimal energy allocations for the next fire mission.

if one wishes to avoid the continuous step feature then one may designate at construction time not only the main battery configurations but also sub-battery configurations. say, 10 turrets may be pre-configured to one factor 9 or two factor 7, or a spinal to one factor T and three factor J. etc. probably the best way to maximize player input while minimizing time spent doing so.

 

[robject]

If energy point allocation could be made organic to the decisions made during combat without slowing down play I would be all in favour.

I have never liked the EP rules in HG2 as they are not tracked as damage accrues. Without an easy tracking system you would be better off just getting rid.

Those are two very interesting points. I DO like the "all power to engines!" rule of Emergency Agility, even though it feels a little contrived (I note that E.A. didn't make it into Battle Rider). And "all power to shields" seems another obvious tactical move that should be exploitable.

But in order to do that you nearly have to turn combat into an accounting game which runs off of allocating EPs.

 

[flykiller]

But in order to do that you nearly have to turn combat into an accounting game which runs off of allocating EPs.

it's not difficult, and I far prefer it. I design all my ships with allocations in mind - double fire, minimal escape jump configuration, casualty response. the only problem is when more than one player has input to allocation decisions - then the endless discussions begin. it makes a nice touch when the captain wants emergency escape power and the engineer has to roll for success to make it happen.

 

[mike wightman]

Another reason not to like EPs:

LBB2 free trader - two triple beam laser turrets, take that pirate scum.
HG1 free trader - two triple beam laser turrets, take that pirate scum.
HG2 free trader - what's a laser?

LBB2 free trader - hey I have the credits to upgrade my computer, take that pirate scum.
HG1 free trader - hey I have the credits to upgrade my computer, take that pirate scum.
HG2 free trader - stick with your abacus and like it.

 

[RandyB]

Those are two very interesting points. I DO like the "all power to engines!" rule of Emergency Agility, even though it feels a little contrived (I note that E.A. didn't make it into Battle Rider). And "all power to shields" seems another obvious tactical move that should be exploitable.

But in order to do that you nearly have to turn combat into an accounting game which runs off of allocating EPs.

I thought that was called "Star Fleet Battles".

 

[aramis]

I like the more straightforward aspects of HG1. I understand Batteries Bearing has two purposes (limiting attacks and damage resistance), but it does seem to 'cost' too much.

If I have time, I'll dive into the HG1 USP. I seem to recall something that looked like a battery factor table in HG1, but maybe that was something else! If it was not actually that, and the USP instead recorded the rough number of guns, then was it pseudo logarithmic like battery factors, or something else?

I do recall that bays required a certain number of guns to fill them, based on the weapon type, but (I THINK) the bays were simply receptacles like a gigantic megaturret. What mattered was the number of guns of a type (is that correct?).

Looks like the fun problem was not on how to provide mass fire, but rather how to divide fire.

HG1, a ship always effectively has batteries = Tonnage/1000. The factor of said batteries is based upon weapon strength per 1000 tons. So, if you load a TL 10 1000 tonner with a single (40 strength) Missile Bay, it's one battery of 40 strength, giving factor 8; on a 2000 tonner, a single missile bay is factor 6, because you spread that strength out over 2× 1000 Td sections, but it now fires twice at factor 6. On a 3000 tonner, it's 13.33 per, or factor 4, firing thrice.

Bays in HG 1 are not "filled" with subunits; everything is simply given a strengthpoint factor by TL.

And the index card version was inspired by the MT USP...