gulogo.gif  
 
1. Hiatus
2. RIP, Satoru Iwata
3. Let there be Robot Battles
4. Regarding pixel art!
5. 16-bit Star Wars
6. Goodbye, Spock.
7. James Randi Retires
8. More Star Wars on GOG
9. Archive.org gives you DOS Games
10. Ralph Baer, RIP.
1. Quickie: Impressions June 2014
2. Quickie: Penny Arcade Episode 3
3. Quickie: The Amazing Spider-Man
4. Quickie: Transformers: Fall of Cybertron
5. Quickie: Prototype 2
6. Quickie: Microsoft Kinect
7. Quickie: X-Men Destiny
8. Spider-Man: Edge of Time
9. Quickie: Transformers Dark of the Moon
10. Quickie: Borderlands GOTY
1. Musings 45: Penny Arcade and The Gripping Hand
2. Movie Review: Pacific Rim
3. Movie Review: Wreck-It Ralph
4. Glide Wrapper Repository
5. Movie Review: Winnie The Pooh
6. Musings 44: PC Gaming? Maybe it's on Life Support
7. Video Games Live 2009
8. Movie Review: District 9
9. Musings: Stardock, DRM, and Gamers' Rights
10. Musings: How DRM Hurts PC Gaming
Main Menu

Affiliates
X-bit labs
The Tech Zone
Twin Galaxies

Login






 Log in Problems?
 New User? Sign Up!


Weekly Musings #6 - Camera, Camera, What's With the Camera - Part 2
Author: Michael Ahlf & Kirk Kimmel
Date: July 22nd 2004

Flaw #1: The "Unlocked" Camera

In a "soft" third person mode, sometimes the default camera AI searches the area for a landmark - something besides the character model to keep in view. This can help the camera seem more fluid, since any motion following a character in these patterns will cause the camera to move less than if it were simply tracking the same path the avatar takes. If the developers are worried about the game causing motion sickness, it's usually a safe bet they'll go for this in order to minimize perceived shaking of the screen.

I'm going to use <i>Spider-Man 2: The Game</i> as my example for this one. Despite the fact that it's a pretty good game, there's no denying it has some flaws, and this is one of them.

In Spider-Man 2, the camera tracks (mostly) behind Spider-Man. When jumping or  webslinging, it tends to hang back a bit, to give a good view of the city streets and crossroads. I noticed it doesn't just trail Spider-Man completely; it tends to pick a point off in the distance and keep that centered until the player either creates a new webline, starts swinging backwards, or jumps off of the webline.

By contrast, when Spider-Man is clinging to walls, it tends to hug the wall - get in real close, give the player a view of his tights-clad ass, and look forward along the wall. If you're seeking to approximate a first-person perspective, or give the illusion the player is crawling along behind Spidey, this is decent. I'd still prefer it to hang back a bit further, but I can live with it.

The problem is what happens when the two have a violent transition, such as happens when a fully charged jump is executed close to the top of a building. Spider-Man goes up, the camera follows... and then swings wildly around, trying to locate a landmark on the ground with which to orient itself. Meanwhile, Spider-man's moving in a roughly elliptical fashion in the air, because motion controls are camera-relative and the camera's frame of reference keeps changing. Normally, it takes the camera long enough to reorient itself that Spider-Man is already falling downwards, which leaves the timing a bit late for the player to recover from the fall and still land on the rooftop.

The solution: 

The solution for this one is actually quite simple - the developers already know, after all, what the maximum jump height one can achieve is. Therefore, they could have put a sequence in the AI for the camera to swing out and upwards once the player reached a point where he could conceivably jump past the building's height.

In other games, the solution is likewise planning - any camera effects which could occur of this sort need to be caught and planned for in beta testing. It's helpful when the developers can point out when the camera's AI is going to shift modes, and hard to believe that the developers and beta testers for Spidey 2 managed to so completely miss - or else ignore - this problem.

Flaw #2: Crossing Borders

The second flaw I'd like to look at is common to Locked / Rail camera games, but not limited to them - "soft" Third Person cameras with controls relative to the camera can occasionally suffer from it as well.

The problem is what happens when one crosses a border. This is even the case in games like Final Fantasy XI when going between zones. In some instances, the same keypress/joystick direction that was used to cross the border, now causes it to cross the border the other way. It's especially a headache when moving into a rather nondescript area (as some of FFXI's zone crossings are) or when there are load times involved; trip over this one time, and you've tripled the time spent waiting to get where you're going.

The solution:

The solutions for border crossing trouble are sometimes easy, sometimes not, depending on the game. For games like Final Fantasy XI where transitions are usually an open-air border, putting in code that sets the camera inside the border - thus ensuring that players pressing "up" move away from the zone point - works well. In zones where the transition is a zigzag point, or even a door, it's not that simple; in these cases, the solution that comes to mind is to set the player's spawn-in point far enough away from the obstruction that the camera can be properly set behind them. That's not a 100% foolproof fix, however; in action titles where a player may have "zoned" multiple enemies as an escape tactic, setting the spawn point that far in could lead to the player being trapped on reentry.

A third fix comes in simply eliminating the zone points - but this in itself can entail high overhead or other troubles. In Asheron's Call 2, for instance, loading points between zones (with the exception of teleportation wait times) are nonexistent. There are still borders between zones, however, and the game has had issues where players learned to use those borders to escape the notice of enemies, or where long-distance attacks have failed because they are not properly transmitted over the border. Single-player games (Soul Reaver, Soul Reaver 2, and even Spider-Man 2: The Game) have much better luck with this solution, as dynamic loading of areas is much easier to maintain when 100% of the world doesn't need to be kept "active" at all times.

Flaw #3: Tracking Directly Behind The Avatar

In some early camera AIs, the camera attempted as best it could to stay directly behind the player. This is nice in some ways, and bad in others. When the camera gets too close in, it tends to mimic the problems some players have with First Person camera - tunnel vision. When it pulls too far back, of course, all the eye candy tends to fade out and the designers wind up lacking in happy, reproducible screenshots with which to sell the game.

In shooting games, the problem can get even worse. When the camera attempts to swing around to keep both player and targeting reticle in-scene, it occasionally can cause the avatar to get between camera and reticle, blocking off sight of whatever it is you're trying to target. Not very pleasant, or desirable.

The solution:

The solution to the behind-avatar tracking comes in a variety of packages. In some games, the solution has been to mimic FPS console controls; foward/back movement and sidestepping on the left analog stick, and camera controls (possibly attached to a targeting reticle) on the right. While it sounds bad on paper, the fact remains that people intuitively can cope with this sort of arrangement; it has repeatedly been used in flight simulators, driving games (one control gas/brake/reverse, the other steering), and first person shooters. The result is that people learn to use the camera controls to make their character do both sharp and slow turns. The downside is that it leaves the player with less buttons; to use a button on the face of the controller, one thumb has to temporarily stop controlling either the character's movement or the camera's.

The second solution to the control problem is to lock the camera at a certain height above the ground level, or above the avatar. In a game like the Dynasty Warriors series, where few if any enemies are normally flying, this could pose little problem. In games with rougher terrain, or with flying enemies, it wouldn't work - the tendency for the camera to hide enemies offscreen from above would be too great.

In the Playstation days, a third option - completely locking the camera angle, and giving the player only left/right control - was tried, more by limitation of the controllers than by desire to fix the problem. It survives to this day in the Tenchu series, where it has caused some issues for players who want to have freedom to look around. It does work to eliminate many problems, provided two things are true. First, the levels and terrain of the game need to be fairly flat; a declination of more than approximately 15 degrees on any surface can tend to hide enemies when going up a ramp or stairway. Secondly, the angle and distance back must be carefully chosen, so as to still give an immediate-area view around the avatar while not hiding enemies at distance.

Flaw #4: First Person Mode

First Person mode offers a few problems of its own - a denial of information among the worst, truthfully. Why? Because it's viewed on a TV screen or computer monitor. This will lessen slightly when FPS gameplay on widescreen TVs becomes common, but never fully disappear unless full-vision VR glasses are developed. 

The problem is simply that the TV monitor or computer screen is not full vision - it's like looking through a window. Even scaled down, it does not  offer the full range of peripheral vision that a human has, nor does it offer the ability to quickly shift views up, down, left and right as our highly mobile eyes can. Jumping puzzles in FPS games perplex the majority of gamers, because they lack the tactile feedback to accurately gauge how closely they are approaching an edge before jumping.

Unfortunately, there is no cure to these problems, short of cutting out to a variety of third-person mode. Some games, like Thief: Deadly Shadows, offer just such an option. Others, like the Quake series, do not. And the FPS camera does offer one advantage; it makes guesswork about a firing angle meaningless. If you can see it, you can hit it.

Flaw #5 The Camera On Or Behind Obstructions

In third-person camera modes, there is always the risk that a floating camera will get stuck on, or go behind, an obstruction. In the worst cases, a camera actually manages to get stuck inside a wall, unable to move out. In other cases, the camera simply shows a wall on the screen, just part of a wall, or other varied obstructions. Sometimes, it simply results in a camera that is too far away from the action to be properly useful.

The solution:

The solutions to these problems are highly varied, but each useful. The first solution is to make the camera an insubstantial object, able to move through walls at will. This eliminates the possibility that it will get "stuck"; it simply moves past any objects in the way. The downside to this approach is that it increases the likelihood that the camera will, in fact, move right through an object that then obscures the view the player needs.

A second solution usually paired with the first is to make all objects between the camera and avatar either translucent or invisible. When properly executed, as done in Dungeon Siege, this can be highly effective. It can still create its own problems when NPCs or enemies are likewise made translucent, or when obstacles to directional movement are invisible but still impeding the character.

An alternate solution is camera code that attempts to steer the camera clear of walls at all times. A good example of this would be Tomb Raider, or Mario 64. When the player moves close to a wall, the camera swings out, displaying the avatar from the side or even the front as necessary. This only works if the player cannot find in the game two objects that cause the camera to have to decide between two conflicting exclusion zones, or a corridor too tight.

Got Comments? Send 'em to Michael (at) Glideunderground.com!
Alternatively, post 'em right here for everyone to see!

Weekly Musings #6: Camera, Camera, Camera


Added:  Monday, July 19, 2004
Reviewer:  Michael Ahlf

Page: 2/2

Previous Previous (1/2)  1 2  

[ Back to Articles index ]

Home :: Share Your Story
Site contents copyright Glide Underground.
Want to syndicate our news? Hook in to our RSS Feed.