Few systems have a greater impact on the player experience than the camera, yet camera technology often receives far less attention than rendering, animation, or gameplay systems. Whether it's a third-person action game, a cinematic dialogue sequence, or a virtual production workflow, the camera ultimately determines how players and audiences experience every moment on screen.

The challenge is that modern camera systems frequently evolve into a patchwork of exceptions and special cases. Gameplay cameras accumulate years of feature requests and edge-case fixes, while cinematic cameras often become tightly coupled to specific animations, timings, and layouts. As projects grow in complexity, iteration becomes slower, maintenance becomes riskier, and camera systems can turn into what some developers describe as "fragile balls of code."

In this interview, Adam Myhill, Co-Founder of Black Eye Technologies, explains how Black Eye 2.0 approaches camera design with a fresh lens.

What problems in modern game production made you feel there was still a need for a new solution like Black Eye 2.0?

Adam Myhill, Co-Founder of Black Eye Technologies: The camera is the lens through which every design, animation, environment, and performance is experienced, yet they’re often horribly underserved parts of a project.

The problem is that camera work often falls into two difficult buckets. On the cinematic side, shots can be fragile because they are hand-authored around very specific animation, timing, layout, or character scale setups. Change any of those things, and shots break. Fully keyframed cameras can make blocking experimentation difficult and slow, and they force a certain order of operations. Camera work goes here in the pipeline. 

On the gameplay side, camera systems usually start clean but then slowly become a pile of exceptions: special cases for combat, vehicles, interiors, bosses, dialogue, traversal, multiplayer, scripted moments, and so on. That huge, fragile ball-of-code camera, which can severely limit iteration time and is often a bug factory.

Black Eye 2.0 came from the belief that cameras should be more directable, more adaptive, and much faster to work with. You should be able to describe the shot you want, tune the behaviour, and keep iterating as the game changes.  In real life, cameras have operators who look through the lens, and they follow the action. Something changes, and the cameras figure it out. We wanted to bring that real-life philosophy to CG. You think in behaviors and framing, not nodes and numbers.

One of the most interesting points in the announcement is the idea that gameplay cameras often become “fragile balls of code.” Why do camera systems tend to become such a production pain point over time?

Adam Myhill: They accumulate special cases. You start with something simple - follow the character, don't clip through walls -  and then the character gets in a vehicle, or goes underwater, or enters a cutscene, or crouches near a ledge. Each situation gets a patch. The patches interact, patches on patches.

Eventually, you have a system where changing one thing breaks three others, and nobody fully understands all the conditions anymore. The root cause is that most camera code is written reactively, solving the immediate problem rather than building a model of what the camera is actually trying to do. 

When you separate intent from execution, "I want this subject framed at two-thirds screen height, slightly leading,"  you get something that can reason about new situations rather than just fail at them.

That’s what we mean by “fragile ball of code.” The camera stops being a creative tool and becomes a machine everyone is afraid to touch. Black Eye works to solve that by giving teams modular, directable camera behaviours and a higher-level camera manager, so the system is easier to reason about, tune, and extend.

Black Eye 2.0 is designed specifically for Unreal Engine. What opportunities or challenges did working within Unreal’s ecosystem create compared to your previous work?

Adam Myhill: Having previously built Cinemachine and Cinebot, we came into Unreal with a pretty clear understanding of the kinds of camera problems developers run into over time. The exciting part about Unreal is that it’s become a hub for so many different kinds of real-time production - games, cinematics, trailers, virtual production, previs - and all of those benefit from better camera systems.

The core challenges are familiar across engines and productions. Teams want cameras that are cinematic, dynamic, and easy to iterate on without constantly rewriting code. Good camera tools should encourage experimentation, not make people nervous when someone says, “What if we tried this?” We’ve seen those problems before, and Black Eye is built from a lot of hard-won experience solving them.

The challenge was making sure Black Eye fit naturally into Unreal’s ecosystem. We didn’t want to replace how Unreal works or force developers into an entirely different workflow. We wanted to build a higher-level camera system on top of Unreal that makes it easier for teams to direct and manage sophisticated cameras without fighting the engine.

Our experience building systems like Cinemachine helped shape how we approached that balance between power, flexibility, and usability.

Why Unreal Engine?

Adam Myhill: Because Unreal is the place to be! It’s where so much 3D work is being built, presented, filmed, and shipped.

It’s not just a game engine in the narrow sense anymore. It is a production environment for games, cinematics, virtual production, trailers, previs, and real-time presentation. The camera sits right at the center of all of that. If you are building worlds in Unreal, the camera is how people experience those worlds.

But there's also a deeper reason: Epic's investment in photorealistic real-time rendering - Nanite, Lumen, MetaHumans - has raised the visual bar significantly. When your content looks that good, bad cameras become more conspicuous, not less. The demand for sophisticated camera tools naturally follows the demand for cinematic quality

From a technical standpoint, how does Black Eye’s modular approach differ from more traditional gameplay and cinematic camera pipelines?

Adam Myhill: Traditional pipelines bifurcate early: gameplay cameras are code, cinematic cameras are keyframes, and they live in separate systems that don't share logic or intent. Black Eye is built around composable camera behaviours -  a LookAt module, a follow module, compositional constraints - that work the same way regardless of whether you're in a runtime gameplay scenario or a Sequencer cinematic. The system is describing what it wants the camera to do, and evaluating whether it's achieving that, continuously.

The important part is that all these modules are not just engineering components. They are designed around camera authorship. The user is thinking in terms of shots, subjects, framing, and behaviour, not just vectors and transforms. The system handles a lot of the underlying math while still giving the user direct creative control. That's fundamentally different from a pipeline where a human has authored every position and rotation explicitly. It also means cameras can respond to things that weren't anticipated at authoring time - which is the core of why they survive production changes rather than breaking at them.

Let me say that the math and order of operation challenges are immense. Most people have no idea how hard it is to seamlessly blend from an orbit camera at any wild position to a cutscene camera and back and have that look like butter. It most certainly is not a lerp. Gerald and I have over a combined 30 years of experience working on camera systems and some things have taken years, numerous AAA projects and significant head-bashing to solve.

Modern games increasingly blur the line between gameplay, cinematics, trailers, and virtual production. How did that convergence influence the design philosophy behind Black Eye 2.0?

Adam Myhill: It influenced everything.

A modern game camera cannot live in a tidy box labeled “gameplay” or “cinematic.” The same project might need third-person cameras, driving cameras, combat cameras, dialogue coverage, scripted cutscenes, trailer capture, previs, and virtual production-style presentation. Those are not separate worlds anymore. They are different uses of the same characters, environments, animation, and action.

So Black Eye 2.0 was designed around the idea that camera systems should be reusable across those contexts. A strong subject-tracking system should help gameplay and cinematics. Good blending matters in both. Dynamic framing matters in both. Multi-subject composition matters in both. The dividing line is not gameplay versus cinematic. The real question is: what is the camera trying to communicate?

If you accept that a game like The Last of Us or God of War needs the same camera intelligence operating across a boss fight, a walking dialogue scene, and a trailer capture, then building separate systems for each is architectural waste. We designed Black Eye around the idea that camera intent should be context-agnostic. The system shouldn't fundamentally change its behaviour because it's now inside Sequencer instead of a gameplay tick. That convergence is also driving virtual production in a direction where game camera tools and film camera tools are increasingly the same thing, which is an interesting space to be building in.

Sometimes the player needs control. Sometimes the director needs control. Sometimes the camera needs to move smoothly between those two modes. That convergence is exactly where Black Eye is designed to live.

You mention that tools like this allow smaller teams to “punch above their weight.” In practice, how does improving camera workflows impact the overall quality and production efficiency of a game?

Adam Myhill: Good camera tools multiply the quality of everything around them.

A better camera makes animation read better, environments feel more intentional, combat feel more legible, traversal feel better, and cinematics feel more polished. It is one of the few systems that touches almost every part of the final experience.

For smaller teams, that matters enormously. They usually do not have a dedicated camera department. They might have one designer, one technical artist, or one programmer trying to solve the whole camera problem. If every camera improvement requires custom code, the cost gets high very quickly.

Black Eye gives those teams a more advanced starting point. They can build cameras that follow subjects, adapt to action, blend cleanly, handle collisions, track multiple characters, and support cinematic framing without building every piece from scratch. That means more time spent making creative decisions and less time rebuilding plumbing.

That is what “punch above their weight” really means: not faking quality, but giving smaller teams access to workflows that used to require much larger production resources.

Looking ahead, how do you see gameplay camera systems evolving over the next several years as games become increasingly cinematic and reactive?

Adam Myhill: The gap between gameplay cameras and cinematic cameras is going to further close, to the point where the distinction probably stops being architecturally meaningful.

Consider how many projects are built today: the gameplay camera is a child of the character pawn, hierarchically subordinate to it. The moment you want to switch players, traverse a level, or move into a vehicle, that model breaks. Cameras need to live above the whole project - managed by a system with a view over gameplay, cinematics, and everything in between, determining the best shot and configuration for any given situation. That's a fundamentally different architecture from what is often built.

The generative content wave accelerates this. We're going to see enormous variability in gameplay cinematics - generative dialogue, branching cutscenes, story structures that nobody fully designed in advance. The camera is going to have to film scenarios where the specifics aren't known at authoring time: different characters, different conversations, different emotional beats, all in the same scene. That's exactly why we built Black Eye the way we did - the cameras need to figure things out rather than execute a predetermined plan.

Looking a little further ahead, we're building synthetic editing systems that use shot evaluation and an understanding of cinematic language to construct movie-like footage from whatever is happening in real time. Think about what that means for esports, spectator systems, and games with dynamically generated story structures. The camera stops being a tool someone aims for and becomes something closer to a director.

Adam Myhill, Co-Founder of Black Eye Technologies