Network issues: (how the game should) deal with it
We've all experienced it before, the network goes bad and glitches start to appear. As a Software Developer in the area of Quality Assurance I'd like to introduce some strategies and mindsets that I've seen developers use when dealing with it (and the cases in which that may or may not apply to HPWU):
Strategy 1: Hoping for the connection to recover.
- The network connection isn't going to stay bad
- The number of things the user can do (and exploit) is limited
Once the connection is lost:
- "log" that the connection to the server was interrupted. This merely means that the client (the app) is aware that it can't or won't get updates from the server - and while it will try to, it won't let "timeouts" interrupt the flow of the user.
- Cache (aka "store") all actions the user does within the app. This is done so when the connection to the server is re-established, it can upload them.
- The client will also disable all actions that would require a client-server-handshake - things like the store or entering POI.
After the connection is re-established:
- The cached actions are sent to the server
- the server will validate whether what the app cached is actually "plausible". If it is valid, it will change it's own records. If it is not, it will
- EITHER overwrite the state of the client with the last plausible state. In case of a fortress battle, this would mean that your Energy, Runestone, Potions, Quests and Achievements are reset back to before you entered the battle.
- OR predict what the user could've done and overwrite the state of the client with that prediction. In case of a fortress battle, it would simulate your fight and then set your energy-level, fortress-gifts, Achievements, Quests, Registry to the outcome of that prediction.
This will only work for those cases where the app already all necessary info:
- Solo Fortress battles where all Enemies have already spawned.
- Inn's where the Meal-Selection and cooldown-information has already been transmitted.
Where this won't work:
- Fortress battles where not all enemies have spawned
Where this MAY work (but it's very complicated to get it to work):
- Group-Fortress Battles where all Enemies have already spawned
This strategy is VERY comfortable for the user. But it requires a lot of complexity to be put both in the client and the "validation" section of the server to prevent exploiting. And given that complexity is directly proportional to being prone to errors, I'd not recommend committing to this strategy UNLESS both the server and client have an ABSOLUTELY FLAWLESS testing coverage (which hardly any company has).
Strategy 2: No Unnecessary Risks
- It is unknown whether and when the user will recover it's connection
- The user may try to exploit the quality of his connection to forge a "perfect" playstyle
What the server does:
- The server will "store" the quality of connection to the user. Once "Package loss" happens or the client isn't responding when it should, it will revert the account back to a state when the connection was perfect. In case of a fortress battle, it will revert Runes, Energy, Potions, Quests, Achievements back to before the battle started.
What the client does:
- The client will abort all actions that require a client-server-connection and disable them until a flawless connection has been re-established. Once the connection has been re-established, it will overwrite its own state with what the server transmitts.
This will work perfectly for pretty much all of HPWU.
This strategy can be VERY frustrating for the user in areas of bad or flaky network coverage areas - especially when pretty much all app-actions require server-approval. BUT at the same time it is a low-complexity strategy that allows for clear attribution of "what went wrong".
Neither strategy is perfect. The best way is probably to find a balance between the two - and clearly communicating to the client (and user) which of the cases currently applies.
Telling the user that the connection between server and client has been lost AND how the application is trying to handle it (roughly) is key here.