As title says, my game logic in server only take actions when receive message from client, so looping is just wasting resource.
And when trying to send different message to clients in custom multiplayer, do i need to create one stream for each client?
Media:
Hi @slind,
Yes, authoritative matches imply a match loop, if you want to spare resources, you can simply lower the tick rate. If your match loop doesn’t do much or any work between ticks, it will barely consume any resources, unless you have many many matches (many thousands) ongoing on very skinny hardware. The other issue is that if messages are sent frequently by the clients, instead of coalescing messages to compute state at every tick, you’d recompute state at every message, which will actually be worse for performance instead of better.
In my opinion, it’ll probably make things more complex and more difficult to reason about, and may require you to maintain some shared Storage object in the database to persist the computed state, instead of doing it in memory, which will put strain on the DB instead.
My advice would be to stick to the authoritative match loop model, unless your game is client authoritative, in which case you can just use the relayed model.
Can you give an overview of what type of game you’re trying to build?
Best
Thank you for your reply. @sesposito
It is a card game. And most game logic happens in client, server just doing some relay job but should handle some minimal sensitive data and some authorization to prevent cheating.
There won’t be synchronized message sending to server, every client will wait message handling to progress the game. But latency should be taken to consideration, and low tick rate seems will significantly make latency higher.
So i am trying to find another way rather than authoritative multiplayer amd relayed one.
And i want to deploy servers in different area to lower the latency but share one datebase to make users can move across areas. I wonder this setting will cause any problem within nakama itself? And any method to use awaitable programming in typescript runtime to handle the high latency to write or query database?
My advice would be to just have a very simple match loop with an acceptable tick rate that mostly relays messages and does authoritative checks wherever needed. As I said before, this scales well and you won’t have issues unless your match logic is very computationally intensive (it shouldn’t be, given your description) and you’re running an extremely skinny instance with many thousands of matches happening concurrently.
The match loop should avoid DB operations altogether unless at the beginning/end or if the match needs to be suspended and later resumed due to server shutdown/restart.
The Nakama JS runtime is ES5 compliant so it does not yet support async/await, If performance is so critical to you, you should be using the Go runtime instead (and there you can actually do asynchronous operations if you must) as there’s some overhead to JS - but Nakama does everything possible to amortize this overhead where possible. I believe the JS runtime should suit you just fine for what you’re looking for.
Multi-region deployment to be close to the edge for a card-game is, in my honest opinion, absolute overkill, it adds operational complexities, and implies there’s cluster awareness between the server nodes to propagate in-memory state (exclusive to Nakama Enterprise), unless you only want to shard players between regions. Database writes will be a fraction of the time of network latency regardless of how close to the edge you are (unless you’re doing something very wrong at the db level).