There are a couple schools of thought on optimization. With any rule in programming, use at your own risk, for your own situation. The one I generally follow is make it work correctly now, optimize it later. Optimizing is time consuming and it locks in an implementation. If there are design changes to be made, it can make it that much harder to change and thus put resistance on the designer to making the change. If it’s loose at first, it can be changed, or thrown out with less attachment.

This doesn’t mean don’t care about any performance, still follow best practices upfront. Two big area’s in UE4 are how meshes are instanced and how much processing is done in a tick. I won’t go into those now, this post is specifically on long load times. I see it on AnswerHub a lot, and I’ve run into it myself. In my next UE4 project I will probably amend my philosophy and spend more attention up front to some of the load times, knowing now how out of control it can get.

Luckily, UE4 provides plenty of ways to improve load times.

The problem: I double click in Steam for my game to play. This is after Steam itself took a long time to make sure it was updated. A little while goes by and then my startup movies play. I could have lived with the time before the movies started. But after the last one, the screen is just black, for a long time. On my desktop it was around 1 minute, longer on my laptop.

It’s not good when you wonder if your game is going to load or if it has crashed. I wasn’t sure where to begin so just kept putting the task off. Last week I went to the Austin Game Convention and showed Lemons Must Die to a few people. I brought it by the Epic booth and at the end asked Zac Parrish if he had any thoughts on it. He thought it was probably loading too many assets and that was the problem that they saw with a lot of Indie Studio’s. He went on to say that any reference is completely loaded, and that casting is a reference.

Between my Game Instance and Player controller basically the entire game was referenced and loaded. Interfaces were recommended as a way to fix it, but he had a kind of sad face when he said it.

I have another rule with optimizing. I only optimize what I have actually tested, not by my intuition. Basically, need to run a profiler or actual tests before and after I optimize something. Intuition can waste a lot of time optimizing things that don’t give that much gain. I broke my rule here.

I went through my main game classes: GameInstance, GameState, PlayerCharacter, PlayerController, BaseProjectile, and all the UI Widgets, and removed every single cast replacing it with an Interface Message. I kept it simple and just made a Blueprint Interface for each class. It took about 5 hours to go through everything, and in the middle of it I was worried that it would never end.

Just doing that brought my load time, between the last startup movie and the Menu opening playable from over 1 minute to less than 2 seconds. The reason that this worked so dramatically for my game is that Between the PlayerController and the GameInstance classes virtually everything in the game was referenced via casting, but they didn’t have hard references. The GameInstance has Dictionaries ( Maps ) with many classes and associated id’s but that doesn’t seem to cause an issue, only references which casts are.

Here is a link describing how to hunt down load time problems through profiling, which is the analytical way to go about it: debugging-and-optimizing-memory