Networking for racing game
Author
I'm currently in the process of reviving a racing game project of mine. I started thinking of how to approach networking, in which I don't really have much experience. From what I understand, I should really use UDP for most things, since it's a fast-paced game. However, I'm between 2 approaches:
1)The server handles the simulation, and send packets to the clients that contain the position/orientation of every moving body.
2)Each client sends to the server input messages(like 'front key was pressed'), and the server broadcasts those messages to all other clients, which handle the simulation locally, based on those messages.
I would like to ask, from those 2 approaches, what would be the most sane and efficient? What are the pros and cons of each one? Also, are there any other methods I'm not aware about?
Any links to resources talking about this would be also welcome. Thanks!
I think your second approach will lead to problems during the simulation. For example if you miss one packet or you have latency, one client will "see" an opponent at the wrong place.
Definitely the first approach is the good one.
Definitely the first approach is the good one.
First method with local simulation.
So when you press a button locally you see the change and the message goes off to the server which will also simulate the world and broadcast these changes (not presses) to all the clients.
Standard client-server with prediction setup.
So when you press a button locally you see the change and the message goes off to the server which will also simulate the world and broadcast these changes (not presses) to all the clients.
Standard client-server with prediction setup.
There is no "best" way. Each way makes different trade-offs between locally perceived latency, global consistency, tolerance to lag, etc. The Forum FAQ has a number of links to various descriptions of various ways of doing it.
I added network support for up to 4 players to my current project "Stunt Marble Racers" (see Announcements), and I took the first route: all simulation is done on the server which sends updates to the clients. The clients just send their controls to the server.
I know of the tradeoffs, so I suggest the game should only be played in local networks. In some test sessions (though never with 4 players) it turned out the it works nice and smooth, with a low ping value in my local network.
I have implemented this as my "first shot", now it's working and, if I ever find time to, I guess I will improve it. This "stupid approach" where all the clients are stupid didn't take me long to implement and now I have something to test. As I am one of those lonesome coders I often go the easy way ;).
I know of the tradeoffs, so I suggest the game should only be played in local networks. In some test sessions (though never with 4 players) it turned out the it works nice and smooth, with a low ping value in my local network.
I have implemented this as my "first shot", now it's working and, if I ever find time to, I guess I will improve it. This "stupid approach" where all the clients are stupid didn't take me long to implement and now I have something to test. As I am one of those lonesome coders I often go the easy way ;).
What happens when a packet is lost?
Method 1 : Everything gets sorted out with the next packet.
Method 2 : Everything goes out of sync until the server realises that the packet got lost and resends. This is the same way a lost packet is handled in TCP and in fact TCP is a great way to implement method 2. If you think TCP has too much lag, this is the process that causes the lag.
There is a third method called peer to peer. Each player sends their position, velocity etc directly to each other player. This has the disadvantage of potential cheating but the advantage of lowest possible latency.
Method 1 : Everything gets sorted out with the next packet.
Method 2 : Everything goes out of sync until the server realises that the packet got lost and resends. This is the same way a lost packet is handled in TCP and in fact TCP is a great way to implement method 2. If you think TCP has too much lag, this is the process that causes the lag.
There is a third method called peer to peer. Each player sends their position, velocity etc directly to each other player. This has the disadvantage of potential cheating but the advantage of lowest possible latency.
I think even if you use method 2 you have to send complete updates at regular intervals. I read an article about the Quake2 network system yesterday (that I currently can't find), and it uses a nice approach that is always sending complete position and state updates at regular intervals. I guess I should find that article and read it again to get the details.
Author
Ok, thanks a lot guys, I think I will use the first method, with local simulation like phantom suggested. Thanks again! :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
