I wonder how coding crews tackle the problem of incorporating cameras for surveillance in games.

The question is basically this: Is the camera put out in the level-design just a prop or does it actually record like a normal video-cam would? I guess it's complicated to understand what I mean exactly.
Now, you could put the camera right there or there and say: “You! Do the work of a camera and observe!”
Or it's just a prop and you program inside the game mechanics that “Ok we have a prop right there and according to the movement patterns of the enemies THIS is what's going on!" I mean the underlying structures in gamemechanics/game engine will always know what's happening so…jees I can't seem to make my point clear…It's hard to describe what I mean. Basically once again, is it pure programming that lies behind the cameras vision or does it actually work like a camera, posted in a certain position? I'm thinking of Duke Nukem 3D or Metal Gear solid or even Deus Ex. I'm pretty sure these games have surveillance cameras. You could watch the pigs in Duke Nukem go about their business while planning the winning attacking strategy/tactics.

Thanks,

/Compu

@undefined Hi Compu, I am making a game that makes use of security cameras. I always found them intriguing in games. I can explain how I programmed mine: The camera, like most moving things in my game, has a forward vector (FV) associated with it. This FV points in the direction the object is facing (or looking). When the camera rotates, it applies this rotation to the FV, so it knows it's looking in a different direction. In the game loop, I call a function to update the camera. This update takes the forward vector and creates a viewing frustum. It then looks to see what objects are in the frustum using the radar method. If the player is in the frustum, that doesn't mean the camera can see the player. There may be other objects (crates, walls) in between the camera and the player. The camera will then cast a ray (line) from its position to the player and see what objects first hit the line. If the first object is the player, the camera sounds an alarm. If the first object is a wall, the player is obscured and the camera does nothing. As far as sounding the alarm goes, what the camera does is get a list of robots and finds the robot closest to the camera. It then sends a message to the robot that says the player is at position XYZ, and the robot begins running to that location.

Here's a link of my camera calling robots:

@CompuServe In the case of Duke3D, you can use a render-to-texture technique. 3D games use the concept of ‘cameras' which manage the view matrix in a game. Usually the main camera is positioned on the player's head in first games, behind the player in 3rd person games. If you're rendering a TV screen that's supposed to show what a camera sees, you can basically move and orient the camera from the player's head to the security camera in the game. Then have the renderer draw the scene to a texture instead of the screen. That texture then gets texture mapped to the TV screen when it's drawn.

Besides security cameras like those in Duke, it can also be used to draw scopes. You can make a zoom effect by altering the field of view in the view matrix.

Here' s a demo of the technique used in a weapon scope, but it could have been applied to a security screen or something else