Is there a better way to get data (set during match configuration) to the RT cloud code than to use LogEvent?
Also, can I take it for granted that RTSession.getSessionId() is the same as MatchFoundMessage.matchId?
Best Answer
C
Customer Support
said
about 4 years ago
Hey Christian,
Unfortunately there isnt a better way to store this data other than making using RTSession.newRequest() to send a request to the core GameSparks DB. You could store it in the match-data for each match, but you'd still need to send a request to get the information.
Is it possible to declare the data in the RT-script so it caches when the script initializes?
Im not sure what you mean in your first question though. Are you trying to get the match-config from the RT script?
Sean
C
Cristian Bontas
said
about 4 years ago
Hello
I'm running an authoritative server, in the RT code.
During match setup (which happens in Spark), certain decisions are made, e.g. on what level the game will be played, each player's units, etc. When the RT session starts, it needs to obtain this information too, from its RT code.
Is there any other way (better) way to do this than to store it in a MongoDB collection, identifying the record by the match ID, and then from RT send a log event to retrieve the information, using the RTSession.getSessionId() key (which is why I asked if they are guaranteed to be the same, as otherwise I would have no way to know from which match the session was created).
Customer Support
said
about 4 years ago
Answer
Hey Christian,
Unfortunately there isnt a better way to store this data other than making using RTSession.newRequest() to send a request to the core GameSparks DB. You could store it in the match-data for each match, but you'd still need to send a request to get the information.
Is it possible to declare the data in the RT-script so it caches when the script initializes?
Sean
C
Cristian Bontas
said
about 4 years ago
That's alright, I was just making sure I didn't miss something.
The data will be cached in the RT script, of course, it will not be requested from Spark every time a player makes an action.
The request will only be made once, on RT initialization.
Customer Support
said
about 4 years ago
Thats fine.
Just a note on your network design btw; the callbacks that intercept packets are something of a bottleneck. Since JS is single threaded, if you are intercepting all packets constantly, it will slow down the network overall. So that this into account. The system runs much-much faster if you are sending packets from one player to another.
We are currently working on some guides on this. The idea would be to let the server tell each player (if possible) who they should send packets to, and then send them from player-to-player so the server can do its thing.
At the same time, see if you can get the game working yourself, and then keep this in mind when you start optimizing the network.
Sean
C
Cristian Bontas
said
about 4 years ago
My game is only 1 vs 1, and each player acts on average every few seconds, with bursts of up to maybe 4 actions in a second every now and then, so I hope that the system can handle it.
Also, since the server must be authoritative and also record games, I think I need the interception anyway.
Cristian Bontas
Hello
Is there a better way to get data (set during match configuration) to the RT cloud code than to use LogEvent?
Also, can I take it for granted that RTSession.getSessionId() is the same as MatchFoundMessage.matchId?
Hey Christian,
Unfortunately there isnt a better way to store this data other than making using RTSession.newRequest() to send a request to the core GameSparks DB.
You could store it in the match-data for each match, but you'd still need to send a request to get the information.
Is it possible to declare the data in the RT-script so it caches when the script initializes?
Sean
- Oldest First
- Popular
- Newest First
Sorted by Oldest FirstCustomer Support
Hey Christian,
Yes, getSessionId() is the same as the matchId.
Im not sure what you mean in your first question though. Are you trying to get the match-config from the RT script?
Sean
Cristian Bontas
Hello
I'm running an authoritative server, in the RT code.
During match setup (which happens in Spark), certain decisions are made, e.g. on what level the game will be played, each player's units, etc. When the RT session starts, it needs to obtain this information too, from its RT code.
Is there any other way (better) way to do this than to store it in a MongoDB collection, identifying the record by the match ID, and then from RT send a log event to retrieve the information, using the RTSession.getSessionId() key (which is why I asked if they are guaranteed to be the same, as otherwise I would have no way to know from which match the session was created).
Customer Support
Hey Christian,
Unfortunately there isnt a better way to store this data other than making using RTSession.newRequest() to send a request to the core GameSparks DB.
You could store it in the match-data for each match, but you'd still need to send a request to get the information.
Is it possible to declare the data in the RT-script so it caches when the script initializes?
Sean
Cristian Bontas
That's alright, I was just making sure I didn't miss something.
The data will be cached in the RT script, of course, it will not be requested from Spark every time a player makes an action.
The request will only be made once, on RT initialization.
Customer Support
Just a note on your network design btw; the callbacks that intercept packets are something of a bottleneck. Since JS is single threaded, if you are intercepting all packets constantly, it will slow down the network overall. So that this into account. The system runs much-much faster if you are sending packets from one player to another.
We are currently working on some guides on this. The idea would be to let the server tell each player (if possible) who they should send packets to, and then send them from player-to-player so the server can do its thing.
At the same time, see if you can get the game working yourself, and then keep this in mind when you start optimizing the network.
Sean
Cristian Bontas
My game is only 1 vs 1, and each player acts on average every few seconds, with bursts of up to maybe 4 actions in a second every now and then, so I hope that the system can handle it.
Also, since the server must be authoritative and also record games, I think I need the interception anyway.
Customer Support
For a 1v1 game, this shouldnt be a problem.
Sean
Cristian Bontas
Great to hear that, thanks.
-
Documentation Notes
-
Design issues with user events
-
Using NoSQL
-
Runtime Collections vs Metadata Collections
-
Anonymous authentication from browser app
-
Modules
-
Movement With Unity
-
Problem with url parameters for downloadables
-
Querying NoSql GameSparks database
-
Challenge accesType
See all 2486 topics