Multiplayer in games: an inside look

Hey.

I recently created a mobile game for Android, which could potentially have multiplayer, which is what users requested.
Multiplayer was not provided, because it did not comply with the separation of model and 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 article goblin wars II, the structure of the game was divided into independent blocks, which ultimately allowed users to play on the network.

The base class for all game objects contained all the logic of the MVC model within itself - it was able to draw itself and change its 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 view.
Any class that draws game objects will implement an interface.

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

Thinking over the architecture for the multiplayer, namely, separately implementing the client and implementing the server, we take out the fields necessary for drawing the object into a separate class.

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

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

When there are a lot of objects in the game, it became too difficult to maintain such a code and add new features.
The transition to components greatly facilitated the creation of new game objects, since in essence the creation of a new entity was a constructor.
All objects in the game are inherited from the Entity base class, 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 bundle:
Server -> ServerImplementation <-> ClientImplementation <- Client
All the difference between a network game from a local one comes down to different implementations.

The actions of the server class are each frame - it gives the current array of states for ServerImplementationand passes to the client.
it looks like this:

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

The class Clienteach frame takes the current state of y ClientImplementation, and then displays the received data on the screen.
Of course, not only states are transmitted, but also events about the start of the game, user commands and others. Their logic is no different from state transfer.

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

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

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

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

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



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