FTL rate of movement for GURPS SPACESHIPS

[Agemegos]

Originally Posted by Rupert

If you use Spaceships there's already incentive to use many small ships over few large ones, even for civilian use - the cost per ton is the same, the payload per ton is the same, and the 'small ship fleet' is more flexible.

On the other hand, the larger ships don't need engine rooms and can be automated more cheaply. I recently did a cost study for a particular set of assumptions, and found that a highly-automated SM+12 ship came in 30% cheaper per ton-lightyear than an SM+9 ship with an engine room.

[Rupert]

Originally Posted by Agemegos

On the other hand, the larger ships don't need engine rooms and can be automated more cheaply. I recently did a cost study for a particular set of assumptions, and found that a highly-automated SM+12 ship came in 30% cheaper per ton-lightyear than an SM+9 ship with an engine room.

I assume that's including crew salaries and life support costs, etc. Did you try a SM9- ship with Total Automation of the Engine Room?

I'm curious as to whether the high cost of total automation would be worthwhile in this case.

[ericthered]

I suspect you get better results if you cap the speed gain from size at some point. That sort of thing happens all the time, as different limiting factors take over.



If you want to create a fighter and carrier paradigm, increasing the FTL speed of the fighters is a little odd, unless you intend for battles to be fought with carriers parked in different systems sending fighters back and forth to each other. Also, with many paradigms you end up with the "Carriers" being nothing more than fuel tankers and cargo ships, so watch out for that.

[Agemegos]

Originally Posted by Rupert

I assume that's including crew salaries and life support costs, etc.

Yes, and propellant, insurance, amortisation, depreciation. Also maintenance, repairs, and overhauls of the reaction and FTL engines based on engine hours.

Did you try a SM9- ship with Total Automation of the Engine Room?

No. It seemed to me that total automation is so expensive that you would need really, really low interest rates, insurance rates, and depreciation to let it compete with crew salaries, quarters, and life support.

I'm curious as to whether the high cost of total automation would be worthwhile in this case.

At 8% interest, insurance, & depreciation (which was as low as I dared to go) each workspace totally automated costs G$400,000 per year. Spaceships 2 suggests a crew employment cost of $67,200 per year for base-level crew, plus which it costs G$150,000 (G$12,000 per year) to give them a cabin, $75,000 to give them a shared stateroom or couchette, or $37,500 a bunk in a bunkroom. And $730 per year for consumables. High automation is really marginal at 8%, even with comfortable long-occupancy crew quarters. Only adding foremen to large crews puts it firmly over the top.

If I had ships with very small payload fractions it might be different: total automation of all workspaces and NAI "officers" might mean having no crew habitat at all. But I was at a payload mass fraction of 70% or better, so it obviously wasn't going to work.

I'll take a look after breakfast and get back to you.

[khorboth]

I would expect a couple of interesting results:

1: Carriers would become a real big deal.

2: Ships would have some kind of connection device or coupling connection.

For some applications, staying together is much more important than speed. You don't want your big ship to jump in-system with no support, so attach a few (dozen) small ships to it's hull and have them ready to detach. This is not necessarily a military application, but for an exploratory mission, everybody may want to arrive together and not 3 days ahead of the supply cruiser.

Similarly, having all the ships show up at the same time may be better than being fast. Even with an exponential slow-down, having all 30 invading ships show up at the SAME time instead of over the 5-minute span which is the closest you can get with careful weighing may be worth a full 2-day delay in the plans. Even with careful weighing and math, it may be impossible to time things better than a few hours when systems are days apart. And that can be an eternity in battles.

If these connections double as some kind of emergency towing and/or rescue attachment and are standardized, that's a bonus.

[Agemegos]

My small freighter cost G$207,307.69 per "compartment" of cargo space, and the large freighter G$189,233.33 per "compartment"; the passenger ships cost G$368.846.15 per passenger compartment and G$358,677.78 per passenger compartment. So total automation is more expensive than more/bigger ships as a way of increasing payload, in the situation I modelled.

[Rupert]

Originally Posted by Agemegos

If I had ships with very small payload fractions it might be different: total automation of all workspaces and NAI "officers" might mean having no crew habitat at all. But I was at a payload mass fraction of 70% or better, so it obviously wasn't going to work.

I'll take a look after breakfast and get back to you.

I had a feeling it probably wouldn't be worthwhile. I do wonder how removing the engine room entirely changes things - it reduces crew requirements, and frees up space for more payload. The question is how much the -1 HT and the annoyance of having to do maintenance from outside the ship costs compared to the savings, and I have no idea how best to assess that.

[Agemegos]

Originally Posted by Rupert

I had a feeling it probably wouldn't be worthwhile. I do wonder how removing the engine room entirely changes things - it reduces crew requirements, and frees up space for more payload. The question is how much the -1 HT and the annoyance of having to do maintenance from outside the ship costs compared to the savings, and I have no idea how best to assess that.

You would need to make assumptions about the amount of extra hangar time needed for the maintenance and the increased rate of depreciation. I'd start with the number of staff-hours that the crew in the workstations put in for the amount of extra MRO, and I might start on the costs of lower HT by looking at the rules for extra maintenance costs of Cheap and Used Ships at the top of Spaceship 2 p.28. You could interpret -2 to HT as costing 1% per month in extra maintenance, and -4 to HT as costing 4% per month in extra maintenance, extrapolate a value for -1, and apply it only to the price of systems that would have a workstation requirement if the ship were large.

[Rupert]

I notice that Cargo Holds, even refrigerated ones, do not require any workstations, and thus a ship that is largely cargo spaces will have little increased maintenance with your suggestion. I think both this effect and your suggestion make sense.

As for the OP's thought on making smaller ships faster, how about simply having a cap on speed that varies depending on ship size? If each stardrive/super stardrive produces 5LY per day for each point of power, and the maximum FTL speed is set at something like: 80 - (SM x 5) LY/day, then a SM+6 ship (a little 100 ton scout, FTL shuttle, or heavy fighter) can do a maximum of 50LY/day, and so can't utilise the output of more than five Super Stardrives. A SM+13 ship (a 300,000 ton freighter or major warship, say) can do no better than 15LY/day, and shouldn't mount more than three standard Stardrives or one Super and one standard Stardrive.

This means that for the same speed a large ship is no less mass efficient than a small one, they just can't go as fast.

[AlexanderHowl]

While it lends itself to certain types of adventures, a faster FTL speed for smaller spacecraft distorts everything. Why have capital ships when you can use the same tonnage in automated bombers to accomplish the same military goals faster? Why have merchant haulers when you when you can use the same tonnage in automated cargo pods to accomplish the same commercial goals?

By having smaller spacecraft go faster, you remove any economic or military reasons for humans to be in space. Now, if your group wants to play AIs, that is fine, but I think that would get boring after a while, as there would be no particular reason to allow robotic bodies on the drone. After all, a robotic body would count against the cargo/weapons available to the drone...