Being an optimist, I decided in advance that everyone would like the game and that a lot of people would want to play it. Within the framework of one machine, you can do optimizations for a long time, you can endlessly upgrade hardware, you can rewrite an application in pure C with assembler inserts for micro-optimizations, but all the same, sooner or later, you will hit the ceiling. It was decided to have an architecture that allows to have many low-power servers, each of which has an online ceiling in the region of 200-300 people.

So that there is no bottleneck in the form of a network to any one global proxy, as well as to ensure minimum ping, it was decided on the site side to choose one specific server from the pool of servers, with minimal online, assign it to the user’s session and further ensure browser interaction user directly with the game server.

At the moment, when choosing a server from the pool, simple logic is used – a server with a minimum online is taken. In the future, it is also planned to add logic for accounting for the location of the client and server.

4) Low entry threshold and quick start

More than once I have seen games that simply must have the most terrible conversion due to the congestion of the interface or the need to enter a million fields in order to enter the game.

I wanted to provide one-click login from the main page, i.e. no mandatory registration. In the same Sliterio, a similar approach is used, with one small difference – they still want the player to enter a nickname.