[2021] Handshake Keep/Castle Sieges

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. 
   

I'm keeping this post on topic, and removing threads that aren't about the design doc presented.   If you want to have a discussion outside this topic feel free to on the forums or discord. 

3 hours ago, macavity said:

This whole thing where the zone is removed from the game by making it inaccessible to everyone that's not in the siege is so INSANELY stupid. Just keep the normal zone, but move the actual siege battles off to a different server entirely since it's already being instanced. It's such a no-brainer.

This isn't an option available as we don't have a server instancing system where can just copy an area (because people would want to use their keep) and put it into an instance. Making tech like that would take a considerable amount of time.
 

3 hours ago, Retchet said:

Kicking players out of the zone who aren't part of the handshake eliminates the possibility of a small guild swooping in at the last moment and capturing the keep for themselves.

The handshakes also prevent marauders from showing up and launching their own attacks either against the defenders or the attackers.

Handshakes also prevent guilds who intend to work as mercenaries from showing up an event and surprising the defenders or attackers because now people are forced to be in an alliance to participate.

Absolutely true, this entire design doesn't help 3rd parties out who want to poke their head into an active siege. However the problem we are trying to attack is people zone capping zones to prevent attacking/defending, and if that is happening, how could 3rd parties fit into the zone anyways? The zones are capped!
 

2 hours ago, UnderGrowth said:

Add more zones, Don't reduce total number of keeps. Make more keepless zones like Polynices in the current dregs. Keepless zones address a lot of the movement issues you are looking at. Stop confining yourself to just 4 zones, it's clearly causing design choke points. increase map size in general.

As we can add more zones we will, I think the 7.100 maps will be pretty interesting, as we are trying some new things with them.

In general locking people out from the zone isn't something that will be popular with anyone, including the developers. There is just more demand than we can currently handle on a single zone if everyone tries to pile into it.
If there were easy tech solutions, we would jump on those solutions in a heartbeat.
So we are going to try something we think might work, and see how it works. It should also have a nice side effect of presenting a reasonably balanced fight from a numbers perspective of attackers and defenders. It should enable smaller guilds to face an equally small force. Yes it does cost us aspects like mercenary action in active siege zones that they can get into, and other 3rd party schenanigans, which is unfortunate.

22 hours ago, Andreaa said:

Sounds like guild and alliance maximum sizes need to be decreased. The response to this is always "But big guilds/alliances will just split their forces between 2 guild tags!!!!!111" Well...okay? The end result is that there is still an additional logistical hurdle, which was not there before, to maintaining a style of play that is clearly having negative effects on the game environment.

Yes we would absolutely love to crank the guild size down from 500 to a reasonable number, however it is one of those things that changing it this far into Live would really suck for many guilds.

21 hours ago, veeshan said:

The problem i see here if your still only catering to large zerg alliances most small/medium size guilds wont be able to fill the roster of the 90-110 odd players on to defend or attack seiges, think it would be a better option to have catagory for smaller scale and the zergs, small keeps for example could be 45 vs 55 and then the larger keeps can be bumped up to the 90vs 110 or what not.
This would allow smaller faction to be able to compete.

They may not be able to fill the roster, but it keeps the other side in check as well. Currently if you can't fill the roster, then that is more zone slots for the bigger guilds to fill even more.

20 hours ago, Yoink said:

This isn't handshake. I don't know what this this. Is this convoluted proposal the way it is to work around existing limitations with the set in stone siege timers?

You need to go back and fix the cracked foundation before you add on more layers.

Get rid of all set siege windows for keeps and castles.

If a guild wants to attack a keep or castle they bane it. Defending guild leader chooses the time of defence between 24 and 48 hours of the bane placement.

The siege isn't over until there is a winner. Set your reserved spots to less than the zone cap. Say 100 attackers, 80 defenders but still kick everyone else out. If the siege isn't over after 1 hour, open the flood gates to everyone.

The reason we went with siege timers was to prevent 1 big alliance from sweeping the map with ease. If there is any form of staggered times on Keep sieges, then it is trivial for big guild X to march across the map. Take Keep 1 from 6-7, 7-8 take Keep 2, 8-9 Keep 3, take a snack break, Keep 4 from 10:30-11, and so on.  The thought was with Siege Times this would be less likely.
 

19 hours ago, macavity said:

If you read the thread, it has been suggested several times for them to just make more zones and POIs and force people to spread out. 

That solution is far better considering that:
1) It doesn't make take an entire zone completely out of the game for 1 hour.
2) It still allows third party interference.
3) It's also anti-zerg since if someone is zerging 1 keep in 1 zone, then there would be 19 other keeps in 19 other zones, for example.
4) It also introduces way more strategy and tactical play if you can't just default win through zerging and you actually have to strategically contest certain zones/areas/POIs at certain times.

"Making more zones" doesn't force people to spread out in and of itself. Alliances can still chose to lock an entire zone if they choose. "Well then also add X,Y,Z!" 
Ok then it is not just make more zones, it is a bunch of other things which may or may not work.

18 hours ago, PopeUrban said:

Like if your goal is instanced seiges, fine, just instance the actual keep parcels all the time. Like literally take them off of the maps, put them on their own micro-islands, and just have "keep islands" and "keep gates" so you don't have to break an entire zone for an hour because two groups of people are playing slap hands in a tiny part of it. Or put a woo woo forcefield around them or whatever.

If your goal is open world sieges, this ain't it. This is very much the opposite of it. This is "we took our open world and actually just made instanced sieges on timers like PvE games"

Even the basic level of "handshake" is missing here. This is just paying to rent a siege window. THere's no handshake involved. The defender still has no influence over the siege timer, nor does the attacker. This still requires defenders to show up for no-shows on whatever timer the campaign scheudling gods decided to attach to a keep even if all their opponent is doing is trolling them, and even if there's a clear time slot imbalance between two guilds.

This does nothing to solve the "prioritize attacks with sooner windows so we get more conquest points in stead of attacking people we actually don't like" whack a mole nature of scheduled sieges.

We tried open world sieges, and here we are, guilds abusing the technical limitations for gameplay wins.
Even if they were instanced in the way you suggest, there is still the zone limitations, which would put us right back to the behaviors we see now.
Why is it required to shift the time to fix the problems we are trying to fix? Don't you think shifting time is just going to take all the problems you listed and some additional bugs/exploits ontop of them?

On 8/14/2021 at 3:03 AM, macavity said:

Don't forget that the only people who actually stuck around during the 6-7 years of development and actively played/tested the game were a lot of people from those big guilds as well. So in a way it's true that some(maybe most?) of those people shaped the game since Artcraft worked off of the feedback that they got from those people.

Yes, the people who where here for the past 6-7 years shaped the game you are playing.
Ground target reticles? removed - players didn't like em.
Root Motion Combat? removed - players didn't like it.
Build time on crafting? removed - players didn't like it.
Survival mechanics? removed - players didn't like them.
There is quite a long list of things that were yanked because of feedback. Unfortunately, There is no way to take feedback from folks who weren't here when the cement for the house was being poured.

That being said, those of you here now are shaping the aspects of the game we change from now on, and that feedback is considered in everything we do. So keep it coming!
 

On 8/16/2021 at 1:23 PM, mystafyi said:

The instancing part is insanity. They want to block off part of the game world to everyone else during that time and make that zone an instance to be loaded into like a lobby game....

The big driver of this is tech, and the alliances locking players out of zones. In a perfect world we wouldn't have these limitations, but we want to try something and not let the issue fester. Yes i know it causes problems with the 3rd+ parties and those parties do add variability to the fight, we just don't have a better way to solve the core issue and not let it be gamed.
 

On 8/14/2021 at 1:21 PM, rutaq said:

So after plodding through 16 pages of posts here is a condensed version.

ACE explained that their current tech limits have resulted in zone caps which can be leverage by very large Alliances to help win a siege by preventing enemies from attending the siege.

ACE acknowledge that they promise Handshake sieges as a top priority after launch because sitting around waiting to kill Bane trees without any opposition isn't the goal of their game.

So given the tech limits ACE has proposed a system to limit zone caps from deciding who the winner of a siege is as well a providing more opposition during sieges and less "no shows".  Given the development resources, ACE is trying to limit the amount of new Tech they have to build to meet this first pass at dealing with the current issues.

The responses have focused on :

1)  Small guild feeling left out of sieges due to ;  the potentially expensive costs to declare a siege, the inability to third party without joining an Alliance and the new smaller siege player caps which are still much larger than many of the small guilds that are lucky have 30 active players.  

2)  Large guild miss the openness of the current system but understand the tech problems and mostly accept that a system like this is needed to prevent the tech limits from determining the siege winner.  Most support the systems while a minority are concerned that Alliance caps with hurt the social aspects of large Alliances of casual players.

3)  A number of players that have theorized their own solutions to the problem that would generally involve huge amounts of new tech and redesign of major game systems.   Given ACE's development history, such efforts would take well over a year to implement.


So we are stuck with a proposal that has issues, isn't perfect, doesn't solve everyone's problems but at it's core deals with the major tech issues at hand and make a first attempt at Siege Handshakes to prevent the "no show" sieges that have make up 75%+ of all siege windows since launch.

 

This is a really good summation of everything contained in this thread, thanks!

I'd like to thank everyone for your feedback, aspects of the design shifted based off of it, and we will move into the next phase where Tech costs the feature out, and we see where it can be put in the schedule.

 

Thanks everyone! We hope to have some new designs up soon for you to review and provide feedback on.