Crash during attack = all troop loss

[Kaiser Shag]

Hi,

I just made an attack, it was an easy one, I used 5 HT mk5 and 4 strike fighters mk6. I nearly finished the battle (with 0 losses), and then I had a game crash.
This means that from an attack for which I would have earned 600k gold, 500k food, 3k oil, instead I win 0 and have to pay 12k oil to reform all my army !!!

This nonsense has to stop now ! it is unacceptable that we loose our entire army because of these problems and that Nexon never gives us back ressources !! even if we make a request we only get sometimes 100 crowns, but these 100 crowns you can't buy 12k oil !

TinSoldier why do we absolutely never have a propper compensation for our losses ? it is so long and costly to retrain 5 HT mk5 + the 4 strike fighters, why aren't this losses just compensated ?

 

[LordAnubis]

It's a total joke....like this game. It's been happening to me all week long. I gave up long ever reporting these things to CS because they don't do a damn thing about it.

 

[melheor]

I have been having this problem for a few months now. It seems like the longer you have the game open on iOS, the more likely it is to randomly crash like this. Nexon support refuses to acknowledge any problems on their end, they keep blaming my device, and yet this same iPad has no issues running newer, beefier games with 3D graphics and special effects. Sounds like a memory leak that Nexon devs don't care to investigate.

 

[TinSoldier]

That sounds like an interesting observation, melheor. Do you have a ballpark estimate on how long you have the game open before the issue becomes present?

 

[LordAnubis]

I have been having this problem for a few months now. It seems like the longer you have the game open on iOS, the more likely it is to randomly crash like this. Nexon support refuses to acknowledge any problems on their end, they keep blaming my device, and yet this same iPad has no issues running newer, beefier games with 3D graphics and special effects. Sounds like a memory leak that Nexon devs don't care to investigate.

TinSoldier it's exactly what is, a memory leak Nexon claims to have fixed. I recently bought a new device with more cpu and more memory yet I am experiencing this same issue. I checked how much memory it's been using and it uses more memory now than it did before. Almost 1 GB! For a game like this that amount of memory usage is not warranted and points to a memory leak.

 

[melheor]

That sounds like an interesting observation, melheor. Do you have a ballpark estimate on how long you have the game open before the issue becomes present?

TinSoldier
It varies significantly. Last few weeks I've been doing 1 to 2 attacks and close the game (waiting for cannons to respawn) and the crash has not been occurring. I've been lucky that there are no expensive oil upgrades to save for, and people don't usually loot me for food/gold. Prior to that my strategy has been to spawn a training blessing and just keep going after opponents in rapid succession until I save enough for my upgrade. Back when I played on Android (which no longer turns on, I think the battery melted inside), I'd be able to do these training blessings back to back for 4-6 hours with no crashes. Naturally, when I switched to iPad, I used the same strategy. Sometimes I'd get through 1 training blessing before the crash, sometimes none, never through 2 (but this is just going from memory). From this, I'd guess anywhere between 30 mins to 2 hours for the crash. Also, I started turning off all background processes now, which may have helped although I have no way to say for sure.

Also, not sure if it's relevant, but I'm an Atomic player in case the issue is related to the number/strength of troops.

 

[TinSoldier]

Thank you for the detailed description! I'll see if we can replicate the conditions.

 

[melheor]

Thank you, you're the first person within the company to acknowledge this issue instead of dismissing it as an issue with player's gaming style or the device.

 

[Kaiser Shag]

In my alliance it has become normal to systematically close and relaunch DN before doing an attack in WW. But doing this for every multiplayer attack is just a joke..

 

[melheor]

TinSoldier I also wanted to point out that the real problem here isn't the crash itself, we understand that no game is perfect. The problem is the unfair penalty the game imposes on a player who crashed, since it does not differentiate between a crash and leaving the battle. For us Atomic players a single crash often means 2 hours of airplane retraining time and 5-10k oil lost on having to retrain heavy tanks, airplanes, and APCs (depending on army composition). It's not a good experience for a player to be set back several hours in game progress through no fault of their own. It's a horrible game mechanic that leaves your players frustrated at you, your support spending time on unnecessary tickets, and your game reviews suffer in the app store.

There have been a number of suggestions on how to improve this system in the Ideas forum, and I really hope your team reads them. One idea was to give player the option to continue or restart the crashed attack if the player reconnects to the network within the next couple minutes or so, and I think this would be the easiest option to implement with least breakage to the original intent of the penalty.

 

[Manifesto]

That sounds like an interesting observation, melheor. Do you have a ballpark estimate on how long you have the game open before the issue becomes present?

I've crashed semi-consistently about twice a month over the past 6 months and the one thing that's stood out is a quick victory rally on the TC, in approx 70% of crashes. I'm not sure if others have noticed this too.
TinSoldier , I would take a guess and say that maybe there is too much going on in those few seconds: troops speeding up, all troops firing, TC defenders emerging, building exploding, game registering the QV and 2 medals, etc.
Maybe the buildup or surge of information at that instant is more than the servers can handle?

 

[melheor]

I've crashed semi-consistently about twice a month over the past 6 months and the one thing that's stood out is a quick victory rally on the TC, in approx 70% of crashes. I'm not sure if others have noticed this too.
TinSoldier , I would take a guess and say that maybe there is too much going on in those few seconds: troops speeding up, all troops firing, TC defenders emerging, building exploding, game registering the QV and 2 medals, etc.
Maybe the buildup or surge of information at that instant is more than the servers can handle?

While dropping down in medals today, I had the game crash with none of my own troops on the board. I've sniped a few resource buildings with my infantry, had them killed, then while looking around the map for another spot to deploy troops, the game crashed. There wasn't a lot going on at that time, and the enemy troops were not moving. Luckily this crash did not affect me much because I wasn't going for the win this time. I did deploy training blessing about 10 mins prior to the crash (prior to that I played the game for a while without the blessing). Perhaps (on iOS, where the crashes are more common) the crash is related to the training blessing? So far that seems to be the only constant I noticed (although I can't definitively say if I had a training blessing up each time there was a crash).

 

[Nb4powerup]

I've forwarded this thread to the team regarding compensation. Thanks everyone for your feedback and detailing what has been happening.

 

[Tsamu]

I am absolutely not trying to deny that this is a serious problem, but... How would the game distinguish between a legitimate crash, and a forced quit? Say I am attacking and I realize 10 seconds from the time limit I'm not going to get the last defensive building in time. What's to stop me from closing the game and claiming it crashed? A solution could be for a local log to be updated every second, even if the server connection has been lost, and then it could be analyzed (by an algorithm) to determine whether the attack would have been successful.

 

[Kaiser Shag]

I am absolutely not trying to deny that this is a serious problem, but... How would the game distinguish between a legitimate crash, and a forced quit? Say I am attacking and I realize 10 seconds from the time limit I'm not going to get the last defensive building in time. What's to stop me from closing the game and claiming it crashed? A solution could be for a local log to be updated every second, even if the server connection has been lost, and then it could be analyzed (by an algorithm) to determine whether the attack would have been successful.

I would do the following :

Just make a simple analysis on many battles to look at how many troops/hp are still alive after a victorious battle, do this on at least 1000 attacks (Nexon should have the stats). Make an average.
If an attack was interrupted when the total troops/hp was above the average+5% then is was very probably a crash and the player should get compensation.
If an attack was interrupted when the total troops/hp was below the average-5% then is was very probably a ragequit and the player shouldn't get compensation.

The 5% in the calculation is just to take into account an arbitrary error as a simple average isn't precise enough.

 

[melheor]

I am absolutely not trying to deny that this is a serious problem, but... How would the game distinguish between a legitimate crash, and a forced quit? Say I am attacking and I realize 10 seconds from the time limit I'm not going to get the last defensive building in time. What's to stop me from closing the game and claiming it crashed? A solution could be for a local log to be updated every second, even if the server connection has been lost, and then it could be analyzed (by an algorithm) to determine whether the attack would have been successful.

If the option is to continue from where you left off, this is a non-issue. Even if the game has to rollback the attack 5-10 seconds to a latest snapshot it's a non-issue. It's not that expensive to track 160 troop spaces and how many of them are still alive. Heck, you can even do this tracking on the client side and only use the server to verify the validity of client calculation to prevent cheating from modified clients. For example:

- have client track all troops that are alive and all buildings that are alive in enemy base (technically the client already does it, just that this info gets wiped after a restart/crash)
- have client generate a hashkey corresponding to this data, and submit it to server every few seconds
- have server track this hashkey from last attack for each player (no more expensive than having server track your username, which it already does, it's just a string)
- upon reconnect, have client send its surviving troop data and surviving building data in enemy base to the server
- have server hash this information and validate if it matches the last transmitted hash key prior to disconnect
- if it matches, continue the attack; if it doesn't, force a loss