Optimize early, optimize often

With so much that goes into making a game, it is easy to just push forward and add all the content and worry about optimization later. I start out doing that very thing, and it can cause many problems. Now I cook/package a level and run it on my development system as well as my low-end test system. This is very important when it comes to catching performance issues early, while I can still understand exactly when the performance took a nose-dive.

For example, in the last post, I stated that the ocean system was causing a large hit in performance which would severely impact playability on lower-end hardware. While this is true of the ocean system in general, it is especially true when the wave generators are being used. If you just added in all the content and worried about it later, you may not realize that the wave generators for the ocean system are the largest contributor to the low FPS that you are seeing. By adding these things in incrementally, and testing for performance along the way, we can better understand where our performance is going.

I am currently reworking the bog area in the second level of the game. I had already tweaked everything to look exactly how I wanted it. All the foliage was simulated correctly, with the right density of large and small grasses, along with ferns, bushes, and other plants. It looked great! The only problem? Performance was low. Very low. On my development system, I was seeing frame rates in the low 40s. Keep in mind, my development system has a GTX 1080ti, 32GB of DDR3200 RAM, and a Ryzen 7 1700x overclocked to 3.8Ghz. Not a world-beater by any stretch, but far from a potato.

What happened when I ran this exact same test on my low-end system? A wonderful looking slide show. The framerate would dip near ten frames per second, and would only average around 15fps. That was the case no matter what I chose in the settings configuration file (the UI isn’t implemented yet, so its the config file or nothing). Just awful performance. Now, it’s true that my test system has a lowly FX5850 and an RX-570. This is the lowest hardware that I want to use as a recommended system, and if the game runs on this system, it should run well on newer hardware. Ten frames per second is obviously unacceptable.

Had I just moved forward with the game, I may not have known where to look to claw back some performance in the bog area of the second level. Because I cooked/packaged a test game, I was able to find this problem and address it. I have made changes to the foliage spawner used for the bog biome, and while I haven’t tested it on the low-end system yet, I gained a good 20-25fps on my development rig. I would expect to see livable, if not impressive, increases on the test system as well.

Profiling code doesn’t need to be done every step of the way; packaging a test game after every change isn’t advisable; testing on your test-rig every hour would waste time. But, if you package a test level a few times a week, or after you have added a new game feature, you can keep performance levels reasonably high. By doing that, you will know how much ‘head room’ you have remaining while moving forward. If your game is averaging 30fps on a high-end system, and you haven’t added any MOBs yet, you’ve past the point where you should have optimized for performance.

Leave a Reply

Your email address will not be published. Required fields are marked *