Retreat Damage During Crashes

Again, the game has crashed, and charged the three active members retreat damage. It is likely either incomplete exception programming or a poor choice to stop some exploit which causes this to happen, whenever the game stops with an active match. Conditions include (are not limited to): Random game crash, device power off, and Android 5 memory management of "inactive" apps.

The fix is straight forward, only charge retreat damage when the user actively his the retreat button.

Comments

  • _RiO_
    _RiO_ Posts: 1,047 Chairperson of the Boards
    Bjornkitty wrote:
    Again, the game has crashed, and charged the three active members retreat damage. It is likely either incomplete exception programming or a poor choice to stop some exploit which causes this to happen, whenever the game stops with an active match. Conditions include (are not limited to): Random game crash, device power off, and Android 5 memory management of "inactive" apps.

    The fix is straight forward, only charge retreat damage when the user actively his the retreat button.

    This mechanic was implemented to prevent 'cord pulls' and get out of matches unscathed instead of losing.

    It's a rather poor implementation though. The game should persist its state before an orderly shutdown and also, atleast on iOS and Android, movement to the background. This is detectable on all relevant OSes, one way or other; the developers just never bothered. Then when the game is resumed, you can force a player with malicious intentions to still finish that match. If you want to combat cord pulls that happen by severing the actual connection (e.g. a literal cord pull) you can prevent that by detecting loss of network connectivity (also doable on all involved OSes) and also persisting state at that point.

    That way you don't penalize players suffering an application crash.
    That only leaves users purposely killing the application, which is possibly also managable to some degree. (Monitoring for the kill signal perhaps?)
  • Agreed, I posted previously suggesting a presistent application state for this issue. Plenty of other games, Puzzle and Dragons for instance, do this. The sacrifice will be a small overhead to maintain state each move, which could easily be handled while waiting for animations to complete.
  • But imagine the lost HP revenue! icon_e_surprised.gif
  • While I appreciate the sarcasm, I'm hoping to see a few more people chime in with their thoughts or support. Being a squeaking wheel with sound reason is more likely to gain developer attention.