It was, however, stated in the playtest that they are different. I don't know why that didn't make it into the copy, but Hunter was clear that they were not compatible.
And in my opinion, that was a serious mistake. Especially since viable compatible vehicle, starship and computer design systems would be easy to do.
And they do represent different things. The vehicle/robot computers represent a computing unit only, while the ship computers' core represents control systemry and long run data-paths capable of supporting the specialized sensors, jump calculation units, and avionics.
As well as redundant systems to mitigate damage, "2 or more back ups", etc? No, in effect, the ship computers, heck the whole bloody design system, was lifted straight from CT and slapped with a D20 wash to make it look like it fits. Starships in T20 don't bother with small scale things like data paths or life support EP costs, or say, the power requirements for active sensors that can reach out a couple million kilometers, the same for communications equipment with similar capabilities (which iirc you have gone over repeatedly as to how quickly EM fades to background noise levels). Its combining an abstract system with a roleplaying system and that just fails when you do it as part of the core mechanic.
I feel whipsnade put it very nicely:
HG2 is a very poor choice when used for "player scale" combat - that is, when used for combat involving small ships, involving small numbers of ships, and/or combat in which player-charecter skill levels matter. "Tactical" is another word that can be used to describe "player scale" combat and we need to remember that HG2 isn't a tactical level wargame at all. HG2 is an operational level wargame and that's another kettle of fish entirely.
Expecting that there be spongeloads(1) of "player scale" or "tactical level" decisions in an operational level wargame is a bit of conceptual error.
(Wargames roughly fall into three catagotries; tactical, operational, and strategic. The boundaries of those catagories tend to bleed into each other. Also, games that operate on one level usually have aspects from another; i.e. operational games with tactical "flourishes".)
From an operational standpoint and IMHO, HG2 is a successful wargame. It allowed me to handle large numbers of large ships with spongeloads of weapons in a fairly quick manner. I didn't need to move formations around a map and the statistical resolution of all the various rolls was obvious even before TCS mentioned it. I can't emphasize the "large numbers of ships/weapons" aspect more strongly; play Starfleet Battles or Starfire with a dozen battlewagons on a side and see how long a single turn takes.
I also found there were enough tactical "flourishes" in HG2's operational framework to add to gameplay without slowing the game down. Decisions about "pig piling" and the defensive use of weapons(2) are about as meaningful as you can get while still keeping the game flowing.
We also need to remember that GDW was operating under size constraints when it put together HG2. Due to various "dead tree" printing restrictions, those LLBs could only be so big and in HG2 GDW had to find room for advanced naval chargen, large ship construction across multiple tech levels, and a wargame. They created an operational level wargame due to the speed of play concerns I mentioned above (big numbers/ships/weapons) and further abstracted it due to size concerns. If you factor in the constraints GDW was under, I'm sure you'll appreciate HG2 at least a little bit more.
One final note; I strongly agree with you that the ship design system is the best part of the entire HG2 book.
Regards,
Bill
1 - That is one of my new favorite words! Thank you!
2 - "Pig piling" comes about because of the Ugo-Igo nature of weapons fire in the game. When your opponent presents a ship as a target, you must announce all the batteries on all the ships you'll fire at it. Because you only get partial information about the damage you've done, you can easily assign batteries to fire at a mission-killed vessel and thus "waste" them.
The choices about defensive fire are equally vital. If a ship is down in the firing "queue", you cannot use all of its batteries offensively because you don't yet know what weapons your opponent will target it with. With batteries "frozen" like this, you might not be able to use them offensively at all.
T20 is first and foremost a ROLE playing game. The combat system is designed with PC's in mind, not just as a strategic simulator. the ship design sequence was designed to be compatible with HG, which is not a roleplaying game.
Also, more practically, the ship design system was done right after CGen and combat. Vehicle design was almost the last thing written. The ship computer rules were already pretty much fixed in place before any playtesters (myself included) saw the vehicle system.
How is this more practical? The fact that ship design was finished in no way excuses the fact that multiple groups worked on items that should have had them communicating to ensure compatibility, and they bloody well didn't. There are good reasons, that I can accept, for the computers to not mesh identically in size and scale. But that is not the end of the compatibility issues, which at some point were definitely expected to scale.
P223 THB
All T20 design sequences use common units:
Cost is given in Credits (Cr) or Kilocredits (KCr) or Megacredits (MCr)
Volume is given in vl, which represents about 10 liters of volume or 0,01 cubic meters of space.
Weight is in grams (g) or Kilograms (Kg)
Displacement is given in Displacement Tons.
Displacement is used for large vehicles like starships and spacecraft which are rated by their displacement; e.g. 400-ton Subsidized Merchant, 5,000-ton Destroyer. One Displacement ton is equal to the volume taken up by one ton of liquid hydrogen. This is approximately 14 cubic meters or 1400 volume. Displacement does not indicate weight or mass.
Energy Requirements and Power System Outputs are given in Energy points (EP)
P189/90 Travellers Guidebook for Players:
Common sense must be used when deciding whether scaling factors apply. For example, some starships carry anti-personnel or even anti-vehicle weapons for close support work. These would be treated as Lifeform or Vehicle attacks, because those are their intended targets. A tank plasma gun does not become more powerful because it is fitted in a turret under a starship, and likewise if someone were to build an orbital defense tank mounting a starship laser, this would be treated as a starship attack rather than a vehicular one. Maritime ships are considered to be Vehicles in almost all cases. Warships should be treated as mounting Vehicle weapons unless they have been specially constructed for the COACC (Close Orbit and Airspace Control Command) role. For example, some surface vessels mount lasers and particle accelerators for engaging starships, and meson-gun armed submarines are used my many COACC forces. These units could turn their weapons on other maritime vessels if they needed to, but they are optimized for engaging starship-class targets.
It is very clearly implied that the intention by SOMEONE was for the different vehicle classes to mesh and scale, otherwise it wouldn't imply that personal and vehicle weapons can be attached to spacecraft, nor that starship class weapons could be used on vehicles. or that starships and spaceships are just bigger vehicles. The fact that on page 247 of the THB in the vehicle mounted weapons table, the heavy beam and heavy pulse lasers and medium plasma and heavy fusion guns do exactly the correct amount of damage against a vehicle as a starship version, and once adjusted for scale, exactly as much damage against a starship as another starship does, indicates some scalability, even if the power required, if identical as indicated by the designation EP, is twice as much for the lasers and 40x for the plasma and fusion guns. And the sizes are somewhat skewed. And size and power adjusted by TL in the vehicle design but not the ship design. Granted these are the only four weapons in the list that are even remotely scaled
as for perfect mesh, bull. Few games have tried, and only TNE and GURPS really succeeded... and their design systems are a nightmare to work with riddled with problems, and not really any more realistic than the more abstract design systems.
Few games have tried simply because there have been few games with such different scales. Its been a while since I have looked at it but iirc Mechwarrior did a satisfactory, if not perfect, job combining personal, vehicle and 'mech combat, as one example I can think of.
Regardless of that fact, I stated that they should, not that the game designers of the world succeed in doing so. I am not commenting on other games, I am commenting on and trying to find a workable solution for problems I think are in T20.
What I don't understand, when you are quite familiar with how many people feel about the fact the design sequences only work together imperfectly, why are you trying to derail the topic with "That's the way it is so deal with it" arguments rather than using your formidable intelligence to help us come up with working solutions? What you said about the computers is a prime point. It works as an explanation, sort of. With some tweaking it could be totally usable as a home rule.
.
