@Fox said in Survival dungeons and game crashes/disconnects:
Is there any other game mode you would feel that could replace survival dungeons in events like Mishka or Stormbeared?
Something that is readily available, tested and working? That kinda narrows it down to a normal dungeon, maze, island or mini-72h challenge. But mazes and islands only grindy and not really challenging.
I kinda like the idea of survival dungeons, but bad luck shouldn't kick out your best monsters. We could use war mechanics in a dungeon: Instead of being permanently gone, a monster is lost for a number of hours after a defeat. If the runes/levels of monsters scale with the runes/levels of the available monsters, that could be quite challenging but still managable. But that's something that would have to be coded, even though this might be an easy addition.
Let me sleep on this. Maybe I'll come up with something better 
I cannot tell you if the reconnect is a valid option as I am not a tech person, though I will definitely ask, but if its possible it would be a more long-term solution.
I'm a tech person, sorta. And I'm sorry that the following is rather technical.
My crystal ball says that ML works as follows: The game has some internal values stored (gold, food, monster stats, basically everything you can see). Whenever something needs to be changed (the player does an action, like collecting gold), the game checks if the client-side values are still consistent with the server-side values. (It's more complicated than that, but that's the general idea.)
Whenever the client-side values do not match the server-side values the game gives the dreaded "something went wrong" message and has to reload, as it does not know why there is a discrepancy, and if in question the client side values are discarded (to prevent manipulation). It can be a bug, it can be a lost connection, it can be that the player logged in from another device, it all works in the same way. Bug seems to happen fairly often. (And it's ridiculous that a simple reconnect will lead to data invalidation.)
And again my crystal ball says that often inconsistencies are not related to the operation at hand. Say if we fight a battle, the game might barf because there is an inconsistency somewhere that can't be caused by that battle (like gold values), but by a bug somewhere else.
So, in a few cases a simple "don't barf in case of a disconnect, simply reconnect" could suffice to fix the issue. But a healthy portion of the issues, major programming changes would be necessary. (Assuming that my assumptions are correct, I'd say very sloppy programming brought is here, but now it's probably very hard to change that.)
For example, say a player wants to move a step in a maze with a fight. Right now, if he presses "move" the coins are deducted (player loses the coins on the SP server), but then if a bug/disconnect occurs during the fight, the reward (progress and roulette draw) are never credited, resulting in lost coins. In wars, once the player presses "fight", the monsters are marked as used, an attack is deducted (both server side, again), but if the game crashes then there is no reward in war coins and the resources are spent.
Roughly, this is as it should be. Once a player enters a "critical" section of the game (where resources are spent, including the resource "monster" in team wars etc.), the game must "lock down" the current state and create a software transaction, that is, all changes related to this action (from spending the resources to rewarding the player for a successful outcome) are either stored as once ("commit"), or not stored at all ("rollback").
So, the correct way to do this is as follows:
-
Start a (software) transaction that marks what the player wants to do (spend maze coins, start war battle, start dungeon battle).
-
If there is a result from the client, complete the transaction (obviously). To validate the state, only the affected monsters/valus are compared. For example, if a player fights a team war battle, the result should be saved even if there is a discrepancy in gold/food and similar states that have no relevance for the battle. If such a discrepancy exists, complete transaction and reload the game afterwards.
-
If there is no result at all (disconnect/flight mode/crash), roll back the transaction. Return the currency (maze coins/attack/used monsters).
-
To prevent players from using flight mode, use a karma value for war/survival dungeons where each player loses karma for a "connection lost" transaction. If the karma becomes too negative, penalize accordingly. But this should never apply for maze coins, for example.
And the key difference should be: If there is a data discrepancy ("Something went wrong"), this should never lead to negative karma/penalties. Only disconnects can change karma.
But as the game shows no signs of using transactions at all, this might be a major programming task, since no database transactions can be used for such long-running actions. But then, it's work, but not technically difficult. Database programmers have used transactions for over half a century, in conditions much more difficult (different processes competing for the same resources). One that should have been done a long, long time ago, and (sorry if this sounds arrogant, but this is what my software developer heart says) the devs should suck it up and do it if they want to maintain the game for a few more years. Instead of developing more features.
