Intercept and modify messages in Authoritative Multiplayer modules without using the match_loop

Local Setup
1

Hi!
We are doing some tests with authoritative multiplayer modules.
We have seen in the docs that you have methods like:
match_join_attempt
match_join
match_leave
match_loop
match_terminate

But we miss a method like match_message_received where we can read the op code, read content, do modifications and sent it again to clients. In others words, we would like to have like a send instant message method without having to wait to the tickrate to be processed and broadcasted.

The purpose of this feature is to send instant messages without the need to add an extra delay due to the tickrate.

Thanks you!

2

Hi @adrianmesa,

An earlier version of Nakama had this functionality - however we had to drop processing messages as soon as they arrived (and thus individually) because it affected performance negatively. Here is what I suggest:

  • Use broadcast_message to ensure immediate message delivery to clients as soon as the function is invoked.
  • If you must, set the tick_rate to 30 to ensure that the server processes messages quicker.

What kind of game are you developing?

3

Thanks you for your response.
We are doing a third person action game with a top-down camera, with melee and shooting systems. At first we will start with two players and coop gameplay.

4

I’m not certain that in practice you need a way to send direct to clients that bypasses the server side tick loop. When you’re in the middle of a tick your calls to broadcast_message (and BroadcastMessage in Go) will always be immediate. The time spent between the message(s) received into the server and relayed onwards will be tiny compared with the wiretime to reach game clients on round trips. This is just the nature of multiplayer networking over the internet.

What are you trying to optimize for with the relayed messages that are part of your multiplayer game protocol?

5

Honestly y did de question because we were working in Gamesparks and they had messages implemented in that way.
I was thinking to use direct messages skipping the tick rate for special messages as “player killed” and other important things like that.

6

I see ok. So it doesn’t sound like there’s a gameplay specific reason to require messages to be sent in between ticks.

I was thinking to use direct messages skipping the tick rate for special messages as “player killed” and other important things like that.

Messages won’t be lost in between ticks so it’s not as though important information cannot be delivered to game clients. I recommend you just set the tick rate to 30 Hz and handle these messages first in your match loop ticks. Just use a set of opcodes that you want to look for in your code and process first.