BGP Week 2 – Camera
|
So, this is going to be a rather short blog post, since most of the stuff I did was “chore” programming. Things that needed to be done, but aren’t really food for an interesting blog post.. One thing which importance is often forgotten in 3D games is that of the camera. It is, by far *the* most vital thing, that could easily, and completely, break the experience. And it’s no wonder either.. When designing a game, you go to great lengths to talk about how the graphics should look, what art style to follow, how the level and environment should be built etc. But non of that matters, if you can’t see those graphics properly. There is of course another absolutely vital role of the camera. Namely the gameplay related one. How do you know where to go, if you can’t see the road ahead? So this is part of what I did during this past week; camera programming. Now, Unreal offers a third person camera to begin with. The problem was, that it is connected to the player, meaning that wherever the player walked or turned, the camera would follow. We wanted to do some very specific things with the camera, which led to me creating a separate blueprint for it, and wrote my own code. So basic requirements:
The normal camera was rather simple. Since it wasn’t “hard” attached to the player, but a separate actor, I had to calculate the camera boom manually. That is, the location of the camera, dependent on the desired distance from the player, as well as the rotation around the player.
Camera Rotation is the rotation set by the player by pressing the Right Thumbstick. Camera Boom Rotation is the rotation value straight behind the player. Basically I’m just taking the Camera Boom Offset (the distance from the player) and rotating that vector around the aforementioned rotation axes. The Soaring camera, meant to follow the player as he/she glides around on his/her wings, is basically a variation of the above code. The difference is that the interpolation speed is higher, keeping the camera from drifting away from the player when he/she increases in velocity. One specific alteration in this, is that, as the player dives downwards, the camera rises, which gives off a sort of vertigo. Lastly, the snap camera. Again, really not that difficult. Basically, we put trigger volumes in the world. When these are entered by the player, the camera is told to interpolate between whatever position it was, to the world location of a specified camera actor in the world. Initially only the location was interpolated and defined, keeping the rotation always looking at the player. This works in some situations, but we realized that there were times when we needed to define exactly where the camera would be pointing, to make sure that important points of interest were in view. Because of this, I added a simple bool that was exposed to the level designers to set whether the cameras rotation should be fixed, or if it should be looking at the player. That’s about it. Not very exciting I know, but there are those kinds of weeks every now and then too. Until next time, Let’s Soar // Sky |
