Fixin' to Fix

With your feedback from the previous post, I think we've come up with a great setup for damaging and repairing ship systems. It will make the game more realistic and fun, get rid of busywork, and giving the crew more agency for how they fix their ship. Let me explain.

How Systems Get Damaged

For starters, systems aren't just damaged or not damaged - there is a spectrum of how damaged a system is, represented by the efficiency. This is how well a system turns power into work.

However, there still needs to be some kind of threshold that keeps a system from being used at all. This will be configurable, but by default, when a system falls below 50% efficiency, it will be completely inoperable and can't be used until the efficiency is increased to 80% through repairs.

Naturally, we don't want systems to fail at a critical point during the mission, so Flight Directors and timelines can mark systems as "Invulnerable" which will prevent the system from taking any damage. Likewise, narratively-irksome systems can be marked as "Vulnerable" which ensures they'll take lots of damage and quickly become inoperable.

But when real-life objects are damaged, they might show that damage in a number of ways:

• More noisy
• Distorted images on a screen.
• Less likely to behave correctly.

We're extending this to damaged systems as well. So far, we've come up with these different dimensions of damage:

• Efficiency - how well a system turns power into work
• Heat generation rate - how fast a system generates heat when consuming power
• Stability - the chance that a command sent to that system will trigger an unexpected error and have to be retried by the crew
• Signature - adds to the sensor signature of the ship and makes it easier for the ship to be detected and followed
• Spontaneous catastrophic failure risk - the chance that the system will completely break
• Cascade failure risk - if the system completely breaks, the chance the system will add damage to other systems on the ship
• Safety rating - danger to crew members that are in proximity to the system
• Hacking vulnerability - how easy it is for a hacker to exploit the system

Do you have more ideas for how systems can represent their damage? Reply to this discussion

And naturally there are different ways that systems can become damaged in the first place which will affect how they are repaired:

• Electrical
• Heat
• Structural
• Mechanics
• Plumbing
• Radiation
• Contamination
• Computer
• Corrosion
• Fatigue
• Cryogenic

This applies to both how the damage is created in the first place and what reports the crews will have to complete to repair the damage.

As a quick aside, both the types of damage and the damage properties are non-configurable and hard-coded into the engine, since the way they interact with other aspects of the simulation are difficult to model in an expandable way.

Let's talk about how to fix this damage.

Repairing Damaged Systems

Instead of long-form reports that Thorium Classic uses, Thorium Nova will have mini maintenance reports that will be up to 3 steps long, but as short as a single step. Completing the mini report will immediately apply repairs to the system.

Maintenance reports will be automatically generated on-demand. The crew can pick a ship system, see all of its current damage properties, and generate several possible reports for that system to improve the property they want to improve. Most often they'll want to improve the efficiency, but they might choose to specifically decrease the signature or the heat rate of a system. The reports that are generated are based on that system's current damage types. So electrical damage will require an electrical damage team, plumbing damage will use a pipe-focused mini-game (yes, there will be mini-games - more on that soon).

But there are some big catches: maintenance reports might apply changes to more than just the system the crew member was hoping to repair. In-universe, we have to be scrappy to repair things in the middle of space. This might turn out either good or bad. For example, replacing the power conduits to the Warp Engines might provide residual improvements to the Sensors.

On the other hand, rerouting coolant lines from the torpedo launchers to the phasers might improve the efficiency of the phasers to the detriment of the torpedo launcher's heat rate. Or fixing the noisy signature of the communications antenna so the ship can be more stealthy might also introduce a catastrophic failure risk. Such is the cost of cutting corners, but at least they can get fully refurbished when the ship gets back to dock.

All of these buffs and nerfs to the damage status of systems will visible to the crew before they pick a step to start working on, so they know exactly what they're getting into so they can weigh their choices based on what the crew needs and what risk they're willing to accept. And the reports will be balanced such that each report is a net positive towards the overall function of the ship. Ruthlessly completing every report will never cause more things to get broken than are fixed.

But the crew will only be able to generate a handful of reports per-system so they don't just keep rolling the dice to get an ideally randomized report. Reports will have expiration times that the crew can see. When they expire, the report will disappear and new reports can be generated. And crew's aren't limited to doing just one report from a batch - they can do all of them, generate new ones, and do all of those too (though they'll need to weigh the negative consequences too!)

However, it will be possible for a Flight Director to define (or assign through the timeline) reports which have expiration side-effects, like a critical coolant leak report that will cause additional damage to the ship if it isn't fixed before the report expires. Because who doesn't love a dramatic countdown timer?

In fact, this style of damage control gives the Flight Director more power to assist the crew without sacrificing realism by magically fixing the system the crew is struggling to repair. A ship-wide maintenance multiplier will increase the effectiveness of repairs. The Flight Director could add a 2x multiplier, which takes a "improve efficiency by 10%" and makes it 20%! Or the opposite, and using a 1/2x multiplier to require more reports to get the same gains for crews that are just eating up damage reports.

---

This is way more complicated than Thorium Classic, but we think it will be way more interesting and fun for the crew and Flight Director.

• It gives the crew agency. They not only get to pick which system to repair, but how to repair it and what the consequences (good and bad) of their repair will be.
• We want there to be obvious, quick wins for the crew to maintain a positive gameplay loop. Instead of trudging through a 10 step report and not seeing results until the very end, each completed step will improve the properties of the system.
• It makes it easier to procedurally generate individual random steps than a full cohesive report.

Last detail: Maintenance reports are implemented using the same tools as timelines - there will be steps which the report will progress through, each step will be able to define actions which will execute and checks which will see if the crew has completed the task for that step. This provides unlimited flexibility for how these reports are constructed, and opens the possibility for Flight Directors to assign longer reports for specific plot points in missions or standard procedures for their particular simulator.

And that's it. Feel free to get in touch if you have any other ideas.