   Multiplayer racing game
  someone please help me.i making a racing game, and i need to make a multiplayer version.so after reading the directplay samples i understood the way of creating server and client and how to send data, my problem is : what data should i send?, and where should the processing occur? in the server or in each client? if 2 players collided with each other, should the collision response be calculated on each client, or should the server do that and send the result to all clients?and the major problem is:suppose 2 players have different PC specifications, one is running on 15 FPS and the other is running on 30 FPS, what should i do to prevent different gameplay and results on each PC?iam really having trouble answering these questions, so please someone help me!!   
  I am working on a racing game too, and I have given some thought to this one. Here's my suggestion.The physics processing should take place at the client. Every client takes care of his/her own car all the time. All other cars should be processed at the client too. Every client sends the status of his car and controls whenever controls change or at an interval (for example, every 100ms if no user input changes occur). The server relays this data to all clients. Whenever a client recieves the status of another player's situation, the in-game status is updated to that data. Between these update packets, the "visitor" cars are updated by the client. This way there is minimal lag and player jumping.My suggested system involves no cheat prevention whatsoever, it should be done by other means, for example by doing sanity checks at the server.hope this helps. I would also like to know about your opinions on the subject.-Riku;  my idea is different, i thought of the following technique to make the trick:the server is the only proccessing computer on the network,clients only renders the world on their pcs as the following data transmition occurs:the clients only send the keyboard input to the server and the server processes the whole world movement, then sends the positions and rotations to the clients, along with the world's objects information.but to tell the truth, i didnt try it out, and thought that there might be a better way to do that.   ;Quote:Original post by Tamer_Malasmy idea is different, i thought of the following technique to make the trick:the server is the only proccessing computer on the network,clients only renders the world on their pcs as the following data transmition occurs:the clients only send the keyboard input to the server and the server processes the whole world movement, then sends the positions and rotations to the clients, along with the world's objects information.but to tell the truth, i didnt try it out, and thought that there might be a better way to do that.the problem with that is the "reaction"-lag a player will get when he plays on a server with bad ping. he might press the key but the car will react with a delay. this will make it hard to control and keep the stability in the car.I've done a few games which had such a problem (no racing games).The client calculated everything on the "fine" level and sent the result to the server.The server gets the "events" from the clients checks if they are "near the same". if they are the middle "event" was done and sent out to the clients. if not the server re-calculated and sent this to the client.advantage: clients do predict the events in like 99+% of the time right so there's no jumping at all. server load is low because it only has to check for errors in the client-calculation and recalculate in these error cases.hope this helps.   ;  Hi!I hate to break it to you but: Your system is very bad.Why? One word: LAG.A typical ping for a slowish broadband user half way 'round the world is something from 30-100 ms. Pings may be even bigger, but taking 100+ ms pings into account is not reasonable, the player should realize, that 100+ ms ping is too much, and should join on another server.A 30-100 ms lag could mean 100-200 ms delay between the user pressing a key and seeing anything happen. That's one fifth of a second! In a fast action racing game, that's half an eternity. Think about a race car doing 70 m/s (about 250 km/h or 160 mph). A fifth of a second at that speed is almost 15 meters. Missing your brake spot by 15 meters is roughly equal to running the corner wide and ruining your race, at best crashing into a wall or even worse, into another racer, ruining his race too.This also treats the players unequally. A player with a 100meg/100meg ethernet connection like I have would kick a 512k/512k (or worse) broadbander's butt, only because his connection is faster.Laggy gameplay is very frustrating, too. If I would experience a fifth-of-a-second lag between my actions and stuff actually happening, I would not touch the game twice.Your method of doing processing only at the server-type solution is only good for non-realtime (read: turn based) games.I must comment your earlier issue on players with different speed pc's. First of all, you should do your physics time-based, not frame-based. Your physics code should also be stable, so that at varying frame rate, the experience is pretty close to the same. This is best achieved with numerical integration and differential equation based physics, but simple simulations will do without.Time-based physics alone might not be sufficient. You should also try to maintain a solid framerate, let's say 40-60 fps. This can be achieved with delay and frame skipping. If the game runs too fast, wait a little bit before doing the physics on each frame. If the game is running too slowly, you should not draw the frame at all, just skip all the drawing for that frame, just update user input, network and physics.when it comes to high end simulation, all physics are done at a constant rate, while the graphics do only what they can. Sometimes even threading is used to achieve this.Hope this helps...-riku   ;Quote:Original post by RichardoXA typical ping for a slowish broadband user half way 'round the world is something from 30-100 ms. Pings may be even bigger, but taking 100+ ms pings into account is not reasonable, the player should realize, that 100+ ms ping is too much, and should join on another server.A 30-100 ms lag could mean 100-200 ms delay between the user pressing a key and seeing anything happen. That's one fifth of a second! In a fast action racing game, that's half an eternity. Think about a race car doing 70 m/s (about 250 km/h or 160 mph). A fifth of a second at that speed is almost 15 meters. Missing your brake spot by 15 meters is roughly equal to running the corner wide and ruining your race, at best crashing into a wall or even worse, into another racer, ruining his race too.This also treats the players unequally. A player with a 100meg/100meg ethernet connection like I have would kick a 512k/512k (or worse) broadbander's butt, only because his connection is faster.Laggy gameplay is very frustrating, too. If I would experience a fifth-of-a-second lag between my actions and stuff actually happening, I would not touch the game twice.Your method of doing processing only at the server-type solution is only good for non-realtime (read: turn based) games.What you post is intresting, but you dont present a solution to the problem.The way you formed your post make you wait for a solution, which you dont give to us. Im very intrested in the solution as I have a simular problem. ;  Collisions, and other things that affect more than one player (can't think of any right now), must be done by the server, otherwise the two players might have different answers as to what happens. So unless you are prepared to have large jumps whenever such an action happens (the message from the server to update the simulation would be two pings behind the clients' predictions), you have to be prepared for a delay of the one way transmission time (30-100ms in this example). (The server doesn't know what you did for that long, so if your client displays a change sooner it is out of sync with the server.) And a client's view of other players' actions will always be the sum of pings behind, making it hard to accurately predict them.The solution employed by many games is to give you visual confirmation of your action (turning the steering wheel, perhaps) but not actually perform the action until your ping has passed. That's commonest in RTS's, but I guess it would work for racing games too. (To be honest, the problem of high latency is why most racing games aren't that popular over the 'Net but are restricted to LAN multiplayer.)   ;  I race live for speed regularly on the internet and usually sessions are rather lag free, the startup usually gets a little lag, but after that things usually run smooth. Whenever a big lag (> 100 ms) occurs in live for speed, the laggy player's car is frozen to it's place and a text appears over it. It's annoying but not as annoying as it would be if the car jumped around like a bunny.I might not share your opinions on doing collisions on the server. I would find that my strategy proposed above (clients handle local player's physics) works for collisions too. The collision response of the two players might not be similar, but very close 99% of the time.I have not tried this out, but with my reasoning, it should work pretty good with reasonable lag (<100ms).Of course, doing collisions at the server might not be a bad idea, or at least the possibility must be left open. I still wouldn't move the player physics to the server, just the collisions, if it proves to be necessary.What you said about RTS's might be true, but it won't apply for racing. Take my word for it. Even though the steering wheel would turn and you would get visual feedback, that would completely ruin the gameplay and the. I would hate to see this happen to my carefully refined car physics.-Riku;  thanks all for help,but i need just another thing,should i use the peer or the client server model?which is better, and which is more effeciant for a racing game?the client server is working fine, but i dont know why the peer is not working.i wanted to use the peer, but the process of the stagedpeer from microsoft SDK9 is getting into an infinite loop, i tried to end the process and tried to shut down the computer but it doesnt close.....i tried to debug the process and close it, but the process stucks in the enumeration function of the peer, and i dont know why, sometimes it works fine and sometimes it doesnt.does any one has an idea?   