Home/ Questions/Q 7986511
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-04T11:52:31+00:00

I’m writing a game server in Python and a game client in Game Maker

  • 0

I’m writing a game server in Python and a game client in Game Maker with the Faucet Networking plugin (though that shouldn’t matter). The client sends an UPDATEXY message to the server each time the player moves, and there is a message chatting thing in the client. With 2 clients connected to the server, it seems that the client gets overloaded with messages (further into the run time, chat messages appear slower and the player lags behind where the actual other player is). I believe this is because the client cannot process the messages at the rate they are flowing in, so I implemented a feature in the client where it would just dump all messages in the receive buffer, and ignore them. This seemed to work, but the player would jerk around violently. Is there any sort of ‘clean fix’ to this problem, or is it a fundamental thing that I have done wrong since the start?

By the way, the protocol I am using is TCP. Is this a problem with TCP itself or am I just using it wrong? Would switching to UDP help?

Thanks.

EDIT: Code was requested so here you go for the server:

def sendmsg(msgtype, msg, conn, args=None):
    if msgtype == MSG_PLAYER_ASSIGN_ID:
        dataload = struct.pack('!hhh', MSG_STARTBYTE, msgtype, msg)
        conn.send(dataload)

    elif msgtype == MSG_PLAYER_UPDATEXY: #This will only ever be broadcasted
        #print("Sending xy from " + str(args['pid']))
        dataload = struct.pack('!hhhhh', MSG_STARTBYTE, msgtype, args['pid'], msg[0], msg[1])
        conn.send(dataload)

    elif msgtype == MSG_ASKFORLIST:
        players = msg
        for player in players:
            if args['pid'] != player.pid and player.dead == False:
                dataload = struct.pack('!hhhh' + str(len(str(player.name))) + "s", MSG_STARTBYTE, MSG_PLAYERENTRY, player.pid, len(str(player.name)), player.name.encode())
                conn.send(dataload)
                loginfo("Sent a player")

^That’s just a few packets, there are more, but they are all pretty much like those

Here you go for the client:

if msgtype == MSG_PLAYER_UPDATEXY
{
if tcp_receive(serversocket, 6){
pidtoupdate = read_short(serversocket)
//show_message(string(pidtoupdate))
if objNewNetProcessor.pid != pidtoupdate
{
xtoupdate = read_short(serversocket)
ytoupdate = read_short(serversocket)
playertoupdate = ds_map_find_value(global.players, string(pidtoupdate))
if playertoupdate != objChar
{
playertoupdate.y = ytoupdate
playertoupdate.x = xtoupdate}
}}}

if msgtype == MSG_CHAT
{
if tcp_receive(serversocket, 4){
fromperson = read_short(objNewNetProcessor.serversocket)
strlen = read_short(objNewNetProcessor.serversocket)
tcp_receive(objNewNetProcessor.serversocket, strlen)
chatmsg = read_string(objNewNetProcessor.serversocket, strlen)
display_chat(fromperson, chatmsg)
}}

^Sorry that’s a total messtastic, it’s just temporary code for now. It too is just a few packets, it handles more below that code, though they all look similar to those.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Generally this should work fine, and I doubt this is a problem with high CPU load – 60 updates per second is quite a lot, but with only two clients connected there should not be that much traffic to process. For comparison, Gang Garrison 2 uses only 30 updates per second, but with a decent PC it can handle 20 players on a server just fine. Check the client and server CPU load in task manager to be on the safe side, but I don’t expect that to be the problem.

    If clearing the “backlog” on the clients makes them catch up, this is probably not a problem with the network speed or the server either, but it might still be valuable to log the traffic on a client with Wireshark to see if everything looks as expected (e.g. packets are sent and received at the expected rates and are evenly timed).

    Since there seems to be a backlog building up on the clients: Do the clients try to consume as many messages as possible each step, or only the messages for one server step? If you only process one server step per client step, any connection hiccups that inevitably happen will cause you to permanently lag behind, which seems to be consistent with what you describe.

    Russell Borogove gave you a good pointer as well, definitely make sure that Nagle’s algorithm is disabled (=tcp_nodelay is enabled) on each game-related socket on the server. Faucet does this by default.

    • 0