One of the most important elements of any multiplayer game is the very thing that carries the information between players or from player to central server(s). This layer of connectivity is Protocol, and choosing the right one for your game is a crucial step of planning architecture setup.
First of all, you’ll need to decide, what protocols you can use with your technology stack of choice and try to classify then as detailed as you can. Later this classification will help you point out their strengths, weaknesses and core utility.
Basic high-level protocol solution can be dichotomized using following criteria (among many others, of course): underlying low-level carrier protocol, persistence of connection, reliability, state preservation, encryption, human readability, compression, proprietary. Lets look on utility and common examples of protocols in some of the above categories.
Persistence of connection
This factor is one of the most important that influences a decision on what protocol solution to pick for your game. There is basically only two options in this category, but choosing one basically is the most important decision one can make when looking at protocol solutions. Persistent connection means, that protocol creates a connection “tunnel” between two endpoints that is persistent and constantly reused throughout the session. This one is massively favoured for any real-time experience, especially MMO, multiplayer FPS, real-time RPG and RTS kind of games.
Another advantage of this approach is ability to send data both ways, without a need of permanent network identification for all the participants of the communication process, as they can just send data through the already established connection. Non-persistent connection means that you can only rely on tunnel existing when you make a new request. Here you’ll have to “find” an endpoint you wish to connect to within the network every time, establish the connection and pour data you want into it. Connection “tunnels” may actually persist for some time, to improve performance of the connection establishing, but you can not rely on this being true every request.
This approach, though sacrificing speed, saves a lot of resources, especially on central servers, where free sockets can be a commodity resource. This type of connection is perfect for turn-base games, where preserving state and slowness of data transfer can be easily masked by end-turn animations or other effects, that don’t influence the gameplay. In the persistent camp you can find solutions like UNet, Forge, Photon, Smartfoxserver and HTTP 1.1 (kind of, with magic and correct keep-alive properties being respected on all sides).
Non-persisten are usually based on TCP/HTTP solutions and WebRequest in Unity.
Another key factor, that severely influences the way one is planning the development process around is protocol reliability. Should you wait until you get the data package or timeout? Should you assume it will never come through and extrapolate the result? That’s were reliability comes into play. Reliable protocols claim, that they will either explicitly deliver the data in exact order, or let you know they didn’t. Unreliable protocols do no such thing. With those you’ll get much more speed, ignoring the checks for hashsums and package orders, but you’ll need a lot more development on client or server logic compensating for this. Reliable protocols are either based on TCP trasport layer (HTTP, some flavours of smartfoxserver and Photon) or use their own delivery checkup functionality (like reliable-udp flavour of Photon PUN). Unreliable protocols are usually based on udp or direct websockets.
Other important factors you always need to consider are encryption (https and other ssl based protocols) vs speed and simplicity, human readability vs compactness and need for state preservation (e.g. fetching any unsensitive data can be completely unencrypted and stateless, maximizing simplicity and speed).
Whenever you start development of a new game, that requires multiplayer, or any other kind of client-server connectivity, you now know what flavours and categories of protocol you can choose from. Take a look on a game you plan, decide on security and performance challenges standing before you, come to a compromize and reach into the category of a protocol you feel is best suited for decisions you’ve made.