Jump to content
  • Advertisement
Sign in to follow this  
CS_Nerd

Lack of Consistency

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

In writing my first networked multiplayer game, I chose multiplayer nibbles because of its percieved simplicity making it seem that it would be easy to add the network capability to the game. I am making this game in Java and I want it to be able to support multiplayer over a LAN, I have no ambitions for it to work over the internet, LAN is all I ask for. So in choosing a network architecture, I made the server to be just a central hub, all it does is distributes packets to the clients. Basically, client A sends a packet to the server then the server sends that same packet to clients B through Z, or in other words the server sends the packet to all clients except client A. As for the clients I followed the quoted design below, for it's low network traffic.
Quote:
"If you co-simulate your entities on client and server, you only need to send controller input, which is a few buttons, rather than position/velocity/orientation, which is some number of floating-point values."-hplus0603
So all my clients recieve and send are user inputs. For reducing the network traffic to a bare minimum this design is absolutely great, however the problem with this is that there is no synchronization among the clients, a complete lack of consistency. Where on one computer a player has just eaten a food, on another computer that same player has collided into a wall. So my question is, how can I make it so there is synchronization or consistency among my clients without forsaking a tolerable network traffic, in this game of multiplayer nibbles?

Share this post


Link to post
Share on other sites
Advertisement
you can synchronize your network with the server


lets say you have a 7kb/s up and 7kb/s downstream (ISDN /DIAL) connection

so what you do is you send control input from the client to the server

the server passes the input to the other clients as well


well now you have more or less only made use of you downstream in form of receiving control inputs of other clients, but you still have a lot of your upload unused


so in order to keep you in synchronization with the server you
could upload the delta of your current entity state to the last synchronisation state


the server then sends you synchronization packets if some of your data differs to much


you can also let the server update your gamestate periodically but this will use a lot more bandwidth of your downstream which is a killer for dial/isdn connections

Share this post


Link to post
Share on other sites
I am not quite sure why you are using a centralized server.
If only using a LAN is your requirement...you should realize that
most current LANs already have a hub architecture..ie the physical layer is
no longer a bus topology. Personally I would simple eliminate the central server and use multicast....or broadcast if you have few other computers on the LAN.

As far as synchronization I don't think the actual network is the problem.
Most LANs have minimal delay and jitter. I have cranked the delay up to 500ms on
my network emulator and the delay is still difficult to see in many types of movements. I would relook at your code before you spend too much time worring about synchronization on a LAN.

Share this post


Link to post
Share on other sites
Maybe try sending the key inputs(up down blah whatever) and the client's position at the time of the input? This should reduce the overall traffic(you aren't sending position updates every frame or anything crazy like that), and then the other clients can backtrack slightly and say player A moved back THERE, not at the position I currently see him...

Maybe a timestamp could also work, if the player's movement is time-limited instead of frame-limited. If you send a timestamp with each global update, everything synchs right back up by reverting players to the position they were at X time, applying the specified commands(turn 45 degrees left) and then fast forwarding back to current time and then drawing the screen appropriately. This may cause some strange screen flickering though, if the time between the player sending the command and the other client receiving it is too great, the update will move the first player rather unexpectedly to player B.

I can see how not keeping track of latency like that would cause problems over time, and I appreciate you bringing this to my attention, I hadn't given much thought to a solution before. Those things I outlined above are just quick theory, I'd love to hear if either solution works for you, and hope I helped in some way. Any other input is smiled upon as well, I'll be going through this soon myself...

Share this post


Link to post
Share on other sites
Quote:
Where on one computer a player has just eaten a food, on another computer that same player has collided into a wall.


You really need to make sure that anything that involves a shared resource (such as food, health, monsters, etc) has a round-trip to the server before actually taking effect. Meanwhile, you can optimistically render effects on the client, and hope it works out.

If you're using TCP, and carefully control your simulation, you can make your game fully predictable, and always simulate the same thing on all machines -- there simply is no room for digergence. This is Ultra Hard (tm) but can be done. The "1,500 archers" paper is all about this model. At work, take it one step further, and do that on top of UDP, with a repair mechanism for cases where packets get out of sync.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!