Just another small topic. With today's sub-200 ms lag, it may be possible to make a lockstep protocol FPS, where there wouldn't be any advantage to having a faster computer or internet connection, so that people with faster computers or faster internet won't get head-shots or escape from fire while the other people are a step behind. Also, you can pack the pitch and yaw rotation in pixels in a tiny packet if you narrow down the range and put all the bits into one variable, and the same for movement, taking only 4 bits for forward, backward, left, and right, or even less if we only allow the 9 possible movements (the 8 directions and standing still), and pack them together, and perhaps add jumping and crouching for 11, and maybe shooting for 12. This can decrease the data expenditure and make it possible to put in more players in an MMO FPS. Also by making the master server only act as a matchmaker, and tell the clients occasionally when somebody joins and their address (maybe using IPv6 ideally, but it's possible with IPv4, if behind NAT) and have the clients talk to each other, so that everybody in the PVS knows each other and updates their positions and keeps in contact, and if anybody from a neighboring region should come into contact with another neighbor's, the intermediary will inform the second that the first is there and pass over their address so that they can establish a connection themselves and update themselves.  At least, it wouldn't be unfair or have any different happening of events between different computers clients, though they might lag, if a client-server lockstep is used where the game might continue on a server faster than a client updates, though the client would still be sending commands and might process the game, though might not receive updates fast enough or render the frames fast enough. Though this is for a client-server model, and would require more work for a distributed MMO model where each client is a server in its own way, though really peer-to-peer with a master server that generally oversees things.  So all together with 9 values for movement direction, and x 2 jumping x 2 crouching x 2 shooting values, gives a requirement for 72 values, which can be stored in less than 7 bits.