Simplified power grid. #771
Replies: 3 comments 2 replies
-
|
I like it. Have you considered that your deactivation priority could be something the crew gets to select instead of it being statically assigned? Choosing when and how systems fail creates for some interesting tradeoffs. It also seems like Shields and other "This thing only works with a constant draw" systems probably need a dedicated battery, since they require drawing down power to keep the shield going, right? It's not like the ship is running copper wires since it's all plasma and sci-fi magic, right? So, the consequences of overdrawing the grid can be made up, but probably involve heat and inefficiency? Just thinking about the "brown out" scenario and what that looks like practically. Is it too much to suggest each system needs a "flaky power" mode (sensors gets grainy or glitchy, maybe phasers discharges energy back into the grid but in a way that's spiky, comms channels shut down or experience higher error rates). Is this system measured in unspecified Units of power, Watts, Volt-Amps, etc? Is there a layer that's "Under the hood" where damage control or other functions can see actual waveforms of power, including spikes and stuff as they happen? |
Beta Was this translation helpful? Give feedback.
-
|
Deactivation priority is static for simplicity sake. I actually did have something similar in the original power grid implementation, but it was so confusing, I decided to do away with it. If crews want to control how ship systems are deactivated when they need more power, they can manually deactivate them. Re shields — I think it's important to be able to direct power specifically to shields. It's not possible to specifically direct power at batteries in this setup, for simplicity sake. Batteries charge when there is a positive net reactor output. So shields will continue to be implemented with a pseudo battery that is separate from the power grid. I did consider altering shields to make it so they only draw power (past the minimum power required when they're activated) when hit, but that makes it difficult to determine what the shield integrity is, since a single battery could be powering multiple ship systems. Power conduits use space magic and as of right now cannot be damaged. That said, overdrawing the present-day electrical grid causes generators to speed up or slow down which alters AC phase and frequency, causing extra heat, noise, and probably wear. That's the basis for the reactors taking the brunt of power grid overloading. Brown outs were considered, I decided they're too complicated to be worth implementing. It would require modeling both current and voltage, which does not sound like a fun time. Flakey power is an interesting idea, but sounds more annoying than its worth. Systems either have power, or they don't. Power is measured in megawatts and megawatt hours (and megawatts per second, for how quickly reactors can power up, which is a fun unit that you shouldn't think about too hard). I've thought about adding power graphs, but haven't gotten around to it. It wouldn't be hard — I'd do it entirely client-side with a rolling window with the power of each system over time. |
Beta Was this translation helpful? Give feedback.
-
|
One downside to this approach is that there is no obvious way to allow systems to overdraw power to operate more effectively at the cost of decreased efficiency/more heat. Every system will draw up to their configured max power and no more. Engines have emergency/destructive impulse which intentionally draws more than the maximum power. Perhaps we could do the same with other systems, like only recommending x number of sensor scans, but allowing more sensor scans which draws more than the configured max power. That's something that can easily be added on later, on a system-by-system basis. The principle remains that the officer that engages the system determines how much power it draws, not the officer that distributes the power. |
Beta Was this translation helpful? Give feedback.
-
|
Inverting who controls the power draw is a neat mechanic and definitely a good idea. If a flight is made up of the main story, cross-team collaboration, side stories involving one or a small portion of the crew (more common on bigger crews, I think), and lastly busywork/mini-games, then I think this helps elevate power balancing from mini-game to cross-team collaboration, which is a really good thing.
Having each system handle its own "efficiency" (backed by heat + cooling, e.g. deeper scans take more power) and then report back how much power it's consuming as a result, and then the "power grid" simulation basically becomes sampling power consumption at some frequency as you proposed. If there's overdraw, then circuit breakers flip like you said until you're no longer overdrawn, and you have to flip them back on in order to re-activate the system. They'll flip right back off if the system would still be overloaded, maybe there's a "cooldown period" or something.
For a physical set, this opens the door to an actual power distribution panel with physical switches (and having looked around, organ stop switches could be great for this since you can remotely toggle them if the breaker "pops").
I do think that the power distribution officer should still be in charge of the breakers. Having one person in charge of controlling whether or not a system is able to draw power enhances the collaboration/politics on a crew. If a system is down, it needs repair and it needs power restored still, but the amount of power to be drawn is its own thing.
I suppose this even opens the door to a "start up sequence" (at the start of a flight or after a repair) where something like this happens (let's assume sensors but this generalizes):
- Sensors officer wants to activate the sensors grid. They have to ask power distribution to flip the breaker to bring it online.
- If power distribution officer is concerned about power availability for some reason, they may ask sensors for how much power will be required, since once you flip the breaker the system will start drawing power. Sensors should have the system configured in a low-power mode so you don't overdraw, but it makes for some "fun" friction if you flip the breaker and the system overdraws, and brings down something unexpected instead.
- Once you have the system online, you gradually start to increase the power draw by using more and more parts of the system (bigger scans, etc.).
I think that scenario only makes sense if you don't have ample power generation. Under the model you're exploring here (which I like) it seems like it would make cold starts much, much harder (which I don't know if I like that - seems like it throws a wrench in storytelling ability if it's not easy enough to get unstuck, since I doubt cold starts will be a routine task so running into that scenario could be very frustrating for a crew).
For that reason, it could be that you can't enable a circuit breaker until there is a stable supply of power provisioned to get the system you want to enable online. Basically, you have stable state consumption (whatever the officer using the system is up to) and you have "start state" consumption (some higher level threshold that ensures you don't start a system without having enough available capacity to get things moving?
Just some rough-cut thoughts, hope some of that is helpful. I like the direction - especially elevating power management from "this is busywork" to "this is pushing the crew to collectively make tradeoffs".
…-------- Original Message --------
On Thursday, 05/28/26 at 09:00 Alex Anderson ***@***.***> wrote:
One downside to this approach is that there is no obvious way to allow systems to overdraw power to operate more effectively at the cost of decreased efficiency/more heat. Every system will draw up to their configured max power and no more.
Engines have emergency/destructive impulse which intentionally draws more than the maximum power. Perhaps we could do the same with other systems, like only recommending x number of sensor scans, but allowing more sensor scans which draws more than the configured max power.
That's something that can easily be added on later, on a system-by-system basis. The principle remains that the officer that engages the system determines how much power it draws, not the officer that distributes the power.
—
Reply to this email directly, [view it on GitHub](#771?email_source=notifications&email_token=AAAK7Z2WF35TTHGAE4NIAET45BBAZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZQHEZDAOJZUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17092099), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAAK7Z5WIGBHFCGVNYX2PML45BBAZAVCNFSM6AAAAACZPXZMI2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMBZGIYDSOI).
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Note that I mention this was inspired by the work Matt did building a power distribution panel for the CMSC. Lots of credit goes to him.
Yes, this will be the case. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Here we go again.
There has been a lot discussed about power already.
I'm not satisfied with the Systems Monitor/Power Distribution card.
For starters, it has information overload — too much going on to be able to understand what's important with a glance. Much of the important information, like heat, battery charge, and fuel level, are inscrutable. Meanwhile the yellow lines and orange squares provide no indication of what they are or why they're important. There's no visual hierarchy, no organization, Its just madness.
A rule of thumb that I use when designing features and user interfaces is whether a 10 year old can understand whats going on. We're nowhere close to that with this card.
I've tried multiple times to tame this beast, and keep feeling like there has to be some way to both simplify this while keeping it more interesting and impactful than Thorium Classic's power distribution card.
So, third times the charm.
This is a long section of context, feel free to skip if you want to see the new design.
Here's what I want:
In Thorium Classic, there's just a single bucket of power that combines the output of the reactor and battery. If you use too little power, it charges the battery. Use too much and you drain the battery. Drain it too much, and... nothing happens unless the Flight Director gets on your case.
It's simple, elegant, and a little unrealistic, since ship systems draw the power that you assign to them, not the power that they're actually using. Hence the third point in my list.
I thought that the complication was the fourth point, since it implies discrete assignment of power sources to systems, which means each little power square comes from a specific power source. In previous iterations, each system had little lines connecting it to power sources. That's what seemed complicated to me.
Then I had a chat with my friend Matt who has spent the last several months designing and building a hardware panel that adds a power grid simulation to Thorium Classic. His eye-opening insight was that the problem was actually in the squares of power themselves.
Those squares are how systems in Thorium Classic say how much power they use. In Thorium Nova, power use is based on system use. So what do those little power squares mean in Nova? Mere power limiting — preventing the system from drawing more power than is allotted to it.
There's another way to limit power — just not using the system as much. As far as I can tell, every ship system except shields has a built-in method for regulating how much power is used by it. Either it only uses a certain amount of power, like life support, or its degree of use dictates how much power it uses, like engines. (Shields currently draw as much power as is provided to them to charge — more about shields later).
This means that preventing power grid overloads is the responsibility of all crew members, with the Power Distribution officer providing guidance to the captain and crew about what systems can be used at that time based on the state of the power grid. This is in line with Requirement 4 of Thorium Nova's North Stars.
So, clearly what needs to be done away with is the power bars themselves.
For this to work, we need to define some mechanics.
Reactors
Reactors consume fuel to generate power. Reactors have an optimal output where the ratio of power to fuel consumption is maximized. Overloading the reactor by consuming more fuel produces excess heat and generates less power per fuel unit. A warning will be provided when the reactor is overheating or running out of fuel so the crew can address the problem by transferring fuel to the reactor.
The ship is equipped with multiple reactors, but each reactor has overhead, so running all reactors at a low output is less efficient than running a single reactor at its optimal output. Reactors also have a lengthy start-up time before they start producing power. Deciding when to turn on or off reactors will be an important responsibility.
Likewise, when more than one reactor is running, there will be an efficiency bonus for having both reactors set to the same output. The ideal situation is when each running reactor is set to the optimal output.
Batteries
Batteries serve two purposes: Supplementing reactors to provide a greater total available power, and buffering reactor output in case of abrupt power demand changes and spikes.
Batteries store excess power from the reactors and distribute it to systems requesting power from batteries. Systems don't automatically pull power from batteries — they have to be specifically assigned a battery that they draw power from when the reactor doesn't supply enough power.
When the reactors produce more power than is used by the ship systems, excess power is distributed evenly between batteries that are not yet full. When all systems are satisfied and all batteries are full, any excess power is absorbed by the reactors, causing them to rapidly heat up. It's actually wise to not fully charge batteries to provide a place for extra power to go when necessary.
In the default ship configuration, batteries come in three flavors:
Ship Systems
Each ship system has a minimum power consumption, and then draws more power based on usage. By default, all systems draw power from the reactors. Optionally, a single battery can be assigned to a ship system.
A switch will allow the system to be isolated from the reactors, relying on battery power alone or deactivating altogether. Any deactivated systems will not draw their minimum required power from the reactors, so any systems that are not being used should be deactivated.
Some ship systems cause power spikes, including torpedo firing, activating warp or impulse engines (a "ramp up" power draw), sending long range messages, etc. If these power spikes aren't buffered by sufficient reactor output overhead or a connected battery, they can cause disruptions in the power grid. In other words, don't jump to warp or fire torpedos without waiting for your batteries to recharge. (As an aside, this is reminiscent of the power systems in the top down space shooter game Ares).
Power Grid Simulation
The simulation takes the following steps:
Drawing power from batteries first makes it easier to determine the net reactor power. It also has the benefit of discouraging attaching multiple systems to a single battery, since the battery will slowly discharge if the power drawn from the battery by all of those systems is greater than the net reactor output divided by all of the batteries.
When the reactors don't produce enough power — the net reactor output is negative — the power grid will shed its power load by forcibly deactivating ship systems in a priority order (with the priority statically defined by the system type), with high priority systems like life support, communications, and sensors remaining on while low priority systems like the cloaking device, signal jammer, and tractor beam are deactivated. In other words, when the simulation step is complete, the net reactor output will always be greater than or equal to 0.
So, a word of advice: if you don't want systems to deactivate, make sure you've got proper battery buffers in place, unused systems are deactivated, and you are running the right number of reactors.
Individual System Considerations
Shields were mentioned as an example of a ship system that has no maximum power draw — as currently implemented, if allowed, it will pull all possible power to charge the shields. As part of this implementation, shields will be given a control which determines how much power to draw when charging the shields.
Warp and Impulse engines have the ability to rapidly change the power usage by increasing or decreasing speed. To more clearly demonstrate causal power relationships, if increasing the engines power will cause the net reactor output to go negative, instead of deactivating the lowest priority system, it will deactivate the engines entirely.
Likewise, if there isn't enough power to address a spike when activating engines, firing torpedoes, or sending long range messages, that action will fail.
Phasers will continue to have their charge based on the power stored in the battery attached to the phasers. Their output will be determined by the power output of their battery. Firing phasers many times in a short period requires having a lot of excess reactor power.
The job of Power Distribution is to:
Each component of the systems monitor card helps them fulfill that job:
The reactors have controls to increase or decrease output, view heat and fuel consumption, and activate or deactivate the reactor.
The batteries show the current charge, net charge change (whether charging or discharging), max output, and current output.
Systems show heat, current power draw, max possible power draw, and controls for activating or deactivating the system and changing which battery the system is drawing power from. Systems with multiple power levels, like warp and impulse engines, will show what their current max output is. Systems that can spike, like torpedoes and long range comm, will show indicators if the system doesn't have enough power headroom to handle a spike.
The goal is for anyone to ask any question about power needs and for the Power Distribution officer to have an answer at a glance.
Major props if you made it through all 1800 words. As usual, feedback is welcome — questions, comments, suggestions, or pointing out things that I missed or overlooked.
Beta Was this translation helpful? Give feedback.
All reactions