Closed Violet-Scarelli closed 3 years ago
dang this is very well thought out
I would love it in game please add it
Approved
Edited to include interactions with batteries.
I like the ideas put on the table here. My input: • Make it easy to understand. Whatever the final implementation, it should never be cumbersome, especially at low levels for new players, as this might be discouraging. My suggestion would be to keep large margins of error, clear indicators of when things are going wrong (such as the suggested color changes), and punishment which is not too severe (e.g. only partial network failures upon overload). • For the colors, I would prefer not having "green" power running through my base; I think it would be better to start out as Red for low power/draining, yellow for healthy, then gradually get more orange as the capacity is close to exceeding, then flash when dangerously close. • Potentially, calculate the power capacity as a combination of the nodes, plus an additional, fixed amount, such that small bases/networks shouldn't need to worry about it. •One potential issue I see is that this could encourage someone to spam a bunch of nodes down just to increase the capacity of the network. This should be addressed somehow.
If implemented correctly, I genuinely think this could be a good addition to the game.
@RogueRedHawk Thank you for the input! I think the "easy to understand" bit is definitely worthy of including. The color feedback is also very valid, and now that I think about it, it makes sense. A gradient from red to orange sounds good. I'd already proposed power capacity as a combination of nodes, but I'm thinking now that instead of multiplying for each node, adding a small fixed amount for each node would be better. The "fixed amount for small bases" needs a tweak though, as 100 power/sec isn't nearly enough to run a small base. Probably something more along the lines of 250 as base power safety should be good. And as for node spam? I was thinking that the more nodes are in an area, the less power each one adds, such that a fully saturated 10x10 square of small nodes only adds about as much power capacity as four well-spaced small nodes. In-game, the effect could be called EM Saturation or something? The closer nodes are spaced, the more EM interference it receives and the less power cap it's able to contribute. Additionally, I thought about direct-contact situations that don't use nodes. I was thinking in those situations, the power cap would be technically nonexistent, since those situations are few and far between as far as I can tell (mini-turret situations and such). To prevent people just making battery snakes, the rate at which a battery can discharge should be capped for each type: small batteries can output at 50 units/sec or similar, large at 500/sec, the stabilizer at 1000/sec if necessary, and a proposed battery (surge capacitor, check here) that holds about 300k power could output at maybe 5000/sec. This would encourage people to actually build better batteries instead of just spamming the small batteries, as it would help their system recover faster after a power drain.
That could be feasible. 10k power units drain/s 1x1 @50 = 200 blocks 3x3 @500 = 20 blocks
Also to be frankly honest batteries aren't often used as intended. They are currently space fillers and just spammed since power cubes are still a thing -_-. But in the context of your suggestion, the batteries, would be an integral part of the power system.
This suggestion is now stale, and will be automatically closed.
Describe the content or mechanics you are proposing. Just as having too little power can make a system nonfunctional, having too much power can damage it... or at least, that's how it normally works. My concept for a power system rework is as follows.
Power would now have a safe range where it can operate, starting at zero and going up to a total determined by 100*(1.5L+1.2S+1.6T) where L is the number of large power nodes, S is the number of small power nodes, and T is the number of surge towers. If the total amount of power produced exceeds the safe network limit at any time, everything connected to the network will take periodic overload damage based on how much overload there currently is. Note that this formula is simply a concept, and is subject to change. Note also that if power produced exceeds the network limit and there are empty batteries in the network, the excess power will drain to those batteries at an increased rate first, before damaging connected buildings.
In order to more effectively protect from this, a couple of new blocks could be added. One: the surge protector, made, predictably enough, with surge alloy, silicon and titanium. This block doesn't add to the power cap, but instead adds to the surge cap: that is, the amount of power overload required to damage buildings. Each surge protector adds 1000 points of power to the surge cap, but will instantly burn out if the total overload ever exceeds the surge cap. A smaller version, the surge limiter, is made with silicon, titanium and plastanium, and only adds 250 points of power to the surge cap, but doesn't prevent damage while buildings are overloaded, only reducing it by 50%. Using surge protectors and surge limiters in tandem works as follows: The surge cap points added by the surge protector are added first, then the points that the surge limiter adds. This creates a sort of gradient of surge protection: the surge protectors give 100% safety out to a point, then the surge limiter allows 50% protection until the power total exceeds that, at which point it starts dealing 100% damage.
Two, the circuit breaker, made with silicon, lead, and copper. Its purpose is much more rudimentary than the surge protector: if it ever detects more power than either a preset limit or the overload cap, it will stop conducting power, requiring a player to reset it. The cheaper version of the circuit breaker is the fuse, which just needs lead and copper, but will break when reaching its limit.
Three, the stabilizer, made with phase, plastanium, and silicon. This block is designed for late-game efficiency, as it acts as a smart battery. A player can set a target power level in either percent or raw amount, and the stabilizer will sponge up excess power over that cap and dole power out when it drops below that. It can hold up to 10000 units of power.
With all these new power blocks, it only seems logical to add a few new building mechanics. One: innate overdrive. Each building will operate at 100% efficiency when fully charged, but on a properly balanced network, buildings can receive additional working speed based on how much the network is overloaded. This gives a real incentive for players to balance their networks. Imagine the builds people will make: a system that keeps a network at a constant 125% and provides additional working speed to every building on the network, or an emergency overdrive that temporarily boosts buildings to nearly 200% but costs a lot and can't be damaged in operation. Note that this is NOT intended to replace overdrive projectors, rather, it's designed to provide a riskier alternative that has a higher payoff. If you want to go the safe route, you can use overdrive projectors, but if you want a higher payoff at the risk of frying a lot of expensive buildings, you can overdrive/overload your whole network.
Two: stored charge. Each node has the ability to store a little charge. Not a whole lot, but enough for players to diagnose a problem before it completely overtakes their network.
Three: visual indicators. Playing on an idea from (I believe) Quezler, power nodes would glow different colors based on the current power level of the network. No glow or dim red would mean the network isn't connected or has insufficient power, respectively. A healthy green would mean the network is in safe operating range. Yellow would mean the network is experiencing overload, but is still within the surge limits. Bright orange would mean the network is approaching surge limits, pulsing orange would signify power overload partially protected, and flashing red would signify power overload not protected (usually accompanied by sparks).
Four: power-based enemies. Some enemies should receive new behavior to reflect the changes in power networks. Crawlers should prioritize power safety mechanisms over anything else if it's available. Eradicators should try and find nearby power networks, clamp onto them, and start draining power. If not destroyed before they accumulate enough power, they'll unleash a burst of power into the network, attempting to fry it and destroy valuable surge protectors. If the node it's on is disconnected, it will retain its charge and hunt for a new one. Other power-based enemies could be added, for example the Spiroct could use its sapping lasers to drain from enemy networks, and perhaps the Zenith could carry specialized anti-generator missiles or something.
Describe how you think this content will improve the game. If you're proposing new content, mention how it may add more gameplay options or how it will fill a new niche. Adding a more robust power network with more options and mechanics would seriously spice up the power meta. As it stands right now, power generation is a game of "make as much as you possibly can". Everyone tries to push the network as far as it can, but if this suggestion was implemented, it would turn into a balancing game. Stabilizers and diodes would be placed near vital systems, ensuring they always have enough power without draining too much from the network. Plastanium walls would have an actual offensive use, as eradicators wouldn't be able to connect through them. Overall, it would make power a more interesting system. Sure, it's great to see "+113400/sec" on your network. But wouldn't it be more interesting to see "12000/sec, network at 120% capacity", or try and fend off an enemy eradicator before it fries your network, or set up fuses at the front lines so that your network can't be burned through?
Before making this issue, replace the spaces in the following boxes with an
X
to confirm that you have acknowledged them. Failure to do so may result in your request being closed automatically.