4. PvP balancing: Reduce maxHits on walls/ramparts, controller downgrade time

PvP balancing: Reduce maxHits on walls/ramparts, controller downgrade time

  • Culture

    I think the impression should be "some battles may take a couple of days and cost some boosts".

  • CoPS

    Does that work? I remember seeing Azurastar move next to me and thinking "wow, 80M walls? I'll never be able to deal to that". Its just too damn big.

    Maybe some documentation or a site tutorial to actually make warfare a tad more accessible is a sideways solution there?

  • Culture

    I agree with the offense part. It's currently extremely difficult to attack an established player. However, I do see why walls/ramparts should be this high as they are right now. People need time to defend against attacks. It's quite realistic that an attacking player has had a lot of time to prepare for an attack. If you suddenly have to adapt your code to write better defense code it will take time. Walls and ramparts are designed so they take a lot of time to tear down.
    Give a 300M wall

    • Dismantle creep with 40 catalyzed boosted WORK
    • Does 8K damage per tick, 50 base + 300% = 200 damage per part. 200 * 40 = 8000

    Given the amount of free spaces next to a wall/rampart this is the amount of ticks it will take to tear it down:

    1: 37500 ticks. (within a safemode reset)
    2: 18750 ticks. (within a safemode reset, within nuke land time)
    3: 12500 ticks. (within a safemode reset, within nuke land time)

    These times feel fine for people who do not have a whole lot of time to invest in Screeps. It will also take time

    I do agree on the controller part. Currently all it takes is a single tick for a defender to get back up to speed, and you can only block an upgrade for 1000 ticks. I think this is where the issue becomes quite apparent. It's become so well known that it takes so little effort to get back up to a normal leven that people even neglect to defend the controller at all. Leaving it extremely exposed.

    I personally always saw the controller as a way to control the room. It should be considered the most important structure in the room in stead of the "oh yeah that thing" structure it is now.

    I think that attacking a controller should result in hefty penalties to the room, and that the cooldown should be a lot easier to bring down (As you can wall it up with 300M walls/ramparts right! 😄)

    It might even be feasible to add a new part type which allows for attacking controllers, which does NOT diminish the creeps TTL and doesn't cost more than 1 WORK part.

  • Dev Team

    We have an idea to make attacking controller more interesting.

    We have 2 proposals which could help an attacker take over the room

    We would like to refactor attackController method and make it more powerful for the attacking party:

    • attackController will apply 1000 ticks of upgradeBlocked and will decrease the ticksToDowngrade by 200 * amount of CLAIM parts.
      The claimer creep will only need 1 tick to do this amount of damage.
      The claim creep will not be able to do another attack until upgradeBlocked is back to 0.

    This kind of change will make battles be more wave-like.
    During the 1000 ticks of upgradeBlocked neither attackers nor defenders are able to do anything woth the controller.
    Obviously after 1000 ticks the fierce battle starts before the attackers or the defenders can fire another shot! Both parties would have to plan their attacks accordingly.

    ==================================

    Another change we can implement is when a controller downgrades a level it will lose 50% of that levels energy.
    For example:
    The result of letting your controller downgrade from RCL 8 to RCL 7 will result in it having a progres of 5467500.
    This creates an incentive to not let your controller downgrade at all!
    It will become very costly to lose a level. Each level lost will result in this effect, so letting your controller downgrade once more (from RCL 7 to RCL 6) will cost you the 5467500 energy that it still had! And additionally it will lose another 1822500 progres.

    This result of downgrading a room from RCL 8 to 6 will cost 10935000 + 1822500 energy (without boosts).

    Let us know what you think of these ideas.

  • Dev Team

    I only want to note that the current mechanic is to lose 10%, since here were some incorrect statements that there is no lose at all. You can check it here https://github.com/screeps/engine/blob/19453d92fb2139f8f1b8cda47ea54983e149e44d/src/processor/intents/controllers/tick.js#L43


  • Interesting ideas, I do think that there should be a lot more emphasis on protecting the controller during a siege. Since one of the biggest advantages a defender has is the freedom to choose where to place all of his or her structures. This means the defender can cluster all of their buildings together in a extremely compact defensible position. The player, however, does not get to chose were the controller in a room is placed. This can force a very significant additional constraint on the defender when planning his/her base layout, but only if attacking the controller results in a serious penalty to the defender.

    Instead of (or maybe in addition to) the current effects, attackController could build up some counter, which if it reaches a certain threshold will temporarily reduce a rooms RCL by 1 for some number of ticks. This would mean an RCL8 room would lose control of 3 towers, 1 spawn, 4 labs, and all the other buildings that become available at RCL8 making defending significantly harder. The main idea here would be that this temporary downgrade would be achievable on a much shorter timescale while still requiring a strong presence in the room by the attacker. Furthermore, it would potentially promote extended conflict around both the controller and the defender's core base.

    Perhaps this idea is redundant with respect to the way attacking the controller is currently implemented, but I feel like decoupling the 'upgrading' aspect of the controller from the 'attacking' aspect would give a lot more flexibility to properly balance this mechanic.


  • I like the idea behind attackController, and I do think it's an improvement to the current system and a step in the right direction, but given that it only blocks the controller for 1000 ticks, this doesn't really improve the "standing army" problem that controllers have.

    I would suggest, however, scaling upgradeBlocked to the number of CLAIM parts used to attack that tick (with future attempts to use attackController being blocked, similar to the way multiple miners can mine a single extractor).

    With the currently suggested system, assuming a player is using a single maximum size CLAIM creep to attack the controller, it will still take over 40 such attackController cases (that is, continuous upgrade blocking, assuming a maximum size CLAIM creep to minimize the number of battles)- 40 battles that the defender must have an army up and ready to fight off anything the attacker can throw at them, and the attacker only has to win one of those battles in order to start the whole process over again.

    Allowing multiple creeps to simultaneously use attackController (even without an increase in upgradeBlocked time would help by reducing the number of battles, but that won't be consistent. Even only having to win one in twenty-two or so battles still heavily skews in favor of the original owner.


  • Add an alternative attack option for claim parts aka. DrillController, that makes the casting creep immobile and unable to be healed until it stops drilling for 20 continuous ticks, but does a LOT more damage to controller, like 5-10x as much as attack controller.

    If you have complete control of room it will allow you to take out controllers much faster, but if the enemy has even a few turrets operational he will be able to take out the drilling creep no problem.

    Alternatively, give attack-controller a range of 2 (or 3) so an attacker willing to shell out the energy can mass more of them.


  • Those seem like some great ideas, and I'm very encouraged by the discussion.

    The mechanics suggested by @dissi-mark have some nice potential but with those numbers they seem to just be a reshuffling, not an increase in potency. The proposed mechanic would have a 15-part CLAIM creep take down the controller by 3000 in one tick. Continuously attacking with a series of the same creep over 1000 ticks would also take the controller down by 3000.

    It could even make some sieges longer. At the moment you can attack with more than one creep.

    So it seems to boil down to an energy savings and a normalization of the amount of distance to the attack room. This is a step in the right direction, but the current big issues are the sheer amount of time it takes (which it could actually make worse) and the fact that it is too easy to lose all your progress as the attacker.

    I still like the general idea and the normalizing effect it has related to the distance that the claim creep has to travel. I'd just ask that it be more potent, perhaps 500 per CLAIM part rather than 200.

    As others have pointed out, it is very unbalancing that ticksToDowngrade is immediately restored upon upgrading with a single energy. It would be much better if upgrading increased it by some amount, but not completely restored it. Perhaps 1 energy would restore 10 ticksToDowngrade points.

    edit: made it a little more concise

  • YP

    Just a thought after waking up... what if there were a structure that an attacker can build in an enemy room that has some effect. Maybe that some energy / minerals to work.

    2 Replies

  • @w4rl0ck

    We were talking about an idea that is similar to that in our alliance chat recently, I think it has some interesting potential.

    One of the reasons I suggested these things in particular is because they would basically require little more than adjusting some constants. I know the devs have their hands full with performance upgrades and new features. I thought this might allow us to bring some balance to PvP in the meantime.

  • Dev Team

    @w4rl0ck Actually, I like this idea. Something like StructureSiege which competes with the controller for control over the room, and should be somehow interacted as well. Does anyone want to elaborate this mechanic a bit?

    1 Reply

  • why an additional structure. As Dissi said: I personally always saw the controller as a way to control the room. It should be considered the most important structure in the room in stead of the "oh yeah that thing" structure it is now.

    so something like when attacking a controler you're granted temporal building rights in the room. Still, there can't be 7 towers, but if you destroy one of his - you can build your own as well as ramparts and such... The room battles will take a whole other perspective than the static one there currently is


  • @artch

    Some ideas for StructureSiege:

    • Disallow safemode while it is in the room (safeMode can always be popped before it is completed)
    • Have upgradeBlocked while it is in the room
    • Give it .energy and .energyCapacity properties and allow some of the same functions as a StructureTower
    • Energy might also be used to attack the controller to reduce ticksToDowngrade
    • Make it expensive to build but also give it enough hits that it can't be knocked down in just a few ticks (perhaps 1m hits)
    1 Reply
  • YP

    I like the idea of the structure over the CLAIM creeps because of the limited range you can use CLAIM creeps effective and it's very expensive. I understand that limiting the claim range is important .. but I don't think that it's the same for the downgrade part.

    My basic idea of the SiegeStructure was that it has to be build near the controller, and slowly degrades the room while it has energy.

    • maybe give it the possibility to upgrade the siegetower to a higher level by upgrading the tower and accepting higher minerals to make the decay faster
    • or let it work like a rampart .. it uses energy but also decays slowly if not repaired and it has a maximum hp count

  • Given the nature of construction I wonder how practical that will be.

    • Simply stepping on the siege construction site will destroy all progress
    • If it obeys the standard placement rules, then basic exit walls/ramparts will prevent placing the site
    • Towers can attack the structure anywhere in the room
    1 Reply
  • YP

    @warinternal said in PvP balancing: Reduce maxHits on walls/ramparts, controller downgrade time:

    Given the nature of construction I wonder how practical that will be.

    • Simply stepping on the siege structure will destroy all progress
    • If it obeys the standard placement rules, then basic exit walls/ramparts will prevent placing the site
    • Towers can attack the structure anywhere in the room

    I don't see the SiegeTower as a Structure that is build while there is still a Tower or a Spawn active in the room but something that takes place after the room is basically lost. If it works like a Rampart it would be build with 1 HP .. but still easy to destroy if not protected

    It needs to be refilled while working and repaired.

    I also think it should be limited so it has to be build like in range of 3 to the controller to be able to interact with it.

  • Dev Team

    It might be constructed right on top of the controller, like an extractor on top of the mineral.

    Or, it may be a more widely used siege structure that assists not only with overtaking the control, but also with directly attacking the room, like a siege machine in the front of ramparts line.

  • Dev Team

    Also, we need to consider power creeps in this regard. Some features may/should be moved to power skills rather than structure mechanics.

    1 Reply

  • @artch

    we need to consider power creeps in this regard

    I can see the sense in waiting to see what solutions Power Creeps will bring, rather than add mechanics that might eventually be unnecessary.

    Since we don't know when that will be, is there anything that seems reasonable to you to adjust in the meantime? Even just increasing the potency of attackController would go a long way toward addressing this issue. CLAIM parts are already very expensive and distance-limited. It seems like the current potency is below what is justified by the cost.