mike wightman
SOC-14 10K
The major change with power plants in FF&S 1+2 is the very low fuel requirements.
A few displacement tons lasts for a year.
A few displacement tons lasts for a year.
FFS3 for T5
- Thread starter robject
- Start date
An attempt to create a Book 2-friendly TL12 fusion power plant.
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Technical Architecture Device/Module Specification (TADS/TAMS):
KAM Name Type/TL Vol Power fuel/wk MCr
---- ---------- ------------------------ ----- ----- ------- -----
TAMS, Type A , Fusion Module/12 , 4, 2, 2, 8
TAMS, Type B , Fusion Module/12 , 8, 4, 4, 16
TAMS, Type C , Fusion Module/12 , 12, 6, 6, 24
TAMS, Type D , Fusion Module/12 , 16, 8, 8, 32
TAMS, Type E , Fusion Module/12 , 20, 10, 10, 40
TAMS, Type F , Fusion Module/12 , 24, 12, 12, 48
TAMS, Type G , Fusion Module/12 , 32, 16, 16, 64
TAMS, Type H , Fusion Module/12 , 36, 18, 18, 72
TAMS, Type J , Fusion Module/12 , 44, 22, 22, 88
TAMS, Type K , Fusion Module/12 , 52, 26, 26, 104
TAMS, Type L , Fusion Module/12 , 60, 30, 30, 120
TAMS, Type M , Fusion Module/12 , 68, 34, 34, 136
TAMS, Type N , Fusion Module/12 , 76, 38, 38, 152
TAMS, Type P , Fusion Module/12 , 84, 42, 42, 168
TAMS, Type Q , Fusion Module/12 , 92, 46, 46, 184
TAMS, Type R , Fusion Module/12 , 100, 50, 50, 200
TAMS, Type S , Fusion Module/12 , 110, 55, 55, 220
TAMS, Type T , Fusion Module/12 , 120, 60, 60, 240
TAMS, Type U , Fusion Module/12 , 130, 65, 65, 260
TAMS, Type V , Fusion Module/12 , 140, 70, 70, 280
TAMS, Type W , Fusion Module/12 , 160, 80, 80, 320
TAMS, Type X , Fusion Module/12 , 180, 90, 90, 360
TAMS, Type Y , Fusion Module/12 , 200, 100, 100, 400
TAMS, Type Z , Fusion Module/12 , 240, 120, 120, 480</pre>[/QUOTE]</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Technical Architecture Device/Module Specification (TADS/TAMS):
KAM Name Type/TL Vol Power fuel/wk MCr
---- ---------- ------------------------ ----- ----- ------- -----
TADS, Type A , Fusion Device/12 , 56, 500, 28, 8
TADS, Type B , Fusion Device/12 , 112, 1000, 56, 16
TADS, Type C , Fusion Device/12 , 168, 1500, 84, 24
TADS, Type D , Fusion Device/12 , 224, 2000, 112, 32
TADS, Type E , Fusion Device/12 , 280, 2500, 140, 40
TADS, Type F , Fusion Device/12 , 336, 3000, 168, 48
TADS, Type G , Fusion Device/12 , 448, 4000, 224, 64
TADS, Type H , Fusion Device/12 , 504, 4500, 252, 72
TADS, Type J , Fusion Device/12 , 616, 5500, 308, 88
TADS, Type K , Fusion Device/12 , 728, 6500, 364, 104
TADS, Type L , Fusion Device/12 , 840, 7500, 420, 120
TADS, Type M , Fusion Device/12 , 952, 8500, 476, 136
TADS, Type N , Fusion Device/12 , 1064, 9500, 532, 152
TADS, Type P , Fusion Device/12 , 1176, 10500, 588, 168
TADS, Type Q , Fusion Device/12 , 1288, 11500, 644, 184
TADS, Type R , Fusion Device/12 , 1400, 12500, 700, 200
TADS, Type S , Fusion Device/12 , 1540, 13750, 770, 220
TADS, Type T , Fusion Device/12 , 1680, 15000, 840, 240
TADS, Type U , Fusion Device/12 , 1820, 16250, 910, 260
TADS, Type V , Fusion Device/12 , 1960, 17500, 980, 280
TADS, Type W , Fusion Device/12 , 2240, 20000, 1120, 320
TADS, Type X , Fusion Device/12 , 2520, 22500, 1260, 360
TADS, Type Y , Fusion Device/12 , 2800, 25000, 1400, 400
TADS, Type Z , Fusion Device/12 , 3360, 30000, 1680, 480</pre>[/QUOTE]
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Technical Architecture Device/Module Specification (TADS/TAMS):
KAM Name Type/TL Vol Power fuel/wk MCr
---- ---------- ------------------------ ----- ----- ------- -----
TAMS, Type A , Fusion Module/12 , 4, 2, 2, 8
TAMS, Type B , Fusion Module/12 , 8, 4, 4, 16
TAMS, Type C , Fusion Module/12 , 12, 6, 6, 24
TAMS, Type D , Fusion Module/12 , 16, 8, 8, 32
TAMS, Type E , Fusion Module/12 , 20, 10, 10, 40
TAMS, Type F , Fusion Module/12 , 24, 12, 12, 48
TAMS, Type G , Fusion Module/12 , 32, 16, 16, 64
TAMS, Type H , Fusion Module/12 , 36, 18, 18, 72
TAMS, Type J , Fusion Module/12 , 44, 22, 22, 88
TAMS, Type K , Fusion Module/12 , 52, 26, 26, 104
TAMS, Type L , Fusion Module/12 , 60, 30, 30, 120
TAMS, Type M , Fusion Module/12 , 68, 34, 34, 136
TAMS, Type N , Fusion Module/12 , 76, 38, 38, 152
TAMS, Type P , Fusion Module/12 , 84, 42, 42, 168
TAMS, Type Q , Fusion Module/12 , 92, 46, 46, 184
TAMS, Type R , Fusion Module/12 , 100, 50, 50, 200
TAMS, Type S , Fusion Module/12 , 110, 55, 55, 220
TAMS, Type T , Fusion Module/12 , 120, 60, 60, 240
TAMS, Type U , Fusion Module/12 , 130, 65, 65, 260
TAMS, Type V , Fusion Module/12 , 140, 70, 70, 280
TAMS, Type W , Fusion Module/12 , 160, 80, 80, 320
TAMS, Type X , Fusion Module/12 , 180, 90, 90, 360
TAMS, Type Y , Fusion Module/12 , 200, 100, 100, 400
TAMS, Type Z , Fusion Module/12 , 240, 120, 120, 480</pre>[/QUOTE]</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Technical Architecture Device/Module Specification (TADS/TAMS):
KAM Name Type/TL Vol Power fuel/wk MCr
---- ---------- ------------------------ ----- ----- ------- -----
TADS, Type A , Fusion Device/12 , 56, 500, 28, 8
TADS, Type B , Fusion Device/12 , 112, 1000, 56, 16
TADS, Type C , Fusion Device/12 , 168, 1500, 84, 24
TADS, Type D , Fusion Device/12 , 224, 2000, 112, 32
TADS, Type E , Fusion Device/12 , 280, 2500, 140, 40
TADS, Type F , Fusion Device/12 , 336, 3000, 168, 48
TADS, Type G , Fusion Device/12 , 448, 4000, 224, 64
TADS, Type H , Fusion Device/12 , 504, 4500, 252, 72
TADS, Type J , Fusion Device/12 , 616, 5500, 308, 88
TADS, Type K , Fusion Device/12 , 728, 6500, 364, 104
TADS, Type L , Fusion Device/12 , 840, 7500, 420, 120
TADS, Type M , Fusion Device/12 , 952, 8500, 476, 136
TADS, Type N , Fusion Device/12 , 1064, 9500, 532, 152
TADS, Type P , Fusion Device/12 , 1176, 10500, 588, 168
TADS, Type Q , Fusion Device/12 , 1288, 11500, 644, 184
TADS, Type R , Fusion Device/12 , 1400, 12500, 700, 200
TADS, Type S , Fusion Device/12 , 1540, 13750, 770, 220
TADS, Type T , Fusion Device/12 , 1680, 15000, 840, 240
TADS, Type U , Fusion Device/12 , 1820, 16250, 910, 260
TADS, Type V , Fusion Device/12 , 1960, 17500, 980, 280
TADS, Type W , Fusion Device/12 , 2240, 20000, 1120, 320
TADS, Type X , Fusion Device/12 , 2520, 22500, 1260, 360
TADS, Type Y , Fusion Device/12 , 2800, 25000, 1400, 400
TADS, Type Z , Fusion Device/12 , 3360, 30000, 1680, 480</pre>[/QUOTE]
daltoncalford
SOC-12
Hi Robject,
Our house system, which is still in the early stages made the following assumptions.
1.) Although a world may have a lower tech level than the highest available to their culture/empire, they will import standard modules.
2.) All newly discovered technological practises are retrofitted into new design methodologies that will spread out from their source.
3.) Levels of efficiency are different depending upon the designer/manufacturer (This is a full subject onto itself if you are interested)
4.) Standardised costs do not apply, as prices change depending upon availability/demand.
What the above assumptions did was have one of our group create statistics for a series of Mega-Corps (using and expanded version of 101 corporations from Bits).
Those statistics allowed us to drop the values into a self calculating database (firebirdSQL with stored procedures and die-rolling mechanics). The database dumped out a series of standardised modules that we autonamed via a random naming/numbering scheme (still being worked on).
That gave us a series of drag and drop items to be used in vehicle design (space ships are just big vehicles with extra design requirements).
Most of the standard ships have been redesigned using the system, at each tech level. So there is a TL 7 scout all the way up to a TL 15 scout.
(Our TL scale is different and caps out at 15 while the imperium is at TL10)
The reason we did this was to have a game mechanic reason why a player would want a hiver vs a zho item. What I am trying to do now is a series of standardised text templates that would describe the items we designed (so that the system makes its own ad copy).
If you are interested in any of this let me know.
Best regards
Dalton
Our house system, which is still in the early stages made the following assumptions.
1.) Although a world may have a lower tech level than the highest available to their culture/empire, they will import standard modules.
2.) All newly discovered technological practises are retrofitted into new design methodologies that will spread out from their source.
3.) Levels of efficiency are different depending upon the designer/manufacturer (This is a full subject onto itself if you are interested)
4.) Standardised costs do not apply, as prices change depending upon availability/demand.
What the above assumptions did was have one of our group create statistics for a series of Mega-Corps (using and expanded version of 101 corporations from Bits).
Those statistics allowed us to drop the values into a self calculating database (firebirdSQL with stored procedures and die-rolling mechanics). The database dumped out a series of standardised modules that we autonamed via a random naming/numbering scheme (still being worked on).
That gave us a series of drag and drop items to be used in vehicle design (space ships are just big vehicles with extra design requirements).
Most of the standard ships have been redesigned using the system, at each tech level. So there is a TL 7 scout all the way up to a TL 15 scout.
(Our TL scale is different and caps out at 15 while the imperium is at TL10)
The reason we did this was to have a game mechanic reason why a player would want a hiver vs a zho item. What I am trying to do now is a series of standardised text templates that would describe the items we designed (so that the system makes its own ad copy).
If you are interested in any of this let me know.
Best regards
Dalton
That's a very clever automation scheme. If there's anywhere you might like specific suggestions, I'd be glad to brainstorm.
Since I'm sticking close to existing print, I probably won't be able to steal any of your product, though I am going to dwell on your process a bit.
Since I'm sticking close to existing print, I probably won't be able to steal any of your product, though I am going to dwell on your process a bit.
This is a bit premature, but I'm trying out the scripts I've developed so far to produce the skeleton of a TL12, 5000 ton, maneuver-5, jump-5 vessel.
A 5000 ton 5G vessel requires 25000 tons of thrust. The maneuver drive stats are:
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Technical Architecture Device/Module Specification (TADS/TAMS):
KAM TL Name Type Vol TT MCr Power
---- -- ---------- ------------------------ ---- ----- ------ -----
TADS, 11, E5k/11 , M-Drive Device/11 , 3333, 25000, 500, 30000MW
TAMS, 11, E5k/11 , M-Drive Module/11 , 238, 25000, 500, 120EP</pre>[/QUOTE]The 120EP power plant is actually the Type Z:
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Technical Architecture Device/Module Specification (TADS/TAMS):
KAM Name Type/TL Vol Power fuel/wk MCr
---- ---------- ------------------------ ----- ----- ------- -----
TADS, Type Z , Fusion Device/12 , 3360, 30000, 1680, 480
TAMS, Type Z , Fusion Module/12 , 240, 120, 120, 480</pre>[/QUOTE]And Jump-5, just to be safe:
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Technical Architecture Device/Module Specification (TADS/TAMS):
KAM TL Name Type Vol JU MCr
---- -- ---------- ------------------------ ---- ----- ------
TADS, 12, EJ512 , J-Drive Device/12 , 8811, 25000, 1250
TAMS, 12, EJ512 , J-Drive Module/12 , 629, 25000, 1250</pre>[/QUOTE]The grand totals:
Drive & Power volume: 1107 tons
Fuel required: 2740 tons/2 weeks
Cost: BCr 2.2
A 5000 ton 5G vessel requires 25000 tons of thrust. The maneuver drive stats are:
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Technical Architecture Device/Module Specification (TADS/TAMS):
KAM TL Name Type Vol TT MCr Power
---- -- ---------- ------------------------ ---- ----- ------ -----
TADS, 11, E5k/11 , M-Drive Device/11 , 3333, 25000, 500, 30000MW
TAMS, 11, E5k/11 , M-Drive Module/11 , 238, 25000, 500, 120EP</pre>[/QUOTE]The 120EP power plant is actually the Type Z:
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Technical Architecture Device/Module Specification (TADS/TAMS):
KAM Name Type/TL Vol Power fuel/wk MCr
---- ---------- ------------------------ ----- ----- ------- -----
TADS, Type Z , Fusion Device/12 , 3360, 30000, 1680, 480
TAMS, Type Z , Fusion Module/12 , 240, 120, 120, 480</pre>[/QUOTE]And Jump-5, just to be safe:
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Technical Architecture Device/Module Specification (TADS/TAMS):
KAM TL Name Type Vol JU MCr
---- -- ---------- ------------------------ ---- ----- ------
TADS, 12, EJ512 , J-Drive Device/12 , 8811, 25000, 1250
TAMS, 12, EJ512 , J-Drive Module/12 , 629, 25000, 1250</pre>[/QUOTE]The grand totals:
Drive & Power volume: 1107 tons
Fuel required: 2740 tons/2 weeks
Cost: BCr 2.2
I've been thinking that one way to model ship components is using a factory paradigm: components consume a resource and produce something in return. The efficiency by which this is done, the volume required to perform this conversion, and the price of the item are dependent upon the component's tech level and the process itself.
daltoncalford
SOC-12
The nice thing is, the system will generate ships with the same component/statistics that book two or highguard generates. (I have not compared MT since it is a little confusing for me).
You just say that MDrive A is a "FluSen 4800 drive that was accepted as a imperial standard design, Imp Lic 3892-9384 granted in the year 872 as part of the system unification overhaul mandated by the Imperial family, Redundancy and availability where prioritised over size and efficiency"
The size, statistics all stay the same as book two. The UDP (Universal Design Profile) can be adjusted to produce multiple different engine designs with different statistics all from one base calculation.
We did this to explain all the different 'standards' that a single formula would not support.
This was prompted by one of our gear headed refs complaining about the 1 dton hardpoints vs the 7 dton hardpoints.
That lead us to redesign the entire ship design process that was halted until we came up with a new starship combat system.
I let the guys go away and stew on the combat system, we then played a few combat only games (the guys loved it, the girls took the kids and went shopping.....lots of beer consumption ensued that had all the wives pass their 'dirty looks and guilt trip' tasks with extraordinary results) After I was finished repainting the kitchen, living room and dining room, installing new hardwood laminate I was able to once again think about gaming.....
best regards
Dalton
daltoncalford
SOC-12
Hey Robject, if you are designing a system, you need to know what is important to the game and what is unnecessary cruft.
For example, a referee wants to know the nitty-gritty about a ship so they can extrapolate a single item into a adventure (with enough flexibilty to not step on creativity)
A player wants to know 'how is this better in game terms so I can use it to 'WIN' (even though there is no winning in this kind of game, it is a mentality) They don't really care about the history of the item, just as you don't care what colour laser is in your dvd player.
When a game is in session, you need to know just enough to handle the current situation. You don't need to know that you are using "mdrive A" you need to know that you have 2G acceleration.
So, before you design a 'design system' you should first review the underlying game mechanics that system will be used to generate.
Whose game mechanics are you going to go with?
best regards
Dalton
mike wightman
SOC-14 10K
Dalton's made some really good points here.
The ship design rules must mesh with the combat rules, which in turn should fit with the skill/task system chosen.
The ship design rules must mesh with the combat rules, which in turn should fit with the skill/task system chosen.
Dalton is echoing the points that Jeffr0 also made over the summer. And I agree with them. Problem is, I haven't got the time to do it right, and I don't know enough about meshing combat with designs.
Jeff's suggestion was to figure out how combat works, then build the design system based on the requirements fed into combat.
Since I'm gearing this system to output Book 2 elements, presumably Book 2 combat is the target rules. That means I don't have to think about it.
I can change my mind after this is done.
Jeff's suggestion was to figure out how combat works, then build the design system based on the requirements fed into combat.
Since I'm gearing this system to output Book 2 elements, presumably Book 2 combat is the target rules. That means I don't have to think about it.
I can change my mind after this is done.
By the way, Dalton, when I talked about the component factories, I was thinking aloud as a programmer.
My goal has been to create a design system that approaches Fire, Fusion, and Steel in its lowest level, but produces modules compatible with Book 2.
As I progressed, I realized some JavaScript code would be nice for testing out my rules. From there the code has evolved into a nearly generic engine. And then I realized that the scripts could be greatly simplified by looking at component generation as kind of Factory software design pattern, except the thing designed isn't software, but a component for Book 2 starship design.
In other words, each set of linear progressions can be modeled in software as a black box, with some tunable factors (Tech Level, Input Efficiencies, Resolution), and a single input -- call it "required strength". The output would be a line of text, or a structure if you prefer, listing the volume, power requirements, fuel requirements, and cost.
In fact, that Black Box I just described is nearly generic enough to be used for all components in starship design. All you need to do is tune each box to produce the desired results, and your coding is done.
Sorry about the confusion. I was designing software at that point, not designing a SDS.
My goal has been to create a design system that approaches Fire, Fusion, and Steel in its lowest level, but produces modules compatible with Book 2.
As I progressed, I realized some JavaScript code would be nice for testing out my rules. From there the code has evolved into a nearly generic engine. And then I realized that the scripts could be greatly simplified by looking at component generation as kind of Factory software design pattern, except the thing designed isn't software, but a component for Book 2 starship design.
In other words, each set of linear progressions can be modeled in software as a black box, with some tunable factors (Tech Level, Input Efficiencies, Resolution), and a single input -- call it "required strength". The output would be a line of text, or a structure if you prefer, listing the volume, power requirements, fuel requirements, and cost.
In fact, that Black Box I just described is nearly generic enough to be used for all components in starship design. All you need to do is tune each box to produce the desired results, and your coding is done.
Sorry about the confusion. I was designing software at that point, not designing a SDS.
daltoncalford
SOC-12
Robject,
As I have stated before, I am a bit of a workaholic. (understatement is my forte).
It is my birthday, the office is taking me out for lunch. Most people would have a slow settled day. I have just started the installs of 6 new servers, built a new Raid 50 San stack. Replied to 32 emails in three languages (I have had some people take my email ramblings on other more technical lists and translate them into multiple languages). Now, I am relaxing, and answering my other secondary forums (COTI is not where I normally hang out) while having a database generate 5000 years of future history from the hiparocus database and my civilization model.
That gives you an idea of what I do, now to say why. My mind does not stop. Wish it did, but it goes on and on in a million directions. Combine that with a background in programing, roleplaying and 60 wps typing skill and you have huge amounts of crap being generated, tested and dumped, with only the best (IMHO) surviving.
My biggest difficulty is my lack of skill with the written word. I take six pages to detail something when a paragraph would suffice.
If you want help, creating a unified gaming system, I am willing to support your efforts.
I already have a working system that you are more than welcome to use/hack/ignore.
Best regards
Dalton
daltoncalford
SOC-12
My background goes back many years and programing languages (most of them are long dead). My first language was card based and was called HYPO.
Currently I program in bash, c, c++, sql, perl, html, pascal. My forte is sql, as I currently manage a dev team of 16 programmers who support a multi-terrabyte database.
Where most people use a spreadsheet, I knock off a multi-generational database instead.
Best regards
Dalton
Here's the skeleton for the Type A2.
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Technical Architecture Device/Module Specification (TADS/TAMS):
KAM TL Name Type Vol JU MCr
---- -- ---------- ------------------------ ---- ----- ------
TAMS, 12, Type B , J-Drive Module/12 , 15, 400, 20
KAM TL Name Type Vol TT MCr Power
---- -- ---------- ------------------------ ---- ----- ------ -----
TAMS, 11, Type A , M-Drive Module/11 , 2, 200, 4, 1EP
KAM Name Type/TL Vol Output Fuel MCr
---- ---------- ------------------------ ----- ------ ------ ------
TAMS, Type A , Fusion Module/12 , 4, 2, 2, 8</pre>[/QUOTE]Total volume required so far: 63
Plus 64t (Bridge: 20t, Staterooms: 40t, Air/raft slip: 4t)
Total: 127t
Cargo: 73t
That's about 12 tons more free space than the original. Are my calculations correct?
</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;">Technical Architecture Device/Module Specification (TADS/TAMS):
KAM TL Name Type Vol JU MCr
---- -- ---------- ------------------------ ---- ----- ------
TAMS, 12, Type B , J-Drive Module/12 , 15, 400, 20
KAM TL Name Type Vol TT MCr Power
---- -- ---------- ------------------------ ---- ----- ------ -----
TAMS, 11, Type A , M-Drive Module/11 , 2, 200, 4, 1EP
KAM Name Type/TL Vol Output Fuel MCr
---- ---------- ------------------------ ----- ------ ------ ------
TAMS, Type A , Fusion Module/12 , 4, 2, 2, 8</pre>[/QUOTE]Total volume required so far: 63
Plus 64t (Bridge: 20t, Staterooms: 40t, Air/raft slip: 4t)
Total: 127t
Cargo: 73t
That's about 12 tons more free space than the original. Are my calculations correct?
mike wightman
SOC-14 10K
Emm, jump fuel?
It's implied in your 63dt, but I can't see it in the table.
You end up with more space because of the reduced power plant fuel.
This is a good thing IMHO.
It's implied in your 63dt, but I can't see it in the table.
You end up with more space because of the reduced power plant fuel.
This is a good thing IMHO.
