Shadow’s Grove
Action adventure narrative game
Optimizations / Gameplay Programmer
A semester long group project in Unreal Engine 5.2.
I joined this team late into development, 2 semesters after they have started. This meant that I had to spend some time getting to know the codebase and existing issues, it was a hurdle at first, I remember scrolling through all the assets trying to find the right one, going through blueprint to blueprint to find a function. It was a valuable experience though, since it was the first time I worked on a big team (10+) and the first time I had to work with an existing project, instead of starting from scratch. There’s a lot more I did not documented here, it’ll be on a new page soon!
Starting out
For the semester, I was mainly focused on optimizing the game as it was running quite poorly through all the levels. I was also tasked with fixing many AI issues that plagued the game through the last semester. For optimizations, I spent a lot of time researching what I can tweak without changing the look of the game too much. Unreal really has some really insightful talks, but they are a little hard to find, I had to dig around on youtube for some of them.
For the first few weeks I looked through the level and profiled various locations with unreal insights and GPU profiler that were causing lag and found a few big reasons. One was the lights, there were many crazy lights around that were causing tons of lag. On the left are some screenshots of shadow depths tanking the FPS, profiled in unreal insights.
(A poor screenshot, but it shows average of 4 million Triangles to a high of 10million in the main zone.)
Nanite and Lumen
It was hard to find a good middle point between fulfilling the designers and artists vision and ensuring that the game could run well. Mid semester, we were having a lot of errors trying to bake the lighting, and the lighting artist was not pleased and what we would have to sacrifice. A professor recommended us trying Lumen instead, and at the same time I was trying to find ways to optimize the meshes as they were too high poly and had no LODs.
With nanite, I had to ensure that meshes converted correctly, and some discussion was had with the designers as they wanted to do certain things that aren’t compatible with nanite, but it still provided a solid ~10fps increase in general on low end hardware. Nanite is frequently misunderstood, and seen as a performance decrease, but it actually increases fps in situations where there are many high poly meshes, so it was a perfect fit for us. Lumen and Virtual shadow maps also work better with nanite enabled, so it was worth enabling all 3, allowing me to solve multiple issues at once. I did have to work with level designers to shift certain objects and lights around to minimize nanite overdraw and overlapping lights/shadows.
CVAR magic
Out of the box, Lumen was way too intensive for our game, so I did some digging. There were a few official tutorials and articles on what Engine Variables we can change, but I honestly could not find documentation for many of the CVARs I used. One big performance gain was from modifying the volumetric fog.
r.VolumetricFog.GridPixelSize
r.VolumetricFog.GridSizeZ
These allowed the game to run better, but I had to do lots of testing to ensure that it still looked good and had no visual artifacts. On my first pass the pixel size was too big, and you could see the degraded quality in certain areas.
More console commands like disabling foliage reflections and ensuring that World position offset objects were optimized for lumen were used and I also worked with level designers to shift certain objects and lights around to minimize nanite overdraw and overlapping lights/shadows. By final release, with all graphic settings on epic, I was able to hit 60fps on all main zones with a 3070 GPU, even after all set dressing was done. These are highly detailed areas with moving foliage,many shadow casting lights, fog and Niagara effects
Profiling Code
Finally, I had some time to look through all blueprints that the team were using. There were some that were also problematic after profiling. One in particular was a blueprint used to give objects a floating animation, moving it up and down slowly. It was running every tick and on over 300 objects, with the main time spent on the blueprint moving components.
I rewrote the blueprint to not tick every frame, and to use a different method, not using expensive sin calculations and “set actor location”. I had to test different versions of my rewrite to ensure it looked the same as before, but it lowered the game thread time by ~3ms when I was done. If I had more time, I would have rewritten more blueprints in native c++ to save even more time, but that was of a lower priority.
My overall experience
It was pretty hard at first to catch up with everyone else in the team, since they have been together for a semester or two already. I’m glad that they were all very welcoming and made it a joy to work with. I spent a long time researching what are the best practices for optimizing unreal games, but I did not expect so much of my time to just be rebuilding the scene, checking to see if I broke anything, profiling the same area again and again. If I had more time, I’ll probably have tried out the automatic build system for me to quickly build on my home PC. I also spent a crazy amount of hours just trying to get unreal to work right, I wanted to use the source build of Unreal so that I can make a test build for the game, but there were so many different errors that took a long time to fix. Although I sound frustrated, I actually really enjoyed doing this, and hope that I have the chance to do something similar in the future.