Feature request: Update the battle data handling and endpoints. #759
Description
What do you want to see in the API?
Endpoints and the background validation should be overhauled to make sure that the battle data is properly handled by the server.
Firstly: There should be an endpoint where the client can inform the server that a battle is starting and to register it with the server.
POST: /gamedata/battle/start (Can also use the preexisting "/gamedata/battle/" endpoint you would rather use the "type" field to split the register and result)
This should take the following information.
Gametype: Enum_string (matchmaking, casual, custom)
Team1: [player_id, player_id] (one id is needed the other can be empty.)
Team2: [player_id, player_id] (one id is needed the other can be empty.)
MatchID: string_id (optional if not given then server generates one.)
Return value should include the MatchID, should the registering be successful.
Secondly: When the match finishes each player sends the result to the server.
POST: /gamedata/battle/result (Can also use the preexisting "/gamedata/battle/" endpoint you would rather use the "type" field to split the register and result)
This should take the following information.
MatchID: string_id (should match the registered id)
Duration: string or float in seconds.
Result: int (1 if team 1 won, 2 if team 2 won)
Senders ID can be determined by the AccessToken sent with the message.
Return value should include the token for raid.
How do you think this should work?
By registering the data at battle start it is easier to validate that a battle actually happened, of what type it is and who should be sending the result for that battle in a minute or two.
Then when the players send the results to server these can be checked to see if they match and if someone doesn't send one we can assume that something went wrong somewhere but we can still use the data from the other players to distribute the potential rewards and log the battle results.
And if the results don't match we can potentially check which result is the odd man out and disregard it.
If match is registered but no results are received (30 mins timeout) then the match is closed and discarded.
When all player have sent their results the match the match is closed and the results are handled.
If at least two players send their results a 2 min timeout is started after which the match is closed and the results are handled.
If the results are vastly different (all player send different information) we can assume that something went wrong and we can discard the results.
If the player is being registered for another match while they haven't sent the results for the previous one we can assume that they aren't sending any for the previous one.
Any additional info?
The timeouts and validation don't need to fully be there for the first iteration as the data sent would be from internal testing anyway and thus not 100% mission critical yet.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status