AttackController too easy to recover from

[Shibdib]

@shedletsky said in AttackController too easy to recover from:

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

[Gankdalf]

@shedletsky I don't think it was ever desired for it to be easier to attack than to defend. To make that happen you would basically have to delete towers and ramparts from the game, which doesn't sound fun.

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]

@artch Wanted to make sure you didn't miss the message above, since you said you wanted player emoji support to validate ideas. I think this separation of concerns is a good start to making downgrade based attacks more doable.

@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.

[Tigga]

Bumping this guy because it's still an issue. If you want it to be possible to take a room without taking down an entire player this needs revisiting. Burst counter attacks at the right time make fully downgrading a controller a multi million tick operation with 1000x+ resources required on the part of the attacker.

[o4kapuk]

Ok, let's get back to this.

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.

[Tigga]

I like option 3. It appears to fix the issue without changing anything else significantly.

[wtfrank]

Maybe I'm missing something, but if the room is 600 steps away, and the attacker immediately spawns a 50 part responder, that means that the attacker would get there just as the RCL 6 room got back to RCL 7. So shouldn't we be targeting a bigger number e.g. 600 * 2 + 150 = 1350 ticks?

[o4kapuk]

@wtfrank Given the response is enough, it should be able to kill the upgrader. 1350 ticks sound too brutal I think, no?

[Tigga]

@wtfrank that is the absolute worst case. In the majority of cases the room will either be closer than 600 ticks or the controller will downgrade a bit before the attack to recontrol it comes.

[Kamots]

Option 3 looks good.

[o4kapuk]

Looks like Option 3 contains a calculation error: RCL6→RCL7 case is still 600 ticks, not 750. Hopefully, this effect will be somehow compensated with a proper attackController overflow handling.

[Maxion]

Wouldn't making the timer half filled after an upgrade make safemode unavailable for some time right after each controller upgrade? Or is that the whole point of that change?

[o4kapuk]

@maxion it will be available, we're changing it from CONTROLLER_DOWNGRADE[level]-CONTROLLER_DOWNGRADE_SAFEMODE_THRESHOLD to CONTROLLER_DOWNGRADE[level]/2-CONTROLLER_DOWNGRADE_SAFEMODE_THRESHOLD

[o4kapuk]

PTR updated. Let's check this out and ensure that we have no reasons to be unhappy about this mechanics anymore.