We’re currently investigating issues with the SOS Report appearing blank, Adventure Sync not working (Android), and in-app purchasing (iOS.) We will provide updates when we have further details.
Network issues: (how the game should) deal with it — Harry Potter: Wizards Unite Community Forum

Network issues: (how the game should) deal with it

LucoireLucoire Posts: 1,244 ✭✭✭✭✭
edited January 2020 in Feature Requests #1 latest comment 09 January, 2020, 03:12 am.

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 assumption:

  • The network connection isn't going to stay bad
  • The number of things the user can do (and exploit) is limited

The strategy:

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.

The usecase:

This will only work for those cases where the app already all necessary info:

  • Traces
  • Solo Fortress battles where all Enemies have already spawned.
  • Inn's where the Meal-Selection and cooldown-information has already been transmitted.
  • ingredient-spawns

Where this won't work:

  • Greenhouses
  • 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

My opinion:

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

The assumption:

  • 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

The Strategy:

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.

The usecase:

This will work perfectly for pretty much all of HPWU.

My Opinion:

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.



  • LucoireLucoire Posts: 1,244 ✭✭✭✭✭
    #204 January, 2020, 03:14 pm.

    "Network Issues" doesn't just apply to:

    • No Internet

    It may also apply to:

    • Low Signal Strength
    • Switching between LTE/4G/3G/2G/E/H+
    • Switching between mobile Internet and WiFi
    • Handover between different Base-Stations
    • Switching between different ISP
    • Signal Jamming
    • Faulty software on WiFi-Router/Base-Station/Smartphone
  • NursePoppyNursePoppy Posts: 80 ✭✭✭
    #304 January, 2020, 06:38 pm.

    Very educational and helps me understand a bit what's happening during a glitch.

    Thanks @Lucoire !

  • MtPolluxMtPollux Posts: 744 ✭✭✭✭✭
    #404 January, 2020, 08:04 pm.

    Thanks for this, it provides some insight into the complexity of the situation for those of us who aren't in software development.

    Having said that, it does seem odd that WU is so easily disrupted by connection issues. I've played WU in the same area where I have used PoGo, Ingress, and other location based apps for years. I can't recall any other of those apps being as susceptible to erratic behavior due to a common issue like my phone switching towers.

  • LucoireLucoire Posts: 1,244 ✭✭✭✭✭
    #505 January, 2020, 09:24 am.

    @MtPollux I think it is safe to assume that different people work on different projects, causing different decisions to be made and different code (and bugs) being written in the Apps.

    Admitedly I can only speculate but consider this: these projects need to be profitable - and profit is computed by "income" (sales) minus cost (developer wage, server cost, license fees). If we were to assume that a big pool of developers were to work on all 3 projects, that would a) require a meticulous metric of how much work (and therefore cost) was put into which project and b) require a regular update of a large group of people on the features. And given that complexity is the enemy of progress, it is relatively safe to assume that there is hardly any overlap between the projects "Ingress", "Pokemon GO" and "Harry Potter: Wizards Unite" - in code, knowledge and personel - to avoid said complexity.

  • OriginalCarusoOriginalCaruso Posts: 502 ✭✭✭✭✭
    #605 January, 2020, 10:20 am.

    @Lucoire - I suspect the code was forked from PokemonGo as there are common features and a lot of reusable code, I have no proof, but it is what I would do to get WU up and running quickly

    Highly probable WU is programmed in Lua or similar high level language compiled for iOS and Android targets - one code base for two (or more) different platforms for the non- techies. If my assumption is correct, this is another level of abstraction to deal with when bug fixing

  • MtPolluxMtPollux Posts: 744 ✭✭✭✭✭
    #705 January, 2020, 01:06 pm.

    @Lucoire that all makes sense.

    My point was more that the usual first response to the various error reports has been "probable connection issues". I've only experienced a few issues with WU, but every time it has been in areas that I regularly frequent, and where other GPS based mobile apps function without error. I was musing about WU's seeming inability to handle a change in cell tower rather than drawing a direct comparison to Niantic's other games.

  • Osprey1Osprey1 Posts: 612 ✭✭✭✭✭
    #807 January, 2020, 04:11 pm.

    Caveat: I haven't read this whole thread. I'll make an attempt to go back through later, but this has been bugging me.

    When you discover that a game needs to educate the user about what a network error is then you have a problem. In my opinion the idea that HPWU is telling users there is a network issue is a horrible design decision. It violates the basic tenets of having an immersive AR environment.

    Of course users will experience network issues with a mobile game and the game should handle those without error messages. The only time an error message should be thrown is if the user can actually do something to resolve the issue. The frequency of error messages in HPWU reported as network problems (and note some of these problems are actually server problems being reported as network problems) is way too high and multiple orders of magnitude higher than I've seen with Jurassic Park, Ingress or Pokemon GO.

    So what should we see instead? If there are areas where frequent network errors actually occur then warn users by blaming the calamity, "the calamity is unstable in this area proceed with caution." If a network error occurs, "the calamity has thwarted your wizarding challenge, runestone returned."

  • AcumenAcumen Posts: 1,102 ✭✭✭✭✭
    #907 January, 2020, 05:23 pm.

    The term "network error" makes my eye twitch. While that can truly be the source of a problem, particularly with apps installed on mobile devices, I just hear it way too much in my line of work from third party software vendors who are attempting to deny responsibility when we report problems with their applications. With a few of the vendors I work with, I'll go ahead and gather mountains of trace data before I even open a trouble ticket because I know their default response will be "it's an problem with your network" and they'll immediately shift the burden of proof back to me, despite the fact that we're paying them tens of thousands USD per year for support. And even in instances where the trace data does reveal some packet loss or routing issues when problems occur, I still won't let a vendor off the hook for it. If an application bombs out over some packet loss and won't recover without manually restarting services, that's just poor error handling.

  • kiheikidkiheikid Posts: 2,168 ✭✭✭✭✭
    #1008 January, 2020, 01:41 am.

    if the lost runestone were returned after a network error affecting a fortress challenge, that might not be so hard to stomach. but because, more often than not, the runestone is lost/taken/stolen with no forward progress in the game to show for it, that really feels like THEFT ... especially the runestones of higher levels or exploration families that we already are short on. making the report-a-bug bot experience so user-unfriendly does not help things.

Sign In or Register to comment.