Legacy GM Networking - UDP and TCP Server(s)?



GM:S Only allows creating a server that's either communicates using TCP or UDP and I was curious if it's possible to do both? And if not, would it be practical to create two network servers for a server program that handles both?

(I'm basing the above off of this method https://docs.yoyogames.com/source/dadiospice/002_reference/networking/network_create_server.html)

To be specific, In my game I'd like the server and client to exchanged two types of information:
One that's crucial that it's being received intact and isn't super time-dependent (Where TCP would be the ideal protocol of choice) and the other would be variables that will be overwritten 60 times a second and ideally would be used the moment that they arrive to the client (Where UDP would be the ideal protocol of choice)

I've seen that in Mark Alexander's tutorial (https://help.yoyogames.com/hc/en-us/articles/216754698-Networking-Overview) he creates two servers in his example program -- One TCP for player movements and ememy locations that's being sent back and forth 30 times a second and the other for broadcasting the server's existence to the LAN if any other player on the local network would want to join that's being used only once per second.

Is it conventional to create two server networks of either type and have those two exchange the appropriate type of information or would it be too heavy on the program/network? In addition, I know that most online actions games have each client send packets to the server at a rate of 60 packets per second but the server would only send back packets at a rate of 20 packets per second. Is there a reason for this?


I think in general, its a bad idea to use both TCP and UDP.

Quote from here: https://gafferongames.com/post/udp_vs_tcp/
The temptation then is to use UDP for player input and state, and TCP for the reliable ordered data. If you’re sharp you’ve probably even worked out that you may have multiple “streams” of reliable ordered commands, maybe one about level loading, and another about AI. Perhaps you think to yourself, “Well, I’d really not want AI commands to stall out if a packet is lost containing a level loading command - they are completely unrelated!”. You are right, so you may be tempted to create one TCP socket for each stream of commands.

On the surface, this seems like a great idea. The problem is that since TCP and UDP are both built on top of IP, the underlying packets sent by each protocol will affect each other. Exactly how they affect each other is quite complicated and relates to how TCP performs reliability and flow control, but fundamentally you should remember that TCP tends to induce packet loss in UDP packets. For more information, read this paper on the subject.


Going to quote myself from another similar topic:
Hate to cut in part way, but there isn't a good reason you can't use TCP and UDP at the same time. I use both for the exact reason you say, you want most things to be udp but some things need guaranteed transmission. Freddy Jones's post is mostly incorrect when you consider routers are configured to drop Udp packets first rather than TCP packets because of the overhead TCP has. Even still, this is only in extreme cases. If you don't want your Udp dropped, don't use Udp for that information. You won't have bigger problems if you mix them. Professional games do it successfully all the time. You just have to use the right protocol for the right information.

Some good discussion if you're interested: http://stackoverflow.com/questions/8157224/tcp-vs-udp-issues-that-arise-from-using-both

Adam Tompkins

FYI, game maker does not support TCP or UDP for IOS games at the moment, as IPv6 is a requirement on the Apple Store and currently Game Maker does not support IPv6 for those functions.


server at a rate of 60 packets per second but the server would only send back packets at a rate of 20 packets per second. Is there a reason for this?
Network have limits. Ex say each client send 60 and the server send 60. So 60 in and 60 out. Now say we have 8 players. Say the server use a relay approach and don't bundle so this means the server get 60*8=480 and send around 60*8*7=3360. I think game maker will crash about now. So that's is one reason the server bundle the state updates and only Sen around 30 in response. You should only send about 30 from each client too.


Would sending 30 or 60 packets a second be even a good choice?
Couldn't you just send packets only when the player changes state? TCP prevents packet loss and ping can be a problem but overall, it probably can be more efficient.

I would like to hear your opinions on this.
Last edited:


Couldn't you just send packets only when the player changes state?
Yes. I just say what the max send can be in a regular game with around 8 players. This would give a fast gameplay. But If you can send less by only sending when the state change you should do that. Note that if players can join anytime and you only send on change you need to add some sort of force send when a new player join. Else the old players state would only come when the player object change state and may become invisible if they just stand still. Or if you make the server save the last full state of each player you could send those to new connected players.

If you aim on 1000 or more players I would make the clients only send 1 message per 1.5 seconds and the server would only send a bundled state (all clients states into one message) once per 3 seconds per client.
This would mean that the server only get around 670 packets/sec and send around 330 packets/sec if 1000 players where playing in the same area. This means a more slow gameplay.
But also in this situation you should only send if you got a change in state.