So... the Useful(P, D) function.
The particular things that fall into each of the categories I established in my previous post (constant, situation-dependent, and user-defined) will be game-dependent, I think that's pretty obvious. But I'm wondering - perhaps there are yet more common elements that could be worked out of the problem? I'm thinking specifically of the types of pieces of information we'd want to present to the player:
- Position. The player will usually find it helpful to know the positions of certain things - his own avatar, the monsters he's fighting, the powerups in his vicinity, etc.
- Orientation. If the player wants to shoot at something, he's going to need to know which direction he's facing it. Likewise, if an enemy's about to swing a sword, he'll want to know if that sword is pointing in his direction or not.
- Action/Status. The player will want to know what certain entities are doing. I know my Prince is standing above the retractable spikes; I know he's facing east. But is he impaled on the spikes, or has he trodden softly such as not to trigger them? Similarly, is the monster sleeping or looking at me with ever-burning hatred?
- Potential. Both information about negative potential - an approaching threat or obstacle - and positive potential - a possible escape route. This is more subtle than simply allowing the element to appear on screen, I fear - showing me the end of a dangling rope would inform me that the rope exists, but unless I can see that it leads up to a way out, I may well just ignore it.
Given those definitions, it may be possible to begin building a framework for the heuristic Useful(P, D) function. We begin defining rules, relating characteristics to their importance:
POSITION of $Player -> 100pts
ORIENTATION of $Player -> 100pts
ACTION of $Player -> 50pts (not so important because the player will frequently *know* what their avatar is doing - because they just told him to do it)
POTENTIAL of $EnclosingSpikedWall -> 30pts
POTENTIAL of $WestCorridor -> 40pts
POTENTIAL of $RopeLadderToCeiling -> 40pts
We can then being scoring shots - a camera position/orientation which shows where the player's standing and which way he's facing , but is distant enough that the action is not easily recognisable, but shows the rope ladder leading up to a hole in the ceiling and safety, scores 100+100+40 = 240 points. Similarly, a shot which shows the player's position/orientation plus the negative potential of the spiked wall scores 230 points; of the two, the camera will be more inclined to focus on the player's options than the encroaching peril (which is a very positive attitude for a camera, I must say). For veteran players, nothing're more annoying than having to rely on a rookie "cameraman" who doesn't keep a cool head in a tough situ; for the novices, a camera which helps guide them to making the correct decisions is something they'll be grateful for.
The numbers would need balancing/tweaking, of course, but that's the principle of it. Identify elements within the scene that may interest the player, and weight them according to their importance at that moment. That's where we bring our constant/dependent/userdefined categories back in, btw.
I should note that this has wider implications on development than just the code for the camera system - it affects content development as well. Level designers would need to "flag" things like the potential escape routes or dangers in the above example. And the artists may need to provide extra data concerning things like orientation - otherwise, how can the system handle a model that looks the same from many angles (such as a square block with a switch on it - how can the system be told that particular orientations of the model are more important than others)? A similar thing goes for a distance-based 'Action' measurement, particularly when LOD is involved; the artists would need to describe the barrier beyond which a given action is not recognisable, as it may very depending on orientation and light level.
There are also certain global factors that it would be good to measure and apply, such as the "urgency" of the game state. As the water level rises or the enemies get closer, the camera may be further weighted towards solutions than problems, "urging" the player to save themselves before it's too late. Scene lighting may also be a major factor - it's all very well pointing the camera at a snoring enemy in the darkness, but if the player can't see them then you might as well not bother. (You could even detract from the gaming experience by giving away the location of the "scary noise in the darkness").
That's probably enough on the Useful(P, D) heuristic function. How about Pretty(P, D)?
Now, this is where things can start getting really subjective. A camera system with aesthetic style? You might as well just install a positronic brain and be done with it! (Of course, it'd get pains in all the diodes down its left arm immediately after release).
How "good" and "bad" aesthetic shots are defined will depend completely upon your project. Perhaps your art style is suited to wide, open shots; perhaps it's better focusing in on the sublime character artwork, and letting the only-average environment fade away into the background.
There's a *massive* load out there on photographic/cinematographic techniques. I know very little of it; bishop_pass once explained something about the "rule of thirds," the idea that you should aim for picture elements to match up with horizontal/vertical lines drawn at thirds across the picture. That's about the sum total of my knowledge.
But still, there must be certain shapes and elements to aim for? Certain assets within the scene that the artists spent weeks on, making it intricately detailed, and that should be shown off? I wonder if such things could be marked out, and a scoring system much like for the Useful(P, D) function could be set up - 10 points for framing the scene with a hexagonal window, 40 points for having the angel statue close up on the left side of the frame. And so on.
I'm really not an artist (as anyone who has seen my exploits with smart_idiot's paint client will tell you), so I should probably stop rambling before I embarass myself. But still, there's a lot more to cover - I've hardly even mentioned camera *movements*, for example. What kind of movements are acceptable and what are not? When? If all we do is move between high-scoring Useful()/Pretty() points, how low can the score drop on the points inbetween? And so on.
But those can come later. Hopefully I've given some people ideas already...