What is the name of the architecture of this game?

Question

IT education

Good afternoon.
There is such a multiplayer online game: travian.ru And I just can't understand how the architecture of such games works. It cannot be called step-by-step, but it is not a realtime application either. Some sort of event-driven architecture.
Players initiate events such as constructing a building or sending troops. Each event has its own duration. As I understand it, the server calculates each task every tick and informs all users "interested in it" when the final is reached. But how is it implemented programmatically?
Does the server calculate all the objects in the game world several times per second (buildings under construction, resources, troops, etc.)? And what does it even look like?
I used to do web development, but I want to try my hand at game development. And I liked games with a similar architecture, but actually what kind of architecture I don’t fully understand. On the Internet, I did not find anything sensible, because I do not fully understand what to look for. Those books that I found talk more about 3D graphics and related calculations. And about such client-server applications, not a word.
Prompt any resources, books, articles that will help you deal with THIS type of architecture. I don't even know what to look for. I will be very grateful.

Answer 1

In my opinion, the solution "on the forehead" is obvious. The author of the question is stressed by requests from the client, but it seems that he misinterprets their essence. The client should not tell the server that "the construction of the building is over, write it down." He can announce the beginning of construction and ask: “Has the construction been completed?”. The construction is completed without the participation of the client.
The server stores both general data about the game world (player parameters, their buildings, objects, units, resource growth, etc.) and the event queue. Most of the additions of events to the queue are initiated by a request from the player: build / upgrade a building, train a unit, send troops, etc. These are the actions that the player must perform while online. It is possible that some events will be initiated by the server as well.
An event in the queue is a description of the event, as well as a timestamp at which the event should occur (for example, a building is under construction for 2 hours, which means that the timestamp will be recorded as a time two hours after the request for construction was sent).
In an endless loop, the server does the following: selects all events whose end time has already come, and processes them: changes the levels / coordinates of objects, recalculates characteristics, changes flags, removes the event from the queue.
An hourly recalculation of the funds of all players, for example, can be implemented by a separate event out of turn, which will be called by a timer, or by the same event, the completion of which will initiate a similar event that ends in an hour.
Everything is done on the server. The client can only: get the information available to him at the current moment, get information about the completion time of all events related to him, send a request to add an event to the queue.

Answer 2

Well, as an option. When the user enters the game, he receives all the data about the construction of buildings.
For example:
the castle will be built in 20 minutes.
troops will be recruited in 10 minutes.
resources will appear in 15 minutes.
This time passes and all this appears on the client.
But sometimes time on the client goes slower than on the server.
A more resource-intensive and reliable option is to send requests to the server every N seconds.
The player sends a request and if something is built, it is displayed on the client.

Answer 3

I advise you to skip Making Isometric Social Real-Time Games with HTML5... - most of it is about graphics, but there is also about this architecture towards the end.

Answer 4

For each event, a separate entry is created in the database with a timestamp. Then, upon initialization, we read and update the data from the client.
The load on the server is minimal since the events are discrete.

Answer 5

I used to work with the same railorz.com/ engine. True, apparently, it has not been supported for a long time. The game is this barbariansgame.com (I also don't know if it works)
The principle is similar - the whole game hangs on the client's backbone. On an event, it sends a request to the server, and on the server everything is done in the background. Also, every few hundred milliseconds there is a synchronization with the server.