Predictability and expression
I’m genuinely fascinated with people’s perception of what in-game camera work is and what it can or should do. I would even go so far as to say that this has become a bit of an obsession for me since joining the rank and file of active members of the industry.
One topic that seems to be particularly prone to extremes of opinion is the question of the camera’s ability to express meaning through movement alone.
I think the basis of this contention arises primarily out of a long history of failed attempts to do just that in games like (off the top of my head) Blue Stinger on the Dreamcast.
If you haven’t already played this game, and have a spare DC kicking around, do so; it’s a great survival horror game, but it’s also a game with what is often an infuriatingly inconsistent camera behavior.
Anyways, the moral of the story is that thanks to games like Blue Stinger, a lot of people believe that development of a stable and expressive camera behavior is either too demanding to be valuable or is simply not worth prioritizing over other key features during those all important gestational pre-production stages in a project’s development cycle.
There’s certainly some logic and sense to this kind of thinking, but I’ve never been convinced that this was really the right way to look at this problem.
Could camera behavior not be made more engaging in less ‘demanding’ and complicated ways instead? And if so, just how do we get the camera to do the talking in our game without sacrificing reliability?
Well, for whatever its worth, here’s my own take on some of those questions after 16 months of very intensive development on what is an essentially an isometric 2d adventure mmo for kids (the player’s avatar is the star of the show and lives in a scrolling colorful bright world with a sizeable cast of NPCS and hundreds of other players.
I mention the NPCs because as you might imagine, one of the core game elements with which our design team had to get cozy with from quite early, was the conditional scripting system. The first working version of the adventure system we have now was actually pretty good (though the tool lacked some much needed finesse). It was pretty magical seeing it come together the way it did, given the amount of time our back-end programmers actually had to develop it.
The core of the scripting system was extremely flexible and allowed us to explore some fairly interesting creative directions in the very limited amount of time we had to do so. But shortly after the skeleton of several of our game’s adventures was stabilized, I started to realize that even if we allowed for a reasonable level of polish on text and visuals, the play experience of the basic NPC interaction behavior would continue to fall well short of the quality target I had very consciously set for myself at the beginning of the process. Being a game for a very junior crowd, the visuals had to do the talking for us, and somehow it just wasn’t quite happening.
The adventures were well written and beautifully animated, but the actual experience of embarking on an adventure still felt kind of disembodied and overly mechanical. It didn’t take a lot of work to get others on board and I started looking for quick solutions to the problem.
One issue was the fact that much of our basic interaction behavior was driven by very simple click trigger logic which allowed scripting to be executed as soon as a click event was registered on a given object.
In practice this meant that your avatar, standing on one side of the room, could engage in a conversation with an NPC standing on the other side. Not an issue in principle (at least in the functional sense of the word), but less than ideal for obvious reasons. Unfortunately this setup also meant that the avatar (as well as the game camera) could still be moving at the point when the first the NPC dialogue bubbles appeared on the screen. And yes, I would be a liar if I said that this didn’t happen all the ‘trigger happy’ time.
Our first solution to the problem was to piggy back the execution of scripts on a more complex ‘click reach’ trigger which stipulated that conditional scripting attached to a trigger point couldn’t be executed until the triggering avatar reached one in a given set of tiles adjacent to the NPC sprite. In short, whenever using this trigger, the avatar would always walk over to the NPC before the NPC could start talking.
This was undoubtedly a much tighter setup. But being the overly critical person I am, I still didn’t feel that we had reached a sufficiently high level of polish. The whole thing was still a bit too mechanical and it was clear that better camera work was the key to making the experience much more seamless.
But up to that point designers had no real input on development of our camera behavior. The system was rapidly developed with the sole goal of having a camera that would behave consistently at all times—an important, if somewhat limiting baseline.
This also meant that the camera’s subject was always the player’s own avatar, centered on the screen, to within a permissible range of deviation; Useful for setting a very safe experience, but extremely limiting in terms creating a fun one.
When framed in this light, most people actually agreed something had to be done. So after a bit of additional convincing, we dedicated a bit of time to testing new types of camera behavior specifically reserved for NPC interactions driven by context rather than raw predictability.
The first thing we did was look at changing the focal point of the scene depending on what was happening. My basic reasoning behind this push was simply the notion that when a player initiates a conversation by clicking on an NPC, this action carries with it the expectation that the subject of the scene had now willingly changed from the avatar to the NPC.
A more generalized way of looking at this assumption is to think about what happens when someone walks in to the waiting room of an office. In all likelihood, granted that there isn’t something more exciting already happening elsewhere, your eyes will be immediately drawn to the new element, even if it is just for a moment.
This same idea applies to the virtual setting on the screen. However, here it means that when I consciously initiate an interaction with an NPC, and that interaction has a tangible result, the reacting object will automatically become the new subject of the scene to me.
More succinctly put, in the context of our game, the camera’s inability to respond to the explicit change in the focus of the scene, or at the very least to acknowledge it, resulted in a kind of uncomfortable dissonance between the experience of what was happening and how that experience was visually represented.
Interestingly enough, everyone I sampled this change with actually seemed to notice an improvement, even if they couldn’t always immediately place it. The camerawork felt more natural and more engaging and we didn’t even have to sacrifice stability (in fact this actually solved some issues we were having with actions occurring off-screen, text boxes cutting off etc.). As an additional level of polish, we also rigged the camera to subsequently pan back to our avatar when the interaction was done.
The camera could now in effect anticipate, follow and respond to game actions by changing its stated subject as well as signal the end of an exchange by returning to expected baseline behavior.
So what’s the take away of all this? Even simple camera work is better than no camera work, doubly so if it’s built on a stable, reliable framework.
To that end, it’s also a good idea to make sure you know and understand the safest camera behaviors on which your intended play experience is built and do not be afraid to abandon this baseline wherever you have the resources and it makes sense for you to do so.
And yes, I realize it might seem kind of redundant to point out how important it is to understand the baseline camera behavior for a given situation in your game, but experience is a great teacher and I’ve come to realize that people rarely appreciate the value of taking the time to understand the aesthetic implications of a behavior, not to mention the importance of even having an ace up their sleeve that’s well tested and proven to be reliable enough to fall back upon until such a time as a better solution might be found.
So know your baseline if you don’t already, and try to play it through a variety of situations. Be disciplined enough to keep notes and stay on the lookout for patterns of visual ennui or momentary strangeness. Above all have the follow-through to create a list of your tweaks and their intended outcomes because that’s the only way your observations will ever likely get the chance to improve what you’re making, whatever it is.
