On how our game works
Good Lords, Fair Ladies!
Today we are here to talk to you about what's under the hood of our game.
At times, community members ask things like:
"I've lowered the graphics settings and the performance is almost the same! How come?" or "I have an RTX 3080 and DiNaO is only giving me 40 fps! Care to explain, why?". These questions are usually followed (quite rightly) by the requests addressed to the developers. You ask us to figure out the architectural issues of the game and fix the obvious defects.
Let us make it clear and tell you how Diplomacy is Not an Option works, and finally give you some answers.
[h2]Let's start with the graphics[/h2]
As you may easily notice, visually our game is far from... being high-detailed. It can be explained by the stylistics (low-poly design and the scale of combat actions in the game limit graphical solutions).
But to be honest, we chose the style taking into account the capabilities of the team (a reminder: our team is pretty much small). On the one hand, this is an unconditional win. At the concept art stage, artists don't need to draw anything complicated. The processing of the large number of objects on the screen doesn't crucially influent the game's performance. (What is called "bottleneck" effect) On the other hand - this solution becomes an Achilles' heel. That is correct, reducing graphics settings can help some potato pcs, but this is more likely a special case, for the majority of hardware configs changing the settings has no effect on FPS rate.
It is worth mentioning the fog of war, or rather, its refresh rate. If Diplomacy is Not an Option runs slowly, you should try to reduce this setting. It is quite possible that it will give a noticeable performance boost for you. (As a consequence, visually the game will not change for the better - the borders of the fog of war will be dissipated step by step, without proper smoothness. Those of you who remember the strategies of the 90s-early 2000s, understand the difference).
"Why does DiNaO runs slowly then?" - you may ask and this is another question to answer. The main resources that our game consumes (as well as many strategies, citybuilders, simulators, and games with a large number of calculations) - come to the work of the CPU. You have understood everything correctly, CPU work is the very "bottleneck" of DiNaO.
To summarize, we can say the following. If you have a powerful video card, but an old processor with just a few cores, FPS will be low. But even if your video card is not top-notch , having a modern processor will give you high FPS rate.
[previewyoutube][/previewyoutube]
[h2]How the power and number of threads of your processor affects the game[/h2]
For many people, it's no secret that DiNaO is made on Unity. In particular, we use DOTS (Data Oriented Technology Stack), and the main features of the Stack are Entities (Essentially a kernel built on the ECS architectural pattern), Job System (Secure Multithreading), and Burst Compiler (Pure Magic. A compiler that requires code to be written in a certain style, which imposes its own limitations, but still allows ILPP to turn IL/.NET code into high-performance native code (in other words, for each processor architecture, it builds exactly that version of code that will maximize performance on that particular hardware architecture). Thanks to all the above, we can optimize all the capacities of modern multithreaded processors. As a result, we can make DNO exactly as we intended it to be!
"And what exactly did you have in mind?" - you might ask. Here comes the answer. We wanted to create a game with crowds of warriors on the map. With the flight of each projectile processed by the game engine. With a complex system of economy and a realistic model of disease spread. Well, and with wild animals change their behavior depending on circumstances. All this (Another reminder about the number of entities on the screen) requires a lot of calculations from the processor. Even despite all the wonderful tools we have, a direct approach to implementing all these features would still not give us a satisfying performance. And would not allow us to fulfill all our ambitions.
In particular, each warrior in the game is a full-fledged, independent entity. Thanks to this, the player can control his behavior at any time, just like in old-school strategy games! (And even civilians that players don't control are also separately calculated by the game). We wanted the battles between tens of thousands of people in Diplomacy is Not an Option to not be a trick that strategy game creators sometimes use. The essence of the trick is that it is actually squads that fight, and it is the squad, not the individual warrior, that is the minimal unit in the game. To make our design work, and work convincingly, we wrote many of our own software solutions based on the basic tools that Unity provides. For example, our navigation system combines many approaches such as A* and Flow Field. We made navigation layered and as cacheable as possible so that all the many in-game entities can "travel" across the map. (At the same time, the processing of their movement must still not burn players' computers). Combining these approaches allowed us to have those very crowds of enemies moving autonomously on the map, maximizing the re-use of "paths" already traveled by other entities. For example, if one enemy from an attacking wave has already traveled a route from a certain area A to area B, rest assured that the other warriors (including those from subsequent attacking waves) won't try to re-find the path. They will reuse the one they already had unless the state of the map changes. (A new obstacle appears or what was an obstacle is destroyed). But even if the route is changed, only a small part of the way is "discarded", which again allows us to save precious hardware resources. We've written our own physics in the game, maximally optimized for strategy, with the main simulation in 2D space (XZ plane of the ground) with the "connection" of the third dimension if necessary ( projectiles, explosions, thrown enemies). And we have listed only the most significant of the solutions applied. In fact, there are many more.
"But since you've got everything so cool optimized, why is the CPU still sucking up a ton of resources?" - you may ask again. That's a very good question. The answer lies on the surface: even with all our tricks and techniques, we are not wizards. If we were wizards, we would have a lot more stuff in our game ;) Anyways, hardware resources are not infinite, and we are literally pushed to the limit of performance. Even considering the maximum usage of each core of your processor, certain algorithms have certain boundaries. Not everything can be done "simultaneously", on all CPU threads. In the image below - each green block is some kind of work that our game is doing on different threads. It could be finding the nearest targets for the warriors or finding the nearest tree for the forester, it could be the movement of an animal on the map or the production of stone at the mine. As you can see, almost every CPU thread on our test machine is actively used.
See the blocks highlighted in red? There is a lot of empty space above and below them, unoccupied by any work. This is a clear example of a situation when not everything can be processed simultaneously. Some calculations in the game rely on previous work and the processor must wait for this work to finish before making a specific calculation. Similarly, if another part of the game relies on that particular calculation - it has to "wait for the right moment" as well. The image above clearly shows how "densely" we are using each thread of your CPU, while also illustrating why CPU usage is never at 100% mark. Each CPU core cannot be fully loaded every second you spend in our game. After all, certain tasks require calculations performed by other cores. In addition, it becomes obvious: if a game has such a large number of calculations scattered across all CPU threads - their number directly affects how many tasks can be solved per one frame. The more of them, the faster it will happen (and vice versa), respectively, the higher the game's frame rate will be (and vice versa).
"Ok, now I see why many people reduce game performance, but what does this have to do with the map size? Why not make super large maps, say 9999x9999 cells?". A fair question. Once again, it all comes down to CPU resources. Let's skip the obvious point that a larger map takes longer to load - to calculate the location of resource sources, to analyze all enclosed areas, to define environment objects, etc. Until recently (before the 0.9.94 update) the maximum map size was 200x200 cells, but we've figured out (once again) how to optimize the processing so that players could have a larger map at their disposal (we increased the maximum size more than twice! (by 125%), up to 300x300 cells) and did it without any noticeable changes in gameplay. As mentioned earlier, the game features our own navigation system responsible for the movement of game entities through the map. In particular, besides the obvious task of finding a way from point A to point B, this system deals with a whole bunch of other tasks, one of which is checking if the path search is necessary at all. For example, in the case when the endpoint is in direct line of sight and you can just move straight to it. It would seem to be an obvious solution. If you don't need to search for a path and can just go straight to the goal, you don't need complex calculations. This should make the game run faster for sure! However, in reality, it's not that simple. This feature (the direct path) is made for aesthetic and gameplay purposes in the first place. From a technical point of view, (again, do not forget that we are talking about TENS of thousands) this functionality - on the contrary, requires a lot of computing. The processor is not a human brain, it cannot determine at the snap of its fingers whether the path is free or not, it relies on pure data (it doesn't have eyes, it can't just see the target). And the data must be processed one way or another. The algorithm itself is very simple, the map is divided into cells, and each cell is either free or blocked. We need to construct a line between the entity and its goal and check every cell on the path of the drawn line until the calculation "gets" to the end point of the route (or finds an obstacle, which means that there is no direct path). This is a very simplified description of the algorithm (We don't just check cells along the line, we check them on several levels, using various tricks to reduce the resources required for the calculation. There are many other calculations involved in this process). But in general, the point is clear to you. For each entity in the game, you need to check a lot of data at a certain time interval (sometimes several times per second). You have probably already guessed how all this relates to the size of the map. As the size of the map increases, so does the number of cells between points A and B. The further the points are apart, the harder the calculations become. And when it comes to our favorite point about tens of thousands of troops (and not only troops), the amount of resources required from the processor starts to grow by leaps and bounds to make it all work!
That's roughly how Diplomacy is Not an Option is set up.
Thank you, and see you soon!
Yours, the Door 407 dev team
