V3-Ship Design

[SableWyvern]

I do think that car argument is disengenous. I don't order the software when I buy a car, true. However, if I'm designing one, I'm going to have to make a software decision at some point.

That being said ... there's no point in making players select software when designing ships unless that decision is a meaningful one.

If a Jump-2 capable ship needs Jump-2 software, cannot rely on inferior software, and gains no benefit in superior software, then selecting Jump-2 software is a process that serves no useful function whatsoever. While it does leave open the possibility of building a Jump-3 ship with only Jump-2 capability, that's such a poor economic decision it hardly warrants modelling. Besides, if you can manage the cash for the rest of the ship, I'm sure you can scrape together a couple credits for a software upgrade.

Edit for clarity: Some software decisions can be meaningful, and thus warrant inclusion. Fire Control is the obvious one, where better systems offer better results, or allow for control of different numbers of weapon systems.

 

[AKAramis]

I do think that car argument is disengenous. I don't order the software when I buy a car, true. However, if I'm designing one, I'm going to have to make a software decision at some point.

That being said ... there's no point in making players select software when designing ships unless that decision is a meaningful one.

If a Jump-2 capable ship needs Jump-2 software, cannot rely on inferior software, and gains no benefit in superior software, then selecting Jump-2 software is a process that serves no useful function whatsoever. While it does leave open the possibility of building a Jump-3 ship with only Jump-2 capability, that's such a poor economic decision it hardly warrants modelling. Besides, if you can manage the cash for the rest of the ship, I'm sure you can scrape together a couple credits for a software upgrade.

Edit for clarity: Some software decisions can be meaningful, and thus warrant inclusion. Fire Control is the obvious one, where better systems offer better results, or allow for control of different numbers of weapon systems.

The old CT software system was one of the least used sections of the rulebook I've ever encountered. I have only used it for a few one-offs where players demanded it; they then changed their minds.

Now, as for jump programs, under CT, the jump program is the difference between a 100 Td Scout's JDrive-A and a 200Td Free Trader's...

And I do think a good computing model is worthy... I'm not so sure this is it in Draft 3.

 

[Takei]

but that is not a space/starship, and not how it's done in Traveller. You are buying a computer used in many diff applications/environments. Even IBM sold it's Mainframes/Midframes. You got the computer, terminals, and O/S, no software that was all extra so you got what you wanted (even if you just wanted programming languages to write your own software, you paid separate for it.

You've focused on just the software aspect of my argument - what I'm asking for is that we forget computers in the design process and just assume that the required computing power is part of the bridge and component tonnage and cost, as was done in T4.

Straw Man Argument. Fusion plants are narrow applications, they don't have the huge amount of options any single type of spacecraft/starship hull can have. (before we confuse you... Traveller cannon: spaceships don't have Jump, stay in one system. Starships have Jump)

I don't believe it is a Straw Man argument. You're saying that we need to specify jump software but not power generation software - why the distinction?

You won't confuse me. I've been playing and running Traveller since 1979.

Any one Space/starship control computer can be used in a variety of ships, the starships having anywhere from Jump-1 to Jump-5 or so (depending on your version of Traveller). Spaceships don't have jump. both can be bough streamlined or not at the same tonnage. Are you saying the computer manufacturers are going to just write separate packages for every conceivable possible hull/engine/weapons configuration and THEN toss them in for free (or the same fixed cost no matter what is or isn't included).

This is linked to my first comment. I would prefer to see computing as a distributed system (and therefore handwaved out of the design process) rather than a single item.
I work in the car design industry, specifically electro-mech, and it would make our lives so much easier if there was an industry standard 'car computer' that we installed in the vehicle that controlled everything. There isn't. Each module has it's own software installed that controls one part of the car function and then talks to a central control module or two. Those control modules are unique (well we try to use existing ones if at all possible) with unique software. The cost of the software is included in the delivery price of the module. I assume that all vehicles (buses, trucks, aircraft, ships etc.) do the same.

A particular hull design (say in GURPS:T the Empress Marauva 200-ton Free trader, two turret ports, turrets sold seperately) has room for guns but doesn't come with the weapons, just the empty turrets in it. Do you want the hull to be one price whether or not you get the turrets? Do you want the comp to include software for guns that that aren't installed in the available turrets.

No, I expect the fire-control hardware that I install with the guns to control the guns and talk to the 'computer'.

All you are saying is, you don't want to deal with the level of detail Traveller has typically had... so don't. In your game include the software in the cost of the comp.

Classic Traveller lost that level of detail with Highguard.

 

[SableWyvern]

The old CT software system was one of the least used sections of the rulebook I've ever encountered. I have only used it for a few one-offs where players demanded it; they then changed their minds.

Now, as for jump programs, under CT, the jump program is the difference between a 100 Td Scout's JDrive-A and a 200Td Free Trader's...

And I do think a good computing model is worthy... I'm not so sure this is it in Draft 3.

As I implied, I have no problems with a software system, as long as it brings with it meaningful decisions and trade-offs. If there's an obvious best-buy for cost/effect, or only one real option, it's a waste of space and effort. A system of meaningful choices is certainly possible, and I would support such a system (or, at least, not oppose it -- all I really want is functional ship construction).

 

[Mongoose Pete]

I'm also in favour of the idea that software is an inherent part of the hardware. Mechanical, electronic and engineering devices nowadays are so complex that they have all their software built in as part of the control system.

If think the bast modern example would be an airliner. Take an Airbus A380 for example. All of the following systems have their own management software built into their own computers. The engines, the air-conditioning, the flight controls, the autopilot, the sat-nav, the landing gear, fuel pumps, etc, etc.

Now the plane also has several centralised computers, which take the information produced by each sub-system and combines them together for display and advanced warnings. In all other cases, save for the entertainment system, the software is hardcoded into the electronics of the subsystem - for stability, safety and efficiency.

Mechanical, electronic and engineering software is integral to the system, it is never purchased separately.

Did you have to purchase the software to run your DVD player? Mobile phone? Central heating system? Have you and will you, ever update their bios? No. You'll simply buy an entire new device.

Software in Traveller IMO (at least in the case of Starships) should be treated as a transparent layer.

 

[Takei]

I do think that car argument is disengenous. I don't order the software when I buy a car, true. However, if I'm designing one, I'm going to have to make a software decision at some point.

Working in that industry I can tell you that the cost of the software is part of the delivery price of the units.

That being said ... there's no point in making players select software when designing ships unless that decision is a meaningful one.

If a Jump-2 capable ship needs Jump-2 software, cannot rely on inferior software, and gains no benefit in superior software, then selecting Jump-2 software is a process that serves no useful function whatsoever. While it does leave open the possibility of building a Jump-3 ship with only Jump-2 capability, that's such a poor economic decision it hardly warrants modelling. Besides, if you can manage the cash for the rest of the ship, I'm sure you can scrape together a couple credits for a software upgrade.

Edit for clarity: Some software decisions can be meaningful, and thus warrant inclusion. Fire Control is the obvious one, where better systems offer better results, or allow for control of different numbers of weapon systems.

Agreed. I think that for the initial release the book needs this lack of detail. Save the nitty gritty level for the Highguard expansion.

 

[Deniable]

<old geezer mode>
I've seen people try to control the wrong gear with one centralized system. It's not pretty, especially when you're hooking up several thousand tonnes of machine that moves around. Things like laser anti-collision systems want to be sampled many times a second and can swamp an already overloaded controller.
</geezer mode>

My opinion is that the hardware will probably look after itself and the only 'software' needed are for upgrades and improvements to things like targeting.

 

[anselyn]

Folks,

It's always seemed wrong to me that the number of hardpoints scales as the volume of the ship. (Hardpoint#=volume/100)

The surface area of a solid - where you're building those hardpoints - doesn't scale linearly with volume. In fact, it's proportional to V^(2/3).

Now, introducing a power law like this into the game might be a bit OTT if ship construction was being formula based. BUT - as it's table based you can just specify the maximum number of hardpoints possible in the hull table in the rules.

I suggest something like:

Tonnage	Max # Hardpoints
50              1
100             1
200             2
300             3
400             4
500             4
600             5
700             5
800             6
900             6
1000            7
1200            7
1400            8
1600            9
1800            10
2000            10

This was calculated by Hardpoint # = round( (Tonnnage/60)^(2/3)).
The 60 is a scaling factor I chose to get the linear depedendence across the small hulls most commonly encountered CT ships. You can try aother and see what works for you. Note: I put in the 50 for fighters too.

I think this different scaling
I. Makes more physical sense.
II Doesn't interfere too much with classic designs.
(I think it's OK for classic Scout, Marava class trader, the classic SDB and Gazelle CE - but a problem from the old Broadsword Mercenary cruiser.)
III. Means that it's sensible to put bays on bigger vessels becasue there's the room and it uses the hardpoints better.
IV. When you get to bigger Naval ships (in Supplement XX) then it's worth to go big for a spinal mount but you get fewer turrets on your 120,000 ton ship than on the 3 40.000 ton vessels protecting it (etc. scale as appropriate.)

Can we do this - or is 1 Hardpoint/100 tons too much of a shibboleth?

PAS

 

[Andrew Whincup]

I'm on the side of the transparent software people.

If I buy something that needs a computer to operate, I expect the drivers to come with it. If I buy a printer (chosen as an example because there's one on my desk), a modem or a gun turret I expect to be able to use it straight away.

This assumes that you have the computing power to deal with it, any software has min system requirements. I've not had the chance to read V3 yet so I don't know where this would fit in, but I suspect that bridge controls would probably be the place.

This doesn't mean that I'm against being able to buy the software separately if I want an upgrade. Yes my life support works fine with the standard software but there's this package that gives me greater efficiency, definitely worth the Cr.s.

Andy

 

[Border Reiver]

But software selection was fun, yes some of the programs are a bit pointless but the playing around with what can be run at once made things quite interesting.

You are being pusued by a pair of type T's who are after the old man and kid on board, you can't outrun them but in order to make the jump to Rhlylanor you need to drop the Evade or Auto-Repair programs. :shock: It was part of the joy of the small ship paradigm.

 

[Tathlum]

2 of my players know a lot more about programming and computers then I do. No way am I listening to long "interesting" discussions on why such and such is stupid every time I make a ruling on computers/programs.

I'm on the transparency side.

 

[Allensh]

Folks,

It's always seemed wrong to me that the number of hardpoints scales as the volume of the ship. (Hardpoint#=volume/100)

The surface area of a solid - where you're building those hardpoints - doesn't scale linearly with volume. In fact, it's proportional to V^(2/3).

Now, introducing a power law like this into the game might be a bit OTT if ship construction was being formula based. BUT - as it's table based you can just specify the maximum number of hardpoints possible in the hull table in the rules.

I suggest something like:

Tonnage	Max # Hardpoints
50              1
100             1
200             2
300             3
400             4
500             4
600             5
700             5
800             6
900             6
1000            7
1200            7
1400            8
1600            9
1800            10
2000            10

This was calculated by Hardpoint # = round( (Tonnnage/60)^(2/3)).
The 60 is a scaling factor I chose to get the linear depedendence across the small hulls most commonly encountered CT ships. You can try aother and see what works for you. Note: I put in the 50 for fighters too.

I think this different scaling
I. Makes more physical sense.
II Doesn't interfere too much with classic designs.
(I think it's OK for classic Scout, Marava class trader, the classic SDB and Gazelle CE - but a problem from the old Broadsword Mercenary cruiser.)
III. Means that it's sensible to put bays on bigger vessels becasue there's the room and it uses the hardpoints better.
IV. When you get to bigger Naval ships (in Supplement XX) then it's worth to go big for a spinal mount but you get fewer turrets on your 120,000 ton ship than on the 3 40.000 ton vessels protecting it (etc. scale as appropriate.)

Can we do this - or is 1 Hardpoint/100 tons too much of a shibboleth?

PAS

1 hard point per 100 tons is one of those things that keeps making custom ships from requiring an actual Engineering degree. Its a simplification for purposes of playability and on that basis, I am all for it.

In the game "reality", I have always rationalized it as an Imperial law (possibly dating back even further) designed to prevent ships from being so overarmed that they become a target for theft by pirates and other violent types.

Allen

 

[anselyn]

Tonnage	Max # Hardpoints
50              1
100             1
200             2
300             3
400             4
500             4
600             5
700             5
800             6
900             6
1000            7
1200            7
1400            8
1600            9
1800            10
2000            10

In the game "reality", I have always rationalized it as an Imperial law (possibly dating back even further) designed to prevent ships from being so overarmed that they become a target for theft by pirates and other violent types.

Which would mean that other polities would have to have different ship design rules as it's about custom-and-practice not engineering and physical laws. That seems an unhelpful way to take things.

1 hard point per 100 tons is one of those things that keeps making custom ships from requiring an actual Engineering degree.

But the table-based rules presentation means that you don't need one.
Those tables are for designing cutom ships - all the standard ships come with the rules else they're not standard.

Its a simplification for purposes of playability and on that basis, I am all for it.

Oddly, as in I feel odd to be saying this, I don't think playability comes into it. I don't think that the design rules are ever used in game play. (Let's face it, it's part of the more onanistic elements of the rules)

However, I do concede that there might be a usability issue. But actually, if it comes to foolproofing the system for the numerically challenged, it's probably better to have the number of hardpoints stated on the hull table rather than asking everyone to divide a number by 100.

PAS

 

[hdrider67]

Are the values for the ship shares table going to be adjusted as to what these ships actually cost with the design system? because right now the numbers don't match up.

Allen

God god I hope share values stay constant.

Number of shares to buy/remaining, now that should be adjusted.

 

[AKAramis]

Can we do this - or is 1 Hardpoint/100 tons too much of a shibboleth?

PAS

It would break compatibility with CT, MT, and T20 designs BIGTIME... (TNE and T4 have no hardpoint limits! Just a fiddly surface area system.) And, given your scaling factor, it would invalidate all the "Big Ship" (above 10KTd) in major ways.

Truth be told, once you go the surface area route, you wind up adding hull radiators and such, and rapidly, you must have larger weapons with smaller proportional area requirements, since surface area becomes the limiting factor, not volumes nor masses.

 

[Rikki Tikki Traveller]

I see that the ship design system has Bay Weapons, but no Spinal Weapons.

The Gunner skill has Spinal Weapons, but no Bay Weapons.

I suggest that the Gunner Skill be expanded to include Turret, Bay, Spinal and Shields.

You should probably also mention Spinal Mounts as being available on very large ships, but save the details for High Guard.

 

[anselyn]

Truth be told, once you go the surface area route, you wind up adding hull radiators and such, and rapidly, you must have larger weapons with smaller proportional area requirements, since surface area becomes the limiting factor, not volumes nor masses.

OK. That's a good reason to not do it. I can see that once surface area is the main focus then every detail of the configuration, for example, will matter. I guess those 100 tons are abstract structural mass/volume factors that count within the overall structure.

 

[GamerDude]

2 of my players know a lot more about programming and computers then I do. No way am I listening to long "interesting" discussions on why such and such is stupid every time I make a ruling on computers/programs.

I'm on the transparency side.

I agree (as a former comp programmer/IT professional) that getting into that level is stupid. For the game the only software decisions needed to be made are "how much are we willing to spend for this level of accuracy/power management/whatever". The characters don't have the extra 50,000 Cr to get +4 on weapons targeting over +3, then they don't get it.

No need to discuss crap that don't affect nothing.

 

[captainjack23]

Truth be told, once you go the surface area route, you wind up adding hull radiators and such, and rapidly, you must have larger weapons with smaller proportional area requirements, since surface area becomes the limiting factor, not volumes nor masses.

OK. That's a good reason to not do it. I can see that once surface area is the main focus then every detail of the configuration, for example, will matter. I guess those 100 tons are abstract structural mass/volume factors that count within the overall structure.

Additionally, I believe that there is more than enough surface area to mount a VAST number of current-footprint turrets on even a 100dTon ship.

Thus, for any kind of (game) balance, one has to either arbitrarily limit the usable surface area, OR the arbitrarily expand the footprint of the turret the shifting the arbitraryness of the rule from volume to something else.

 

[AKAramis]

Additionally, I believe that there is more than enough surface area to mount a VAST number of current-footprint turrets on even a 100dTon ship.

Thus, for any kind of (game) balance, one has to either arbitrarily limit the usable surface area, OR the arbitrarily expand the footprint of the turret the shifting the arbitraryness of the rule from volume to something else.

The problem isn't the low end, Jack... it is the big end.

Bigger ships have proportionately less surface available for combat purposes since more is taken up by hull radiators...

Surface area goes up as As=6*Vol^2/3
Radiator Area goes up as Ar=PPVol=x%Vol (where x is based upon performance)

so available surface area is roughly (V^2/3)/V function (with a few odd constants thrown at it) so a ship 10x the size has only about 60% the available surface area for weapons...

In TNE this became a very real problem for large ships, some of which could not make 6G simply because the PP radiator area exceeded that of the ship....