Game Optimisation
Technical Summary:
A glaring issue that I discovered during the development process of this game was a huge tank in FPS seconds after you start the game. This was an entirely accidental discovery, found after leaving the game running before having my attention took away and then returning seconds later. This was a clear issue that had been presented to me, and one that I knew would need tackling, but how to tackle it was something I needed to learn.
Doing some research into optimisation, my first test was optimising through reducing textures and seeing how that would impact performance. I know that I stook to a strict process of having textures at a maximum of 1024*1024, but reducing it down for the assets that don't require large texture sizes, like the iron gear or computer chip. However, I couldn't reliably know if the rest of the team had been following a similar rule as myself, which they hadn't. The easiest way for me to check all my textures was to use a filter of Textures, open them in the mass editor matrix and assign them a new resolution, primarily focusing on those above 1024. Although I modified the textures, this was however not the issue.
One way of figuring out the issue with the game was using Unreal Insights, a built in recording system allowing for the current playthrough to be measured and analysed to help diagnose a problem. I created the trace through the Standalone game option, and simply played through the game. The trace broke down the results into a long graph that you could follow and showed all the processes that were occurring throughout the playthrough. It became very apparent what they issue was when checking the individual frame times which should have typically been at 6-7ms, but could sometimes last for 100ms which doesn't seem like a big amount, but was not good. After discovering that the real culprit behind this was the use of the Event Tick event. Several significant components used the tick event such as the Objective Markers and the Objective system which was heavily impacting the game performance as well as the environment particles. To fix the use of event tick, I essentially created my own version which would be called 0.2 seconds after the code had been ran to create an infinite loop, although not a perfect solution, it ensured that performance was kept at a good level and made the game a lot more stable. This worked really well for the overall gameplay, but there was often frame drops during loading, which was to be expected and is mostly unnoticeable.
Another significant factor to performance was the particles. Niagara Particles has the option to be rendered through the GPU and CPU which can have some benefits for each. As a default, Niagara is rendered through the CPU, which for us having atmospheric particles could hit the frames significantly. I changed the Sim Target to be the GPU rather than the CPU which was much better for performance keeping us with a sturdy 140+ fps. Something that I did notice with using the GPU renderer was that you can see particles disappear depending on the angle you view them from, but this issue was resolved through changing the bounds which let them be viewed all the time.
Reflection:
I never really intended to look into optimising the game to any extent when we started the project, but with FPS issues like we had, it felt imperative to fix the errors and help the game run much smoother. In the future, I hope to be more mindful of the issues that Event Tick can create in the future, and the different ways I can combat it. Likewise, I will also be mindful of the use of a fixed GPU simulation rather than keeping it at the CPU and impacting performance. I think these are useful skills to have developed, whether it be for a future solo project or a group project.