Well, you should think at the communication protocol level and what data you really need to display on the screen and at which point you will receive data and this varies from the type of game.
Example, in an LOL game you do not need to circle the players' names over the network throughout the game. Just at the beginning, at the end, they are discarded from the client's memory after the game.
Now in a life Tibia, you need to circulate this data because you do not have a phase where you can load this data, they will be displayed during the move, so the balcony is probably in focus on the communication protocol, compress the data during the transmission, send only when changing the map or interacting, that is, it analyzes each need to send data. Not to mention that separating players by server / region is a common practice due to latency.
In general, the first step is to analyze what can be put on the client and what should come from the server.
1- Never, however, never make a customer communicate directly with another without the user knowing and agreeing to it. This is a simple design issue for the security party, if you design like this, one client will know the network address of another and 'listening' the connection may have access to the other user's machine. Another latent problem with this type of design is that the latency between different players harming more than one player, because the server has no way to manage direct connections that do not pass through it and would end up waiting too much at some point, including increasing the complexity of the code to control these things.
2 - Separate visual information from the messages that make up the game's communication protocol. One thing is what you see on the screen, another is what circulates in the network between the server and the client, most of the time that's why customers are great to download. An example, the name of a monster does not need to circulate in the network, just the number (ID) of the monster that is transformed locally in the image and the text on the screen.
3 - All content that can be displayed as default among the clients of a session should be placed in the client download for installation. Only control data (object identifiers) must circulate across the network. Basically the flow between a user click and action is send click to server, server processes, return response to client. This flow, obviously, should be just in the sense that animations and positioning run, never from running data itself.
4 - Almost last and in a nutshell, the server maintains the real status of all objects, maps and interactions, performs the processing and determines the results, since the client is just a graphic window that renders and displays the results of the actions, whatever the type of game.
5 - Design the protocol for different types of messages, type, what kind of message can be dropped if it gets lost in the network? If yes, UPD, otherwise TCP.
An example of this is the moment when you have lag and the screen when you return already appears in a totally new position (probably dead): D
Well, it does not have a magic recipe and programming protocols and games is not so trivial.
Edit: Some people have been 'studying' the LOL protocol, you can find these examples on google (ex: a link in English: link )
Edit 2: An interesting link with the numbers of the guys and a little of the infra ( link )
