Does this even make any sense? :[
Author
I'm currently creating the framework for an RTS. There won't be any computer players, so I don't have to worry about that. I read the excellent article here.
This is what the article suggests: At regular intervals (possibly 200 milliseconds), player input will be sent to all other players.
Because only input is sent to other players, each player will need to have an identical "copy" of the game running separately in order to know what is going on.
To ensure that the games are all running identically and smoothly, the game will update itself two intervals behind the network data. In other words, when data from interval 100 is sent out, the game is executing data from interval 98.
It's that last part that I don't understand. What is gained from doing this? Why not wait just one interval and have them twice as long? I don't really know much about this stuff, I'm sorry if this question is ridiculous.
To take a guess, it sounds like triple buffering, but applied to network data, rather than graphics.
Network communication is non-instantaneous (a _good_ ping is 100 which means it takes ~50ms for a packet to travel from one machine to another)
So you see, if you make it one long frame there's no data between which to interpolate so you'd end up with a graphics frame rate of 3FPS. By running 2 frames behind you always have data between which to interpolate thus allowing for a fast framerate.
Some of the newer RTS games have shortened their logic framerate so that they get ~10-15 logic frames per second instead of 5. They can do this because more people are on broadband now so there's generally faster pings. This gives you a subtle (but noticeable) feeling of better unit response time.
-me
Frame 98|| current render (i have 2 frames between which to interpolate my unit's| positions, draw projectiles, etc)|Frame 99|| data from Frame 100 is still being sent across the network so we wouldn't be| able to interpolate information to render|Frame 100 (real-time)So you see, if you make it one long frame there's no data between which to interpolate so you'd end up with a graphics frame rate of 3FPS. By running 2 frames behind you always have data between which to interpolate thus allowing for a fast framerate.
Some of the newer RTS games have shortened their logic framerate so that they get ~10-15 logic frames per second instead of 5. They can do this because more people are on broadband now so there's generally faster pings. This gives you a subtle (but noticeable) feeling of better unit response time.
-me
Author
Thanks to both of you!
Palidine: I don't see why you would have to interpolate anything though. Each action would have a time attached to it, during the interval, the previous interval is played out. Either way, the game is running 400ms behind the input. I'm probably not being clear...
Instead of having intervals of 200ms, and executing 2 intervals behind (400ms), how is it not identical to having intervals of 400ms, and executing 1 interval behind (400ms). I don't see how the result would be any different. In both cases, the game would be playing out actions from all of the players with a 400ms delay from their input.
Agony: I'll read that and then respond.
Palidine: I don't see why you would have to interpolate anything though. Each action would have a time attached to it, during the interval, the previous interval is played out. Either way, the game is running 400ms behind the input. I'm probably not being clear...
Instead of having intervals of 200ms, and executing 2 intervals behind (400ms), how is it not identical to having intervals of 400ms, and executing 1 interval behind (400ms). I don't see how the result would be any different. In both cases, the game would be playing out actions from all of the players with a 400ms delay from their input.
Agony: I'll read that and then respond.
So let's draw out your idea:
So with this solution we are now rendering at about 3 frames per second. Units will jump from one position to the other and generally look crappy.
So to go over the other solution in more detail
Frame 99 (all the data for this has crossed the network)||| In here we have the calculated positions for all the units on the map| We know what player clicked where and what orders were given| But we only know this for Frame 99 so we can only draw everything where they| were at frame 99. So now we have to wait 400ms until all the network data for| Frame 100 is collected before we can move anything|Frame 100 (the data for this is only beginning to cross the network)So with this solution we are now rendering at about 3 frames per second. Units will jump from one position to the other and generally look crappy.
So to go over the other solution in more detail
Frame 98 (all the data for this has crossed the network)|| This is where current rendering is happening. We are rendering at 60| frames per second (or whatever the user's computer can handle). To render| we interpolate between an object's position at Frame 98 and it's position| at Frame 99. So from the user's perspective the tank or whatever moves| smoothly at 60 frames per second (each frame moving a little bit)|Frame 99 (all the data for this has crossed the network)|| nothing is happening with the data between frame 99 and 100 we're just| waiting until the 200ms of time between Frame98 and 99 passes. At that| point we'll swith over to interpolating between 99 and 100 while the| data for 101 crosses the network|| If a user clicks "now" then that click gets assigned to Frame 100 and is| immediately sent over the network.|Frame 100 (this data is crossing the network)
I belive you are thinking in a real-time model:
User A clicks a button
his units move locally
the message is sent over the network
When User B gets the click message he moves User A's units
The problem with this is that network information takes a long time to get from one place to another. So now we have 2 totally different games going on. On User A's machine, his units started moving at time 1. However, on User B's computer the units started moving at time 1.2. The reason we use logic frames and delayed updates is so that on both User A and User B's computers User A's units start moving at exactly time 1. Because of what I drew, you need to be 2 logic frames behind for smooth updating and reliable simulation.
-me
User A clicks a button
his units move locally
the message is sent over the network
When User B gets the click message he moves User A's units
The problem with this is that network information takes a long time to get from one place to another. So now we have 2 totally different games going on. On User A's machine, his units started moving at time 1. However, on User B's computer the units started moving at time 1.2. The reason we use logic frames and delayed updates is so that on both User A and User B's computers User A's units start moving at exactly time 1. Because of what I drew, you need to be 2 logic frames behind for smooth updating and reliable simulation.
-me
Well, the basic premise that you have to adjust for latancy is fair, but the way it seems to be implimented, or at least the way its worded, is asking for trouble.
Unless you have a solid, proven distributed application framework to build on you *need* a dedicated server. This can be a unit that solely serves the game, or it could be the player with the best machine/connection. The point, though, is that one machine *must* be the authoritative source for the gamestate and updates. Without very robust mechanisms in place, hoping that 2 or more clients simply passing input between each other will stay in sync is crazy. I've written simple networking code that was used in 3 college game projects, the first attempt at netowrking the first game was a p2p system like what you describe and even on 2 identical machines on a LAN and a latancy of probably 10ms or so the game would de-synchronize after a minute or so.
Aside from that, p2p systems are ripe for cheating. If I'm only recieving input, I can ignore inputs that cause my character harm, or generate false inputs that cause you harm. Someone could hack their client to not take damage and to launch multiple attacks with no reload time, for instance. If there's no authoritative entity to call them out, then how can they be stopped?
My advice is to either provide for a dedicated server, or to select one player as the "host" for a game. I'm not aware of any profesional game that uses a p2p approach.
Unless you have a solid, proven distributed application framework to build on you *need* a dedicated server. This can be a unit that solely serves the game, or it could be the player with the best machine/connection. The point, though, is that one machine *must* be the authoritative source for the gamestate and updates. Without very robust mechanisms in place, hoping that 2 or more clients simply passing input between each other will stay in sync is crazy. I've written simple networking code that was used in 3 college game projects, the first attempt at netowrking the first game was a p2p system like what you describe and even on 2 identical machines on a LAN and a latancy of probably 10ms or so the game would de-synchronize after a minute or so.
Aside from that, p2p systems are ripe for cheating. If I'm only recieving input, I can ignore inputs that cause my character harm, or generate false inputs that cause you harm. Someone could hack their client to not take damage and to launch multiple attacks with no reload time, for instance. If there's no authoritative entity to call them out, then how can they be stopped?
My advice is to either provide for a dedicated server, or to select one player as the "host" for a game. I'm not aware of any profesional game that uses a p2p approach.
Author
Quote:Original post by Palidine
I belive you are thinking in a real-time model:
User A clicks a button
his units move locally
the message is sent over the network
When User B gets the click message he moves User A's units
The problem with this is that network information takes a long time to get from one place to another. So now we have 2 totally different games going on. On User A's machine, his units started moving at time 1. However, on User B's computer the units started moving at time 1.2. The reason we use logic frames and delayed updates is so that on both User A and User B's computers User A's units start moving at exactly time 1. Because of what I drew, you need to be 2 logic frames behind for smooth updating and reliable simulation.
-me
I must be completely lost. :(
I don't see why the games wouldn't be identical for each player. All players would see the result of their actions 400ms after they are made, which gives enough time for all other players to have recieved their input.
0-399ms - Players tell their units to move around, attack etc.
400ms - Each player sends his actions to the other players
401-
************* OH *************There isn't any time to receive all of the input because the auctions would have to start executing immediately after that. Wow, sorry about that. Thanks a lot for bearing with me, that must have been frustrating. :P
I'm sure I'll have tons of other questions later, but thanks to both of you for your information.
Quote:Original post by ravyne2001
Unless you have a solid, proven distributed application framework to build on you *need* a dedicated server. <snip> Without very robust mechanisms in place, hoping that 2 or more clients simply passing input between each other will stay in sync is crazy.
What I mention above is how many AAA RTS games work; it's not just a theory, it's how they are actually designed and work. You don't need an authorotative server. It's certainly possible, it's just a different networking paradigm. Both solutions have their own problems and neither is "harder" to implement than the other.
-me
Author
Quote:Original post by ravyne2001
Well, the basic premise that you have to adjust for latancy is fair, but the way it seems to be implimented, or at least the way its worded, is asking for trouble.
Unless you have a solid, proven distributed application framework to build on you *need* a dedicated server. This can be a unit that solely serves the game, or it could be the player with the best machine/connection. The point, though, is that one machine *must* be the authoritative source for the gamestate and updates. Without very robust mechanisms in place, hoping that 2 or more clients simply passing input between each other will stay in sync is crazy. I've written simple networking code that was used in 3 college game projects, the first attempt at netowrking the first game was a p2p system like what you describe and even on 2 identical machines on a LAN and a latancy of probably 10ms or so the game would de-synchronize after a minute or so.
Aside from that, p2p systems are ripe for cheating. If I'm only recieving input, I can ignore inputs that cause my character harm, or generate false inputs that cause you harm. Someone could hack their client to not take damage and to launch multiple attacks with no reload time, for instance. If there's no authoritative entity to call them out, then how can they be stopped?
My advice is to either provide for a dedicated server, or to select one player as the "host" for a game. I'm not aware of any profesional game that uses a p2p approach.
Yes, cheating will be very possible, but not what you are describing.
I will actually pass input (mouse + key presses), so you couldn't trick the game into doing something that it couldn't do. Map hacks, etc., would be very possible, unfortunately.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
