No announcement yet.

A system to prevent delay catches?

  • Filter
  • Time
  • Show
Clear All
new posts
  • Class: {{esusrinfo_class382519}}
    Level: {{esusrinfo_level382519}}
    Guild Name: {{esusrinfo_guild382519}}

    A system to prevent delay catches?

    Delay catches are one of the worst design side effects in the game's PvP. They result in starting combos that have no counterplay aside predicting exactly when they would happen (AKA perfectly reading your opponent) and doing a move that would set up an active hitbox to end the delay (by hitting the opponent with that hitbox). It's very upsetting to die to something you have next to no way of stopping, and delay catches are only made worse in the current meta of heavy gear, where players can very easily tank for awakening and MP to abuse delay catches with if their opponent doesn't do heavy damage.

    In consideration of this, I wanted to propose a design change to skill delays that would prevent delay catches from happening in general (not just for any particular skill that has this problem). Additionally, I want to bring everyone through my logic that led to this solution.

    So, shall we detail the problem?

    SPOILERFirst, let's think about our ideal. In an ideal scenario (AKA where delays work properly), how would skill/awakening delays work?

    The main purpose of delays on skills or awakenings is to allow the user to complete the animations of those moves, which often involves firing off an attack. So ideally, skill/awakening delays would allow for the completion of animations (so targets don't get out of the way when they weren't supposed to), but nothing more.

    So now that we have the ideal setup for a delay, let's take a look at what we have in-game right now. What is the current in-game method for delays, and how does it fail to meet the ideal?

    Currently, any awakening animation or special active that takes time to complete is given a preset amount of time as a delay. This would be an acceptable setup so long as the delay time given by the developers always matched the animation time. However, there are several places where this can fail.

    The first issue that can pop up is that human error occurs on behalf of the developers, and the delay time is set to something shorter or longer than the animation time. The respective results are delays ending before the animation completes (meaning targets might have a chance to get out of the way they were never intended to have), or a delay catch results (targets are in a delay longer than intended, and the attacker has more of an opportunity to catch them than intended).

    The second issue is that the animation speeds of some special actives are affected by attack speed, allowing players to complete those animations faster. This instantly becomes a problem if the delay time is fixed, but the animation time can be arbitrarily sped up - the animation time will end up being shorter, so the delay is longer than necessary, resulting in a delay catch.

    The final issue is that some skills don't have a fixed animation length. This is mostly prevalent in moves that have to land on the ground to finish - Lu/Ciel's Stomp, Anemos' Sharp Fall, and Comet Crusader's Mod Burst Wolf provide examples of this kind of move. This kind of situation cannot be resolved with a fixed delay length, because depending on the conditions the move was used in, the delay will either be the right length, too short, or too long. Since the delay is a fixed duration, it can't adapt to the different scenarios these moves could face (such as varying heights to descend down).

    Now that we've defined the problems that prevent delays from being ideal, how do we get to a solution that bridges these gaps and lets us get an ideal implementation of delays in-game?

    From the description of the three issues, it's obvious that relying on a fixed delay length will eventually fail. Due to the second and third points, animations may vary in length, resulting in situations a fixed delay length can't ideally compensate for. Fixed delay lengths are also dangerous due to the first point - developers are humans and are capable of making mistakes, which are bound to happen sooner or later. Having to manually put in delay lengths means that eventually, someone will slip up and create a delay that's flawed.

    Therefore, any implementation of ideal skill/awakening delays must be dynamic. In particular, the delay length must be dynamic in relation to animation length. This is quite fine as a concept, but how do we solidly integrate this into the game's code?

    One suggestion might be to simply believe that each awakening/special active has a defined base animation time in the game's code. Then, it might be considered that you could just take that time, reduce that time according to attack speed (if necessary), and then make that animation time the delay time as well. Unfortunately, this solution fails: it does nothing to resolve the third issue of animations which have varied durations based on exterior factors, such as the height the move was performed at. Furthermore, there are also some in-game moves (such as Furious Blade's Bloody Accel and Code Esencia's Assault Spear - Buster) whose animations can be ended early by moving - this is a situation that can't be resolved by relying on the animation time alone.

    Then, what if the implementation ignored animation time, and instead looked at the character's state? Instead of relying on a specified time for the delay to end, the delay can instead look at the status of the character. All special actives either put the user in I-frames or super armor for the duration of the animation, and the game might be able to rely on these facts to tell when an animation ends (the player would be outside of I-frames/armor at this point). Alternatively, the game could look to see if the user is using a special active/awakening (if such an in-game state exists), or look to see if the user is in combat while not in a special active/awakening animation (you are considered in combat if you deal hitstun, receive hitstun, attempt an attack, use a skill, or successfully move).

    This implementation is certainly interesting, but would have a couple points to smooth out. First, if there was a reliance on the state of the character being in I-frames or super armor, the game would have to know the source of the I-frames/armor was the special active, and only observe that source. If I-frames of any kind were considered, skill delays could become excessive while people were in I-frames gained from revival effects (such as Eclipse or just being resurrected in a team match). If super armor of any kind was considered, alternative sources of super armor - such as Iron Body for Elsword/Elesis, or the Unaggressive Aura item - would end up confusing this system.

    This implementation could also end up encountering issues with lag, particularly if a player was aware of how this system worked. In theory, a malicious player using this system to their advantage could trigger a special active, then force lag to occur. This would cause the opponent's game to believe that, since that malicious player is still in a special active/awakening on their screen, that player is still in I-frames or super armor, so the delay should keep going. This could give the malicious player delay catches that never should have occurred once the lag subsides.

    If lag was a potential issue, then, perhaps a fail-safe could be introduced to counteract that possibility. While fixed delay times can't be used as a solution by themselves, perhaps they could be useful for checking when it's obvious that a delay should have ended. This would, in part, involve basing the delay time around the animation time (adjusted for attack speed).

    However, special considerations would also have to be made for moves whose animation time varies by height. In that case, developers might consider a maximum height it would ever be reasonable to see a move descend (perhaps 5 platform tiers, reached by jumping off the top level of an area via Rena's double jump or Chung's cannon jump, then going to the area's floor), then set the delay time according to that move's vertical acceleration and terminal velocity. There would be very few situations where a player could actually reach heights beyond this in a PvP match - and even if they did, they would probably be in a situation where they couldn't even see opponents below them anymore.

    This hybrid setup does help combat a lot of possible situations that would thwart the system, but some issues might still pop up if I-frame/armor states were referred to and their sources weren't discerned. If a person got resurrection I-frames and used a special active, the fixed timer would trip the end of delays for most moves... but for ones whose time limit had to be set higher due to potential maximum heights (such as Sharp Fall), delay catches could still result. Similar issues could result with moves whose animations could be ended early via movement, depending on how the fixed time limit was implemented.

    The problems seen with the I-frame/super armor implementation wouldn't come up in the "in combat" implementation - even if the person was in I-frames after the move ended, the second they moved, the game would register them as being in combat, ending the delay. However, relying on an "in combat" status has a couple of its own hurdles to deal with.

    First, in order for an "in combat" implementation to work, the person causing the awakening/skill delay can't be considered in combat while performing their animation, as this would end the delay. This is no problem for targets dealing/receiving hitstun, since any player who deals/receives hitstun during a delay gets out of that delay... but in a team match where both opponents are caught in the delay, yet only one gets hit by the special active, the other opponent would ALSO get out due to the caster being in combat, letting them move much earlier than they should be able to. This causes issues with being in combat due to movement as well, since a solid number of special actives move the character horizontally and/or vertically.

    Second, if the fixed time limit for the delay is higher than the animation time (to account for moves with varying heights, for instance), there's nothing preventing that player from standing still for the rest of the delay. They can't catch anyone doing this, and risk hitting the end of the delay if they aren't careful, but could let time-based effects (such as elemental DoTs) run for a little bit to gain a small advantage.

    ...after this logic, this where I get stuck and I'm not sure how to proceed further. Here's a summary of the potential solutions I stated above:

    Secondary Solution (meant to be used alongside a primary solution): set skill/awakening delay time limit based on skill/awakening animation time adjusted for attack speed. Developers set extended maximum limit for moves whose animations can end early (e.g. Bloody Accel) or can have longer animations based on exterior factors (e.g. Sharp Fall, whose animation length depends on the height it was used at)
    + Heavily counteracts attempting to use lag to trick the game into thinking a special active is still being performed, because the time limit will be tripped
    + Able to adjust for attack speed stats and buffs
    - Moves that can vary in animation length require developers to set the base times (before attack speed reduces this time), creating a possible source of human error
    - Must be coded properly to account for all buffs and debuffs on the character - missed sources of attack speed would throw off the delay time limits

    Primary Solution A: Check I-frame/super armor state to see if the character is done performing a special active/awakening
    + All special actives/awakenings put players into I-frames or super armor during their casts
    - Requires the game to know the sources of I-frames/super armor, or else other sources of I-frames (e.g. being revived in a team match) or super armor (e.g. Iron Body, Unaggressive Aura) could confuse this system

    Primary Solution B: Check for an "in combat" state
    + Characters are "in combat" if they deal hitstun, receive hitstun, use an attack/skill, or successfully move; if delays ended due to movement, any attempt to get near the opponent would end the delay immediately
    - Requires the game to not trigger the "in combat" state while the special active/awakening animation is being performed due to the animation moving the user, or due to the skill hitting a player (which would end the delay for other players in team matches, even if they weren't hit); currently unknown if the game is capable of meeting this condition
    - On longer delays (for moves whose animation lengths can vary), this system would allow the caster to simply stand still for the rest of the delay, letting time-based effects continue with the opponent helpless to do anything about it
    -If a player couldn't be considered "in combat" during a special active/awakening, it could lead to stalling for effects that require you to not be in combat (e.g. charging Lightning Chain)


    This would be a lot more trivial if it was the case that the game could recognize when a character is either performing a special active or awakening animation, and simply end the delay when the character leaves that state. However, I get the feeling that if the game's coding had that capability, delay catches would be extinct already.

    So this is what I've come up with, but it's evident that these suggestions are still flawed and in need of adjustments before any solution here could cover all the situations that might come up in PvP matches.

    I'd really love to get some input on what could be changed to make these solutions function, or alternative solutions. Delay catches aren't a problem that will magically disappear unless some change annihilates the possibility of delay catches in general. Laby's Eternity Winner path already has a delay catch (Inner Aurora), so it seems delay catches are a mistake bound to be repeated unless a change to the system is made.

    Even if these solutions I've provided are flawed, they're certainly better than what the game has now.
    Trial Dungeon Mode - Compete in PvE Challenges!

    Petition - Make Hitstun Recovery Constant

    RNG Explanation/Discussion
  • Class: {{esusrinfo_class382532}}
    Level: {{esusrinfo_level382532}}
    Guild Name: {{esusrinfo_guild382532}}

    This is a bit outside of the usual utilities-to-resource delving that I do, but I'll put some thoughts down.

    From what programming logic I can apply, the game almost certainly already has a system that checks whether a player is using a special active or other fixed-animation skill.

    The existence of skills that allow you to cancel out of their animations (as you mention before, Bloody Accel and others) proves that there has to be some kind of an flag coded into the game that allows a character to interrupt their special active animations. What we can derive from this is that there is a system in place that 1) locks a player out of directly controlling their character for the duration of most other skill/awakening animations, 2) this system prevents players from cancelling out of these animations (Ara and other cases excepted), and 3) allows them to resume control of their character once the animation is complete or other conditions related to the skill are met.

    Therefore, if I were in a position to inspect the code of the game, my goal would be to find where this "fixed animation" flag is set for any given skill to identify what variable triggers its On/Off state. Once that is achieved, the aim would be to tie the active state of any given skill freeze to that On/Off flag.

    Broken down, we have a variable that permits control and a check that determines whether a skill is active already. Therefore we can attempt to tie skill freeze into this system such that it only activates if the two conditions are active at the same time.

    Control = true;
    when(SA_Awakening = true), Control = false;
    when(Control = false && SA_Awakening = true): Skill_Freeze = true;

    This is just conjecture, but that's the basic breakdown of the programming task that I can think of.

    Personal rant about pause buttons in the spoiler below.
    One of the first things I ever learned about fighting games was in Smasn Bros 64: even as an elementary schooler it was glaringly obvious that I gained a huge advantage over my brother when I paused the game and resumed it at a point he couldn't predict. From then on pauses were on a strictly need-to-use basis, and we always counted down after a pause so both players knew exactly when the game would resume.

    I really, really despise classes that have cheap, spammable Special Actives since this often reduces their gameplan to spamming the pause button, and since I learned about this kind of abusive strategy before I was nine depending on it seems incredibly infantile. Pause button characters always set me off and I would most definitely welcome a change to this system.
    Last edited by XlVA-solace-; 01-12-2019, 08:08 PM.


    • Class: {{esusrinfo_class383912}}
      Level: {{esusrinfo_level383912}}
      Guild Name: {{esusrinfo_guild383912}}

      Alright guys, I just briefly read all the logic here but the problem is not how to remove delay catches but whatever or not delay catch need to go or what we need to do about it. I am pretty sure everyone already have a good idea how delay mechanic in this game work.


      • Class: {{esusrinfo_class402568}}
        Level: {{esusrinfo_level402568}}
        Guild Name: {{esusrinfo_guild402568}}

        Though this is old, I'm bumping this thread. This logic is still as important as it was before, and honestly, this is the kind of conversation I think we need to be having at this point.

        It's becoming pretty obvious that mistakes like delay catches and backward hitboxes are being repeated as new characters and skills are produced (Laby has both of those). I think it would probably be best for the game's health to revamp the internal systems that guide these mechanics and led to these problems, which would cut off the old issues and prevent new ones from coming up. The delay system isn't the only one - things like calculations for Gigantic traits need to be observed (as a significant number of Gigantic traits have led to unusual hitboxes that don't line up with their graphics), as does coding to prevent storage (the removal of safe cancels was a massive mistake whose consequences show up in matches to this day).

        Of course, it would require KOG's investment in such matters... but if the whole of PvP improves as a result, I'd hope they'd consider it as worthwhile as I do.
        Trial Dungeon Mode - Compete in PvE Challenges!

        Petition - Make Hitstun Recovery Constant

        RNG Explanation/Discussion


        • Class: {{esusrinfo_class402829}}
          Level: {{esusrinfo_level402829}}
          Guild Name: {{esusrinfo_guild402829}}

          This seems all well and fine just would be hard with current peer to peer connection it may make pvp worse. I like the logic behind it tho.


          • Hitotsuoboe-solace-
            Editing a comment
            Knowing our server is prone to lag is why I wanted to use the current, static delay system we have as a failsafe, in case some massive lag spike hits and throws things out of proportion.

            Outside of that, I guess my assumption was that if, due to lag, a move comes out half a second later on the opponent's screen than it does for the caster, on average, it would likely have its super armor/I-frames end half a second later via the same logic. Of course, this can end up varying depending on latency's jitter, so I can see concerns there.

            Still, I'd rather not keep a system that is guaranteed to produce problematic delays under a perfectly stable connection.
        • Class: {{esusrinfo_class402956}}
          Level: {{esusrinfo_level402956}}
          Guild Name: {{esusrinfo_guild402956}}

          ...or maybe JUST MAYBE KOG could SIMPLY just not let the skills have delays longer than the animation!!!! OUO

          Your ideas aren't bad though.
          Last edited by ImmortalSage-solace-; 04-14-2019, 06:07 PM.


          • Hitotsuoboe-solace-
            Editing a comment
            Yes, that's the goal, but how to get there is the problem. Once again, there's some moves (e.g. Sharp Fall) the current delay system cannot properly handle no matter what.
        • Class: {{esusrinfo_class403656}}
          Level: {{esusrinfo_level403656}}
          Guild Name: {{esusrinfo_guild403656}}

          How about no delay at all. Still have i-frames and stuff.

          Super speed gameplay.

          i mean I think that time adjustments for delay might work but personally imo I don't think fixing delay will drastically help pvp too much. Other factors need to be worked on for a substantial fix (gear, balance/passives and skills that are hard to contests, etc).
          Last edited by Wolf7-solace-; 04-19-2019, 06:57 PM.

          <---My Rune Master/Elsword Suggestions

          #fixPhoenix Talon

          <---Request log from kog regarding changes from balance patches


          • Hitotsuoboe-solace-
            Editing a comment
            I honestly wondered about that when Templar brought it up. The thing is, we already have the means to check this one out, since Ereda and Sparring's Brawl mode disable skill delays.

            Though, I ultimately wonder how some skills with long casting times would be adversely affected (Code Ultimate's Assault Spear, for instance - it's a fantastic single-hit skill for damage, but also takes a good 2 seconds to fire off). That's the main concern in that environment... but at the same time, it would be interesting to have to guess your opponent's moves in advance with your specials that much more often.


            However, we can't just ignore the delay problem because there are other problems with balance. "Skills that are hard to contest" accurately describes delay catch special actives, anyways. Advancing one problem at a time is the only chance of even getting close to a stable game.
            Last edited by Hitotsuoboe-solace-; 04-19-2019, 09:32 PM. Reason: Added second section to response
        /* */