The game’s framerate has been an issue for several years now. Each new character added to the game had a negative impact on the framerate, so for a long time, I was hesitant to add new characters to the game. Now that I’ve shifted my focus to fully populating the school, a lot of characters are being dropped into the game all at once, so we’re beginning to see the framerate dipping lower. As a result, improving the game’s performance has shot upward in priority – and that’s partially what this new update is about!
You’re probably wondering what’s causing the low framerate. Is it the game’s code? Is it the Unity engine? What’s the big deal? There isn’t one answer, since there isn’t one primary problem; there are a bunch of tiny problems which all need to be addressed individually.
1 divided by 60 is .016667. In order for a game to run at 60 frames per second, each frame must be processed in 16.667 milliseconds or less. If we check the Unity Profiler, we can see how many milliseconds it takes for the game to perform individual operations:
- Rendering – 28.05 ms
- Physics – 24.94 ms
- Animation – 16.16 ms
- Pathfinding – 8.11 ms
- User Interface – 3.72
- Student Behavior Scripts – 2.76 ms
(These numbers are inflated because running the Profiler is taxing on the CPU, but this is a general overview of what’s going on.)
As we can see, the scripts governing student behavior are not a significant problem. The real problems here are rendering, physics, animation, and pathfinding. (The pathfinding plugin is actually very efficient, but causing a character to move is a very expensive operation, since it involves physics simulations and collision checks. So, you can really combine “Physics” and “Pathfinding” into the same category.)
Each new student added to the game is another object that involves rendering, animation, physics, etc. That’s why each new student added to the game was impacting the framerate. The scripts are having a negligible effect on the framerate. The FPS isn’t actually dropping because of scripts; it’s dropping because of everything else aside from the scripts.
Anyway, the solution here is to figure out what is causing the game to spend a whopping 28 milliseconds on rendering 3D models, how to reduce the impact of running physics simulations, how to reduce collision checks, and how to make animations way less expensive. None of these things are happening for one reason; they’re all happening for different reasons, and each will require a different investigation and solution.
Over the past few months, I’ve been receiving extremely valuable help from a programming volunteer. Yesterday, we made a breakthrough in making the game render 3D models much faster. If I told you “We fixed the problems that prevented us from switching to DX11, enabling GPU Instancing, and activating Graphics Jobs,” it would probably sound like I’m speaking an alien language, so I’ll put it this way: we got the framerate to go up! In places where the framerate was previously 15 FPS, it’s now 20 FPS! That’s a pretty significant jump! (20 FPS is still beneath the threshold of what’s acceptable in a modern-day title, but the important part is that we’re making forward progress! Woohoo!)
In short, I’m letting you know that we’re finally entering the stage of the game’s development where we investigate and fix the game’s performance issues, and that you should be able to notice a difference if you compare the current build to the previous one. Further optimizations and improvements are likely to arrive in the coming weeks and months!
In addition to the performance optimization described above, this new build also contains some bug fixes and general improvements. To see a list of everything that is new or different in the latest build, scroll down beneath this video by Kleiner Pixel, who created an amazing Yandere-themed cosplay makeup tutorial!
