[HG revamp] What I have so far

[Tobias]

Okay, so as I announced in the other thread, I'm going to elaborate a bit on my design goals for my HG2 revamp and on what I have so far.

First of all, my goals. I've always like the scale and concept of HG2's design system, and I've liked what the combat system of HG1 in particular attempted to achieve, but I found the execution and the way in which the game fits into the fictional Traveller universe rather lacking. After years of trying out this and that, I've identified four major points to improve in a possible re-imagining of HG2.

• Simplify combat resolution. HG2's hundreds of batteries per ship are a nightmare to resolve by rolling. And if I'm going to use statistics and averaging, I can just as well apply them during the design phase.

• Remove artificialties and counter-intuitive idiosyncracies. The USP-padding weapons, the 19,990-ton-"must avoid that DM+1" ship, the impossibility of small warships ever doing something about each other, etc.

• Increase tactical choice. In HG2, almost all choices were made during the design phase. I'd like that to shift to the game itself. To that end, at least some maneuvering or positioning rules, abstract or simulationist, are going to be needed.

• Mesh better with the universe as described. Dreadnoughts should be at least somewhat sensible ships to build. System defense boats deployed en masse should be a viable defense. Vargr corsair cruisers should be a threat in numbers, not something that a single Imperial monitor will effortlessly mow down by the hundreds. High TL ships should cost more than low TL ships. Robots should be useable to crew ships etc. etc.

In addition, I'm also keen to remove some things I've always found to be pretty silly, such as sandcasters, and add some things I've always felt to be missing, such as better maneuver drives for higher TL. However, I'd be interested in ideas on how to keep these concepts in their original form as optional rules.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Now for some ideas I've already had. These are basically my concept notes in a (somewhat) organized fashion. I've written some elaborations on some of them, but these are still in the "scribbled down" stage.

Ship Design

• Military maneuver drives receive a performance bonus, making maneuver drives up to factor 9 possible.

• Simplify weapons down to spinal mounts (either PA or meson, as usual), secondary beam weapons (PA, lasers, energy weapons rolled into one) and missiles. There will be a single factor for each of these three weapon types (like in HG1) – no multiple batteries.
  Sandcasters, repulsors, bay energy weapons are all going to be eliminated. I may keep PA and meson gun bays in some fashion, haven't decided yet.

• Missiles are going to be 1-dton capital ship missiles. A bay (50 ton only, 100-ton missile bays going to be dropped) will hold 10 launchers with a total of 50 missiles. Smaller ships will have the option of mounting single missiles (1dton) or launchers with 5 missiles (5 dtons) in place of a turret hardpoint.

• Spinal mount factors will be condensed to the A-F range.

• Overall ship prices are modified by TL and by the distinction between civilian and military ships.

• Effective Hull (armor) value is going to be influenced by the ship's size and possibly by its configuration. Haven't quite decided on how to do this yet.

• An extended range of streamlining options, similar to MT.

• Probably going to give power plants unlimited endurance, but introduce maneuvering fuel (transforming drives from reactionless gravi-magic thingamotrons to not-quite-reactionless-but-unbelievably efficient gravi-magic thingamotrons.) Reasons being that a) I find power plants which run out of juice every 4 weeks to be a bit daft and b) I find maneuver drives which can accelerate to any velocity without limitation to be a bit abusive as well as daft.

• Add support for partially or fully (*Hiver waves in the background*) robotized ship crews.

• This is a pure change of fluff text which can be ignored, but IMTU I use "tonnage" as a measure of mass, not volume, one dton being 10 metric tons. In the actual rules, I'll keep "tonnage" ambiguous.

Combat

• Attack tables will be completely revised and rebalanced. Among other things, to allow for meaningful combat between smaller ships.

• Attack tables will be condensed to require at most two 2d6 rolls to hit and penetrate, plus damage rolls.

• Armor and meson screens are both going to be treated as defenses to be penetrated.

• The ship's configuration will have an influence on to hit rolls (especially for meson guns) as well as on damage resistance (like in HG1.)

• The extreme influence of the computer factor will be migitated somewhat.

• Damage tables will be redesigned.

• Shielding other ships from missile attacks will be possible.

Fleets

• Ships below cruiser size can be organized into squadrons, forming a single beam weapon battery. This will also give fighters a role, at least as screening forces.

• Crew quality rules are going to be completely redesigned, and will include uses for skills other than Pilot, Fleet Tactics and Ship Tactics.

Open questions

• Should the computer be eliminated as a distinct design category? If so, a TL 15 ship would automatically have TL 15 fire control, and there would just be the distinction between military and civilian ships (expressed by something like a +2/-2 DM.) This would also obviate the need to incorporate TL modifiers into the actual beam weapon factors.

• Should I use an abstract battle line movement or a simple vector movement system? This is also strongly related to the next questions:

• Should I use armor facings or a single armor factor? The former option would offer an elegant way of incorporating size efficiency for armor: Ships would distribute a multiple of their HG armor factor among (probably 4) armor facings, and the multiplier would be higher for larger ships.

• For an abstract movement system, in which ways could I introduce more tactical decision making? I've thought about using an extended range band system, as suggested in the previous thread, and also about things like flanking maneuvers. Should I maybe use flank and center positions as well as front line and reserve?

• For a grid movement system, which disincentives could I use to stop all ships of one side being cluttered together in a single square? I've encountered this problem in previous versions. One idea would to make missiles affect multiple targets (saturating an area with kinetic kill swarms or multi-megaton nukes) if they are in the same square or possibly even in adjacent squares (i.e. kinetic kill projectiles could also affect the square "behind" the target.)

• While armor facings could still be used in an abstract movement system, it would feel a bit forced. Or wouldn't it?

• Should the increased efficiency for large ships also affect meson screens?

• Should I gear the size rules to give 500,000+ ton ships, such as the Tigress, a special status?

• Keep PA and meson bays as „mini-spinals“ for smaller ships?

• What about the scale? I've thought about one turn being either 30 minutes (with a 50,000 km scale for a square grid) or one hour (with a 100,000 km scale.) If I use maneuver fuel, it may become a tactical consideration.

• Ditch the USP or not? By "ditching" I mean removing the data string in favor of a text block format such as in Sup9, or MT.

Things I already excluded

• Small maneuver drives, big jump drives. Sorry, LBB2 lovers. LBB2 compatibility is not a concern, and small maneuver drives do not make sense to me from a game viewpoint either (they massively change the balance between riders and ships, for one) so this ain't happening.

• Highter TLs than 15. I don't need them IMTU, I don't think they are needed in the OTU, and it would be extra work. But higher TL components should be easy to extrapolate from MT.

• 3D movement. Tried it, came to the conclusion that it adds too much complexity for very little extra tactical depth. Since one of my ideas for the square grid was that people could play with pencils on simple graph paper, it's out. May come back in if someone has a genius idea on how to implement it in a simple fashion not requiring tedious book-keeping or extra playing equipment.

 

[Dagrill]

Hi,

I would take a look at Mongoose High Guard, if you don't have it. It gives a much more accurate depiction of capital ship combat, but has some major problems with missiles.

I like the 8 range bands and damage allocation by section, it gives a better depiction of big ships grinding each other down.

Regards

David

 

[Tobias]

I would take a look at Mongoose High Guard, if you don't have it. It gives a much more accurate depiction of capital ship combat, but has some major problems with missiles.

I have taken a look at it, but it's a lot more complex than what I'm aiming at. Also, I don't really like the style of presentation, especially not the incredibly wasteful way in which capital ship data sheets are layed out.
Regarding attacks and damage, I was more inspired by TNE's Battle Rider. Damage point tracking is something I'd like to eliminate largely.

 

[mike wightman]

This isn't e revamp. You are writing a completely different ship construction and combat resolution system

Why not just dump all references to HG so that you don't have that baggage and write a consistent and coherent set of rues for building and fighting ships across a range of TLs that suits your ATU?l

 

[mike wightman]

Open questions

• Should the computer be eliminated as a distinct design category? If so, a TL 15 ship would automatically have TL 15 fire control, and there would just be the distinction between military and civilian ships (expressed by something like a +2/-2 DM.) This would also obviate the need to incorporate TL modifiers into the actual beam weapon factors.

Yes, dump it. TL of construction differences achieve the same modifier as you say.

• Should I use an abstract battle line movement or a simple vector movement system? This is also strongly related to the next questions:

As i've said a few times now, I use a modified form of range band movement. Vector combat provides the greatest tactical movement element. but it means you have to limit your weapon ranges and it comes at the expense of making the game last much longer.

• Should I use armor facings or a single armor factor? The former option would offer an elegant way of incorporating size efficiency for armor: Ships would distribute a multiple of their HG armor factor among (probably 4) armor facings, and the multiplier would be higher for larger ships.

I like this armour facing idea.

• For an abstract movement system, in which ways could I introduce more tactical decision making? I've thought about using an extended range band system, as suggested in the previous thread, and also about things like flanking maneuvers. Should I maybe use flank and center positions as well as front line and reserve?

I start by organising each opposing fleet onto one base card, each ship or fighter squadron is a chit placed on the is card. You can then split your fleet into subunits by grouping them, these become your new manoeuvring units. You arrange these on your card and each place their fleet on the table at a range of 20 range bands. Maneuver points can be spent to close range, open range, or split from the main card to represent a flanking force. each side manoeuvres to engagement, splitting off flanking forces as they go.
Once at weapon range you can spend manoeuvre for closing, opening, flanking or for a defensive DM.

• For a grid movement system, which disincentives could I use to stop all ships of one side being cluttered together in a single square? I've encountered this problem in previous versions. One idea would to make missiles affect multiple targets (saturating an area with kinetic kill swarms or multi-megaton nukes) if they are in the same square or possibly even in adjacent squares (i.e. kinetic kill projectiles could also affect the square "behind" the target.)

A stacked fleet is easily out manoeuvred. if you use armour facing and flanking manoeuvres you could end up with a fleet completely surrounded.

• While armor facings could still be used in an abstract movement system, it would feel a bit forced. Or wouldn't it?

It would work well with my range band system, I'm going to plug it in and try it.

• Should the increased efficiency for large ships also affect meson screens?

Yes, the meson screen should scale by TL and ship size, so a TL 15 BB could have a factor 15 screen.

• Should I gear the size rules to give 500,000+ ton ships, such as the Tigress, a special status?

Only if that's the way you want things to work in YTU.

• Keep PA and meson bays as „mini-spinals“ for smaller ships?

Yes.

• What about the scale? I've thought about one turn being either 30 minutes (with a 50,000 km scale for a square grid) or one hour (with a 100,000 km scale.) If I use maneuver fuel, it may become a tactical consideration.

I use a variety of scales for movement. System scale measured in 12 hour units for fleets maneuvering from system arrival to engagement (may not be necessary depending on system arrival point). I have considered reducing weapon ranges so that combat can be conducted in minute long turns.

• Ditch the USP or not? By "ditching" I mean removing the data string in favor of a text block format such as in Sup9, or MT.

I use a data string much like the USP but with multiple lines so it resembles the MT data block. One line for spinals, one for bays one for turrets.

 

[Tobias]

This isn't e revamp. You are writing a completely different ship construction and combat resolution system

Why not just dump all references to HG so that you don't have that baggage and write a consistent and coherent set of rues for building and fighting ships across a range of TLs that suits your ATU?l

I do aim to keep some compatibility to existing HG2 designs, not least because there are so many of them around, both officially, in the depths of the Internet and on my own hard drive. Ideally, it'd be possible to take an existing design from HGS, spend a few minutes on manually editing the text output file and have a ship compatible with the new system.

Also, I use HG2 as a basis for the construction system because I like its simplicity and design flow.

 

[Tobias]

Yes, dump it. TL of construction differences achieve the same modifier as you say.

I've been leaning towards this as well. I may still repurpose the "computer" as something else (sensors, such as in T20, for example) while basing fire control DMs on TL.

A stacked fleet is easily out manoeuvred. if you use armour facing and flanking manoeuvres you could end up with a fleet completely surrounded.

In the past I haven't used armor facings, so players simply clustered their entire fleet together. Even if using armor facings, the advantages of concentrating your force may still need disincentives to counter. It's not such a big concern if I opt for the abstract movement system as the main one.

Yes, the meson screen should scale by TL and ship size, so a TL 15 BB could have a factor 15 screen.

Well, I could simply add the size factor to the standard meson screen factor. I use a different size code than HG2, basically powers of 10, so small craft are size=1, 100s of tons are size=2, etc. - in this case a million+ dton ship with a factor 9 (meson screen) would have an effective factor F. Or I may actually break the pattern and let size=6 start at 500kdtons rather than 1mdton - that would also handle very large dreadnoughts (like the Tigress, the Zhodani Idlev and the even larger ships from FSSI) getting an extra resilience boost.

I use a variety of scales for movement. System scale measured in 12 hour units for fleets maneuvering from system arrival to engagement (may not be necessary depending on system arrival point). I have considered reducing weapon ranges so that combat can be conducted in minute long turns.

Well, I mean just the time scale during the actual engagement. The problem being that in order to have even the slightest resemblance of realism, ranges need to be very long and that if you want to have meaningful maneuvering at these ranges, turns need to be quite long as well.

I use a data string much like the USP but with multiple lines so it resembles the MT data block. One line for spinals, one for bays one for turrets.

Could you give me an example of what that looks like? Basically, I like MT data block style presentation the best, and I use a modified version for my vehicle designs (which are made with a modded version of STRIKER, with some MT mixed in.) I think the "Universal profile" approach is fine for up to 10 or so different values, but I find the USP a bit pointless - especially since it has always needed extra text explanation anyway.