Dear Tankers,
Welcome to our 29th Development Status. You can see what we have been working on for the last two weeks.
We’ve been asked recently by a member of our community discord, if we could explain what do we do to optimize our game to make it possible to run smoothly on regular PCs. Today we present some of the techniques that we use to achieve that.
Level of detail
Most 3D models in our game have a LOD (level of detail) version. Each LOD version is shown depending on the distance from the player’s perspective. The main difference in LODs is the number of triangles and vertices in the model. This optimization technique is applied in 3D models of environment, vehicles, characters, weapons. A model seen from far away does not need the same amount of detail as a character seen from close. Each model has got a so-called LOD group.
On the left, there is the most detailed version of the character. As you can see, its topology is the most complex one. On the right, there is a simple version of the model which will be seen from far away. Fewer triangles being rendered on your computer at the same time means better performance.
In some cases, the last LOD (farthest from a player) is just a 2D image of a 3D model. From far away you can’t tell the difference but the difference for the GPU is very noticeable. A 2D image has got 6 triangles, meanwhile for example a whole tree can have 15k triangles. This 2D image is what is called an impostor or billboard.
Another trick that we use is that we do not render shadows for objects that are far away from the player.
Bullet pool / VFX pool
To optimize the performance of our game we are developing an object pooling system. During gameplay, each object dynamically spawned in game, like bullets, effects, etc. is stored in a dedicated pool. Each time we want an object to appear on the scene, instead of creating it, we take it from the pool of previously created inactive objects and activate them with proper values, then instead of destroying we deactivate it and restore it back to the given pool. This way of reusing previously created objects helps to relieve the processing power of the CPU.
AI
For AI we split it into separated logics, so it can combine them as we want, but we save Ram and CPU this way. This also allows us to switch between commands, so it saves CPU as we have only the current one and previous command (only if needed) at a given time on all squads. We also made that finding big obstacles is only made by the squad leader, and he sends that info to others in his squad. A similar thing is with finding enemies, Leader checks if any of the units have an enemy, if he has it, he checks whether this enemy is still within range, whether the unit still has a weapon for that opponent, etc.
- If there is at least one such unit, then it should be searched for a new enemy, only then the leader looks for potential enemies
- If he has a list of potential enemies, on its basis, the unit that needs a new opponent selects the enemy accordingly, checking whether this enemy meets these requirements above (I have a weapon on him, he is within range)
We use our custom pathfinding that bases on the system that is used also by the game Easy Red 2, made by our friend Marco. It is more optimal, dynamic, and easier to use than Unity NavMesh, as we only have to set which collision layers are obstacles, and AI will find them.
For Infantry
Now code of AI infantry of player that follows tank is executed on this player client side, before that all AI was executed on the host side. Infantry gets logic of taking covers only when they are got near them, thanks to mentioned before commands system, so another CPU save.
For Tanks/Vehicles
In the case of Vehicles, we rewrite the way of syncing them in multiplayer. Now they send/receives only info about their movement as position and rotation, but we already had one idea of how to make it even more optimal. And all other calculations are made on the client side.
For Cannon and Turret, we send only info about rotation on one axis (x and y, respectively) and only for a weapon that is currently used.
BattleManager
We use BattleManager to control the course of the battle, it collects references to all objectives, events, and AI spawners in a given battle scenario, in the form of so-called Dictionaries. This allows us to use one of PhotonView instead of having a separate one for each of these objects. It also deals with their synchronization, as well as turning on / off further objects under a given scenario.
Animations
Also in the last two weeks, we’ve prepared some hand order animations using motion capture technology.
The list of hand order animations:
- Attention
- Unite
- Stop
- Lie down
- Move left/right/forward/back
- Follow this way
- Stop/Start engine
- Move slow
- Move back
Thank you and have a good one!
DeGenerals
