Supporting continuing development for Empyrean Challenge / Cluster Wars
You are not logged in.
Another idea -- FOOD should decay over time. Or food storage should consume LFS capacity (at some fraction). Or "hard tack" style food (freeze-dried) could be made, but would require extra inputs and/or a higher tech level.
Extending the idea:
A component remains functional throughout combat as long as it isn't damaged beyond the threshold. But instead of "magically repairing" at the end of combat, some combination of CNW or SLD would repair damaged components by consuming MTSP. Repairs "beyond the threshold" would require double the MTSP. CNWs would be more efficient, and could handle many more repairs, than SLD. Anything that doesn't get repaired to within the threshold gets destroyed/scrapped. Anything that remains damaged will not function until it is repaired. This would make a case for building repair ships, MTSP freighters, etc.
I am a software developer. I'm no genius, but I can write code, design objects, etc. If you would like some help, let me know. If not, that's fine. I can stick with design suggestions, playtesting, and commentary.
Looks like you're fixing the biggest problem with Command Central -- that it is a MS Access app, with all sort of limitations.
The next fix I'd suggest it make order-writing and ship-design leverage easier UI elements. Maybe I use a slider to move half my fuel to the OBC, for instance. Or maybe quantities can be bumped up or down in 10% increments instead of typing in values and percentages. This would make turn entry on a phone considerably easier.
Add more click-and-drag wherever it makes sense, particularly in moving ships around, docking ships, and transferring/targeting ships.
I'd be interested in 1, 2, and 3. In other words, I'd suggest architecting this such that each game can be modded or configured independently. I might want to try a game where the cost of each new tech level goes up exponentially instead of linearly, for instance. I've also suggested a few other rules mods/additions.
But if the popular consensus is to focus on just #1 (replicating CW as faithfully as possible), I'd still be interested.
I will note that Vern himself modified the game more or less continuously.
One thing I have advocated for in the past was that FRM consume not just energy, but also LFS capacity. Farms on OPC would not have this requirement, but in any other S/C they would. This would model the fact that it takes considerable water and atmospheric management to maintain plant growth. It would also model animal farming -- livestock consume prodigious quantities of water, plant materials, etc. In the real world, farm consumption of water dwarfs all other uses.
Interesting problem. If the ship takes 10,000 damage, and that damage is applied randomly across all components (by mass or volume), then necessarily there will be components that take far less than full damage. My sense is that Vern used logic such that if the SEN-1 (in your example) took a hit, it would soak off 3000 worth of damage before any further damage is calculated. This might have simplified things, and prevented the problem of what to do about a SEN-1 that takes just 1 damage (is it destroyed or unharmed?) But it left open the question of what would happen if the ship were hit with 1000 damage, and the first thing hit is the SEN-1. It's not enough damage to destroy the component altogether, unless the logic determines that ANY amount of damage destroys the component.
If the SEN-1 must absorb 3000 damage before being destroyed, then an unlucky 1000-damage hit on a ship might be completely negated if it hit that SEN-1 first.
If the SEN-1 (and all other components) is targeted one damage point at a time, then either everything would get knocked out very quickly (assuming each component is disabled upon the first single hit) or everything would be quite robust (assuming each component remains fully functional until it absorbs its last hit).
You could model each component as its own object, keeping stats on how much damage it has absorbed, but that might end up being murderously fat in terms of data and processing power. Or you could go with your damage-threshold idea. Any component that is damaged UNDER the 50% threshold remains fully operational, and is magically-repaired at the end of combat. And component damaged OVER the 50% threshold is inoperable, though that component can continue to absorb hits *during that combat* (and soak off damage that might hit something else). At the end of combat, it would be destroyed. And of course, any component that takes 100% damage is immediately destroyed.
Seems like a good compromise between accuracy and insane computation. Maybe the damage threshold could even vary. Maybe HEN is delicate, with a 30% threshold, while SPD is heavy and solid, with a 70% threshold.
You could also add something akin to the old "MTSP" stuff -- military supplies. That was supposed to be an abstraction for ammo, medical supplies, hull-repair equipment, necessary after any combat operation. You could revive that, maintain a damage stat on every component that remains from one turn to the next, and have CNW pop consume MTSP to repair components after combat.
This would add a dimension of battlefield repairs, ships with disabled engines, etc. Could be wild.
I remember using STUN as buffering armor. If I remember correctly, any of the structural unit types (STUN, LTSU, SLSU) were equally useful for armor, if you go by mass. My understanding was that hits applied are allocated randomly, so if you over-built STUN by a large margin, it would in effect soak off damage. If half your ship's mass is STUN, then half the damage gets sunk right there.
The problem is that this abstracts away something that is actually interesting to model. From the perspective of physics and narrative theme, armor is entirely different from bulkheads and cargo holds. As a ship builder, if you're going to maximize the utility of ship-mass in warding off damage, you're not just adding extra staterooms and hallways all around your ship. You're building plates of armor, or ablative surfaces, or collapsible frames, or angled mirrors, etc.
Given everything else that is modeled in Cluster Wars, it makes sense to model armor, too. Also, I remember the ship design stuff in Traveller, where they had different hull configurations that conveyed different combat properties. You could build a sleek, needle-like design, but get only 10% of the internal volume for a given investment in hull, for instance. Such a hull would allow the ship to land on atmospheric worlds, and would be much harder to hit in combat.
You could go for a big block or sphere, which would maximize internal volume and minimize exposure, but limit maneuvers and how many weapons you can bring to bear.
Or you could go for a "dispersed structure", in which your ship has components welded on with no regard to compactness or volume efficiency. It would be the cheapest hull for the volume, but have sharp limits to maneuverability and any incoming damage would be maxed out.
I believe they also had options for using hollowed out asteroids as hulls -- cheap and pre-armored with a rock/ice buffer, but slow!
A very simple way to model this would be to just add an "armor" component, which can be researched and upgraded. Some percentage of incoming damage must hit armor first, and armor gets destroyed by damage just like anything else.
A little more modeling? Maybe add 2 types of armor -- one for missiles ("traditional" armor plating), and one for energy weapons ("mirrors" or sand-casters). Maybe the traditional armor plating blocks both kinds, but is considerably heavier.
Maybe add a "hull configuration" element to ship design. Compact/sleek hulls take less damage and/or get more protection from armor, but need to spend some multiple of STUN/SLSU for any given ship volume. Bulk hulls maximize ship volume, get moderate advantage from armor, but can't ever have structural modifications once built. Dispersed structure hulls get minimal advantage from armor, get penalties to speed, and can be modified/expanded any number of times.