QSDS for HG, MT, and MGT

[robject]

Hans mentioned, almost in passing, the good quality of QSDS as a ship design system. Back in the day, I used QSDS a bit, and found it was compatible with the OTU, had a reasonable number of steps for ship creation, was extensible, and normalized a lot of ship components drawn from previous rule sets.

Upon reflection, it seems that QSDS could be seen as an upgrade path from High Guard, MegaTraveller's ship design, TNE ship design, and perhaps even Mongoose Traveller ship design. It's close enough to HG to be mappable, and therefore able to represent the other systems playably.

I played with QSDS for awhile after T4 faded from the picture. I liked its accessibility, and its faithfulness to the OTU. I think with some polish and further alignment with the OTU, QSDS could be an acceptable upgrade.

My main concerns are in how it handles volumes, prices, Ranges, and its abandonment of the hardpoint. The first two are rules-streamlining, the third impacts playability (and admittedly is part of the T4 rules system), and the fourth is arguably an OTU-specific feature. I would argue that if QSDS is to be an upgrade path, it needs explicit support of hardpoints.

 

[Tobias]

All QSDS does, as far as I can tell, is to develop tables from formulas for a given range of tonnages. You could do exactly the same for HG. Personally, I don't see the point as I am more comfortable with formulas, but if it is easier for you to pick drives from a table rather than calculate their characteristics according to a formula, it should not be too difficult to provide the same kind of table based on HG.

Is this what you mean?

 

[aramis]

I found QSDS badly flawed - it rounded poorly, and was based upon the TNE FF&S, not the T4 FF&S2, but was a T4 design system.

The "compatibility" with Bk2 and MGT is no better than FF&S' compatibility with same - the drives are wrong, wrong, wrong!

Bk2 drives are incompatible and non-formulaic (well, semi-formulaic), as are MGT ones. Which means the tables themselves are copyright-protected. (Formulaic tables are not, at least in the US.) It also means the designs are incompatible with the MT, FF&S, FF&S2 and HG designs, all of which are formulaic (MT's are buried in tables, but are formulaic tables).

QSDS was a nice idea, implemented poorly, and not managing to significantly reduce the complexity of the design rating process.

 

[DonM]

I never understood why I would trade a working HG2 design system for a broken T4 design system.

On top of that, QSDS is limited to small ships. Unless you want to extrapolate a tome of hulls for QSDS that gives Tigress-sized hulls?

 

[Tobias]

I never understood why I would trade a working HG2 design system for a broken T4 design system.

On top of that, QSDS is limited to small ships. Unless you want to extrapolate a tome of hulls for QSDS that gives Tigress-sized hulls?

Well, some people apparently find it easier to pick components from tables (this appears to be the main appeal of Book 2) than to apply formulas, even simple ones as in HG2.

For these people, a HG2-derived set of tables for small ships could easily be produced.

 

[aramis]

Well, some people apparently find it easier to pick components from tables (this appears to be the main appeal of Book 2) than to apply formulas, even simple ones as in HG2.

For these people, a HG2-derived set of tables for small ships could easily be produced.

Some of us prefer the tech-level limit on drive size (bk2 & 3), as opposed to the TL limit on drive capability (HG). And the much smaller Bk2 M-Drives. (2 Td per 200Td per G, for most of the range...)

 

[Tobias]

Some of us prefer the tech-level limit on drive size (bk2 & 3), as opposed to the TL limit on drive capability (HG). And the much smaller Bk2 M-Drives. (2 Td per 200Td per G, for most of the range...)

That's more a matter of the specific underlying formulas (or in the case of Bk2, rules of thumb) than with the setup of the design system. QSDS does not share Bk2's underlying assumptions in this regard and it does not have a TL limit for drive sizes either - so evidently that's not what robject is going for. I assume.

 

[robject]

I never understood why I would trade a working HG2 design system for a broken T4 design system.

On top of that, QSDS is limited to small ships. Unless you want to extrapolate a tome of hulls for QSDS that gives Tigress-sized hulls?

Hey, you're the guy who told me there is a close mapping from HG to T4.

 

[DonM]

Hey, you're the guy who told me there is a close mapping from HG to T4.

No, there's a conversion. That's different. I'll send it to you...

 

[robject]

I found QSDS badly flawed - it rounded poorly, and was based upon the TNE FF&S, not the T4 FF&S2, but was a T4 design system.

The "compatibility" with Bk2 and MGT is no better than FF&S' compatibility with same - the drives are wrong, wrong, wrong!

Bk2 drives are incompatible and non-formulaic (well, semi-formulaic), as are MGT ones. Which means the tables themselves are copyright-protected. (Formulaic tables are not, at least in the US.) It also means the designs are incompatible with the MT, FF&S, FF&S2 and HG designs, all of which are formulaic (MT's are buried in tables, but are formulaic tables).

QSDS was a nice idea, implemented poorly, and not managing to significantly reduce the complexity of the design rating process.

But in a way, you're making my points over again. QSDS lacked polish and focus. But it was a nice idea, it is compatible with Traveller, and I think it could make a foundation for a unified design system. Might have to free it from T4. Might have to polish it. Might have to focus it.

Frankly, incompatability is an obstacle to be overcome, not a wall to smack into.

This is worth consideration, if only as an exercise in futility. At the end of this process, I expect that the numbers will change more than anything else. I don't think it will look like HG, and it certainly won't look like Book 2.

 

[robject]

A Quick Review

QSDS 15e - a quick review

No surprises in this design system, grounded firmly in FFS and HG.

Hull configurations are, to say the least, over-reaching, with annoying numbers, but the concept is sound.

Drives are missing their formulas, which should not be annoyingly over-complicated. Maneuver drives are mis-named 'thrust plates' IMO. Otherwise, nihil obstat.

Avionics are missing their relevance to the rules system. I suspect they could simply be absorbed into the hulls table without loss of anything.

Sensors could be broken down by element, rather than packaged, and simplified in terms of cost, area, tonnage, and power. Thus the USD could simply go away, forever. Just note a task mod for each, with the standard model having a mod of Zero.

Merge comms with sensors.

I suspect weapons have the biggest issues. They need their own thread for discussion, perhaps.

Extra goodies could be simplified, as could the power plant.

Throw out the cost requirement for workstations, and use workstations to calculate the bridge size.

Throw out power for Quarters, and fix the cost.

There. Not so bad. Mostly polish.

The devil's in the weapons, as I suspected.

 

[robject]

My thought is that most of QSDS' problems stem from trying to package annoying formulas into prebuilt groups. This results in not understanding all of the tradeoffs of the design system, cutting off potentially meaningful choices in the design process, while giving us bizarre values (cost, power, area, volume with one or two or three decimal places) -- it's a lose/lose/lose scenario.

So the solution is to break it down into its component parts and approximate whatever the formulas were with simple replacements.

Weapons

Weapons need the makeover badly, and QSDS doesn't support a rules system (marginally it supports T4). So going back to first principles, we have weapons and we have emplacements. I propose to part them out, completely break down the QSDS tables, and reintroduce near-universal Traveller concepts.

So I'll have turrets, barbettes, small bays, standard bays, and large bays in one table. In another table I'll have lasers, PAs, meson guns, missile launchers, sandcasters, plasma weapons, fusion weapons, disruptors, mass drivers, et al. Some exclusions apply - PAs at least need a barbette, for example.

But I think I'd keep it parted out. So, if you want a Large Particle Accelerator Bay, you'll have to buy 50 particle accelerators to fit it out (assuming 2 tons per PA - might be wrong there). A Large Laser Bay would require 150 lasers, since a laser element is 0.33 tons each.

The benefit of the bay is a longer range. For the sake of this discussion's sanity I will refrain from assigning damage to weapons.

 

[rancke]

My thought is that most of QSDS' problems stem from trying to package annoying formulas into prebuilt groups. This results in not understanding all of the tradeoffs of the design system, cutting off potentially meaningful choices in the design process, while giving us bizarre values (cost, power, area, volume with one or two or three decimal places) -- it's a lose/lose/lose scenario.

My thought (actually for an HG-compatible Book2ish version) is to include the formulas, but to make a list of standard components. Those are the ones that shipyards can make in their sleep, so to speak (or that manufacturers of subcomponents manufacture routinely). They get the full available discount. Anything else you want has to be custom-built at full cost or only partial discount[*].

[*] In a recent discussion, someone told me that discounts for multiple units tend to be pretty much universal. Perhaps one could use the figures he gave instead of the 10 or 20% figures.​

It's been a long time since I used QSDS, so I can't remember why I liked it so much, just that I did. I used it to design freighters and liners and merchants, so I don't think I ever did look very much at the weapons.

I do (vaguely) remember that the rules for carried crafts were different (and IMO inferior) to other systems, but I can't remember just what was wrong with them. (Sorry).


Hans

 

[robject]

My thought (actually for an HG-compatible Book2ish version) is to include the formulas, but to make a list of standard components. Those are the ones that shipyards can make in their sleep, so to speak (or that manufacturers of subcomponents manufacture routinely). They get the full available discount. Anything else you want has to be custom-built at full cost or only partial discount[*].

That's reasonable.

 

[robject]

How to tackle the hull

Assuming first that I dislike the current hull table, and suspecting that the only other alternative is something like High Guard, I'll forge ahead anyway and reformat hull construction.

Shape implies structural considerations. Structure seems to consist of streamlining and acceleration considerations. Ship length and surface area are also implications; I am prone to ignore those items, at least for now.

I abstract shape a bit, and therefore merge it with structural considerations. The result is simpler and different than QSDS, but I think no less reasonable.

At the same time, I'm introducing two concepts that I haven't really defined: friction and agility. I think these two concepts are nascent in the concept of streamlining.


Open Frame (aka Dispersed)
MCr4 per 100 tons.
Max acceleration = 1G.
Perhaps harder to hit under certain circumstances.

Unstreamlined
MCr4 per 100 tons.
Considerable friction generated in atmospheres.

Streamlined
MCr4 per 100 tons.
A bit less armor than typical.

Airframe
MCr5 per 100 tons.
A bit less armor than typical.
Considerable agility in atmospheres.

 

[robject]

Drives

The only foolishness with the jump drive is the pricing and crew calculation.

MCr4 per ton should do it.

As for crew, the calculation should instead be workstations, and the calculation should be based on the sum tonnage for all drives and power plants: 1 workstation per 35 tons of drive.

Similarly, cost and power calculations for the other drives should be simplified, and in fact reduced to formula in all cases.

HEPlaR % by rating: 4, 8, 11, 15, 18, 22
Cost per ton: KCr 150

Maneuver Drive % by rating: 2, 3.5, 5, 7, 9, 10
Cost per ton: MCr 3.5

Power plant % by rating: 1.5, 3, 4.5, 6, 7.5, 9
Cost per ton: KCr 100
Power per ton: 20 MW

 

[robject]

Sensors

Breaking these down into a sensor type and a sensor mount is the key to a flexible and simple solution.

Each sensor requires a mount and a workstation.

Sensors have a base TL, price, and optional task mod. The task mod in T4 parlance is the number of dice to add or remove from the task roll; in 2D systems it may be a die modifier or explicitly a range adjuster. A mod-1 makes tasks easier, while a mod+1 makes tasks harder. This emulates the range capabilities of sensors.


TL8 Communicator. MCr 1
TL8 Radar. MCr 2
TL12 EMS. MCr 2, task mod = -1.
TL10 LADAR. MCr 3, task mod = -2 for targetting or attacking.
TL12 Proximeter. MCr 0.1, task mod = +2.
TL12 Neutrino sensor. MCr 0.1, task mod = +2.
TL12 Densitometer. MCr 0.1, task mod = +2.

Mounts have price, volume, and an optional task mod.

Surface - no price, no volume.
Antenna - MCr 1, 1 ton, task mod = -1.
Large antenna - MCr 3, 5 tons, task mod = -2.

 

[aramis]

But in a way, you're making my points over again. QSDS lacked polish and focus. But it was a nice idea, it is compatible with Traveller, and I think it could make a foundation for a unified design system. Might have to free it from T4. Might have to polish it. Might have to focus it.

Frankly, incompatability is an obstacle to be overcome, not a wall to smack into.

This is worth consideration, if only as an exercise in futility. At the end of this process, I expect that the numbers will change more than anything else. I don't think it will look like HG, and it certainly won't look like Book 2.

If it doesn't work with MGT/MHG, its probably not a good idea. No matter how nice.

My biggest complaint with MGT and CTBk2 is non-formulaicness.

 

[robject]

Weapons

Component + Emplacement Following the lead of sensors, weapons can be seen as having two parts: the weapon component itself, and the emplacement. If we assume that an emplacement contains the focusing apparatus, then we can divide complexity along conceptual lines: you buy the weapon for its specific damage characteristics, and the emplacement for range.

Power If we go one further and embed weapon charging infrastructure in our emplacements, we remove the 'power' axis of complexity while still requiring a central power source. The emplacements become a distributed net of load balancers for the sake of charging up weapons. (This also might give us a reason to retain a version of High Guard's "batteries bearing" rule.)

Components Components have cost, volume, damage characteristics, and may have a task mod.

TL8 Missile launcher 1/3t
TL9 Sandcaster 1/3t
TL9 Pulse Laser 1/3t
TL10 Beam Laser 1/3t
TL10 Plasma gun 0.5t
TL11 PA 1.5 t
TL12 Fusion gun 0.5t
TL13 Meson gun 1.5 t

Emplacements Emplacements have volume, price, damage rating, and may have a task mod. To outfit an emplacement, you fill its volume with the appropriate weapon.

0t - Fixed mount
1t - Turret (1/2/3)
3t - Barbette
6t - Dual barbette
[10t - Small bay?]
50t Bay
100t Large bay