Devlog Four: We Need to Talk About Cameras

Devlog 4, We Need To Talk About Cameras

Hello once again! I’m back, with another update that should actually run on other people’s computers. For some context, I took my game into a play testing session at university yesterday where it quickly became apparent that something had gone terribly wrong. It ran at 5fps no matter what machine attempted to use it.

I tried, in-vain, to fix it in time and unfortunately those who did play it were unable to enjoy the experience as intended. This was seriously frustrating, but the moral of the story is this: Everyone should have a terrible laptop to try their game on. If it can run there, it can run anywhere. Armed with such a laptop, I decided I was going to fix the issues and get a new build out as soon as possible. Here’s what went down.

Why are you lagging?

Seriously!? When did that happen? I’m very new to Unity and I had no idea what could have caused the issues I was seeing. It wasn’t a minor stutter, the game was literally unplayable on even modest hardware. You shouldn’t need a supercomputer to play Flammin’ Joe!

I spoke to my lecturer who advised me to seek out the profiler. The profiler in Unity can show you in real time what resources are being used. I could see my FPS, and spikes in resource consumption. It was clear that Rendering was the biggest issue, but even after removing fires and lights, I barely claimed back 5 fps. It took me a while before it struck me that I should try the cameras. They do render the scene after all.

It was instant, the game ran much better. I’m not sure why… yet, to me it shouldn’t have mattered. You see, I was careful to enable and disable each camera respectively on each camera change, and confirmed this was the case with Debug.Log(). However, by simply existing, the multiple cameras were thrashing mine, and everyone else’s, CPUs. I re-wrote the cameraActivation script so that on every collision, depending on what zone was hit (by name) a different set of parameters would be send to the MainCamera which would update its position, and rotation, thus simulating a multiple camera setup.

This worked fantastically, though I’m still confused as to why it didn’t work before. I’ll have to look into it at somepoint!

Why Walk When You Can Run?

I think the game is fairly good, but slightly basic. I wanted to give the player more expression within the current restrictions I have created. The easiest addition to this was to give them a choice. The choice would be a boon to speed, but NOT to rotation. In-fact trying to rotate at full speed is actually quite challenging, but you don’t HAVE to speed up! I was happy with how this turned out, and I’m excited to see what times people can get with the new setup.

Changelog

• Optimised game by removing extra cameras and updating the camera position and rotation directly to simulate a multiple fixed camera angle setup.
• Further optimisation by adjusting values across multiple parts of the game and removing ALL wall lights.
• Added the ability to run for extra challenge! You’ll move forward and backward faster, but you can’t turn any faster, look for the perfect curve to perfect your time!
• Updated the fire layout. With only one camera, I was able to keep the good lighting effects from the fires… and add a few more! I feel there’s a nice degree of challenge to be had now, especially in-combination with new run ability!
• Fixed a minor bug with language not being set correctly.
• Removed all non-enabled default game components on objects that I do not use.
• Adjusted Timer and Deathcount text for clarity.