Min/maxing isn’t bad, until it is. What enables a fully optimized build or flowchart is perfect knowledge of physical numbers. Real-world optimization is constant struggle against the vagaries of quantum mechanics, the incomplete nature of general physics, and the raw depth of pixelation in the system. In a game? high-level objects are often described in fullness by a concise notepad document and can be further compressed into raw mechanics and shorthand notation. Solving game optimization is easy- but only so long as you can see the numbers at work and have a certainty in their mechanism of function.
Hide the numbers, lampshade them with lore that approximates the game statistics, energy imparted at [x] distance under testing conditions, energy ranges, newtonian values (already done with propulsion systems).
Similarly, take away the clean data and percentages in the healthbars and charge groups, give flat color-coded indicators:
- Orange (Overheating) - Flashing Indicator, Intermittent Buzzer
- Blue (95%+)
- Green (80%~95%) - Intermittent Warning Blips
- Yellow (60%~80%) - Repeating Warning
- Red (20%~60%) - Steady Alarm, Klaxon and Lights
- Black (0~20%) - Silence
Another thought to add to this dynamic is letting damage over a certain amount, determined however, from hull class ratings to a model-specific value, deal overheat damage to modules. Hitting this threshold on shields puts overheat ticks on low-slots; armor thresholds tick over low and mid slots; hull threshold puts overheat ticks on everything.