Final Post

This will be my last post for the project, so I’ll try to sum up everything. But first, let’s start with the last steps to the final release.

Field of View and the feeling of speed

The physic system limited us how fast the game could be. Every time we exceeded a certain velocity, the boat became uncontrollable very quickly. But the players should have a rough ride, instead of a cozy one. Actually, the controls were fine, but still, it felt somewhat slow. Other racing games inspired us to experiment with the field of view. As it wasn’t complicated to implement it, the outcome is very present in every game situation. This little feature doesn’t change the gameplay at all, but the players’ reaction to the top speed is a completely different one.

Those games with an afterburner (e.g. Burnout Paradise, Need for Speed Payback) increase the FoV and the camera distance to the car very slightly to have the feel of speed. But I also learned that racing simulations, in general, tend to have a lower FoV value, because the player has a better feedback from the game. He can drive more precisely because his real-world skills and assumption are more useful, in case the game looks like in real-world. Sadly, I missed talking to him yesterday.

Pursuing Boat

While test playing the game, the most engaging moments were those, where the pursuing ship was very close and very present to the players. But these moments were very rare in the Alpha Build. Other racing games inspired me to add a rubber band system.

It alters the speed of the ship in relation to the distance to the players. The ship speeds up when the players are too far away to increase the possibility of exciting moments. And it slows down while being next to them, to increase the duration of those moments.

Performance

The minimal technical specifications for the player increased dramatically in the last phase of our project. We added a lot resource heavy stuff, like post-processing effects. Especially the last level got my notebook at its limits. With Unity’s’ build in Profiler, I tried to investigate into this.

I could identify the way I animate the waves was the most impacting part of the game. At the beginning, it consumed around 48% of the processing power. The mathematics behind it was very simple: every rapid object was capable of spawning up to ten waves and in the last level, there were up to 400 of those rapids. That multiplied to 4000 objects that were calculated and moved just slightly every frame. The first thing I did, was to limit the activation range only to those rapids that are actually seeable by the player (around 50m in range). Then I dig a little deeper into the code and realized that I used two different functions to move a wave: one that moves them on the Z-Axis and one that moves them on Y-Axis. That was somewhat ineffective. By calculating the new movement position for Z and Y separately but apply the overall result just once, I could double the effectiveness of that code.

In the end, the waves are still the most consuming part, but it drops from 48% to 21%. It is still a lot and I am sure that a regular game development studio would deny it to go with that feature, but as the deadline for the project came closer and every other solution I tried before (animating the mesh filter of the water plane or animating the UV-Map of the water, as mentioned in earlier blog posts) weren’t promising, we shipped with it.

We also had some frame drops on weaker machines due to the particle effects. I tweaked those a little. Reducing the amount of particle by half and scaling up each particle a little to compensate this, did the trick.

Some minor tweaks here and there in the code (e.g. inverting blacklisting objects for the OnTriggerStay to whitelist only the desired ones) added to the overall performance optimization.

In the end, I am satisfied with the result.

Testing

This is only one story I really want to tell: There was a bug that made the game unplayable at all. In case you were one of the “lucky” ones how encounters the bug, the game would load a level and move the pursuing boat instantly to the players’ position and shows you the “game over” screen.

I was aware of that bug, but I couldn’t reproduce this. David wanted to install the game on the MACs at CGL after the Final Presentation for demonstration and he ran into the bug on every machine. I felt helpless, booted up my notebook and looked out for any idea. Gladly, David showed up again and told Daniel and me that the bug doesn’t appear when you switch the language setting of the operating system to German. At first, I laughed about that… it was unbelievable to me. But I also thought that it would just cost me second trying to reproduce it on my machine and David was totally right. Daniel and I investigated the code, trying to identify the harmful line.

In the end, it was a parse function that translates a string into a float. “0,2” translated into a float on a German machines equals 0.2, but not on an English one. We fixed that, updated everything and took another deep gulp of beer, laughing.

What I want to tell you? Trust your fellow team member and test the game on as many machines you can get your hands on! 

Release Phase

Shortly before the deadline for the final product ends, we switched over to a more agile procedure to test the game. All of the team members except the programmers played the game and tried out everything they wanted to do. They wrote every bug that appeared on a card and passed those over to the programmer. The programmers than weighted out every bug in importance and tried to solve them in order. The most important part was, that everyone was testing on a potential “release candidate build (RC)”. The programmers released a new potential RC every half an hour and there was a fixed deadline until we ship. That way, everyone was very focused and engaged with testing.

It made a lot of fun doing it that way because it felt like a game itself. I will definitely get back to this procedure for the next project, but doing it for just two hours wasn’t enough. Next time, I would go for a full day of testing with RCs for every hour.

Release Party

This event was a major success for us. There were a lot of people that tried the game and even some of them tried to beat the game completely. And I tell you, the last levels are hard to beat. To see their emotions after getting caught by the pursuing ship again and again, but then arguing with each other how they can improve their playstyle and not to blame the gameplay or the difficulty really made me happy and proud of my team and our product. We gathered a lot of valuable feedback and I will thank every one of you for your honesty.

Project Recap

The scope was bigger than I expected initially. And it was a tough task to fulfill our own requirements. We had a good start and improved a lot over that few weeks. We became friends and professionals at the same time. I thank you for your confidence in my management skills and your will and ambitions to perform as a single unit.

I am looking forward to the next project, but first… I need a break