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

Search the Community

Showing results for tags 'handshake sieges'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • CROWFALL
    • News & Information
    • Game Play
    • Character Creation and Development
  • LIVE SERVER BUG REPORTS AND FEEDBACK
    • Live Server, Web, and Localization Bug Reports
    • Live Server Update Feedback
  • CROWFALL COMMUNITY
    • Community and Social
  • PLAYERS HELPING PLAYERS
    • Support
  • PUBLIC TEST SERVER
    • News and Information
  • ARCHIVE CROWFALL BETA
    • ARCHIVE CROWFALL LIVE BETA
    • ARCHIVE CROWFALL COMMUNITY
    • ARCHIVED ECS21 HungerDome
    • ARCHIVED TEST SERVER
    • ARCHIVE BEYOND CROWFALL

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Interests


Guild


Location

Found 1 result

  1. 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: 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. 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: Sorted as usual (chronologically, first in/first out, with VIP given priority, and then everyone remaining.) 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.
×
×
  • Create New...