UE Gameplay Cameras: A Modernization of Camera Systems

This is the sixth article in my UE Gameplay Cameras developer (GPC) diary. Last week I wrote about one of the first decisions I had to make when I started this work, but I realized I could write about the very first decision I had to make: the decision to start making a camera system in the first place, and in particular making one this way! So, why am I doing this?

Whenever I try to explain this, I often tell the following story. It comes from a good friend who cut his game-dev teeth through various Vancouver-made games of the late 1990s and early 2000s. These were, of course, EA Sports games.

At the time, my friend was working on SSX. I’m not sure which SSX game it was, but given the rough timeline, let’s say it was SSX Tricky… if only because we can look at what video game covers looked like at the turn of the millennium:

I don’t even know where to start… Anyway, at the time, other EA Sports teams were working on a new animation system. Probably for some upcoming FIFA game. Let’s say it was for FIFA 2003, just so we can look at one more wonderful video game cover:

It was meant to be an advanced, fully data-driven animation system. This was pretty innovative at the time, when “technical animator” was not a job description that really existed. You would setup the animation logic with a state machine and custom blend spaces and so on.

Over on SSX, my friend was looking at this with some interest, being an animation programmer himself. But one of his fellow animation programmers wasn’t impressed. He allegedly said something like: this isn’t gonna work, it’s way too complicated, you can’t expect anybody to make up animation logic in this thing, you need a programmer to code it. I just want animators to give me animation loops for, like, lean left, lean right, lean front, and lean back, and I can efficiently blend them in a 4-dimensional matrix based on what you’re doing with your snowboard. That’s the way to do it!

My friend asked about the possibility that the next SSX game might have new features like picking up the snowboard and walking around. The other guy replied: well that’s fine, I can easily make it a 6-dimensional matrix!

Of course, we know which way the industry went. Nowadays, pretty much every engine has an advanced, data-driven animation system. I believe Unreal Engine got its own around 2005 with UE3. That SSX guy was right that not everybody can make up complicated animation logic, but he was wrong that it necessarily had to be a programmer doing it in code.

This birth of the “technical animator” wasn’t an isolated event. In the late 1990s, materials for 3D games were pretty limited. Once again, a programmer would make up the core rendering logic, and only let artists plug-in a few assets and tweak a few values. You would pick between, say, a “matte”, “specular”, or “reflective” material, and only configure a few properties like the diffuse and bump textures or whatever.

Then we got material stacks and, eventually, arrived to shader graph editors, which I know some rendering engineers were opposed to, often for reasons similar to those argued by that SSX animation engineer. Again, we know which way the industry went, and the “technical artist” was also born.

Many more domains underwent this transition, from programmer-driven systems to data-driven systems, from a few black-boxes to a full-blow graph editor. These include SFX, audio, movie rendering, and more.

You see where I’m going with this, right?

Yep, I’m going with… “Ludovic’s Law of AAA Game Development”!

“Given enough time, any game system becomes a graph editor”

OK, but more seriously, you see where I’m going.

I’d say that 70% of the camera systems I’ve seen follow the late 1990s school of design. They provide a handful of “camera modes”, a bunch of properties to tweak on them, and maybe some blend type to choose from a drop-down list. You get to choose between a “follow” camera and a “spline” camera and an “overhead” camera, or something. Don’t get me wrong, these systems may have some really cool stuff implemented under the hood, and are just as likely to result in great cameras in practice, but that’s besides the point.

The remaining 30% of camera systems I’ve seen are a bit more modern. Some let you combine an attachment mode with a targeting mode. Some have a modifier stack reminiscent of 3DS Max, where you build your camera behaviour by chaining logic blocks… we’re getting there! I heard about a system at Ubi Soft that had some node graph. But I haven’t seen much in the way of truly deconstructing the concepts behind video game cameras and laying them out for technical designers to play with. Not in the way that, again, shader graphs or animation systems lay out concepts like texture sampling, gradient functions, colour manipulation, blend spaces, pose matching, and so on.

That’s what I’m trying to do with GPC. I’m trying to modernize camera systems by cracking open the programmer-driven black boxes, and letting technical designers go truly wild. That’s one of the main goals I set myself when I joined Epic Games and the Unreal Engine team. I really hope to succeed… but in the immortal words of Ozymandias, I actually already did it.

I already built this camera system once, about 8 years ago, at Electronic Arts for the Frostbite Engine. Last I checked, most of EA’s Frostbite-powered games were running their cameras with it, which is good given the variety of genres EA games cover. I have to thank my former colleagues for keeping the system alive and improving on it since I left!

Obviously, I’m hoping to build an this system even better the second time around!

Well, I hope this was interesting? Shout out to everybody writing custom camera systems out there! Cameras are cool!

In fact, game engines are generally cool all over, and I really hope we keep seeing games made from custom tech every now and then. There are are many good reasons to roll your own engine or camera system or whatever else, and often, “because it’s fun and educational” is a good enough reason!

For everybody else, Unreal and the other commercial engines are there to start from. And GPC will be there for your camera needs.