Artifact: Camera

In our game we wanted the camera to be more than just a static viewport. For us, the camera is an important element to convey information to the player.

Firstly, we wanted the camera to gravitate towards the reticle, giving more vision towards the direction you’re looking at. This in itself is simple enough to implement. A simple mathematical formula for the camera position would be

a + b × f

where a is the position of the player, b is the position of the reticle in relation to the middle of the screen and f is the focus multiplier.

However, we wanted to compensate the viewing distance lost in the y-direction of the screen due to a non 1:1 aspect ratio. To compensate we used the absolute dot product of a heading vector pointing straight up and the heading vector of the reticle relative to the middle of the screen and multiplied that with the difference of the width and height of the screen, which gave us the following formula:

a + b × (f × (1 + |c · (0, 1)| × (width / height – 1)))

where a is the position of the player, b is the position of the reticle in relation to the middle of the screen, c is the unit vector of b and f is the focus multiplier.

Ref. A & B – The camera offset from the player.

However, this solution is problematic. When aiming towards the corners the offset is greater than when aiming directly up or down, defeating the purpose of the mechanic.

One solution would be to limit the mouse position to be position within a set radius from the player. This is a solution we’re still considering viable and may be what we eventually decide on.

Another solution, however, which is currently implemented in the game uses the mathematical formula

x’ = a_x + b_x × f × height / width

y’ = a_y + b_y × f × width / height

where a is the position of the player, b is the position of the reticle relative to the center of the screen and f is the focus multiplier.

However, this solution makes the aim not go over the center of the screen. It also makes the mathematical formula to rotate the player towards the aim somewhat more complex. Neither of these are big issues or are hard to solve, so this is the solution we’re settling on for now.

There are a few other features planned for future iterations of the camera.

We want the bullet spread to correlate to the camera offset, meaning that the further away from you you aim, the more spread your attacks will have.

We’ve planned for simple things to help with the immersion of the game, such as camera shake and similar features.

I want to mention one planned feature in particular. We’re all in agreement that we want a minimalistic HUD and that as much information as possible should be conveyed through the game itself. Therefore instead of having a health meter we decided that the camera, together with other mechanics, should convey the current level of health.

What we’ve decided that the lower health you have the more zoomed in the camera should be. Colors also get slowly desaturated. Other mechanics outside of the camera that will help this effect include time slowing down and audio changing.

About Malcolm Yllenius

2015 Programming

View all posts by Malcolm Yllenius →