In the current implementation even with maxed out creeps it takes a while to downgrade a room from RCL8 to 0 and this is how it should be. But if the attacker starts such attack the defender only needs to gain control for a few ticks (particularly if they time it well just after a downgrade) to get their controller back up to full level)

1. A defender can recover 100 downgrade points a tick, this means that you can recover fairly quickly from an attack that has been going on for 1000's of ticks particularly at low levels.
2. If the attacker successfully downgrades the controller one level, then once the defender has cleared the downgrade timer the controller levels up by a level per tick until the remaining control points are used.
3. A 10% control point penalty is applied when the attacker successfully downgrades the room by a single level, but this penalty is only applied once, so as an attacker then is nothing to be gained for me between downgrading 1 level and downgrading all the way to 0. (nb I am not sure I have this mechanic correct and cant find any reference to it in the docs. )

So my proposal is as follows:

1. Make the rate that you recover from downgrade timers related to the number of work parts on the creep doing the recovery. e.g one WORK part recovers 5 ticks of downgrade timer per tick at the cost of 1 energy.
2. When a player clears the downgrade time and upgrades their controller 1 level the downgrade timer is then set to the max value for the new level (or as near is practical without immediately downgrading the controller again)
3. Every time a controller is downgraded 1 level the rooms looses 10% of its total control points and not just the first level.

I am sure other people have other thoughts on this feature, and so I welcome the discussion.

4. I guess this is related to 2, but I just want to stress that this can be used to upgrade the controller to max very quickly. If you wait until just after you lose RCL the controller can be upgraded back in one tick, and from there upgraded to max RCL one RCL per tick. I'd suggest that when upgraded to a new RCL the stating downgrade timer should be on 25% of maxmum (so if max is 5000, it should downgrade in 1250). That shouldn't impact regular upgrading at all.
5. There's no overflow from attackController. IMO it should overflow into the next level.

Some balancing is needed here and your proposal sounds like it should fix it or at least be closer to balanced than it is now.

@deft-code Actually, it is 10% per level. See here

So its 10% of the cost of getting to the level you were downgraded from.
8 => 7 lose 1093500 points
7 => 6 lose 364500 points
6=>5 lose 121500 points
5=>4 lose 40500 points
4=>3 lose 13500 points
3=>2 lose 4500 points
2=>1 lose 20 points

So in reality the number of points reduces exponentially per level.

Jokes aside, can't it still be too easy?

For example, the difference of attacking someone who is AFK for a coupel days vs someone who is active is a huge change. This is just another extension of that, where if they come back they can recover quickly from losses, but if they ignore it they can lose everything.

I'm with @artch on this, I think its a (mostly) healthy way to keep people who care about the game significantly engaged. It might be tuned a little too strongly, but when you remember it took someone probably a month to build up that room to level 8, losing half of that while afk is a downer.

Today, if you time it correctly, you can get from RCL 1 to RCL 7 with 6 ticks at the controller. For an RCL 8 base the defender loses maybe 15% of the energy into the controller. Ticking down an RCL 8 to RCL 1 takes significantly longer than 6 ticks.

The main issue therefore is that on upgrade you can instantly upgrade to the next level, and then the next. And on downgrade there is no cooldown for upgrading.

To me this makes the current system no better than the old. You need to seige a room for tens of thousands of ticks to remove it, you need to regain power in a room for 6 ticks to undo that seiging.

For an RCL 8 base the defender loses maybe 15% of the energy into the controller. Ticking down an RCL 8 to RCL 1 takes significantly longer than 6 ticks.

Consider this: 15% of an RCL8 controller equals to 1.6M energy, or 160K ticks per source harvesting. This is the time which the owner has lost even if he managed to recover.

you need to regain power in a room for 6 ticks to undo that seiging

Not exactly true. The defender needs to fight back and regain control over the controller for 1000 ticks in order to execute those 6 ticks. The 1000 ticks is the crux, not the 6 ticks. And the attacker is supposed to guard the attacked controller while he's downgrading it. If your tactic is sending an one-time raiding party and then just simply sending a lone claimer every 1000 ticks, you're not supposed to success.

It would be great if the attacker could continue using .attackController() while the controller is upgrade blocked, not to downgrade it faster, but to keep the upgrade block at 1,000 ticks. This would mean that a well timed burst attack squad will not simply mow down the attacker for 6 ticks to regain control of the room.

Also... assuming a 2 source room with a measly 2 remotes, 1.6M energy is less than 50-60k ticks. There is also the Market though, and last I checked, energy doesn't exactly have the highest price tag.

I like how I cannot just lose my assets over night, that's cool, but at the same time, why am I allowed to continue trolling this considerably stronger player by preventing room downgrade for over 500k ticks, when I haven't been able to keep the room for more than a few ticks in a row?

I'm not protecting my assets at that point, no, it's called trolling at that point.

The defender needs to fight back and regain control over the controller for 1000 ticks in order to execute those 6 ticks

To rescue the room you need an overpowering force over the course of 30-80 ticks (too short for a dynamic reaction force) every 50,000->100,000 ticks. Time it to arrive when the blocked timer is running out (can't be renewed until it does), especially if that co-incides with shortly after controller downgrades, and there's not much I can do against that. The only solution is to have a force myself that can overpower any possible incoming force for every single one of those 1000 tick intervals over the course of 50,000->100,000 ticks. I need to win every time, and because it's 1000 tick intervals (and that's less than CREEP_LIFE_TIME) it's pretty much full time. The blocked upgrade does very little to actually help.

IMO you should have to actually properly regain control of the room over a sustained period of much greater than 100 ticks to be able to recover it from RCL 1 to RCL 7. That's simply not the case today. Above you say they need to control the room for 1000 ticks. If that was actually true, I'd have less problems with the current design, but it's just not true. Maybe it's the intention, but it's not how things pan out!

Cd limitation is on attackController, but blockController can have the equivalent to a reservation timer that the enemy can increment up by committing resources. This will give attackers a longer window if they commit, but still allow defenders who hold the room to defend themselves.

blockController: Adds 2 ticks of blocked controller per 5 claim parts, up to 2000 ticks. No cd on it.

attackController: current behavior with the 1000 tick cd, except it only adds 200 ticks of blocking.

Make a shard where it is easier to attack than defend and let people who want a more dynamic game spawn there. Could be fun.

Crazy idea:

Make a shard where it is easier to attack than defend and let people who want a more dynamic game spawn there. Could be fun.

Seasonal shard would prevent people being able to turtle to unkillable levels... but that idea was shot down as being too good and requiring it's own game and another payment

This idea wasn't to make attacking easier than defending. It was to make attacking a controller a reasonable possibility.

Not to mention that 95% of the time, there isn't even a benefit to attacking another player. You pretty much will always lose more than you gain from attacking a neutral entity (even if you kill them).

@davaned said in AttackController too easy to recover from:

@artch I think the best way might be an inbetween for attackController. Make there be an attackController that downgrades, and a blockController that prevents upgrading/safemode.

Cd limitation is on attackController, but blockController can have the equivalent to a reservation timer that the enemy can increment up by committing resources. This will give attackers a longer window if they commit, but still allow defenders who hold the room to defend themselves.

blockController: Adds 2 ticks of blocked controller per 5 claim parts, up to 2000 ticks. No cd on it.

attackController: current behavior with the 1000 tick cd, except it only adds 200 ticks of blocking.

While I agree that a fast and easy recovery still an issue, it's not that easy to come up with a final solution which doesn't affect regular upgrading, makes a minimal impact on 'regular' room recovery. The main issue as I see it is that an attacker must maintain control over the room for tens of thousands of ticks in a row while defender can perform well-timed strike and almost immediately (10+1*levels) have RCL7 back. In order to solve this, we need to somehow expand a window for an attacker to react.

I think that @Tigga's suggestion is the closest to the solution, with some additional balancing work, of course.

First, let's calculate these 'tens of thousands'. Assuming an attacker use 19C19M controller attackers which always arrive about time, it's 6700 ticks of downgrade per 1000 ticks. Full (RCL8 → RCL0) 'natural' downgrade takes 405000 ticks (~2 weeks) so it's around 60 of 19C19M creeps in ~60000 ticks (~2 days). Let's keep these numbers in mind because we want to keep it.

Second, let's define a reasonable attacker's reaction window. We assume that attacked room is 600 or fewer tiles away of an attacker's room (obviously), means the window should be like 600 ticks for travel and 150 ticks for spawning (I deliberately don't count boosting time because I think that a capable raider must have a very efficient boosting system; if not, he could simply attack someone living closer to him; I also don't count “oh wait, my spawners will be busy for the next 100 ticks spawning haulers” because we have .cancel() for cases like this).

Third, let's take a look at the primary flow we shouldn't hurt: it's a novice player who has his room bugged out; said novice player should have exactly same time to wake up and fix the bug as before. Currently, he has (assuming 3s tick) about 16 hours to fix a bug in his RCL1 room or ~20 hours to recover RCL2 room.

Let's assume that losing and gaining a level leaves half of the downgrade timer instead of full. Upgrading to RCL8 is not an issue because it requires over 1M of energy so let's take a look at lower levels. Given the current CONTROLLER_DOWNGRADE_RESTORE is 100 ticks, recovering from RCL6 to RCL7 would take 300 ticks taking at least 300 energy (500 ticks and 500 energy from RCL5 to RCL7 and so on). In order to turn these 300 ticks to 750 ticks, we could either nerf CONTROLLER_DOWNGRADE_RESTORE (40 seems to be the right value) or increase CONTROLLER_DOWNGRADE values, or both.

Option

Together with making the timer half-filled, doubling CONTROLLER_DOWNGRADE values would make full 'natural' downgrade 555000 ticks, which is 37% longer than now, or require over 80000 ticks of downgrading with a single 19C attacker. We will have 600 ticks of reaction window for RCL6→RCL7 case (still not 750 but close enough) or 1000+ ticks for lower levels (more than enough).

Option

Together with making the timer half-filled, we nerf CONTROLLER_DOWNGRADE_RESTORE to 40 which makes 750 ticks for RCL6→RCL7 but also reduce full 'natural' degrade to 277500 ticks (~1.37 weeks) and (much more importantly) reduce downgrading time for RCL2 rooms from 25000 ticks to 15000 ticks (12,5 hours, sounds like definitely not enough). Plus, it's a little more than 40k ticks of downgrading with a single 19C attacker, sounds too brutal.

Option

Together with making the timer half-filled, revisit CONTROLLER_DOWNGRADE making it like {1: 20000, 2: 10000, 3: 20000, 4: 40000, 5: 80000, 6: 120000, 7: 150000, 8: 200000} leaving all other constants as they are. This is my favorite because it has minimal impact on 'natural' decay and recovery (420000 ticks of self-decay – very close!) and novice recovery (still 20000 ticks for RCL1 room, also 20000 ticks for RCL2 room), and it naturally gives the required 750 ticks in RCL6→RCL7 case, more for deeper degradation up to maximum of 2100 ticks (RCL1→RCL7). It will be a bit harder to knock down RCL8 to RCL7, but, considering it's the only downgrade you can't recover from easy, it makes sense.

I suggest voting below or leaving your comments/suggestions/corrections below in the thread. Please choose wisely because we really want to have this sorted out once and for all.