Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Concern


Drakano
 Share

Recommended Posts

Posted by Tiggs in previous thread

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

image.png

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!”)

image2.png

image6.png

 

 

 

 

 

Here is my statement and question. I was looking over some previous posts and ideas and I wanted to bring this topic up for the Handshake Siege topic. I was going to post in first thread but the thread is closed. How will you prevent guilds like death trying to do the thing they did the other day by dropping tags and trying to the keep from themselves. Here is the bottom line. Guilds have proven that they will manipulate the system even if the spirit of the system was to prevent said action. Crowfall has been slop to take actions on this so I would like to make a statement (IE Infinite tree bug that was only removed after it was made known to everyone who played. FYI was a massive load of Chaos Embers). If you do this it may result in guilds dropping tags forming new guild or asking their "Friends" to siege their keep so it is never able to be taken? I heard recently that you all will be cracking down on certain behavior. Have not seen this really so wanted to make sure I voice this issue before it was live. 

 

How do you plan if you plan to stop this from happening?

Edited by Drakano
Link to comment
Share on other sites

You are wasting your energy. The game is all ready done. One 9-28 there wont be enough people playing to support even 4 zone dregs. Handshake sieges sound fantastic but its not whats wrong with this game. 

-The game is 99% terrible game play for 1% laggy pvp.

-The engine will NEVER support the large battles this game requires. 

-The player base has lost faith in the the leadership in house. 

 

 

Link to comment
Share on other sites

I think the Handshake Siege design is way too involved and goes against the vision of a sandbox MMO. It further alienates smaller guilds from a major feature in the game and denies some of the more memorable siege moments from last Dregs where smaller 3rd party guilds showed up and made massive impacts in the outcome of what was happening.

The problems (zone capping to prevent proper sieges and no-show sieges) could have been solved by many other simpler solutions. I was out of town when that design went up and wasn't able to provide feedback. I believe they are spending a large development effort on an overly complex design that goes against the core game design, but I think that ship has sailed.

Link to comment
Share on other sites

On 9/16/2021 at 12:01 PM, Spineless said:

You are wasting your energy. The game is all ready done. One 9-28 there wont be enough people playing to support even 4 zone dregs. Handshake sieges sound fantastic but its not whats wrong with this game. 

-The game is 99% terrible game play for 1% laggy pvp.

-The engine will NEVER support the large battles this game requires. 

-The player base has lost faith in the the leadership in house. 

 

 

I agree 100%.

Even worse, as a reward for my 1 year VIP membership, the game kept closing when I tried to login.

Sad really, as the game could have been good.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...