The play "Developing a multiplayer online game." Part 1: Architecture

Part 2: Protocol
Part 3: Client-server communication
Part 4: Moving to 3D

In general, as promised, I publish a series of articles on the development of multiplayer network game. Initially, I just wanted to roll an article on the development of the server part in the interesting Scala language. But I realized that one little article for the deployment of the topic will not work. And to write the next topic about everything and never wanted to, initially. Therefore, meet the play in three acts. During which we will develop the project architecture, we will implement the server and client parts ...
Everyone remembers cool tanchiki on dandy?
Well, using the example of these tanchiki we will develop a server and a client.
')


For fans of freebies and hard copy-paste I will say right away that there will be no complete source codes. I will upload only some interesting (complicated?) Moments of both server and client.

So let's start dear viewers.
In the course of our narration, you will plunge into the world of network gaming ... you will know the sweet fruit of the forbidden scala code and get the opportunity to taste the coding under flash ... and as a final action we will try to arrange a habraeffect for the finished project that I will run on a separate server to test the resulting architecture on real hardware .

Part one. Action one: General description of the project.

Let us write in order what we will do.

Since we are not faced with the task of making our BigWorld (this engine is for those who do not know it) and we are creating a prototype, we simplify our task wherever possible. For our main task is to show how network games are developed in general. On a concrete, working example. And do not make a finished commercial product.

Task : Network game like “tanchiki on dandy”. Client part on Flash, server on Scala. Sockets connection. In order to remove many troubles, we will make an asynchronous server according to the principle “Whoever got up earlier - that and sneakers”.

What is generally meant by the client server-side interaction in the game?
1. User login
2. Exchange with the server (Sending a command from the client to the server, Receiving a response to a command from the server, Receiving a command from the server)
3. Adimin part of server management

User login is the primary authentication in the game. We do everything in a simple way and the check will go only at the login stage. In general, the authorization should be periodically checked in the game for every fireman from cheaters. When you first log in with a new login, the game puts it into the database and that’s all registration.

Admin part is also primitive. We will display a list of users online. It is useful for load testing.

Exchange with the server - this is the game protocol. We'll write it down when we do the server implementation.

Server

In the server implementation, we will not bother with any synchronous client synchronization options (history playback, prediction, etc., etc.). (I bent it - synchronous synchronization ... - author's note)
Those. The principle is very simple. We measure ping to the client and thus know the delay of each client. This allows us to remove the influence of customers with poor connectivity for the whole game and the implementation is simpler than the synchronous options. Yes, with this option it is possible that when the ping is very long, get a slide show. But at the same time everything will be processed correctly. And only clients with a big ping will have a slide show. In the load will get the need to store the current value of the ping for each client.

With a general description of the project, everything seems to be clear.

Part one. Step Two: Server architecture.

I just want to warn you that the article is to some extent research. Those. in the process of implementation and load testing of the server, its architecture can (and will) change under the influence of various circumstances ...

The general scheme is as follows:



In general, we do the classical scheme with a pool of threads. Our game is simple, there is no physics in it, and indeed there are few calculations on the server.

The general logic of the server is as follows.
1. We receive from the client an authorization request.
2. Randomly give the coordinates of the appearance of the tank on the map.
3. The client sends its coordinates to the server with a periodicity (During the movement more often).
4. When fired, the coordinates of the point from where it originated are sent to the server.
5. The server calculates the flight of the projectile and decides whether there is a hit or not.
6. Also while driving, the server detects obstacles. And it does not allow the tank to move in this direction.
7. At the request of the client, the server transmits the number of clients online.

Here, in general, and all that is intended.

In the future, if the habrovans are interested, this scheme can be expanded to a normal architecture with the separation of server parts on different machines.

In a couple of days there will be the next part in which we will develop an exchange protocol, we will implement a TCP server and make the first connection between the server and the client.

PS In fact, the topic is very extensive. Therefore, if there are any wishes on what to focus or there is something that I lost sight of when describing - well in the kament.
Your wishes and criticism will make the next part of the story more useful and constructive.

upd. At the request of habravchan opened Github for the project