I have a to-do list for every single one of my projects. Usually these are formatted from, “Things I need to do immediately” to, “Things that would be nice to have eventually”. One of the bullet points that has been between these two polar opposites for quite some time is optimization.
When you start a project where you’re unsure of its size, it’s difficult to consider optimization. I don’t like to even think about such things until I’m confident that I have fun core mechanics. Why waste time on things like optimization when the idea might not pan out? Succeed fast or fail fast!
You might recognize the above room from one of the older builds. The room was a maze with reflective surfaces that projected the space skybox onto every surface. There were a few items floating around the room to show the room’s boundaries in addition to creating a pretty awesome effect.
A few versions ago, I noticed a distinct drop in frame rate whenever the player’s vision was merely looking in the general direction of this particular room. So I started play mode in Unity, setup my VR headset, and opened the Steam frame rate monitoring control panel.
I began turning entire rooms on/off and monitoring frame rates to see which had the largest impact on frames per second. Removing the Dark Space Room did help, but in continuing this process I learned that the overall size of the level was the primary cause of my performance issues. This was unfortunate as I had always envisioned DGHITF as being a single, vast level that players would need to explore via multiple playthroughs. Players would find secrets and new paths that others might not even stumble upon. These findings squashed that idea.
A revelation like this would ordinarily be pretty disheartening, but I already had plans to completely re-design the level layout (which I will be discussing in my next blog post). I’m currently working on decreasing the size of the level’s footprints. Though the footprint was only one cause of the low FPS. Since the game takes place in space, I have low gravity for hundreds of items in the game that can all be moving at once. Drag is very low and inertia is higher than what we’re used to on Earth. This means once items start moving, they usually don’t stop moving. This can be intensive the longer the player stays alive. This coupled with joints (spring, hinge, fixed) on items, animations, and explosions also heavily contributed to the performance issues. Lowering the total number of rooms and objects per level vastly improved the gameplay experience.
When is the right time to look into optimization? Generally, it’s agreed upon that you should consider optimization whenever you’re designing your code, game, etc. However, as I mentioned previously if you’re mucking about in Unity trying to find an idea for a fun and original game, you probably don’t want to even consider optimization until you find a fun mechanic. As a solo dev, I can sometimes get carried away with fun new features and I should have looked into optimization sooner. This is a good lesson for the future that I won’t soon forget. I hope it can benefit you too!