Camera Systems

One of our first lectures of the semester covered camera systems in games and how we may go about implementing different types of camera systems. We also watched a GDC presentation of how Sony Santa Monica went about designing the God of War camera systems. For this blog I will be talking about the camera systems in other games similar to those described in the GDC presentation, and how one may go about implementing it.

Game Controlled Dynamic Cameras

Firstly I'd like to talk about game controlled dynamic cameras. These are cameras that automagically move and point at things and players have absolutely no control over what happens.

This camera type is featured in many local multiplayer games such as Little Big Planet, Super Smash Bros, and similarly in God of War.

Super Smash Bros' camera transforms to fit all players on screen. Occasionally it may include an NPC its calculations as well.

Firstly, I will discuss the implementation in Super Smash Bros and Little Big Planet. The camera essentially moves to fit all players on screen at once. It does this by using a bounding volume known as the viewing frustum.

Viewing Frustum

The viewing frustum is a bounding volume that represent everything the camera can see. If something is intersecting with or within the bounding volume, the camera can see it.

The way the camera system works in SSB and LBP involves only a few steps.

1. The system checks whether or not all players are within the frustum.
2. It calculates a new position and/or field of view such that all players fit within the frustum
3. It stores this new calculation as the next target and begins to interpolate towards the new calculation.
4. Rinse and repeat.

This system is pretty standard in many local multiplayer games I have played.

In God of War, it's a bit of a different story. Essentially, God of War works in the same way (only at certain points in the game). The GoW camera system calculates new best fit bounding volumes using a priority system for each character that appears on screen.

Basically, the player is designated as the top priority to include on screen. Next, enemies are assigned a lower priority. The priority essentially acts as a weight when calculating the new bounding volume. Otherwise for the most part, this system works very much in the same way.

God of War features even more game controlled dynamic cameras however. If I'm not mistaken, all the camera systems in GoW are predetermined by a designer. As such, giving designers a lot of control means they created a lot of tools for designers to use.

One of the highlights from the GDC presentation was the camera node blending. Essentially, a designer would place nodes in the scene that contained all the necessary information for the camera at specified points. When Kratos entered the area, the camera would shift between these points seamlessly, to create a very cinematic feel. This effect was achieved using a blend system, similar to that used in animation blending.

When animating between different poses, or combining animation poses, it is common practice to use animation blending to smoothly transition from one animation to another, or to combine two animations smoothly. Blending is achieved using weight factors. Similarly, we can consider each camera node in a scene as a pose, and assign weights to blend seamlessly between them! 

The last dynamic game controlled camera in God of War were the rail cameras. These cameras were fixed to a path and could only move along said path. As Kratos moved within the level, the camera would travel along the rail. This effect was created to mimic Hollywood's use of rails and tracks in cinematography, except in the case of a game it is interactive.

Player Controlled Dynamic Cameras

Player controlled dynamic cameras are limited to first-person and third-person cameras. Player controlled cameras change the camera view when the player does something.

First-person cameras are in my opinion a lot of fun. They do a good job of immersing you in the game and with the advancements in virtual reality technology (Occulus Rift!) the immersion level can only increase.

Many first-person camera systems usually attach the camera to the player avatar's head, because of course it is from the first-person point of view. This means that the player avatar's hands, arms and weapons may be in view. Today's first-person games tend to animate the camera whenever the player avatar animates. So when the player is running, the head bobs up and down to reflect this. Conversely, when the player orients themselves, most first-person games will animate the character's body accordingly.

This system is easy to explain, but probably more difficult to perfect. Making sure all the animations and controls are smooth is important because the player has a much more limited view of the world around them. The advantage of using this system though is that you don't have to worry as much about the things that plague third-person controlled cameras such as clipping with world geometry and awkward camera angles.

The best use of the first-person camera in games, in my opinion, were DICE's Mirror's Edge and Arkane Studios' Dishonored.

Mirror's Edge has to be the most adrenaline pumping game I've played in years. Great action, and a great implementation of a first-person camera.

The first-person action in this game is amazing. It definitely increased the level of suspense, and made the stealth aspect of the game more interesting.

Third-person cameras used to be much more troublesome in games, and luckily today, many of the kinks have been worked out. Third person cameras are usually positioned relative to the player. Many games incorporate different camera animations and and different points of view, and it is mostly game specific. Traditionally, the player can change the position of the camera relative to their avatar. In some games, when the player starts fighting or aims down the sights of their gun, the camera shifts to reflect their actions.

Some really fun third-person cameras I've seen were Infamous 2's camera system and the Batman Arkham Series' camera systems. Both change frequently between different third-person camera views based on what the player is doing.

Batman AA's camera system shifted between several views. When walking the game camera was an over-the-shoulder view. When running, it zooms out a little more and puts the player in center view. When snapping to cover, the camera zoomed in to give a sense that you were looking around a corner. There are also some dynamic pieces when you finish of the last goon in a fight where the game slows down, and the camera zooms in the get a close-up of the final blow.

Infamous 2s camera system mostly changes during combat sequences for an awesome close-up of the combat.

Cutscene Cameras

Last but not least (actually sort of the least) we have cutscene cameras. Cutscene cameras are predetermined and mostly boring. They may follow paths based on a timeline, or they may be fixed. Some games allow minimal control over a fixed camera where you can slightly change where the camera is looking, but this feature is basically negligible.

Domain Specific Languages

In one of our previous Game Engine Design lectures we watched a presentation that covered scripting as technology and domain specific languages (DSL). For this blog I will be focusing on the subject of a DSL.

First things first, what in the hell is a DSL?

A DSL is a type of programming language that is designed to solve a specific class of problems. DSLs are (or should be) designed in way that is easy to understand and easy to use. The idea is that while a DSL is indeed a programming language, it should not have a learning curve as high as a programming language such as C++ or Java. In fact, a DSL is usually built on top of a lower-level language such as C/C++ and is used to simplify the process of programming for designers. DSLs can simplify statements such as:

if(playerIsHit == true)
{
            player->removeHealth(weapon.damage)
}

To plain old english:

When player is hit by weapon remove health

As I mentioned before, DSLs are designed to solve a specific class of problems which can include game elements such as AI, cutscenes, and basic game logic. DSLs are stored in text files, in a similar fashion to scripts, meaning you don't have to recompile your engine every time you change a tidbit of game play logic. In addition to the time management benefits, DSLs also help keep engine code clean and much easier to debug for programmers.

A rudimentary but good example of a DSL are the controls for text-based adventure games. When you type a message such as "go west" the text is read in, and interpreted using a dictionary defined by a programmer, then the appropriate functions are called. A DSL would essentially work in the same way except the instructions could be stored in a file and fed to the program.

The fact that creating a text-based framework is so easy, disproves a common misconception that creating your own language is difficult. The reason this is a misconception  There are a few things one has to keep in mind when designing a DSL. Namely you have to identify the core problem you are trying to solve using a DSL. Next you'll want to select algorithms and solutions for any identified problems and break down the solution into separate logical pieces. Finally you would implement a DSL concept for each piece.

In terms of how code is stored, it is probably a good idea to use existing file formats, such as XML since there are libraries openly available that allow you to parse the code, making it easier focus on optimizing the engine itself and the actual design of the DSL.

In conclusion, DSLs can be useful if they are used and designed wisely. It can take a bit of effort to get one complete, but in the end it's definitely worth it and plus it doesn't hurt to experiment (don't do drugs kids).