Versus retaliation notifications

Options
Calnexin
Calnexin Posts: 1,078 Chairperson of the Boards
I don't know whether this is a bug or a feature, but often in PvP I will come out of a match to see that my score has decreased.  I know that I have been hit by another player, but I don't get the notification until later, usually after completing the next match.

To me, the logical order of operations would be to display the attacker, then deduct points.  Done the other way around it looks like the game is arbitrarily decreasing your score.  More than that, losing points with no retaliation node makes it impossible to strategize in the moment.  Whether I shield right then or keep playing has everything to do with the power of the team and/or the expanded roster of the player that beat me.  I know that if I've been hit by a double-champed 5* team, there are 2-3 more hits coming within the span of my next match, so I should shield immediately.  In comparison, a team that is equal to or weaker than my own might not be able to finish the next match before I do, may not be specifically targeting me, or may deduct fewer points than I can gain during my next match with the single hit they are likely to complete.

I realize this gets into the code and is likely difficult to change, but it's a significant (though not critical) issue in PvP.  It matters most when at or near 900 when MMR opens you up to everyone, which is also the most critical time in terms of earning rewards.

If the win-based progression rewards are implemented it becomes much less of an issue, but still important for anyone chasing placement.

Comments

  • abmoraz
    abmoraz Posts: 712 Critical Contributor
    Options
    I don't work on this game, but I do code for a living.  I can tell you just from observation that the reason for this is that different calls are being made from your device (the "client" or "front-end") to the MPQ servers ("back-end").

    When you exit a match, the screen you dump out to has to make a couple of calls:
       - The "results" screen that shows how your score(s) change + any reward progression
       - The base screen.  The background image, the node placement, etc...
       - The contents of the nodes are then added.  Who the opponent is, what are their values
       - A call to populate the top status bar (your score, rank, time left)
       - The bottom bar is populated with another call (recruit heroes, number of tokens, number of roster, alliance messages, etc...)

    The notifications are handled differently.  Notifications are Pull (the client has to request them) rather than Push (the server forces them to the client).  This prevents things like "Notifications popping up mid-battle".  When you have notifications (retaliation, facebook gifts, compensation, rewards, etc...), they get put into a "messaging queue".  The game (on your client) makes calls every so often to the server to see if there are any new messages.  If there are, it gets them all and proceeds to display them (starting with claimable rewards, first, then broadcast messages (such as new events or emergency notes), and finally "info messages" (such as retaliation notices from this event or others or alliance notices).

    When you are hit in PVP, the server has already resolved the results of the match, updated your score, and added the retaliation message to your messaging queue, however, since you are still in a game, your client hasn't reached out to the server to get any of this info yet.  When your match ends, your client uploads the results to the server (updating your score again) and gets the display (including the updated score) to show you in the "rewards" screens.  After that, it dumps you back out to the PvP event and gets the page info I described above.  Only once all that is loaded, does it check for messages. 

    Since the other pages are called before the messaging, you see the updated scores, first, then the notifications.

    Hope this helps explain why you are seeing what you are seeing.  Your assertion that "this gets into the code and is likely difficult to change" is more correct than you probably imagined, because to change it would require changing core functionality of how the client and server interact.