An Ocean of Problems

The last week has been a trying time on the project. Performance concerns are always valid, but when there are no foliage assets in the level and your only seeing around 30fps, that is cause for worry. Even more cause for concern is when you cook and package a test level and the game crashes on start-up. These were a few of the issues that I ran into this week.

The crashing was caused by the fruit objects that are passed to the goal generator when the level is being opened. In-editor these Blueprint based objects exist and will work fine. However, when you cook and package the game these assets are converted to BlueprintGeneratedClass type objects. And as the name implies, these are not an Actor based object and will cause a crash when you attempt to use SpawnActor to create one in the level. But, thanks to this post, I was able to finally get the packaged game to open correctly with no crashes. It took quite some time to figure this out, because the error that is reported is similar to an error that can be seen in other games, such as GTA 5. That lead me to believe that this was an issue with Windows 10 and not the game itself. Clearly that was my mistake.

As for the performance issues, they all stemmed from the ocean system that is being used. I knew that it was expensive, but I had no idea that it would cost upwards of 45fps. This was true regardless of the scalability settings that were chosen. I thought that nativizing the Blueprints to C++ may help, and it did seem to, but I only gained a few frames from that. It was actually the nativization feature that lead me to cook and package the game to begin with. So after quite a bit of testing and tweaking, I have a somewhat workable solution. Unfortunately it means that for people setting the scalability settings to medium or low, they will not have the ocean system. They will have a fairly basic water material applied; there is no sea foam on the beach, no waves crashing on the shore, no dampness that ebbs-and-flows with the waves. These are the tradeoffs that will have to be made.

On one last note, I was painting the landscape layers to define the different regions on the test map. Because I am using the original Brushify layers, along with duplicate layers that have been renamed for the foliage spawners, I was having a really difficult time differentiating between the various layers. So I added a color overlay to each of the layer functions outputs and connecting these to a parameter switch that would allow me to turn this effect on or off. It isn’t beneficial to have it on all the time, clearly, but when painting the layers it is a huge help. The featured image for this article shows the effect while it is turned on. The image below shows the same terrain with the effect turned off.

Figure 1. The terrain without the overlay effect.

Without the overlay, there is no way of telling the difference between the various landscape layers. These landscape layers are used to control the types of foliage that can spawn in a given location. Beach is easy to pick out, but the different types of grass all blend in together as they were meant to. Without the overlay, you can’t accurately define the biomes that will be controlled by the painted landscape layers. With this, I am now able to easily view exactly where each layer is and how they blend together.

Game development is difficult. There is a reason that studios employ a large number of highly specialized, highly skilled people to create a game. The production of a game is akin to a movie now, and it requires a lot of effort to get anything worthwhile. But, when things are all done and the game is what you envisioned at the start of the project, your efforts will all be worth it.