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).

Convergence at BioWare

BioWare is the developer of triple A role-playing game franchises such as the Mass Effect series and the Dragon Age series. Both series play similarly in terms of their RPG elements, and share many gameplay features. While at MIGS, I attended a session held by Blake Grant from BioWare. The session was titled Convergence for Success. The title was vague and I had no clue what it would be about, but I went anyways.

The session began with an explanation of how the Mass Effect and Dragon Age series shared many features, and highlighted a few like the dialogue wheel and real-time cut-scenes and whatnot. The speaker then revealed - at least to me this was a revelation - that the games were built on two different engines. Mass Effect was built on the Unreal Engine, while Dragon Age was built on BioWare's own Eclipse Engine. So while the two game shared many features, the work was basically done twice when a lot of it could have been done once had they developed both games on one engine.

Now once development had started on both franchises, it would have been difficult for either team to switch to a new engine and redo all the previous work they may have done in developing a framework around their respective engines. It would have also taken time to sift through all  After the development of Mass Effect 3, the company decided to plan for a way to share the work between BioWare RPG games to reduce development costs and development time by moving to EA's Frostbite Engine.

However, moving to Frostbite alone still presented the same problem to both the Mass Effect and Dragon Age teams; they still have to add new features to their respective games, and seeing that they are being developed at the same time, this means that work would have to be done twice. The next step for BioWare was to create their own version of the Frostbite engine named BioWare Frostbite. The BioWare Frostbite Engine would contain all the shared features that both development teams would require.

The next step for BioWare was getting all BioWare development teams (Mass Effect, Dragon Age, and a third new team) to communicate with each other to determine which features would be shared, and in turn added to the BioWare Frostbite Engine. Shared features could range from something very genre specifc, such as the previously mentioned dialogue wheel, to things like artificial intelligence behaviours and even shaders.

The communication is the hardest part to manage for BioWare but the process of convergence and sharing the work has proven to be extremely successful in the early stages. The first game to go into production was Dragon Age:Inquisition BioWare's first next-gen title. Out of 141 man-months worth of work, approxiamtely 60-70 of the work is being used in both the next Mass Effect title, and BioWare's new IP. The process of convergence in my opinion has been successful at BioWare; the Dragon Age team has cut-down the development times of both the next Mass Effect and their new IP by sharing the work.

Other EA studios are also moving to Frostbite, however whether or not they are implementing convergence is another story. I could definitely see this process being implemented in many large studios, not just EA. It makes me wonder if games like Assassin's Creed, Watch Dogs and even Prince of Persia would benefit from a development process like this.

I find the process of convergence is simply the next logical step in the development of game engines. Convergence introduces a third layer in the process of developing a game engine. As opposed to having a general purpose engine, then a game specific layer, we have a general purpose engine layer, a more game genre specific engine layer, and then the game specific layer.

Designing an Engine with Live Operations in Mind

This week I went to MIGS and went to a talk that touched on the subject of games as live operations. A live operation or live-ops, refers to games that have already been released and the game is now being treated as a service. The idea is that you release the most viable version of your product, or put another way your 'base' product first. Then whenever you want to add a feature, you do a quick and dirty implementation, test it with your customer base, take the feedback from the tests and either add support for it, improve it and test again, or chuck it out the window. The focus of the talk was actually about how to use metrics and player feedback to change your game design, and also focused on community management in regards to live-ops.

For this blog, I would like to focus on how I might go about actually designing an engine with live-ops in mind.

Flexibility

When it comes to live-ops the development team has to be flexible and open to change. This is no different when it comes to the game engine itself. As I mentioned before the initial product that is released is relatively lightweight. It usually only includes core game features. Once the game is released the team starts collecting data, analyzes it and then based on the analysis new feature requests or changes are added to current or near-future plans. Even without metrics being collected from players, the team itself may want to add or test new features,

This means that the engine has to be built in such a way that designers can implement and test features quickly. In other words, the engine has to be modular. This can be achieved through a scripting engine, and implementing all game features using script. This would effectively allow designers to implement new features, alleviates pressure from the programmers themselves to implement and test features, and this also means that for players, updating their games doesn't take excessive amounts of time since script files are extremely small.

If the test version of features prove to be successful, the team could write better more optimized script, or if the features is important enough to be a core of the game, they could add it to the engine itself.

Metrics Collection

Metrics collection is extremely important when it comes to live-ops. As a developer you want to know what your players are doing, when they are doing it, and how often they are doing it. All this information is then used to improve your product. But this isn't done automatically obviously, it has to be integrated into the engine itself.

I thought about how I would collect the data for a while. The main thing I made note of while brainstorming was that while we might want to collect all the data related to what players are doing, when and how often they are doing it, we don't necessarily need all of it. Nevertheless, I am assuming everyone is uncertain about everything and so we want to collect everything.

The second thing I made note of was that even if we limited our metrics collection to select features, we'd still have the problem of reading it, because in the end it's all just numbers. So organization of the data collected is also important.

Flexibility + Metrics Collection: How to Manage Both

A word that constantly comes up here is data. It's all about the data. This made me think about MMOs and how data is stored on servers and players use a client to access (pushing input, pulling output) the data on those servers.

Basically, the best thing to do if you want to maintain flexibility and perform effective metrics collection, is to have your game related data stored on a server.

Processes for collecting data at a high level using a server:

1. Player opens game client
2. Client checks for updates and pulls.
3. Player plays the game.
4. If the player is in an area flagged for metrics collection, the server should know and begin collecting data.
• For example, let's say we want to know if players are entering certain dungeons or levels, we'd simply log every time they actually enter the level. If we wanted to know how long they take to play through the level, we'd log the time they enter the level and log the time they' leave the level.
5. The collected data is stored on the server, at which point designers would have their own client that pulls the data. The client would be able to take all the data and present it in a readable form for designers to analyze and interpret.

In terms of the processes for pushing new features or updates for players:

1. Designer has feature they want to test.
• New level, new item, new mechanic
2. Designer has their own client which can simply push these small updates to a test server (an exact copy of the live server) where they will test their update to see if it breaks the game.
3. Designer's new feature has been tested and is now pushed to the live server.
4. Player plays the game and data is collected.

As far as I can tell most the of the game engine design principles we have already learned are applicable to designing an engine for live-ops. The major difference is that your game has to be online in some way or form to maintain the level of speed necessary when it comes to updating a game.

TIL: Maya Has More To Offer

It's been a while since I last blogged. Since then I've learned quite a bit about Ogre3D and I'm still working on Havok. But for this blog I'd like to focus on my new relationship with Maya (Autodesk Maya that is).

Not long ago I believed Maya was nothing more than just a 3D mesh creation and animation tool, among other things. In one of our Game Engine Design lectures, Dr. Hogue showed the class some menus that were basically created using Maya. Funnily enough I had been working on the assignments and for some reason I got it in my head that Maya was only good for creating locators, waypoints or paths. But after toying with the FBX format I realized that Maya can be used for much more than just creating paths; using a predefined naming convention in Maya, one could essentially use the FBX format as a design tool.

The FBX format includes meshes, animations, locators, lights, cameras and even the scene nodes' hierarchical structures (and possibly other things I may not be aware of). When loaded into Ogre3D these all get added to the scene graph. Finding them in the scene graph is just a matter of a search through the scene graph by name.

Now using a naming convention for a point on a path - say something like "path1_point1", or simplified further "path1_1" - we could have a class that stores paths, and to store the points after they are loaded in from the FBX we would create a search algorithm that searches for all the "path1" points. Once the node is found in Ogre we would search for the next path point until we are finished. The same naming system, applied to the objects in a level could achieve a similar result.

For example, if we have weapon pads in 6 different places in the level, traditionally one would have to either hard code each one's position or create a level editor and save those positions in a text file. With Maya, we basically already have a level editor and so the positions are saved in the file itself. Loading those weapon pads into game is done for us when we load the FBX, and finding them is a matter of a naming convention e.g.("weaponPad_1").

In terms of the pipeline this makes things so much faster. For one, as one of two programmers I get to be even more lazy as I don't have to create a level editor. This also means that as long as the development team has access to Maya (which luckily we all do), anyone can create a level. The only training I have to provide the team will be the naming conventions that we will be using, which I plan to store on the repository wiki.

I am still in the planning phase for this system, as I don't want to just jump into implementation and then along the way discover that it'll never work, but so far I think that this pipeline will be solid and reduce our development time significantly.

Week 3: Design Patterns

This week our class focused on design patterns that are commonly used in software design. We covered the factory, facade, state and singleton patterns. 

Factory Pattern

The factory pattern is basically the idea that you have one place where you can create your objects. All it requires is for you to pass in an ID indicating which object you'd like created and the factory will create it for you. This design pattern is especially useful in terms of implementing support for scripting. As opposed to having a user explicitly instantiate objects, we would simply have them call the factory and ask for the factory to create the object for them. This simplifies the process for the user of the script, as they don't have to worry about what is going on in the background. This also gives control to the engine programmers as they determine how objects will be instantiated through the factory.

Facade Pattern

The facade design pattern simply involves taking a collection of related classes and giving them a single interface to communicate with a the interface of a different system. If we think of our code as a store, and objects as employees, these would be the managers of a specific department. Managers of different departments communicate information about their own individual apartments to each other and/or to their managers. 

This also keeps each major component of a framework independent of another. If your graphics and physics systems must communicate but are tied together, then you won't be able to change one without affecting the other. Using the facade design pattern we would have them communicate from a single interface, and if say we wanted to update the physics system because it was poorly designed on the first pass, then we would only change that system. This design pattern keeps communication between systems clean, avoiding the messy practice of unnecessary interdependent systems.

State Pattern

Having used states in the past, and experiencing first hand the nightmare of maintaining all those states, I can only thank the software design gods for revealing this design pattern to humanity.

Thank you Software God for revealing these design patterns to us.
And ye

This design pattern involves creating a state manager that handles the logic and switching of states in an object. The use of a manager also allows the code to be shared between functions since it is not hard coded into a single class. This design pattern makes state hadnling a much more managable, clearer and cleaner process.

Singleton Pattern

The singleton pattern basically limits the instantiation of a class to one object. Put simply, you would use the singleton pattern in situations where you only need one of that specific object. Some examples given in class included only requiring one renderer or one mouse. This is implemented through a class that contains a static data member, and all instantiations of that class point to the same place in memory. 

The most obvious example of where this design pattern should be used is in something like a Game class, where your main game loops are; you don't want to open multiple instances of a game at the same time! Although I've never heard of anyone doing this, I'm sure it has somehow happened before. Any manager of a system or subsystem should also be a singleton. The idea is to have just one.

This design pattern is one that I've actually used before. Although I didn't really use it for the important things, like renderers, physics managers, animation managers and the like - I used it for storing mesh information and texture information.

Our second year game, a bullet hell shooter titled The Next Dimension, had to render several enemies on screen at once. Initially, we had set up our classes such that each enemy object stored all the information necessary to render it, which was really just a mesh and a texture. The problem with this was that we were storing the same texture and mesh information, about 100 times. When we realized this, it was a simple solution really; all we had to do was make sure that the texture and mesh were shared across all instances of the objects such that they could be accessed and drawn 100 times, whilst only having to store it once.

Singletons mostly seem there to protect the dynamic loading of objects in code, as you never know who might try to instantiate more than one instance of an object.

Week 2: Engine Design Plans

This week we had a class on modularity. The class was enlightening and got me thinking more about the design of our engine for this year.

Last year our 'engine' - if it can even be called that - was fairly modular compared to what we had done before but that's not saying much. The components weren't exactly designed well in and of themselves, but most could be dragged and dropped into another project and be used there (although there was some dependencies on the math libraries). Our biggest problem was actually that it was difficult to manage all the code. We didn't implement any managers. We didn't really allow for communication between systems and so code that should have been encapsulated within a manager class ended up all over the place. We also had no tools, which made designing levels and particle systems difficult as they were had to be hard coded, and everything always had to be recompiled.

Bottom line is development tools were non-existent last year in our engine. The code was messy and difficult to manage, and even though our game turned out fine, it really could have gone more smoothly.

Based on the design of the game described in my previous post, the lower level functions such as the physics, graphics, animation, collision, artificial intelligence, audio, input systems and the core gameplay mechanics will be built into the engine itself.

The game modes will all be done using scripts which will allow us to quickly test game modes and re-balance them without having to recompile the engine. I also hope that our development tools will include at the very least a level editor, a particle designer and a menu creator.