[h2]Dear Tankers,[/h2]
Welcome to our
64th Development Status.
[previewyoutube][/previewyoutube]
[h3]Long time no see[/h3]
It's been a while since we've been heard from, we're hard at work optimising the game in everything from code, animations, missions, tanks or weapons. We've been working on everything to reduce RAM and increase FPS. And what specifically have we done? Read more about it below.
[h3]Ballistics - Behind Armor Effects and X-Ray progress[/h3]
We’ve been also working on adding the long awaited X-Ray feature, our current progress is adding dedicated armor for few tanks and adding few new ballistics features:
- Spalling (when penetrating vehicle armor)
- Shrapnels (every explosion)
- APHE effect (explosion after triggering HE fuse and reaching designated meter offset)
- HEAT effect (as a cone after first fuse trigger)
- Effective armor calculation - based on attack angle
- Effective projectile armor penetration - also based on attack angle
[h3]AI Infantry anti-tank behaviour[/h3]
Now that we've added periscopes (not just for the Tiger), we've extended the damage system to the periscopes. Now enemy soldiers with AT rifles will prioritise them when firing at an armoured vehicle.
This is also a part of the game where, later on in development, we want to add vulnerabilities or points on vehicles where a particular soldier or weapon will do the most damage. So, for example, a light AT gun or rifle will not just shoot at the centre of the tank, but try to see if their weapon can damage the main armour, if not then try to see if they can damage tracks, wheels, etc.
If the distance is too great, or the available target is too hard to hit, the unit should remain silent if not attacked - but this is something to be added later.
[h3]Playtests status[/h3]
The main target of our last few months was to implement feedback from the demo, optimize the game and start a small playtest of a new mission. This is taking forever as our new mission was very heavy on performance and required a lot of work - that is still not yet finished.
Right now grab a small peak from our internal playtesting of the map, as we’re trying to get a stable and acceptable FPS and RAM usage.
Right now the FPS is getting where we wanted it to be, but RAM usage is still above 13-14 GB at peak on that mission. We have to lower it at least to 11-10 to even think about sending it to a playtests so still takes time.
[h3]PzKpfw V Panther Ausf. A[/h3]
During the last development status, some of you noticed that the Panther tank can be spotted in the video. We added it to the game when we were working on the optimisation, but there wasn't much opportunity to 'officially' introduce it. So we are doing so now.
[h3]Desync fixes[/h3]
We've been working on a problem that made the game completely unplayable at one point - the desynchronisation of the game. This was caused by large lags, for example when spawning many units at once, especially vehicles, and caused the game to lose at least a few dozen frames. When frames were lost, the synchronised OnChange property notifications were lost. Clients would not respond to the property change and desync was imminent.
We've just finished rewriting much of the project to take a different approach, optimising what and how we load during unit spawn. The desync is gone, but the spawn time can be further reduced and the lags spread out - still to be done.
[h3]CPU - GPU Optimization[/h3]
The biggest optimisation problem we've encountered so far in Tank Squad was related to the way objects were sent to RAM and VRAM. Previously, each texture in our scene, was sent as an instance, but was sent independently. That is, each unique material was treated as a separate object that had to be mapped to the graphics card's memory.
Each graphics card has a limited capacity to process unique textures simultaneously, no matter how much VRAM it has. If we exceed the parallel computing capacity of the graphics card, the system starts to compensate for this problem by creating special paging files in which the CPU will hold textures in RAM ready to be sent to the graphics card. This generates a huge consumption of system memory. This problem already existed in our old demo, which you still have the opportunity to play.
Our solution was to create texture sets that are sent in packets to the graphics card, so that we can store them on VRAM, which the graphics card can access much faster. The difference is that the GPU treats the texture packets as one composite texture. This managed to halve the system memory usage, and resulted in a much more stable Unity experience.
This solution required us to make fundamental changes to the way objects are rendered, which was a laborious and lengthy process, but it has had the intended effect.
At the moment we are still in the process of testing the changes we have made. Our aim is to achieve optimal performance on computers with 16GB of RAM.
Thank you and have a good one!
DeGenerals
