   desynch in RTS
  I''m a bit new to this networking thing, and I''m anticipating a desynch problem I just know I''m going to have.All I will send over the network is the input commands from the player (move here, build this there, etc). The problem is something like this can happen.Player A tells unit A to start moving right. 200 ms later, unit B owned by Player B walks in firing range where unit A used to be. On Player A''s system, the two go their separate way. However, assume there was a small lag spike, just 300 ms. On Player B''s system, the two units stop and start fighting. A trickle effect takes place and the whole game becomes desynched.Is there any way to solve this without having the server maintain the game state as well? I haven''t seen any commercial RTSs have desynchs like the one I''m thinking of, and they don''t seem to keep the state on the server either. 
  Can you tell more about your game?  Are you actually writing network code now?-----Loulou @ escapepod dot com ;  If I''m not wrong, the *craft games always proceed in lock-step. Every game tick the server tells the clients of any new commands that have been issued by other players, and the clients tell the server of any commands their player has issued. If all the talking doesn''t happen within the specified time period (I dunno what it is but I''d guess 200ms or so) then the game freezes until things recover or the players get fed up and drop out.Another neat trick I''ve read about (been thinking about doing my own RTS but lacking in effort factor so far), which I think the *craft games also do, is to put a uniform delay on all commands of half a second or so. Apparently a consistent short delay is less noticable and/or irritating than a random but possibly shorter delay... ;  For each entity, someone needs to be authoritative. Every so often, it helps if the authority sends out a baseline. You could say that you send the baseline for 2 units piggybacked on whatever data you send in each packet, and just cycle through them. That way, you get a repair mechanism built in.Whether there''s one server that is always authoritative, or whether each client is authoritative for his own units, or whatever is up to you, but there needs to be authority, and there needs to be sync. ;  Always the server, and only the server, should be authoritative. If the clients have last say over where units are etc. then you''re opening yourself wide up to cheating. The worst cheat you can have with trusted server/untrusted clients is a maphack (assuming the client knows all of the enemy units'' positions, which it may do to cut down peak bandwidth). With trusted clients, anyone can munge their client to allow them to randomly teleport six Level 10 red dragons into your base, which is always fun.[OT] Hey, how about a game where you (the player) has a ''mana'' level independant of any units (or maybe based on how many peons you have or something) and can use that to manifest things like the aforementioned red dragons? That would be cool... ;In a peer-to-peer game, there is no server. Peer-to-peer is still a viable strategy, because it costs $0 to run the servers. Well, you might need an introducer/match-maker service. But maybe not.Similarly, LAN play is peer-to-peer, and the risk of cheating is pretty low. This still counts as a "networked" game, and, in fact, may be how the majority of "networked" games are actually played (depending on the game). ;  Thanks everyone, "lock step" is what I was looking for.Now, I''m having a similar problem with computers with low frame rates. I can''t do frame-by-frame physics/ai very well. Assume two objects are moving fairly quickly at each other. On normal computer, they are calculated to hit each other and they go their separate ways. On a slow computer, no single frame records them intersecting, so they pass right through each other.I was going to lock the ai/physics at 30 or 60 times a second, or whatever it would be (maybe calculating it for everyone based on the slowest computer). Assuming 30 times, and 30 fps, one physics cycle is done per frame. If for some reason there is a whole bunch to be rendered and the fps drops to 10, it will do 3 physics cycles per frame. The only problem is that it might be recursive. Doing those 3 cycles slows it down even more, so the next frame it does more cycles, slows down, and so on. At some point all computers would have to switch to a lower rate. Is this what other games do? ;quote:hplus0603:In a peer-to-peer game, there is no server. Peer-to-peer is still a viable strategy, because it costs $0 to run the servers. Well, you might need an introducer/match-maker service. But maybe not.Similarly, LAN play is peer-to-peer, and the risk of cheating is pretty low. This still counts as a "networked" game, and, in fact, may be how the majority of "networked" games are actually played (depending on the game).True, for one-on-one games. I wouldn't do peer-to-peer with more than two or three players because of factorial-order data transfer and synchronization nightmares (although, thinking about it, one could have a ring topology where you receive the game state, modify it with your input, and pass it forward... then what if someone drops out?)Whether play is over a LAN or internet doesn't affect whether it's client-server or peer-to-peer. I guess it does make it less likely for people to cheat when the person they've just wallhacked and shot can walk over and thump them. Raloth - what sort of physics are involved? Most RTS-type games I've played have no real physics, units just move along a path from start to destination. For that sort of thing, you can probably get away with updating unit positions only every 100ms or so... what you need to do is instead of doing a simple  if(unitA.distanceFrom(unitB) < mindist) doCollision();you need to represent unit A's and unit B's paths as vectors:a   = start_a   + t * (end_a   - start_a  )b   = start_b   + t * (end_b   - start_b  )where 't' is the time (0<t<1) between last frame and this frame. Then you find the value of 't' where they approach most closely, and if that's less than your collision distance (or visual range or whatever) then you can do something about it.Generally the actual game logic takes next to no time compared with rendering, so any computer that can't keep up 10fps with the game logic really isn't fast enough to play pong on.   [edited by - fractoid on February 18, 2004 12:49:26 AM];  My "physics" would just be simple collision detection and AI. It gets a little complicated when I have a bunch of units collide with each other. The AI of how they navigate through needs to behave the same on all computers. When I detect a collision I have to step backwards in time and figure out just when it happened for the ai to behave properly...and maybe that little change changes a different collision...ow my head hurts .[edit] On average, what % of packets are dropped?   [edited by - Raloth on February 19, 2004 10:15:24 PM];  We have done 10 and 12 player Warcraft III in the office. It rocks! All LAN play.There is one player "hosting" and he''s the "server" but from your point of view, it''s still peer-to-peer, because that player is just another player, and his machine can be hacked just like any other machine. So, unless you involve an authoritative server, you can put decisions in any client, because any client has equal chance of being hacked. Let the others detect that he''s out of sync a lot and kick him out. 