RTG feels too powerful (or power generation is unbalanced)

This is such a difficult balance issue. I'm essentially fighting the laws of physics to get any of it to work. I have a single unit that needs to charge a battery that all other units will use the charge from to run at night (albeit at a reduced production rate to make it more reasonable). A potential solution might be to increase the number of required solar panels to charge the reserve battery from the electrical module. So then in that situation it would require 2 RTGs (or double the number of current solar panels) connected to the electrical unit to provide the charge rate that you've described above. I would have to add more solar panel connection slots and another RTG slot though to accommodate for a change this significant. Thoughts?

Actually, you are not fighting the laws of physics, you are fighting an oversimplification which you chose to use yourself instead of making things work as they in fact do (or as close to it as it's reasonable in a game), which approach created an unsolvable anomaly. This anomaly already manifested itself in the day/night power mode difference, for which you hacked a workaround in (reduced duty cycle during the night), but that addressed only a symptom, not the cause. This RTG issue is just another manifestation of that anomaly, and the real solution is to rethink and rework the entire power system, by eliminating the one single and fundamental flaw: the power output of the panels being defined as a unitless percentage, and what's worse, that percentage meaning a different amount depending on what the panel is installed into, instead of a real fixed charge capacity per panel.

Let me explain:

All four units draw "100%" power each, whatever unit of measurement that may represent (maybe we could call it buccaneer-samurai, and then we aren't even accused of, erm, borrowing that name from elsewhere ;), to work per any chosen time frame or "tick". During the day, it needs to come from the solar panels (or the RTG), during the night, it needs to come from the battery. However, the battery also needs to be charged during the day so that you can take this 100% per system out during the night too. This means that during the day you actually need a total of 800% power per tick, 400% to run the units, and another 400% to put into the battery. And that 800% (or close to it, due to the aforementioned hack covering some of what's missing) is actually what's being generated, only it's reported as 4x 100%. Oxy, heat and water generate 3x 100% with 3x 100% panel input, while electrical generates (by my guesstimation) 500% with only 100% panel input.

And this is the anomaly itself: a large panel generates "50%" power when installed in oxy/water/heat, but it generates "250%" when installed in electrical. And the RTG does the same, except it generates that both day and night, so a single RTG effectively generates "500%", being able to cover more than all units combined need.

And the solution is to move away from this unitless, percentage based power scheme, and actually measure the power draw of the systems, and the power generation of the individual solar panels, in a very specific power measurement unit internally; you can still display the supply/demand in percentage to the player, but those percentages result from calculations done based on comparing the actual and specific power units produced and consumed in the background.

Here's how it could work:

Each system consumes 100 units per tick when turned on. This means that each needs to have a total solar panel capacity of 100 units per tick installed. But this only covers their power need during daytime when theres input. To harvest enough reserve power for the night, they need twice as much, so 200 units per tick power input needed for the duration of the daylight period. This also means you don't need the hack for "slowing down" the systems at night anymore, since instead you will simply make sure you harvest enough power to begin with. When this 200 units input is met, the system displays 100%, while internally only 50% is used locally, and another 50% is sent to the battery (when electrical is turned on and functional to manage the power flow; if/when electrical is not running, the excess is not sent to the battery and simply lost). Battery capacity needs to be large enough to hold 400 units per however many ticks are in the period of time when panel output is not at 100%, or preferably even larger to allow "overcharging" to store reserves for short power outages.

However, since power generation is not uniform throughout the day, the total power units harvested will be less than needed for an entire day. The simplest solution is to just offset the power used vs. power sent to storage ratio to, say, 90/110, so that while input is not yet 100%, the missing amount is still drawn from the leftover reserve from the previous day (since you know the actual numbers, you can make a better estimate of by how much the effective mean power generation is lower during the day, as in, ramping up from 0 to 100%, staying there for a while, then dropping back to 0, which will result in a mean value of something less than 100%, and that is by how much the used/stored ratio needs to be offset). Then there's a 5th "system" which may also need to be charged: the EVA suit when the player is in the Hab, so let's spread it's overhead across the 4 systems and set, say, an 85/115 used/stored ratio for each (creating a 20 units / tick charge capacity for the suit).

Now this means that we have an 800 units power pool per tick to fill: 340 units is to be consumed to run the systems, and 460 units is to be sent to storage (of which 20 units may get sent into the suit instead). From the side of power generation, it's a total of 800 units input needed, 200 per system, potentially spread across 5 solar mounts per system. If we want to keep the current panel amounts, then it means a large panel supplies 100 units (50% of 200), a small one supplies 60 (30% of 200) and a portable supplies 40 (20% of 200, tho I think the portable should be less, as it's not even half as big as the small one yet provides 65% of it's output; 20 units/10% would fit better to its size, which would be perfect when conisdering we set aside 20 units for the suit, so when the portable is used on EVA, you indeed get 20 units from it). The power output (in units) of the panels then would get reduced by local light levels as dictated by time of day and storm density. And an RTG would provide 85 units per tick, day and night, so this system, if powered only by the RTG, would be "power neutral", it would not produce charge nor draw from the reserve.

Now, this approach still has one simplification in terms of how the power state of the systems is displayed: 100% means the system actually gets 200% input, 100% to be used and 100% to be stored. When running on panels, this wouldn't really be an issue, but when an RTG is installed, this would result in showing only 42,5%, even tho that would be correct: with panels, it's 100% (200 units) for half a day then 0% for the other half, with the RTG it's constant 42,5% (85 units). If needed, this could be addressed by splitting the power display into two values: local and charge. When the solar panels start generating power and their output goes from 0 toward whatever the maximum installed is, it would first increase the "local" display to 100%, then once local demand is met, the excess harvested would get directed to the battery, so "charge" would also start to rise to however many units are actually provided. For example, 200 units worth is installed and it's early morning with only 30% panel efficiency at the moment, so it's only 60 units provided vs. the 85 units needed to run just the system with nothing left to send to battery (the missng units would be actually drawn from the battery, and thus the system would be in "yellow" state), so it would read as "Local: 70,5%, Charge: 0%". Later in the day with 80% panel efficiency at that time of day, you have 160 units provided so you have the local 85 (85 out of 85) covered and have another 75 (75 out of 115) to send to battery, so it's now "Local: 100%, Charge: 65%". And then the RTG would always just show "Local: 100%, Charge: 0%" as it generates constant 85 units, 85/85 local use covered with 0/115 for charge (and if you had panels added to that, then the panel output would just change the charge value based on current efficiency).

All this would also make it possible to individually differentiate the power use of the 4 systems, to reflect what would be "realistic" for them, instead of a uniform power consumption. You could "weight" the systems differently so that they still add up to a total of 340+460 (use+battery charge), but by running/not running one or the other you could save more or less power, for example, during a storm. One possible weighting could be 55 units for electrical (hab lighting, airlock, computers, all the other appliances inside), 75 for oxy (mostly pumps, magnetic valves, the electrolysis unit, control electronics), 115 for water (pumps, control electronics, and some heat generation method for melting the ice which needs a lot of power) and 95 for the heater (control, air compressor/pump, and the heating elements which are again high power components), while their excess could simply be uniformly 115 sent to the battery, or also adjusted to result in 200 units total for each to match the solar panel capacities.

I didn't want to make the above post even longer...

What also could work, and would be closer to the current method, is a much simplified version of the above solution paired with the removal of the 100% hardcap on power utilization per system regardless of actual power, and loss of any excess (which never made sense to me anyway).

Let's just say each system consumes 100 units (important, not percent, units, everything is still in units, percentage is only for display) per tick, day and night. When you have less than that provided to one particular system from local source, at any time of day, the missing amount is drawn from the battery. When you have more than that provided from local source, the excess is not lost, unlike currently, but sent to the battery to charge it. There is no artificial cap: if you install 5 large panels to any one system, you get all of the provided charge, the amount not used locally being sent to the battery as long as electrical is operational and turned on to route the charge. So you don't need to magically create the reserve battery charge out of nowhere in the electrical system like currently, instead, it is actually and visibly provided by each system itself in the form of above 100% power, assuming you can achieve it by adding the required amount of power input. And again, the battery needs to have a capacity of at least, but preferrably slightly more than 400 units (or the combined power unit needs per tick of all the systems if it's a different amount for each) times however many ticks are there in the not producing period of the day.

In practical terms it means that if you see less than 100% power on any system during the day, that one has a power deficit and you need to add more panels or you will run out of reserve power even during the day. If it has 100-200%, then you have enough power for it during the day, but will run out of reserves during the night. And if it has more than 200%, then it generates enough to run constantly (from local power during the day while also charging the battery, and during the night from the reserves it accumulated for itself during the day).

The power unit capacity of the panels would be the same as above, 100 units for the large, 60 units for the small and 40 (20?) units for the portable. The difference would be that when 2 large panels are installed, you will now see 200% power, since that's how much the unit actually needs during the time it can generate power versus during the time it can not, to be fully supplied for an entire day: 200% for half a day then 0% for the other half = 100%. The RTG would also be 100 units, but you only need one of those per system: 100% for the day and also 100% for the night, not adding to nor drawing from the battery.

This would also make it possible to set different power needs (less/more than the uniform 100 units) for each system, to give more room to contol power need by having to choose what can you turn on and what you can not when power input is limited (storm, lack of panels), only the display percentages won't look so nice due to the needs possibly not matching the stepping possible by mixing the sources (combination of 100/60/40).

Lots of interesting suggestions. I do like the idea of having the surplus charge from other units help contribute to the reserve battery. It's actually something I've been considering for a long time. The difficulty comes in how to best communicate these systems to the player. It's one thing to allow the surplus to contribute to the reserve battery charge, and it's another to literally require a "surplus" in order for the modules to have enough power to run overnight. The concept might be better communicated by only requiring 50% power for module operation while 100% equates to adequate operation and charging for night use. If I went this direction I think I would probably reduce the number of solar panel slots per module from 5 to 3. That way the max power generation would be 150% per module. Basically there are just a lot of things that might be obvious to someone who understand the complexities of electrical engineering, but in a gameplay scenario I somehow have to tutorialize anything that isn't super obvious to the average joe. Making these systems sufficiently complex to result in dynamic gameplay scenarios, but simple enough to understand within the first 20 minutes for a new player is a difficult balance.

There is one thing that was never really clear to me (and your wording may hint at that you intended it to be the second): does the Electrical system itself use power when turned on, or it's only supposed to generate charge for the battery? If it does not use power, then what powers the Hab itself? There are the internal and external lights, ther airlock doors, the compressors/pumps for the airlock, the computers and other displays inside, the trafting tools, the (currently only make believe) kitchen equipment, etc. And even then, Electrical would have to be able to generate 3x as much power than each of the other systems, since it needs to produce enough reserves for the night for all 3 of them, and yet, it requires only one set of solar panels, not 3. So this is one thing that needs to be made consistent and clear, which it currently isn't at all: all 4 systems (need to and) do consume power, and each need to produce enough to run and to make reserves for itself for the night.

And then saying if 100% is when you have enough input to run the system during the day without external supply, or when you have enough to put sufficient reserves away for the night too is just the matter of how you define it, so, sure, 50% when no leftover and 100% when enough leftover for the night works just as well. However, then we're back to the issue of 100% not being really 100% due to the reduced effectiveness in the morning and evening, so you'd again have to offset the consumed/stored ratio to make 100% truly mean you have enough to run for a whole day... or expect the players to realize that on their own, and experiment with by how much they need to go over 100% to have the power actually last through the night (which might kill them on their first night so not much experimenting will go on in that game anymore).

Reducing panels slots may not be a good idea. The players won't necessarily have enough large panels to use only those for all systems, and when they have less, only 3 mounts per system may not be enough to fully power all systems. Granted, you could just expect them to actively manage power drain in this case by having to choose one system which they need to turn off for the night. And it would be an even bigger issue when a storm reduces power output to 15%; even with 5 large panels you'd only get 75 units for any system with the current balance, while they need 100 just to function without producing reserve, which means you need to start saving power a few days prior a storm to have a fully charged battery when it arrives, and even then, you'd be able to operate one, maybe two systems only during the day when you have at least a partial charge. Not necessarily a bad thing, but it would likely kill the player the first (few) times before they realize this.

If you insist on limitng the excess that can go towards charging the battery, then the better way is to go back to a hardcap: no matter how much input is installed, only a maximum of 300 units (150%) per tick will be taken into account / displayed of it, and the rest is ignored. It actually even makes sense, since power supplies and their internal components are rated for a maximum load / current, and their output increases only up to that point, no matter if their feed would be able to provide more.

Thanks for all your input here. I'll definitely be considering this in the near future.

"Basically there are just a lot of things that might be obvious to someone who understand the complexities of electrical engineering, but in a gameplay scenario I somehow have to tutorialize anything that isn't super obvious to the average joe. Making these systems sufficiently complex to result in dynamic gameplay scenarios, but simple enough to understand within the first 20 minutes for a new player is a difficult balance."

Well, the electrical side of things is actually nothing different from, let's say, your calorie system, and is that too difficult for the average Joe? It certainly fits with Mr. Fusion's suggestion to make systems use units instead of percents, with the unit being the (kilo)Watt.

Energy stored (battery capacity, or calories in my analogy) is in kWh, or kilowatts times hours. Each solar panel/RTG produces a number of kW ("calories per hour"), depending on weather conditions, time etc. Multiply this with the amount of hours it has been producing, and you've got the amount of kWh ("calories") you can add to the battery charge ("calorie pool"). For example, let's say you want to check what your equipment's new status is after a hypothetical checking interval of 1 minute. If your panel produces 120 kW ("cals/hour") under current conditions, for this 1 min you can add 120/60=2 kWh ("calories") to the battery charge. The connected heater uses 30kW, so it requires 30/60=0.5 kWh from the battery charge. Leaves you with a working heater and 2-0.5=1.5 kWh which you can add to the battery charge to use at night.

As you can see it isn't too different from your calorie system at all: walking uses x calories per second, so walking for 10 seconds requires 10*x calories from the calorie pool. Using a heater requires x kW, so using a heater for 10 hours requires 10*x kWh from the battery charge. Not too difficult, is it? :)

An added advantage is that you can base your power requirements on real-world systems. For instance, a quick google search shows it takes 1kWh to produce 160g of O2 from water (https://www.quora.com/How-much-water-can-you-split-into-hydrogen-and-oxygen-using-electrolysis-with-one-kilowatt-hour-of-electricity). A reasonably good solar panel produces some 0.2 kW per m2 (https://www.theecoexperts.co.uk/how-much-electricity-can-i-generate-solar-panels) so with today's tech you'd need around 1/0.2=5 hours of good sunlight to produce 160g of oxygen with a 1m2 solar panel. The Tesla Model S 100D has a 100kWh battery, so on a single charge you could produce 100*0.16=16kg of oxygen. Charging the same battery with 10 1m2 panels would take 100/(10*0.2)=50 hours of good sunlight.

Of course you could display the power generation in a percentage of consumption, similar to how it looks now. But I agree with Mr. Fusion that this percentage needs to derive from calculations done in another unit rather than be the unit itself, and the most suitable unit of energy is the kilowatt hour.

Or maybe the simpler solution is to just say that RTGs can't be used to charge the reserve battery for some technical reason and just remove the RTG connection slot for all electrical modules. Then you are forced to chose some other exterior module to use the RTG with.

This would be just yet another hack, not addressing the issue, only forcibly covering another symptom.

Why not just work with kW(h) in your calculations? Physically correct, and shouldn't be too hard.

I'm an electrical engineering student, so if you've got any questions regarding power calculations, don't hesitate to ask :)

I'm working on this right now and I think I've found a relative balance between my desired gameplay and a more realistic implementation of power management. Much of it comes from the wonderful suggestions here.

Since I haven't done the actual kWh calculations (and I'm not sure I want to get to that level of granularity yet since you don't need to know that stuff to understand the basics - "power in" needs to be greater than "power out"), so I'm going to use the "per tick" cost basic math.

RTGs generate 100 per tick, day and night.

Large Solar Panels generate 50 per tick during the day.

Small Solar Panels generate 30 per tick during the day.

Portable Solar Panels generate 20 per tick during the day.

There are still only the 5 solar panel slots and one RTG slot for each module, but now they all contribute directly to the reserve battery so long as the electrical module is operational. However, now there is a maximum of 100pt charge from any set of module slots. That means the most you can generate during the day would be 400pt from all 4 modules.

Then, all the modules also incur a general per tick cost that pulls from the reserve battery in order to operate.

• Water Reclaimer

• 50pt cost to produce water.

• 40pt cost to keep water filtered and in liquid form if tanks are full.

• If at least 50pt is being supplied by solar panels/RTG directly connected to this module then water production is more efficient.

• Reoxygenator

• 50pt cost to produce oxygen.

• 40pt cost to keep air filtered and circulating if tanks are full.

• If at least 50pt is being supplied by solar panels/RTG directly connected to this module then oxygen production is more efficient.

• Heater

• 50pt to heat up interior to normal temp.

• 40pt to keep temp stable if at normal temp.

• If at least 50pt is being supplied by solar panels/RTG directly connected to this module then temp will increase faster if below normal temp.

• Electrical

• 25pt to keep all electrical systems running (lights, crafting, etc).

From the above requirements, the highest possible cost per tick to keep all systems running would be 175pt, but if all oxygen and water tanks are full and the interior temp is stable then the cost would only be 145pt. This means that you should be banking between 225pt and 255pt if you have the full 400pt of solar panels connected to your modules during the day. Which should be more than enough to cover the cost of all modules over the night.

The only thing that is difficult to balance for with this system (though it was equally hard to balance with the old system) is whether or not this will provide enough surplus battery charge to use for transferring to your suit for EVAs. This will simply need to be playtested. Though, even having a single RTG would greatly alleviate most worries related to power management since you would be generating 100pt even during the night.

Above you will also notice the incentives to have at least 50pt of solar panels/RTG connected to each of the three main modules. This, along with the 100pt limit of charging per module, I think will add some additional power management considerations for the player rather than just making all the panel slots effectively just be extensions of the slots for the electrical module. I wanted it to be more strategic than just putting 400pt of panels wherever you want.

I’m looking for your feedback on this setup before I put it out in the public beta build. It will also require some major changes to the UI and help text. Let me know what you think!

At a quick glance, it looks good. Fairly simple and straightforward, while removing the behind the scenes "magic" that needed for the previous implementation to work.

I don't think it would actually matter if you did all the research needed to figure out what would be reasonable numbers if you wanted to express estimated power needs of such systems in kWh (not to mention what would you base the estimates on for something we never built/used yet, maybe if there are such info for the ISS available that could be used as a baseline, still, they don't generate water and oxygen the way the habs do); what the "power unit" itself is doesn't matter as long as the calculations made with them are consistent and the whole thing works as a closed system. Maybe it would be needed if you wanted to give the player a more detailed way to manage power by knowing exactly how many units are being produced and used over any given timeframe so that they can decide which system is best to be turned off when low on power, but that might be simply too much for some players to want to care about. "Do I see 100% on the systems? Yes, then all is fine. No, then I may need to save power by turning something off." That should be enough from a gameplay perspective.

A simple enough additional feedback could be that the hab system view (the detailed one) could give an estimated charge/drain rate (over some period) instead of just saying "charging" and "draining" so that if it says something like "76.4% (-17.2% per [timeframe]), then the player would be able to estimate how long will it last under these conditions, and recheck after having turned one or another system off to see if that lowered drain to the point where it may still be negative but at least lasting until charging is expected to pick up again.

I like the idea of "producing" and "maintaining" states of the systems. I actually made a note about suggesting something similar at one point, actively manageable by the player, but this implementation is simpler from a gameplay perspective (and doesn't need additional UI elements) and does effectively the same. It also gives a bit of room for balancing: you can slightly reduce the maintain mode power drain a bit if more unused charge is needed. It may worth keeping in mind that the heater and water systems will be the most likely to run in low power mode (heater almost always, water occasionally), while oxy will likely never, so those two would make more impact with their difference between high/low power mode.

You could also do the same dual mode thing for electrical: when the player is not in the hab, the power drain could drop by 5-10 points; internal lights could get turned off, computers go standby, appliances/tools not used etc. It would also add a bit of overhead to be sent to the battery.

As for the suit, if you consider how much electricity that might use/be able to store compared to what the hab and its battery does, it should be a tiny amount, like, 2-5 units/tick, maybe, and even that should charge the suit fairly quickly. You could simply establish a power draw scheme similar to that of the hab systems: heating needs up to this much (depending on external temp, I suppose), light draws this much per tick when turned on, scanner needs this much per tick when turned on, and I want the suit to be able to run for x ticks with a single recharge, so how big the battery should be? And then set the charge draw to get a reasonable charge time with that capacity needed to be filled, and use that as additional drain while the suit is charging. Currently you have a 25-55 units/tick overhead (more if you adjust the low power drain state of some systems, the ones more likely to spend more time in that state), so if you can fit it into that budget with maybe a little leftover, it should be good (the suit will not draw power indefinitely, only for a limited amount of time, after which it will drop off the power draw side of the budget anyway).

Hmm, actually, I think the RTG should be only 50 points per tick, since it will supply that constantly, not just during daytime (you need two large panels, or 100 units, input per system because they have to produce what the system draws now plus what it will still draw when there's no panel input). That way, when installed into heat/water/oxy, that one system will become power neutral (or rather, 0 or +10 depending on current power mode), and electrical will be always power positive (+25).

If it was 100, it would still supply two systems' worth of power, while the intention was, I believe, for it to supply only one, but regardles of sunlight availability.

Sadly, this still creates the issue of an RTG supplied system showing only 50% charge... Or maybe you could add an exception for the system display that if an RTG is installed, then it simply displays 100% all the time. Hacky, but I don't really see a good way to get around this problem.

Umm, no, scratch that, it's not a solution to hack the power display to 100% with an RTG installed, because you can still have solar panels installed and effective in that system. The RTG provides 50 units of the 100 units cap, and solar panels can provide up to another 50. If the display was a fixed (and fake) 100%, then the input added by the solar panels would not get displayed anywhere (eg. RTG + small panel should display 80%, not 100%).

This requires explaining in the systems manual that the "sufficient" charge level is 50% or more when an RTG is installed, and no less than 100% (actually, with the low power mode factored in, it's, umm... 95%, maybe?) when only solar panels are installed. Not intuitive, but either that, or the RTG will still be as "broken" as it is now if it's set to generate 100 units only to avoid this display oddity.

Or, back to approaching from the other direction... 50 units input = 100% charge display (local drain met), 100 units = 200% charge display (local drain plus reserve charge production met), with the cap being 100 units / 200%. Still needs an explanation regarding an RTG producing 100% day and night equalling to solar panels producing 200% during the day and 0% during the night averaging to 100%.

Third option: if an RTG is installed, solar panels in that system simply become ineffective. Basically, RTG locks the charge display to 100% (via the hack; you could even replace the charge percentage with a text saying "Constant RTG supply" or something to better convey that this system behaves differently than the solar powered ones), and that system adds a fixed 50 units / tick to the battery regardless if any panels are installed or not. Put this into the general systems manual document (if you have an RTG installed, you can/should remove solar panels since they won't do anything anyway), and it's kind of solved.

Yeah. I've been considering most of the options you've outlined. Basically, I think the new system works as an elegant solution to the original problem, and now I'm just down to figuring out how best to communicate the functionality of the new system to the player.

The one functional change you've added here that I do like is changing the RTG to generate only 50 since that is day and night. That does make sense to me, again, I'll just need to consider how best to communicate these changes.

I think that in general I would like to skew towards transparency. As much as possible of the bulleted post I made above should be explained in game somewhere so that players can make informed choices about which systems to turn off/on when in dire survival situations. I just need to decide how much of that info should be immediately represented via the habitat and module status screens and how much should just be in the module user manuals. I think I can find a good balance. I'll let you know when the new power management system is available on the public beta branch.

Your input here has been invaluable. Thanks so much!

Beta Test is up now: http://steamcommunity.com/app/252090/discussions/0/2381701715721445297/

I'll be putting this live today. Going to mark this topic as completed even though the topic expanded well beyond the original post. Any new changes/suggestions should be in a new thread.