Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Activity requirements/Anti-camp/Anti-grief #6

Open
Jikoo opened this issue Apr 22, 2022 · 1 comment
Open

Activity requirements/Anti-camp/Anti-grief #6

Jikoo opened this issue Apr 22, 2022 · 1 comment

Comments

@Jikoo
Copy link
Member

Jikoo commented Apr 22, 2022

Camping unfortunately does seem to be a core flaw of existing siege and I'm not sure how to get around that. If the besieged user has a sealable bunker, they may as well just go AFK for the duration of the siege. Granting attackers access to levers/buttons would wreck a lot of chest securing mechanisms as you've described. Maybe defenders must move a certain distance or perform certain actions to be considered active? Taking damage from attackers is definitely participation, but the other options I'm not too sure of. I'm already envisioning someone's bunker being a 50 block tunnel that they just run back and forth in, or shooting an arrow into a wall every so often to refresh the timer. Maybe the attackers taking damage refreshes the defender's activity timer? That opens up the possibility of some kind of Home Alone situation where the defender is hiding and using a bunch of traps to discourage the attackers.

Siege should mandate some form of activity from participants to ensure that the siege is actually ongoing.

  1. Defenders must be attempting to either harm to attackers or flee from them.
    • Defenders should not be able to sit idle in a secure room inside their base.
  2. Attackers must be attempting to harm defenders.
    • Attackers should not be able to sit idle in a secure room near the besieged claim.
    • Attackers should not be able to run away and wait for defenders' timers to run out

Initial idea:
Timers for activity checks: internal timer -> display inactivity alert timer -> loss

  1. Longer forgiveness period at start so that defenders can prep before activity mandates hit
    • 5 minute starting period prior to activity mandates? 2 minute refresh?
    • Configurable, will need to be as total siege length may vary
  2. Attackers get more time
    • Defenders have to refresh timer before attacking team is disqualified so they cannot just hide
    • +10 seconds? Configurable. Doesn't need to be a lot, attacker participation timer should just start a little later to keep the pressure off when they might be about to win by a default
    • Combines with "return to battle" system - attackers cannot just leave and win
      • Maybe: refresh defender timer with attacker bonus if an attacker exits besieged area
  3. Direct PvP damage in either direction refreshes both sides' timers
    • PvP initiated by defenders does not grant attackers usual bonus; defenders are clearly fighting back, and if defenders can launch direct attacks so can attackers.
  4. Damage to attackers from certain non-PvP sources refreshes both sides' timers
    • Damage must be real damage
      • Snowballs, cactus, etc. that do trivial damage are likely stall tactics and should not refresh timers
    • Damage from projectiles fired from dispensers
    • Damage from lava
    • Other traps, etc.
    • Probably not fall damage
      • Too easy to accidentally drop 4 blocks when exploring unfamiliar territory
      • Using ender pearls should not extend timer
  5. Attacker timer should only be refreshed by non-PvP sources inside besieged claims
    • No walking away and tanking light hits in an area nearby that the defender cannot access to upkeep own activity
      • Defender timer will still refresh

Any activity on either side will refresh the timer for the entire side. The goal is to make the timer easy enough to refresh that players will never encounter it unless everyone on a side is actually not participating in the siege at all.

@Jikoo
Copy link
Member Author

Jikoo commented Apr 22, 2022

One major shortcoming of this system so far: Prepping an attacker victory by hiding/running.
Couple scenarios come to mind for this, but they're all very similar:
Player1 hides in an area near Player2 and the claim to siege. Player1 sieges Player2. Player3 joins the siege against Player2 and attacks, then runs away, refreshing the attacker timer before becoming disqualified for being absent. Player1 then waits out the defender timer and "wins" despite doing nothing.

Hiding alone is mitigated by the idea of using a bell to highlight attackers, which negates the need for a hacked client to see through walls/invisibility potions. If the attacker is too far away, the return to battle timer should forcibly fix that.

Maybe if the defender timer is supposed to alert but no attackers are inside accessible areas (i.e. all remaining attackers in areas the target cannot build in or under "return to battle" timer) the defender timer is refreshed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant