VERC: Security Cameras Last edited 5 years ago2019-05-13 13:19:14 UTC

Remember in Blue Shift in the security room where you could have a peek at the happenings around that area through the security cameras? Or in Counter-Strike, where one could see those nasty Counter-Terrorists sneaking around your building? It's a cool effect, and this article aims to show you how to do it.

There are many variations on how to do this. I chose one of the more complex ones; a moving security camera with a true-to-life monitor in an area that the player can't normally see from the monitor. Variations of this should be easy, and will be mentioned.

Prelude: Overview

Here is an image that shows you an overview of the entire project. This might get a little confusing based just on how many parts make this up, so refer to this image whenever you're not sure about something.

Step One: The Layout

In our example we have a room with an "S" hallway. We want the room to have a security monitor that looks down the hallway towards a door at the end. We want the camera to rotate slowly from the corner of the hallway, showing down the two segments. In a single player map, one of the first things we need to do is figure out if the hallway is visible to the game engine from where the monitor is (multi-player mappers can safely ignore this bit all the way to the next green comment). You see, if you make the player's view switch to an area the game engine can't see, you won't get anything but a Hall of Mirrors. There are a couple of ways to check if an area the camera is looking at can be seen from the monitor:

• If you're using OpenGL, go to the monitor, type gl_wireframe 2 at the console and turn towards where the camera will be facing. If you can see the outlines of the room/hallway the camera is looking at, the engine will render it from where you are.
• If you're using software rendering mode, go to the monitor, type r_draworder 1 at the console, and turn towards were the camera will be facing. If you can see the shapes making up your hallway, it can be seen from where you are.
• You can also just use common sense. An "S" shaped hallway like ours is obviously going to be a visblocker, and as a visblocker, will hide the visibility of that section from the engine.

Either way you do it, if you determine that the camera will be out of the engine's view, which most cameras will be, you need to take extra measures to make the camera will work properly. You will need to teleport the player to a hidden room that can "see" the hallway. In our example, it is simply an additional room added at the end that has a func_wall that looks like the original wall between it and the hallway. That way the engine thinks it can see that area.

Step Two: The Secret Room and Camera

If in the last step you determined a need for the player to be teleported to the location, you need to create a room separated from the hallway by a func_wall. In a simple case like our example, you simply split the hallway's wall in half and build a room next to it, converting the split half into a func_wall. The player can't see through a func_wall, but the engine sure can. For an added bonus, cover all the walls of your secret room with the NULL texture, which will reduce the polys the engine sees; and as the player will be looking through the camera instead of his normal view, you won't get any Hall of Mirrors effect.

You multi-player mappers can come back now. The reason this is not needed in multi-player maps is that the whole map is considered "in view" for the engine, because you have more then one player.

The next brush to construct is a camera. If it's not a moving camera, it's super easy. If it's a moving camera, like our example, you need to take some extra steps.

First step is to make the camera (duh). Make a camera using whatever texture you want, however you want it to look. Add a brush covered with the ORIGIN texture. This brush should be centered right at the spot you want the camera to rotate around. It should look like this:Select both the ORIGIN brush and your camera, right click them, and click "tie to entity." Scroll through the list of entities till you reach func_pendulum. Set up the entity like this: Now, in the flags tab, check Start ON, Passable, and Auto-return. The first makes the pendulum start with the level. The second makes it so the player can't interfere with the camera (or get stuck on it for that matter). The third is so that the pendulum keeps swinging even without being triggered again... something that we definitely want here.

Step Three: What the Camera Looks At

The next step is to give the camera something to look at. If your camera is static, you simply need an info_target down the hall. But we aren't going to do it the easy way, are we? We want the camera to rotate back and forth. For that, you are going to have to make something move back and forth between the two hallways. A func_train works well for this.

Make a cube. Make an origin brush in the cube (it really doesn't matter what it looks like, it will be invisible in the end), like this:Normally, func_trains don't need ORIGIN brushes, but the camera entity needs an exact point to look at. Since a brush entity defines a space, not a point, we need an ORIGIN brush to define a point for us.

Select the two, right click them, and click tie to entity. Select func_train from the drop down list. Now, setup the func_train like this: As for the flags, there is only one, not solid. Check it.

Now, halfway down each segment of the hallway, make a path_corner ; that means two. Set the name attribute of one of them to secPATH1, and the next stop target to secPATH2. Reverse this for the other path_corner. Now the train will loop back and forth between the two of them.

Step Four: The Camera Entity

Known to his friends as trigger_camera, this friendly little entity simply acts as the point from which the camera looks, as well as the entity to be triggered to start the camera. Add this entity with its center inside your camera (func_pendulum), so that it looks from the same spot as the camera. If your camera is fairly simple in design, you will not be able to see any part of the camera from inside it. Set up this entity like this: The only flag to check in this one is freeze player. Keep that bugger from running around while the camera is on.

Step Five: Teleporters

As we determined in step one, we need to teleport the player to the new location. This also means we need to teleport him back as soon as the camera is done. So, we will need two trigger_teleport entities and two info_teleport_destination entities. I gave the first trigger_teleport a name of secTELE1 and destination of teldest. The second trigger_teleport should have a name of secTELE2 and destination of teldest2. Place one of the info_teleport_destinations in your secret room facing down the hall, and give it a name of teldest. Place the other one in front of where you're going to have your security control monitor, facing the monitor. Name it teldest2. Place your trigger_teleports somewhere out of the way, you have to trigger them anyway. They should look similar to this:

Step Six: The Monitor

The monitor is fairly simple in its components, it's just a func_button. The hard part is making the front of it look like it's viewing your hallway; more on that in a minute. First, let's make a monitor in front of the second teleport_destination, attached to the wall. Tie it to a func_button. Set it up like this: In the flags, check don't move. Now you have your monitor. Now, for extra eye candy, we are going to make some custom textures to add to the front, so it actually looks like a security monitor after everything else is set up. Just wait on that until after we can actually activate our camera to get an accurate view for the screenshot.

Step Seven: The Multimanager

Ok, I'll assume you know how to use a multi_manager. If not, read this. So, assuming you know how to use a multi_manager, here is a list of things to add to it: Simple, isn't it?

One last thing to add is a trigger_auto, which makes autolycus attack your computer... just kidding. Seriously, make the trigger_auto and set the target to secTARGET so the train your camera looks at will start moving as soon as the level starts.

Step Eight: Making the Monitor More Real

Ok, now compile your map and test out the monitor. If all has gone well, you should see through your camera. Press F5 when the camera is looking down your hallway. Exit the game, and load up your favorite image editing program. Look in your Half-Life directory and open the picture named "yourmapname0000.bmp". Note: if you have taken shots of your map before, it won't be 0000, it may be a later number. Either way, grab the screenshot you just took. In your image editing program, reduce its size to something more palatable to Half-Life, like 128 by 96, and save it. Load Wally and create a new wad. Open your image, and add it to the wad. Save the wad in the half-life/valve directory. Now, go back to Hammer and add that wad into Hammer. You do this under the Tools->Options menu and the textures tab in that dialog. Your texture should be something simaler to this:Whew. Got all that? Now simply re-texture the front of your monitor with this new texture. You may want to wadinclude this texture instead of making everyone download this little wad, unless your map has a lot of other custom textures, too. Then just put the texture in whatever custom wad you are using, again with Wally.

Step Nine: Final Test

Ok, compile again and test that sucker out. If all went well, you should see a moving camera in your hall, and when you +use the monitor, your view should jump to where the camera is for 6 seconds (approx.) and them jump back to the monitor. Pretty cool, eh? One thing to note, the camera does seem to have some erratic motion... I'm pretty sure it has something to do with cameras starting off facing the way they do in Hammer and not starting facing their targets. It's just something you have to deal with, as far as I know.

Modifications to the Camera

For a multi-player map:
Omit everything doing with the teleporters. Basically, just triggering a trigger_camera with a func_button that looks like a monitor. Much easier.

For a stationary camera:
Make the camera a func_wall instead of a pendulum. Omit the train and the trigger_auto.

For a moving view monitor:
Take multiple screen shots, then add them as an animated texture.

Appendix

func_button
func_pendulum
func_train
func_wall
info_teleport_destination
multi_manager
path_corner
trigger_auto
trigger_teleport

I would like to thank Merl and autolycus for their new popup system. Saves me some work.