So, there have been quite a few performance patches that have gone out over the past few weeks and the gains have been really nice!
As I played tonight I was seeing a fairly consistent frame rate of 30-45 fps, on Ultra. This would still dip down on some of the levels, or when lots of payers were in the server [~12 including the AI].
Even still, there is always room for improvement towards the goal of 12 players at 60 fps!
To start on this pass of optimization, I used Giant Leap and 6 AI bots, played in single player, as my starting point. After doing many play tests, I noticed two big items still sucking up a lot of the CPU at a consistent level. Highest offender was Camera.Draw, clocking in at a beefy 20 ms every frame. Next up, that pesky Mech.Movement, eating up another 20 ms per frame. Combined, these items were hogging 40 ms of frame time, when my goal is for everything to be under 16 ms total! Lots of room for improvement!
Starting with the obvious, the camera, I took note of a few key items. Most importantly, the total number of draw calls and the number of batched draw calls. I was currently running 8500 draw calls and 2100 batched draw calls! This number should be MUCH lower. I know some devs out there are staring, but I can explain the high numbers! MAV is draw call heavy already due to how players can build their own mech. Any custom robot game out there has to find creative ways of reducing draw calls and most of them do it by reducing customization. Not an option here, so I turned to the level its self.
By toggling off lots and lots of geo rendering, I was able to prove without a doubt that the draw calls were the issue affecting the camera frame time and not something else. In doing this, I accidentally solved my next mystery as well!
The fact that Mech.Movement was still popping up as a hot spot was intriguing, as all the optimizations up to this point have been very focused on this issue already. Seeing it pop up again meant I had missed something. In my previous tests, I was testing on Blind Alley, a level with not much in the way of anything. When I turned off the all the objects holding the level geo to test the camera, Mech.Movements performance ALSO increased dramatically! This was because they held all the static colliders for the movement system, helping me narrow the performance issue down to the level collision geo!
Good news, this is VERY fixable!
Bad news, it’s tedious and time consuming, as I am basically rebuilding the levels.
However, with that said, I have already reduced the number of draw calls by over 50% and have started to optimize the level collision as well. I am having to be very careful so as to ensure the level collision stays 1 to 1 with the visuals of the level. Last thing anyone wants is a game full of invisible edges!
The next level up for optimization will be Grassy Creek, as it can be a big CPU hog as well since it has such long visual draw distances.
That is all for this week!
Comments 2
Toldja you’d need to rebuild the levels. Or if I didn’t tell you, I thought it very, very hard at you.
Single skin level except for things you need to drive under.
I’d gladly do the tedious stuff for you, btw. But of course, you must do all on your own, or via paid contractors. Yep.
Author
It’s a bit more complicated than that, as with most things in game development.
Each level had very different, very specific performance issues, that needed to be addressed in a very specific way. This was only discover-able through detailed performance logs.
Just ‘rebuilding’ the level as a ‘single skin’ [never heard this term before] would not have actually addressed these issues.