You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A game server calls POST /v1/match/create without any additional info. This creates a Match row in the database with a globally unique id and an autofilled property started. The game server receives, in response: {'id': <some_int>, 'token': <some_secret_token>}.
Whenever it wants, the game server calls POST /v1/match/update with the id, secret token and the info about the match we want to track (TBD). These updates will be stored in a separate table MatchUpdate, which Match has a one-to-many relationship with. The final call to /v1/match/update will include something like {'ended': True}.
The ended event allows the Metaserver to process awards, and closes the Match to further MatchUpdates. There will be a cronjob that periodically cleans up old matches that were never marked as closed.
The separation between a Match and a MatchUpdate allows a reconstruction of each match. The granularity of the reconstruction depends on the frequency of updates.
Updates that are submitted to this route should contain the complete numbers up to that point in the match, not the difference since the last update. E.g. a field 'team_1_resources_mined' should be monotonically increasing with each next update -- the game server doesn't report how many resources were mined since the last update, but since the beginning of the match.
A route GET /v1/match/by-id returns the Match object and all of its MatchUpdates (in chronological order).
A route GET /v1/match/by-server-id returns all Match objects with their MatchUpdates in pages of 50 matches or so.
The text was updated successfully, but these errors were encountered:
I'm thinking the following:
POST /v1/match/create
without any additional info. This creates aMatch
row in the database with a globally uniqueid
and an autofilled propertystarted
. The game server receives, in response:{'id': <some_int>, 'token': <some_secret_token>}
.POST /v1/match/update
with the id, secret token and the info about the match we want to track (TBD). These updates will be stored in a separate tableMatchUpdate
, whichMatch
has a one-to-many relationship with. The final call to/v1/match/update
will include something like{'ended': True}
.ended
event allows the Metaserver to process awards, and closes theMatch
to furtherMatchUpdate
s. There will be a cronjob that periodically cleans up old matches that were never marked as closed.Match
and aMatchUpdate
allows a reconstruction of each match. The granularity of the reconstruction depends on the frequency of updates.GET /v1/match/by-id
returns theMatch
object and all of itsMatchUpdate
s (in chronological order).GET /v1/match/by-server-id
returns allMatch
objects with theirMatchUpdate
s in pages of 50 matches or so.The text was updated successfully, but these errors were encountered: