Multiplayer Games: Inside Look

Hey.

Recently, I created a mobile game for Android, in which there could potentially be multiplayer, which was what the users requested.
Multiplayer was not envisaged, since it did not respect the separation of the model and the presentation.
In this article I will consider a simple implementation of the network mode of the game and talk about the mistakes made at the stage of thinking through the architecture of the game.
Inspired by the goblin wars II article, the structure of the game was divided into independent blocks, which ultimately allowed users to play over the network.

The base class for all game objects contained all the logic of the MVC model inside of him - he knew how to draw himself and change his state.

public abstract class BaseObject { public byte type; public byte state; public Rectangle body; public abstract void update(float delta); public abstract void draw(float delta); } 

Separate the model from the presentation.
Any class that will draw game objects will implement the interface.

 public interface Drawer { void draw(BaseObject obj, float delta); } 

Thinking through the architecture for multiplayer, namely the separate implementation of the client and the implementation of the server, we move the fields necessary for drawing the object into a separate class.

 public abstract class State { public byte type; public float x, y; } 

Thus, we will be able to store only the presentation on the client side, and there will be no need to create model objects.

When there were a lot of objects in the game, it became too difficult to accompany such code and add new features.
The transition to the components greatly facilitated the creation of new game objects, since in essence the creation of a new entity was a designer.
All objects in the game are inherited from the base class Entity, and the only difference is in the state returned by the getState () method and a different set of components.

The structure of the game has changed significantly, and the separation of entities allowed us to create such a bunch:
Server -> ServerImplementation <-> ClientImplementation <- Client
All the difference between a network game from a local one comes down to different implementations.
')
Server class actions every frame - it gives the actual state array for ServerImplementation and transmits to the client.
It looks like this:

 public class LocalServerImpl { ... public void update(float delta){ clientImpl.states = server.getStates(); ... } } 

The Client class each frame takes the current state from ClientImplementation , and then displays the received data on the screen.
Of course, not only states are transmitted, but also events about the beginning of the game, user commands and others. Their logic does not differ from the transfer of states.

Now for the implementation of the network mode, we need to change the implementation of ServerImplementation <-> ClientImplementation , as well as for the state classes to implement an interface for serialization and deserialization:

 public interface BinaryParser { void parseBinary(DataInputStream stream); void fillBinary(DataOutputStream stream); } 

Why when parsing we do not read the byte responsible for the type? We read it when determining the type of an object in order to create the necessary entity from the input byte array.

I used the Kryonet library to work with the network, it is very convenient if you don’t want to know how data packets are transmitted, and only the result is important to you.
LocalServerImpl replace on NetworkServerImpl , transfer data is not more difficult:

We get the current status, write to the array bytes, archive, send to clients.
On the client, the differences are also minimal, he will also receive the status, but they will come over the network:



Any actions on the client side are first sent to the server, the server status changes, and this data is returned back to the client.
I recorded a small video that demonstrates the network mode (the libgdx engine allows you to run applications on a PC)