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?

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.

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...