Handshake Keep/Castle Sieges

[DEV-Tiggs 4,034]

Summary

We have a social issue caused by performance-driven server population caps on the zones.  When a large defending or attacking alliance wants to lock out the competition for a siege event, defending players will log into the server hours ahead of the event and “lockout” all other players by flooding the zone with their team.  Worse, the fear of this happening forces other alliances to do the same thing, just to keep it from happening to them -- resulting in uninteresting gameplay sessions with no action on either side, waiting for siege windows to open, then close.

The proposal in this document is to combine the current siege scheduling system with a zone reservation and handshake sieges concept, allowing these 2 teams within a zone for the period that there is an active siege in that zone. This new siege model becomes an option in the Siege Schedule for a particular campaign, which means Dregs can use either the reserved handshake sieging mode -or- the current non-zone reserved sieging for any given campaign.

Note: This design is assumed to be Dregs-only, and for Keeps and Castles-only initially, as the design is intended for coherent groups with specific leaders, unlike the leaderless factions of The Shadow.
Note: Assume for this entire document when we talk about a “group of players” we are discussing an alliance, and if a guild isn’t part of an alliance, then default to the guild.  

Zone Reservation

The proposed solution is to allocate player slots available (up to the max Zone Cap, currently set to 250 for sieging zones) and grant these slots in a siege zone to alliances based on a Handshake Declaration prior to a siege.  Additionally, we need to revamp/upgrade the player queueing system to understand and apply these allocations and deal with it appropriately when more players from a given alliance attempt to log in (or Runegate into an area) than that alliance has been assigned allocation slots.

Challenges:

1. Recognize that we have a limited number of player slots available in a zone, and it is unavoidable that sometimes more players will want to engage in these events than we can support.
2. Allocate the limited player slots in a way that is the least offensive to all players (as no group is going to be happy, even if they were allocated all the slots -- because without conflict, the game is boring).

Solution:

• Allow players to reserve player slots  (from the Zone Cap) based on a Siege Handshake; the defending Alliance reserves 45% of the zone cap and the attacking Alliance reserves 55% of the zone cap. (these are tunable variables in design config data) 
  
  Note: This maximum amount per alliance is enforced even if one of the teams is short players. (ie defenders can have a max of 112 players but only have 92 players in the zone, the excess amount (20) does not allow there to be additional attackers, it just means defenders are fighting short-handed and others of their alliance are free to zone in.)
   
• There is also a desire to be able to define the max zone size during a siege hour based on the size of the keep in the zone (design set the value somewhere) whereas a small keep has a max player zone amount of 150 (during the siege) instead of the standard 250. The players thought it would be valuable for the smaller keeps to have smaller sieges such that a smaller alliance couldn’t get zerged by a much larger group. This is data design could setup in the Siege Schedule where we already plan to define Handshake siege or not, basically a max_zone_players field.
  • Initial Designer Data
    • Small Keep - 150
    • Medium Keep - 250
    • Castle - 250

Allocation Enforcement at Start of Event — the Snap!

At 10, 5, 3, and 1 minute prior to the start of the siege event, notify the zone via one of the message types as well as the events tab in the chatbox, that a siege will be starting in X minutes and the zone will be cleared of all players not eligible to participate in the siege. 

• Different messages will need to go to different groups of people;
  • People not involved in the Siege zone
  • People involved in the Siege zone but will not be removed because of Rank(Guild Leaders)
  • People involved in the Siege zone and are in danger of being snapped because their alliance currently has more than would be allocated to the zone.
• There are 3 different types of messages we can use in a zone ;
  • Toast - Middle of screen announcement
  • Broadcast (false) - left side of the screen 
  • Broadcast (true) - Modal Center of the screen and requires a Yes Confirmation

At the start of a keep or castle siege event, notify players that the reservation system is about to engage for the next hour in this zone (The Siege is about to begin! Alliances who do not qualify to participate will be removed from the zone!”).  Then divide the players up into separate lists, one for attackers, and one for defenders.

Then divide the players up into separate lists, one for attackers, and one for defenders. Calculate the number of slots for each alliance. If the number of players in an alliance's list exceeds their allocation of slots, remove excess players (except guild leaders ) from the alliance back to their Bind Spots/Temple until they only have as many players in the zone as they have allocated slots.  If they have fewer players than allocated slots, that’s fine, it leaves room for more players from this alliance to arrive later.

The Algorithm on who gets the boot and who doesn’t when it comes to alliances is as follows using the example of a 300 person alliance with 112 available slots as defenders.  Guild Leaders within the alliance and in the zone are guaranteed to be chosen.  The remaining people in the alliance are apportioned related to Guild size, i.e. if guild a, b and c are 50, 100, 150 in size, the algorithm will first try to pick 19, 37, and 66 people from each guild that are in the zone to keep in the zone.  If there are extra slots because one or two of the guilds don’t have that many players they will be equally divided between the remaining two guilds or given to the last guild.  Preference in picking people to stay will be given to officers in the guilds, then full members.   

The algorithm runs every time the messaging is about to be sent up to the 1 minute last warning message, so someone may be in at minute 5, but out by minute 3. 

Players in alliances that have no allocated slots should likewise be informed and removed from the zone. (Attempt to place them at their Bind spot first, then their Temple, and as a last resort any other zone with a valid Runegate start point for their alliance/faction that has available player space.)  
(Internal note): There are start markers for Runegate start points, but not generic start markers for zones like we have in Temples.)
(Internal note T.C): I really want us to add visual effects to make this look like “the Snap” from Avengers endgame.)

Messaging

When a player is removed to the temple, inform them that their Faction (or alliance) only has X slots and they are being removed (or if not part of the alliances reserving the zone, inform them when the zone will be available again), but are welcome to queue back into the zone via a runegate. (“Your Alliance has more members in the zone than allowed! You are being moved to a safe location!”)

UI: Players can see how many of each team is in zone

Alliance Queue Sort Order

As noted, the attacking/defending alliance should each have a dedicated queue for players in that alliance, and attempting to login to this zone to use one of this Alliance’s allocated slots.  When a slot opens up for a player to be moved from the queue into the zone, the sort order for entry should be:

1. Sorted as usual (chronologically, first in/first out, with VIP given priority, and then everyone remaining.)
2. Unless the zone is at World Max capacity for their alliance, in which case leave them in the queue until the World is no longer at max capacity.

If a player who is not part of either alliance attempts to enter the zone, they should be unable to enter the zone and will have a modal UI popup that informs them a siege is in progress, it will end at X time, and they are unable to enter the zone. 

Who is Attacker/Defender? - Handshake Queuing

The idea is that most of the time, the zone player queueing system works as it does right now (allowing players into the zone until the zone hits a maximum amount and then forcing additional players into a queue). The addition to the current system is during any siege event as dictated by the siege schedule, each event should have an option to instead use the Handshake System as described below.  This means we will need to add data to the siege schedule for each defined event so that we can specify whether this event uses the Handshake System or not. (For example, hot zones will never use this.  Keep sieges will always use this.) Additionally, we need the ability to specify whether or not Handshake sieging is enabled on a campaign by campaign basis and this needs to be shown [UI] in the Campaign’s Rule and Restriction section. 

Handshake Sieges

When a siege window attacker wants to force the Handshake, the attacking alliance (a hostile alliance towards the stronghold owners) must invest into a War Camp Hippo in order to “fund” the scheduled siege event no later than 24 hours prior to the siege event starting, and any siege event not “funded” simply does not happen. 
Note:  Hippo is the interactable objects you feed materials into to build buildings in a keep

• Attacking an existing Keep or Castle requires the attacking alliance to feed a siege declaration (crafted from materials and items, including vendor purchased) into a War Camp Hippo
  • This Hippo will only be active to fund the next siege in the zone up to 24 hours prior to the beginning of the siege. (disable the interact during this time)
  • The cost of gold for the vendor purchased item is up for debate, it should be enough that it has a felt cost, but not enough that it discourages Sieges. (100K-300Kg?)
  • A stronghold can have one War Camp Hippo located near the front of the keep.
  • Once built the War Camp Hippo should be in a built state to indicate a siege will happen (We will need new 3d props for hippo/built siege camp/tent)
  • If the War Camp’s Hippo's costs are not met (“funded”), the Handshake version of the siege does not occur when the siege window goes active
    • If a Siege is not “funded” yet, then the Siege Schedule needs to reflect this.
• A War Camp Hippo has a series of prerequisites that must be met in order to feed them 
  • Prerequisites to interact/feed the War Camp Hippo can include:
    • A minimum “Potential Conquest Points” generated in the next interval(tick) for the alliance (calculated based on the existing held strongholds/outposts)
      • This value is set per season
        • Eg. The alliance must be set to generate 10 points in the next Conquest Interval in Spring but must be set to generate 15 points in Summer
      • This is a new UI element that should show all the time so players know how many Conquest points total they are generating each tick.[UI]
    • A minimum alliance size

UI Method 1 : Gate on Interact

UI Method 2 : Gate on Hippo requirements

• On interacting with the hippo without meeting prerequisites, we need to clearly message which prerequisites they do not meet
• The War Camp hippo resets at a random interval 2-4 hours after each siege window the Keep or Castle is a part of
  • Disable/Re-Enable  the F to interact when appropriate
• If a Faction (or alliance) finishes the War Camp hippo, the siege is enabled during the appropriate Stronghold's next siege window, and their Faction is labeled as the Attackers for the siege window
  • Based on the 24 hour prior to the siege event constraint, we should show a timer for when the siege can be funded until.

UI: Adding “Attacker” to a Funded Siege

UI: Adding a widget for the amount of Conquest “next tick”

 

• Post Siege there is a 2 - 4 hour delay for the War Camp Hippo respawn

What Does this Mean for Map Design?

• In dregs, reduce all zones to only have 1 keep. This will prevent issues where multiple keeps could trigger in the same zone at the same time causing breakage. Also, it would really not be fun if you were a member of the 2nd keep and were locked out of your home zone for an hour. 
  • We can be as random or as deliberate as we want. We could make some of them large keeps and others small keeps. Either way, we need to update data and validation to support whatever changes we want to make. 
• Design needs to rebalance the conquest points accordingly. Since we are lowering the number of keeps per zone, thus the overall number of keeps. 
• Dregs campaigns will need a minimum of 2 connections to 2 different zones going out into the world. Otherwise they could end up in situations where they cannot leave the temple. 
• Players should be able to reach any zone through 2 or more zones moving forward into the future. This way we don’t bottleneck players from being able to go to where they need during siege windows. 
   

[Communist_Puppy 264]

I like this.

[Darbtree 0]

first?

Second....I like the explanation.

Edited August 12, 2021 by Darbtree

[Ruq 232]

Thank you for posting this document for us to review. I have a brief question before I think this over and post some additional thoughts later. My question is as follows:

• Since there will be a scalar approach to keep size, a.k.a. larger forces at a castle versus a small keep, will you be adjust conquest point values for the small and medium keeps to also reflect this scalar approach?

[Recatek 413]

Could the handshake portion (without the zone population cap part) be included in Shadows? No-show siege defenses are a problem there as well, and they contribute to burnout over time. It would be nice to know that a siege is actually going to happen and that the attackers have some commitment to it.

Edited August 12, 2021 by Recatek

[TwoLucky 43]

I think the one part of this that may pose an issue is that of reducing the number of keeps in a zone to 1. Taking away more keeps makes it harder to have more of the buff buildings held by any particular group.

An option may be adding more zones to combat the loss of keeps, while the victory points would be made up with less keeps it reduces buff building availability and choice of attack for guilds. This would also give more zones to play with the worldwide timers concept, which is badly needed to stop hemorrhaging players from EU who can't participate well without region appropriate timers.

 

Also for Siege cost I would suggest using 125k or 225k so that siege cost + seed is 200k or 300k as a nice goal number.

Edited August 12, 2021 by TwoLucky

[Arkaini 73]

 One thing in this game, I enjoy much of is when the Random third party which come to a siege. Like sometimes its not even on purpose or planned. This always makes fights fun and interesting,

Another thing is, its defender favour for sure in some keeps.

I would like to see the zone caps, Raise higher, based on server. We should have reserved based on numbers. 
example - we have 300 zone cap.
140 attacking
100 defending
60 Randoms (third party)
or if cap is 250
120 attacking
90 defending
40 Third part

Things do get stale when its A vs B, the fun is when C shows up not in an alliance with either A or B and does their own thing, or maybe they are there to help A or B based on whats better for them. These fights are always the best.

Handshakes are amazing its needed but A s B night in and night out is boring


Also we need the handshake to cost something to do, because you can get guilds who will use maybe a NAP with another guild to declare war on them, and nothing happens. We need it to cost something to declare a war on someone
examples (conquest points)
500 conquest points for attacking guild
anything else can be expose to cheating

Edited August 12, 2021 by Arkaini

[Lyeos 53]

Just now, Hostility said:

So exploitable. lol

Get ready for minimum inscriptions.

Siegfe fight will have 5 DEF and 6 ATK. 'cause it's way easier to full gear 5 guys

[blazzen 4,632]

The biggest thing that's not addressed is preventing fake sieges.

If LoD makes a deal with W to siege each other but not capture each others keeps then nobody can ever siege us. It just becomes a gold farm cost to keep it up.

There needs to be a conquest point cost to sieging to prevent such a thing from happening. 

[PhantomHydra 16]

This seems to be going the right direction!  Once it gets implemented and ironed out a bit, can we get a mechanic for 3rd-partying?

[Grivyn 320]

War camp Hippo:

To trigger the siege you should have to place a seed for each bane tree, thus making the cost 225k (prevents meme sieging to waste a alliances time)

[Svenn 424]

There are a bunch of problems with this whole thing.

First of all, this seriously hurts small guilds in a variety of ways. For one thing, sieges are the best time to go to a zone and do anything else since most of the people there are busy. It's great for going to cap outposts or just to farm a spot that's usually heavily camped by whoever owns the keeps in that zone.

Second, it removes any third party interference. Whether that's showing up just to mess with a guild you don't like, or hiring mercenaries to come help you with an attack/defense. 

Quote

A minimum “Potential Conquest Points” generated in the next interval(tick) for the alliance (calculated based on the existing held strongholds/outposts)

• This value is set per season
  • Eg. The alliance must be set to generate 10 points in the next Conquest Interval in Spring but must be set to generate 15 points in Summer

This is terrible. Guilds that have keeps will easily meet these requirements and guilds without a keep will need to somehow hold onto 10 outposts without being back capped constantly. 

That also encourages large guilds to do MORE back capping and just general locking down of a zone. For any smaller guilds this means even more frustration as you're trying to just grab a few points here and there but now the large guilds want to make sure that no one can get any points they might need to be able to start a siege.

Quote

In dregs, reduce all zones to only have 1 keep. This will prevent issues where multiple keeps could trigger in the same zone at the same time causing breakage. Also, it would really not be fun if you were a member of the 2nd keep and were locked out of your home zone for an hour. 

We need MORE keeps, not less! Obviously there shouldn't be enough for everyone to have one, but it's already out of reach for so many guilds. You're basically cementing the idea that this game is only for mega-alliances and no one else. Not a mega-alliance? You don't really get to participate in half the game. On top of that, if you don't have a keep you are at a disadvantage because there are a ton of keep buffs that the people with a keep will have that you can't get.

The core of the problem you are trying to solve is that a single guild/alliance can cap out a zone preventing anyone else from participating. What about when they decide it's advantageous to cap out a zone for a reason other than a siege? This does nothing to solve that. You need a comprehensive solution. An easy one would just be a 24/7 alliance cap per zone. No alliance can have more players in a zone than half the maximum zone size, at any time. It's simple and it allows for some of the things that make the game interesting: guerilla tactics, third party interference, mercenaries, etc. 

Also, how often does this actually happen? I rarely see queues on any siege night. In fact, I think I've seen one queue in the whole current dregs campaign so far.

There are becoming less and less reasons for anyone that's not in a mega-alliance to stick around.

Edited August 12, 2021 by Svenn

[xHeXx 28]

So if i get this right, we are still limited by the days that a castle/keep is available given from the game/map generation?

Why do we have to reduce the amount of keeps per map if they are on different days given by the map generation? Not sure this is a must.

[BourbonDad 223]

On 8/12/2021 at 11:32 AM, TwoLucky said:

I think the one part of this that may pose an issue is that of reducing the number of keeps in a zone to 1. Taking away more keeps makes it harder to have more of the buff buildings held by any particular group.

One possible option if available would be to implement a game rule making sure that two sieges cannot occur in the same zone on any given night, this would allow us to keep the 2 keeps per zone which also allows more people a shot at owning keeps.

Another option may be adding more zones to combat the loss of keeps, while the victory points would be made up with less keeps it reduces buff building availability and choice of attack for guilds. This would also give more zones to play with the worldwide timers concept, which is badly needed to stop hemorrhaging players from EU who can't participate well without region appropriate timers.

Remove PvP buffs from keeps plz.

Edited August 18, 2021 by BourbonDad

[Chebachris 4]

reduce guild/ alliance size. having a zone cap that is smaller than a guild cap makes zero sense. 

[Robfacetat 0]

 .

Edited August 12, 2021 by Robfacetat

[Lyeos 53]

1 minute ago, Chebachris said:

reduce guild/ alliance size. having a zone cap that is smaller than a guild cap makes zero sense. 

You clearly nerver heard of wing guilds

[EvilGhandi 152]

This isnt a handshake. This is a mediocre version of an instanced siege. You're being outclassed in siege warfare by NW with this. 

No 3rd parties? 1 keep per zone? 

Handshakes are supposed to be a time that both parties agree to, not a time slot that nobody else is allowed to participate in. 

This is a swing and a miss.

[yianni 1,758]

13 minutes ago, blazzen said:

The biggest thing that's not addressed is preventing fake sieges.

If LoD makes a deal with W to siege each other but not capture each others keeps then nobody can ever siege us. It just becomes a gold farm cost to keep it up.

There needs to be a conquest point cost to sieging to prevent such a thing from happening. 

needs more than that conquest. for 2 reasons

a. attackers may be way ahead in conquest and may not hurt them at all

b. attackers may not give a poorly made dergs about conquest

[Breakyr 3]

6 minutes ago, EvilGhandi said:

This isnt a handshake. This is a mediocre version of an instanced siege. You're being outclassed in siege warfare by NW with this. 

No 3rd parties? 1 keep per zone? 

Handshakes are supposed to be a time that both parties agree to, not a time slot that nobody else is allowed to participate in. 

This is a swing and a miss.

Seconding this, it would be great to hear the developer's point of view on why we're excluding 3rd parties from siege content. Many of the initial and ongoing keep fights in Dregs have more than 2 alliances involved.