Packet send on demand?
by Sam Redfern · in Torque Game Engine · 11/26/2005 (3:17 am) · 9 replies
The game I'm working on is essentially a turn based RTS-style (the 1 second turn rolls forward after everyone submits their move or the timer runs out, which is every 30-60 seconds). I have managed to separate the camera from the server (sort of, it's a hack) so that smooth client-side animations can be done without juddering due to arguments with the server.
What I'm considering doing now though is making the packet sends between server and client only happen when needed, rather than multiple times per second. Most updates only happen when the turn is actually running, but also things like chat messages would need sending. Leaving things as they are currently would be massively inefficient for my game, with probably hundreds of times more data being networked than is really needed. Reducing packetratetoserver/client clearly isn't going to fix it properly, and will only introduce its own problems e.g. with mission download times.
Ideally, I'm going to add a flag to the gameconnection objects so that they only go thru their send cycle when required. Obviously some fixing will need to be done regarding lag icons etc.
I'm really just wondering whether this is something other people have attempted, and if so do they have any advice or comments on how they did it?
What I'm considering doing now though is making the packet sends between server and client only happen when needed, rather than multiple times per second. Most updates only happen when the turn is actually running, but also things like chat messages would need sending. Leaving things as they are currently would be massively inefficient for my game, with probably hundreds of times more data being networked than is really needed. Reducing packetratetoserver/client clearly isn't going to fix it properly, and will only introduce its own problems e.g. with mission download times.
Ideally, I'm going to add a flag to the gameconnection objects so that they only go thru their send cycle when required. Obviously some fixing will need to be done regarding lag icons etc.
I'm really just wondering whether this is something other people have attempted, and if so do they have any advice or comments on how they did it?
About the author
#2
BTW I would consider TGE as beng intended for more or less any kind of game, the special starter kits are simply fast-tracking common modifications for specific types of games.
11/26/2005 (3:25 am)
Yeah, I had a suspicion that the RTS kit did some of this stuff already, but I think what I'm suggesting (if it works, haven't looked at it yet) should be simple enough, so why go to the bother and expense of digging into the RTS kit code?BTW I would consider TGE as beng intended for more or less any kind of game, the special starter kits are simply fast-tracking common modifications for specific types of games.
#3
11/26/2005 (3:31 am)
You can put a flag at the top of the wrritepacket for when it needs to send the data. Then if its false its only sending 1 bit of data per object wich is essentially nothing.
#4
11/26/2005 (3:41 am)
Peter: yes, that's a good idea. It still seems somewhat strange sending anything at all, but us indie game devs are a pragmatic lot... ;)
#5
This should help me push the number of concurrent client connections waaay up (hopefully..)
11/27/2005 (12:50 am)
Just to let you know my idea worked well! It took a few changes here and there but it's great to see a zero packet count most of the time and then just a single one as each turn rolls over or whenever something else needs to be notified such as a chat message. The control object (always a camera, of course) needed a bit of convincing that it wasn't a bad thing that the server just didn't care about it any more.This should help me push the number of concurrent client connections waaay up (hopefully..)
#6
Network programming is a complex beast. Trust me when I say that Torque's network model is one of the *best* in the industry and the sooner you understand why that is, the sooner you can learn to take proper advantage of it.
11/27/2005 (1:10 pm)
Torque already uses netflags in packUpdate/unpackUpdate to control how much data gets packed into a packet from any particular object. Properly tuned this is highly efficient and can allow for thousands of simultaneous connections. Currently it is tuned for a 128 player first person shooter with high per-object movement precision but if you understand what you are doing it is easily possible to tuned it into a 1000 player rpg or rts. Having the clients and the server stop talking completely from time to time is actually a bad idea. If you study how the Internet works you will find that much of the underlying hardware will tune itself to help maintain continuous two-way connections between two computers. As soon as that continuous connection is broken, then the hardware will begin to give priority to some other connection and you will lose a bit of fidelity until you re-establish your two way connection and use it for a bit. As odd as it sounds, you will actually get better network performance by "wasting" some packets then by totally optimizing your connection.Network programming is a complex beast. Trust me when I say that Torque's network model is one of the *best* in the industry and the sooner you understand why that is, the sooner you can learn to take proper advantage of it.
#7
"I have managed to separate the camera from the server (sort of, it's a hack) so that smooth client-side animations can be done without juddering due to arguments with the server."
I'm curious about that.. care to explain more what you did?
11/27/2005 (1:26 pm)
@Sam"I have managed to separate the camera from the server (sort of, it's a hack) so that smooth client-side animations can be done without juddering due to arguments with the server."
I'm curious about that.. care to explain more what you did?
#8
Thanks, I hadn't thought of that... and while I have no doubt that the continuous-send model of Torque could be tuned for much more clients than it currently is, by cutting off the transmissions all together I am probably saving 95% of network traffic. The thing is, my game doesn't need network performance in the way that I think you're defining it, and I'm not sure that it would be any problem that "hardware will begin to give priority to some other connection". It's not a real-time rpg or a rts, it's a *turn based* game.
And I'm aware already of how good Torque's network model is, thanks :)
Ramen:
I'm not sure if I can recall everything, but here's a go:
I added a flag "mControlObjectClientSide" to the gameconnection class: this is initially false, and when its false the server is allowed to send updates to the client.
So then in GameConnection::writePacket() we only send control object update info. if this flag is false. And after this send, we set it to true, so the only server-to-client update is the very first one.
It's a hack because the server will continually be unhappy about the checksums.
If scoping was an issue you could still have the client tell the server where to move the camera to, but don't let information returing from the server update the client, since that's what messes up the smooth animation.
I have improved this as part of the packets-on-demand modifications: now, the client doesn't even send control object move messages to the server (some changes were needed to stop the movelist queue from clogging up). Again, I will need to be careful with scoping.
11/28/2005 (8:38 am)
Matt:Thanks, I hadn't thought of that... and while I have no doubt that the continuous-send model of Torque could be tuned for much more clients than it currently is, by cutting off the transmissions all together I am probably saving 95% of network traffic. The thing is, my game doesn't need network performance in the way that I think you're defining it, and I'm not sure that it would be any problem that "hardware will begin to give priority to some other connection". It's not a real-time rpg or a rts, it's a *turn based* game.
And I'm aware already of how good Torque's network model is, thanks :)
Ramen:
I'm not sure if I can recall everything, but here's a go:
I added a flag "mControlObjectClientSide" to the gameconnection class: this is initially false, and when its false the server is allowed to send updates to the client.
So then in GameConnection::writePacket() we only send control object update info. if this flag is false. And after this send, we set it to true, so the only server-to-client update is the very first one.
It's a hack because the server will continually be unhappy about the checksums.
If scoping was an issue you could still have the client tell the server where to move the camera to, but don't let information returing from the server update the client, since that's what messes up the smooth animation.
I have improved this as part of the packets-on-demand modifications: now, the client doesn't even send control object move messages to the server (some changes were needed to stop the movelist queue from clogging up). Again, I will need to be careful with scoping.
#9
Also, I have just found that netconnections are automatically pinged every 4.5 seconds by default, quite outside the regular packet sends. Does that not mean the continuous connection is kept alive anyway, despite my other packet reductions? (Or perhaps this is only in the server-to-client direction, and it needs to be bi-directional?)
11/28/2005 (1:24 pm)
Matt:Also, I have just found that netconnections are automatically pinged every 4.5 seconds by default, quite outside the regular packet sends. Does that not mean the continuous connection is kept alive anyway, despite my other packet reductions? (Or perhaps this is only in the server-to-client direction, and it needs to be bi-directional?)
Torque Owner Dreamer
Default Studio Name
Being as how this is the TGE SDK forums, which is really meant as an FPS (or anything thats not turn based really) engine, it's a little OT right here.
But I think the RTS kit does much of what you need already.