How we are debugging in a browser samopisny ECS on the game server

I want to share the mechanisms that we use on the server to visually debug game logic and how to change the states of a match in real time.

In previous articles, they described in detail (the list immediately under the cut) how ECS is arranged in our new project in development and how they chose ready-made solutions. One such solution was Entitas . He did not suit us primarily due to the lack of storage of the history of states, but I liked the fact that in Unity you can visually and visually see all the statistics on the use of entities, components, the system of pools, the performance of each system, etc.
')
This inspired us to create our own tools on the game server, to see what happens in the match with the players, how they play, how the system performs as a whole. On the client, we also have similar practices for visual debugging of the game, but the tools in the client are slightly simpler compared to what we did on the server.



The promised list of all published articles on the project:

1. " As we swung at the mobile fast paced shooter: technologies and approaches ."
2. " How and why we wrote our ECS ."
3. " As we wrote the network code of mobile PvP shooter: player synchronization on the client ."
4. " Client-server interaction in the new mobile PvP-shooter and game server device: problems and solutions ."

Now to the point of this article. To begin with, we wrote a small web server that gave out some API. The server itself simply opens the socket port and listens to http requests on this port.


Then we register several special handlers for each request.
One of them is a handler for viewing all matches in the game. We have a special class that controls the lifetime of all matches.




Clicking on the link with the match, go to the control menu. Here it becomes much more interesting.

Each match on the Debug-assembly of the server gives out full data about itself. Including the GameState we wrote about . Let me remind you that this is essentially the state of the whole match, including static and dynamic data. Having this data, we can display various information about the match in html. We can also directly change this data, but this will be a little later.

The first link leads to the standard match log:



In it, we display the main useful data on connections, the amount of data transmitted, the main life cycles of characters and other logs.

The second link GameViewer leads to a real visual representation of the match:



The generator, which creates us the ECS code for data packing, also creates additional code for representing the data in json. This makes it quite easy to read the match structure from json and render it to render using the three.js library in WebGL.



Almost every entity that possesses the logic of movement in our physical world has a component Transform. To see a list of all components, follow the link WorldState Table Editor.



In the dropdown menu at the top, you can select different types of components and see their current status. Thus, the figure above shows all the transformations in the game. The most interesting thing: if you change the values ​​of the transformation in this editor, then the player or another game entity will teleport sharply to the desired point (sometimes we have fun on playtests).

Changing data in a real match when editing an html table occurs because we pull a special link to this table, which contains the table name, the field and the new data:

 function handle_edit (id, table_name, field_name, value) { var data = table_name + "\n" + field_name + "\n" + id + "\n" + value; ajax("POST", tableset_name + "/edit/", data); } 

On the part of the game server, a subscription to the necessary URL, unique to the table, takes place thanks to the generated code:

 public static void RegisterEditorHandlers(Action<string, Func<string, string, string>> addHandler, string path, Func<TableSet> ts) { addHandler(path + "/data/", (p, b) => EditorPackJson(ts())); addHandler(path + "/edit/", (p, b) => EditorUpdate(ts(), b)); addHandler(path + "/ins/", (p, b) => EditorInsert(ts(), b)); addHandler(path + "/del/", (p, b) => EditorDelete(ts(), b)); addHandler(path + "/create/", (p, b) => EditorCreateEntity(ts(), b)); } 

Another useful feature of the visual editor allows us to monitor the fullness of the player input buffer. As follows from the previous articles of the cycle, it is necessary to maintain a comfortable game for customers so that the game does not twitch and the world does not lag.



The vertical axis of the graph is the number of player inputs currently available in the server's input buffer. Ideally, this number should not be more or less than 1. But due to the instability of the network and the constant adjustment of customers to these criteria, the schedule usually oscillates in the immediate vicinity of this mark. If the input schedule for the player goes down sharply, we understand that the client most likely lost the connection. If he falls down to a rather large value and then recovers abruptly, this means that the client is experiencing serious problems with the stability of the connection.

*****

The features of our match editor on the game server allow you to effectively debug network and game moments and monitor matches in real time. But on the sale, these functions are disabled, as they create a significant load on the server and the garbage collector. It should be noted that the system was written in a very short time, thanks to the already existing ECS ​​code generator. Yes, the server is not written according to all the rules of modern web-standards, but it helps us a lot in everyday work and debugging the system. He also gradually evolves, acquiring new opportunities. When there are enough of them - we will return to this topic.