View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0009564 | AI War 1 / Classic | Suggestion - Game Mechanics | Sep 12, 2012 3:51 pm | Nov 19, 2012 6:29 pm | |
| Reporter | Sunshine | Assigned To | keith.lamothe | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 5.079 | ||||
| Fixed in Version | 6.007 | ||||
| Summary | 0009564: Command Station Rebuild Delay is losing me games; not fun | ||||
| Description | A small delay to rebuild command stations after it's destroyed, when it's done automatically is fine, but 4 minutes? Having a 4 minute long brown-out because you can't get your command stations back online (and by extension, power plants) and getting rolled because of it is just not fun. Additionally, having the rebuild delay even when you're swapping command stations is again, not fun. It puts me in a situation where I have to put up an economic command station in order to get the power plants online, and then the command station either gets destroyed by the enemy because it's not the military command station that I need (another 4 minute delay to even get anything going), or I replace the command station with a military command station and see *another* 4 minute stall, during which the command station will probably get destroyed again. | ||||
| Tags | No tags attached. | ||||
| Internal Weight | New | ||||
|
|
I can take it out, but I'll have to take out command-stations-drop-rebuildable-remains at the same time. |
|
|
Maybe other changes can be made to accommodate this but not have it be annoying. Like have the upgrades to the stations be stand alone "foldout" type things that provide the boost (allowing upgrade without time delay short of build costs, but not introducing an exploit as the foldouts won't provide supply and ownership on their own) And maybe reducing the energy costs (econ stations energy generation goes up, logistics go up to above zero, but not by much (like 1000 or something), and military goes up to 0 energy usage), this way you can rebuild all but the warp jammer station even in the absence of energy. (Yes, this second idea shifts balance, but IMO, the annoyance that this would remove is worth the slight shift in balance for the player) EDIT: The foldout idea was not my own. The energy idea is though. |
|
|
Hmm, also, why 4 minutes? Wouldn't something like 2 minutes be long enough to stop exploits? |
|
|
What about clearing the delay if no enemy ships are in the system? This would allow non-combat Command Station swaps as well. It could even require 10 seconds or so of no enemy ships before it clears the delay. |
|
|
Why is it sometimes 1 minute and sometimes 4? Also losing due to a brownout is intentional, the AI will try to cut your power supply off to disable your homeworld shields. Preventing that should require stopping the attack, not simply rebuilding fast enough. |
|
|
Personally I dont see the need for Command Stations to drop rebuildable remains at all. They are not that expensive over all, and even the longest only needs 1.5 minutes to fully build without engineers. (going off memory on the build time, could be off, though I know its very short) I would rather have 0 wait time than have remains. |
|
|
Iirc military command stations get the 1 minute timer, the others get 4. |
|
|
@ZaneWolf It may be worth throwing up on the forums which system people liked/like the best: 1) Remains with a timeout to rebuild on destruction (current system) 2) No remains and no timeout with "magically" destroyed colony ships on that planet when the station is destroyed (but not on replacement, which seems like it could open up some exploits) (previous system) 3) No remains and no timeout with the colony ship having to be within N range of the target site to place the command station (the system from quite some time ago) 4) Other (post idea) Keep in mind, any system needs to be stop the exploit where people can just keep a stock pile of colony ships or rebuilders around and just rebuild or keep systems alive infinitely near instantly no matter where the planet is. (Keith can probably give a better explanation of the exploit and why it needed to be stopped) |
|
|
I actually like the current state of things as they are. You can always build energy converters if you brown out, only takes about 20 seconds to speed build some engineers and energy converters. I can see what Sunshine is saying though, some aspects of the new solution are not perfect. Some solutions could be: 1) Reduce the timer for non-military command stations to two minutes. 2) If no enemy ships are present in a system then the timer is reduced to zero. 3) Have a lobby option to choose if command stations should have remains. |
|
|
I support allowing a function to enforce manual rebuilding of command stations. Even a minute-delay can be problematic, especially with a gap-in-the-wall problem as detailed below. I have had military command stations take 4 minutes to rebuild, particularly since I only use military command stations in the early game. A huge gap in the wall with the current system is that a command station and the infrastructure get destroyed, but the remains rebuilders don't because they're cloaked. They start rebuilding the command station automatically once all enemy ships leave or the timer runs down, but as soon as the enemy ships see a command station being rebuilt they all come flooding in and destroy the in-progress command station. Since there's no alerts about when the command station is actually being re-built without constantly checking the planet (could be problematic in really hairy situations), there's no warning until the in-progress command station is actually under attack. By that point it's dead, the timer resets and increases, and your recovery is delayed even more. I honestly think I prefer the old system of manual rebuild better. For turrets auto-rebuild is okay, but for command stations (especially if there are delays involved, even for switching command stations; the "modular" function doesn't allow for easy swapping of econ and military for example) I'd really prefer to have that under my control at all times, especially if the alternative is to have some penalty associated with death. Edit: As for matter converters, they're a terrible solution to the problem when you've been knocked down to just your home planet (because you can't rebuild for 4 minutes or more), and are trying to rebuild your forces to a level where you can hold the line long enough to get all your planets rebuilt without extending the delay. |
|
|
@Sunshine That bug has already been reported elsewhere. And yes, matter converters are a terrible solution, but the whole point is that it is either hold your planets or be possibly the AI pushing into a very nasty situation. Aka, they are supposed to be a terrible solution, but rather that than die. The key is to try to make the need for them as rare as possible (for example, not losing planets) Anyways, for what it worth, my favorite solution to this exploit was actually the first one tried, the proximity requirement for colony ships. Yea, it was a bit annoying when colonizing a planet for the first time, but it was intuitive, followed the system many other games use to prevent such exploits, was very visible, and had no extra mechanics to penalize death (like this and the previous system did). Yes, one of the things this did (and the previous system did too, which the remains was implemented to fix) was introduce an "annoyance/tedium factor" to recolonizing. But TBH, that seems like a fair penalty/balancing point for what should be a severe loss, and a hopefully rare one. If it is not a rare one, then you are either willingly losing planets for things like "throwaway planet" type tactics (where you are deliberately willing to pay this price), or you are losing and the AI is going to "break through" soon. Actually, since no one has made that poll yet, should I go ahead and create it? |
|
|
I play with a ton of minor factions enabled, so hybrid and/or neinzul preservation or enclave incursions frequently will take out isolated planets while I'm busy kicking the AI around elsewhere. The problem becomes when the 4 minute delay doesn't let me rebuild, so every planet I end up losing, which would normally be a very minor delay, now becomes extremely costly because I have to devote significant forces to now protecting the planet so the delay doesn't get extended. Then when the next incursion comes, or I have to divert forces to waves, it just snowballs and I end up losing because of 4 minute rebuild delays. In previous versions of the game, this was a totally recoverable situation. Right now, it's not. While I'm at it: Yes, I play to lose. I've only really won one game, but I like the frenetic pace of things having absolutely everything enabled, trying to carve my way through the galaxy, and then seeing if I can *actually* hold against three exo waves. So I'm expecting to lose, just not to command station rebuild delays. |
|
|
Personally I really like the current system, I found the need to get colony ships out to dead planets in order to rebuild one of the most frustrating parts of the game. I would say things need to be fixed so CS remains can't begin rebuilding until the timer expires (as that is a very cheeseable problem) but otherwise the current state is by far my favorite. As for the issue with losing due to brownouts: I find this an interesting thing that needs to be considered in your strategy. You can't just let that outlying world die every so often if you need the energy from it. For me dealing with this is more satisfying than dealing with how to replace the CS as fast as possible. |
|
|
As Astilious mentions, I think one of the goals of the new energy is to make you care about energy and the planets that provide them; to make losing a planet a much more impact full thing that isn't easily worked around without large cost. Yes, this does imply a moderately large shift in the way we now need to think about border planets, "satellite" planets, and "I don't care enough to defend heavily" planets, but I think that is healthier for the game overall. That said, I still think that even if the current system is kept, it could be made less annoying. Like reducing the timer to 2 minutes, making the countdown zero if it was a replacement (but NOT a normal scrap) if there were 0 enemy ships at the system at the time of the replacement, and fixing the rebuild before the timeout exploit will help out greatley. BTW, have you played with the energy buffer to maintain control option? It can really help you keep you from, for example, using so much energy that one planet lost will put you in blackout situation. EDIT: It is also worth mentioning that I think the new energy system itself could use some balance tweaks too. |
|
|
I like the current system. Not allowing the CS remains to be rebuilt before the timer is up makes sense (would also keep the rebuilders from revealing themselves while there are enemies around) but otherwise I prefer the current situation over all previous solutions. It's just much less tedious once the actual threat to the system has been eliminated. |
|
|
Yes, I do need to actually prevent the rebuilders from _starting_ the rebuild of the command station, to avoid the gap-in-the-wall problem. That's separate from the delay-by-timer vs. delay-by-requiring-colony-ship-micro issue. |
|
|
For 6.007: * Command Station rebuilding behavior: ** Now when the stall timer is running because the previous human station on the planet was destroyed, the remains rebuilders cannot do anything with the command station remains until the stall timer is up. ** Once the stall timer is over, Remains Rebuilders looking for something new to rebuild will give command station remains absolute priority. ** The stall timer on non-military command stations from 4 minutes => 2 minutes (military ones still get 1 minute). Thanks :) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Sep 12, 2012 3:51 pm | Sunshine | New Issue | |
| Sep 12, 2012 5:54 pm | keith.lamothe | Note Added: 0028353 | |
| Sep 12, 2012 5:54 pm | keith.lamothe | Assigned To | => keith.lamothe |
| Sep 12, 2012 5:54 pm | keith.lamothe | Status | new => feedback |
| Sep 12, 2012 6:12 pm | TechSY730 | Note Added: 0028355 | |
| Sep 12, 2012 6:13 pm | TechSY730 | Note Edited: 0028355 | |
| Sep 12, 2012 6:13 pm | TechSY730 | Note Edited: 0028355 | |
| Sep 12, 2012 6:13 pm | TechSY730 | Note Edited: 0028355 | |
| Sep 12, 2012 6:32 pm | TechSY730 | Note Added: 0028356 | |
| Sep 12, 2012 6:32 pm | TechSY730 | Note Edited: 0028356 | |
| Sep 12, 2012 8:17 pm | Hearteater | Note Added: 0028359 | |
| Sep 13, 2012 8:15 am | KDR_11k | Note Added: 0028362 | |
| Sep 13, 2012 8:16 am | KDR_11k | Note Edited: 0028362 | |
| Sep 13, 2012 10:10 am | Zane Wolfe | Note Added: 0028363 | |
| Sep 13, 2012 10:10 am | keith.lamothe | Note Added: 0028364 | |
| Sep 13, 2012 11:08 am | TechSY730 | Note Added: 0028365 | |
| Sep 13, 2012 11:09 am | TechSY730 | Note Edited: 0028365 | |
| Sep 13, 2012 6:05 pm | Varone | Note Added: 0028375 | |
| Sep 14, 2012 1:25 am | Sunshine | Note Added: 0028382 | |
| Sep 14, 2012 1:25 am | Sunshine | Status | feedback => assigned |
| Sep 14, 2012 1:26 am | Sunshine | Note Edited: 0028382 | |
| Sep 14, 2012 1:34 am | TechSY730 | Note Added: 0028385 | |
| Sep 14, 2012 1:35 am | TechSY730 | Note Edited: 0028385 | |
| Sep 14, 2012 1:41 am | Sunshine | Note Added: 0028386 | |
| Sep 14, 2012 1:42 am | Sunshine | Note Edited: 0028386 | |
| Sep 14, 2012 1:53 am | Astilious | Note Added: 0028387 | |
| Sep 14, 2012 2:01 am | TechSY730 | Note Added: 0028388 | |
| Sep 14, 2012 2:08 am | TechSY730 | Note Edited: 0028388 | |
| Sep 14, 2012 2:17 am | TechSY730 | Note Edited: 0028388 | |
| Sep 14, 2012 2:18 am | TechSY730 | Note Edited: 0028388 | |
| Sep 14, 2012 2:20 am | TechSY730 | Note Edited: 0028388 | |
| Sep 14, 2012 3:27 am | KDR_11k | Note Added: 0028390 | |
| Sep 14, 2012 12:27 pm | keith.lamothe | Note Added: 0028397 | |
| Nov 19, 2012 6:29 pm | keith.lamothe | Internal Weight | => New |
| Nov 19, 2012 6:29 pm | keith.lamothe | Note Added: 0029013 | |
| Nov 19, 2012 6:29 pm | keith.lamothe | Status | assigned => resolved |
| Nov 19, 2012 6:29 pm | keith.lamothe | Fixed in Version | => 6.007 |
| Nov 19, 2012 6:29 pm | keith.lamothe | Resolution | open => fixed |
