#Spawn structures should always generate +1 energy per tick
22 messages · Page 1 of 1 (latest)
I believe so yes? The motivation is primarily aimed at occasional edge cases newer players may run into where a critical early game energy-harvesting creep may die due to Time To Live expiring, but then being unable to respawn on its own. So for example, if there is 300 energy stored across 6 extensions, then the Spawn will not currently regen per tick. But, if the critical energy creep dies and requires 350+ energy to respawn, then it will never respawn, and the entire game comes crashing down overnight.
Now, to play devils advocate against myself, the current solution would be to simply make the critical creep cost less to spawn temporarily. You could also program some very specific checks which force other non-harvest creeps to manually fix this. But, in practice, a player may leave the game for a day and come back to find their operation came down due to this specific edge case
You can always spawn a harvesting creep with 300 energy, and you need to be able to do that anyway to start playing.
Also if an invader or player kills all your creeps.
Now, to play devils advocate against myself, the current solution would be to simply make the critical creep cost less to spawn temporarily.
Ding ding ding 😉
300 energy is sufficient to get a room restarted. Yes, players do find their rooms dying due to this, but that's part of the game and one of the many problems to be solved. Having a fixed 300 energy passive cap means the max passive regen is always known, if you just make the spawn always regen then you create this weird dichotomy where you want to keep dumping energy out of the spawn to maximize the regen.
Not sure I’m a fan, being able to recover in situations like this with dynamic size creep is just part of the game. This is one thing to handle among many in terms of making a resilient bot
Yes, it is confusing visually, and perhaps adding a "total available energy" line to the spawn in the UI would help make that more clear, as we do often get people wondering why their spawn stopped regenerating. That would be a good suggestion imo.
But changing how the regen works is unnecessary.
Also if your code crashes and burns permanently if there's an extension with energy and you can't regen to 350 total, it's going to crash and burn just as badly if there are no extensions with energy. So the "fix" solves nothing.
Another thing to consider is that if you made the spawn just always regen regardless of what's in the room total, you'd actually end up tripling the regen because every spawn would just endlessly regen. 3e/t passively is not insignificant, especially in a CPU-restricted environment like shard3.
The current rules give you a known minimum energy: you can get up to exactly 300 for free. No more, no less.
To be clear I know how to "solve" the edge case without this suggestion. The suggestion itself is mostly a quality of life for the newer players to make the barrier to entry less frustrating since this is something newer players can and will easily overlook
Not "sometimes 300, sometimes 12900"
A good QoL would be making it more clear how the regen works when looking at the game's UI, not changing how it works.
Yep.
That is true, at the very least that would help for sure
Its already very clear in the docs
And yet, I see someone confused nearly every week 😛
That has more to do with a lack of reading rather than a documentation issue id argue. Like i will agree if something is buried in an unexpected location but the energy regen behaviour is very clearly described at the top of structure spawn in the API docs in a table under an appropriately named entry in a bold font. Like i cant see how much clearer it could be
If a new player is already at the stage where they are spawning bigger creeps than can be done with a 300 E spawn when they write that code there should be the appropriate checks. That is not an unreasonable expectation. And even with this change as Pwk correctly pointed out you still dont actually fix the problem you sought to solve
I suppose in reality it would just be pushing the problem until a later stage, which I'm not sure would be good or bad, but you're right it technically wouldn't solve the root of the issue. I do like D3matt's idea of having a more clear UI element or something that explains it directly in-game
I wouldnt necessarily be against making information like that available to see in the UI (if it was well designed) but i do think generally people need to get used to reading the API docs. As if you arent you are definitely going to struggle (or annoy people with RTFM q's). They are generally very well written