One of the problems with Slinki's Alpha versions was the camera. Some of it's deficiencies were obfuscated by the addition of a few fixed positions throughout the levels but adding them whenever the camera started to even hint towards being unwieldy was a bit of a hassle.
So obviously we started looking into different ways to fix it and the two most promising were setting up an attractor system and what we eventually went with.
The attractor system basically tried to frame the most relevant elements on screen. The camera would work out a way to display all nearby relevant items as much as possible. This was interesting but it was quite hard to determine what was important and when. For instance, if an enemy was nearby it would try to frame it inside the view even if you're moving very fast in the opposite direction but maybe we should focus more on the pits our bionic bunny is quickly approaching. What should be more important? Are checkpoints important? What if there's two identical enemies on opposite sides of the screen - shouldn't we show at least one? The entire concept seems interesting but would probably better suit a cinematic platformer where there's less things competing for attention.
But first let's talk about our objectives:
- Firstly we ought to be able to see where we want to go. Preferably the faster we're going in one direction, the more screen space should go towards being able to react to elements coming from that direction.
- A vertical frame of reference should be maintained -ie: you should never lose track of where the ground is (and preferably whatever else is down there)
So what did we end up using? A seemingly rather simple system that required quite a bit of vectorial Math (mostly because our camera is slightly tilted down). Fortunately, Unity abstracts quite a bit of that away!
This is getting pretty large by now so next week I'll go more in-depth into what we've got so far.
