# Does this even make any sense? :[

This topic is 4100 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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.

##### Share on other sites
To take a guess, it sounds like triple buffering, but applied to network data, rather than graphics.

##### Share on other sites
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)

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

##### Share on other sites
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.

##### Share on other sites
So let's draw out your idea:

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)

##### Share on other sites
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

##### Share on other sites
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.

##### Share on other sites
Quote:
 Original post by PalidineI belive you are thinking in a real-time model:User A clicks a buttonhis units move locallythe message is sent over the networkWhen User B gets the click message he moves User A's unitsThe 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.

##### Share on other sites
Quote:
 Original post by ravyne2001Unless you have a solid, proven distributed application framework to build on you *need* a dedicated server. 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

##### Share on other sites
Quote:
 Original post by ravyne2001Well, 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.

• 9
• 23
• 10
• 19