Vlatitude: Advanced Doors Tutorial Last edited 5 years ago2019-04-25 11:46:49 UTC

You are viewing an older revision of this wiki page. The current revision may be more detailed and up-to-date. Click here to see the current revision of this page.
Download example

Okay, considering that you've read Brian's basic doors tutorial, you should know how a door works. It is a brush-based entity that moves a distance equal to its length in the designated direction. In this tutorial, we'll discuss different approaches that will make your doors more interesting.

Multiple Brush Doors

Doors made from multiple brushes can be a giant pain in the ass, or they can be a summertime walk in a peaceful park. I hope that after reading this tutorial, your experience with them will be somewhere between those two extremes.

As you probably know, grouping brushes can make for cool and complex brush-based entities. This is a good way to make interesting doors, just group the brushes that make up your door, go into its properties, and go nuts. However, there is a limitation. The limitation is that all of the brushes in the group will serve the same purpose. They will all move in the same direction, have the same flags set, all because in theory, they are like one brush, or one door. This is all nice and good, but then people try to make doors with a glass window in them, and they run into problems. The problem is that a glass brush has one set of properties, while the rest of the door must have another, therefore they cannot be grouped as one entity. Don't despair, because there is a solution, although it comes at a cost. The solution is that you make the glass part and the regular part two separate doors. the glass part is of course a func_door, but you will have to adjust the lip to make sure that it doesn't move only as far as its own length. Remember that the lip is how much less distance than its length the door will move. Giving it negative lip is how much more distance than default the door will move. Now to make it look like glass, take a look at my glass tutorial, and adjust those properties. Okay, now you have your two doors (the glass and the regular). Here comes the limitation I was talking about: they cannot be opened by the "use" key. Yep, they have to be triggered. This isn't a big deal, just add a func_button or a trigger_multiple. Since we want the two doors to open at the same time, give them the same name. Now whatever is triggering them should have that name for its target. Your door with a glass part in it should work now. If it doesn't, ask yourself these questions

Doors with parts that move in different directions

Okay, the above section covered doors with multiple brushes that move in the same direction, but what if you want a door with two parts that slide apart? Simple, make two or more doors, tweak their properties so they move in the appropriate directions, give them the same name, and trigger them!

Rotating Doors

Rotating doors are a little more complicated than normal ones. A rotating door must consist of a door brush, and an origin brush. What's an origin brush? An origin brush is a brush that is textured on all sides with the origin texture (a green face-type thing). So find the origin texture, and make a brush, then group it with your door. Think of the origin brush as a sort of hinge for your door. The center of the origin brush is the point around which your door will rotate. Therefore, it's a pretty good idea to have the origin brush touching your door brush. After you have grouped these brushes together accordingly, click the To Entity button and make it a func_door_rotating. We're not done yet, go into the new entity's properties, and start adjusting those attributes. Things like speed and sound should already be familiar to you, and to my knowledge, the lip attribute doesn't affect rotating doors. The distance attribute is how many degrees your door will rotate. It will rotate away from the player when it's activated, and for the type of door commonly found in the real world, the value of 85 is fine for distance. If the door is opening in the wrong direction, you can make that value negative, or check the Reverse Dir flag. The default plane of rotation is the Z plane, or a normal-looking door. In the flags tab, you can set this to X axis or Y axis, using which you can create effects like doors that swing open from the floor or the ceiling and etc. The one-way flag makes sure that a door will not swing or rotate in both directions.

The Pitch Yaw Roll attribute is really funky. It allows you to create an additional offset angle of rotation. This is used to create doors that open in a way that is not expected. Instead of a normal hinge, imagine it having more like a ball bearing pivot point. This is pretty awkward to explain, because the possibilities with rotating doors and their different angles of rotation are virtually limitless. Try adjusting the Pitch Yaw Roll and see what kinds of effects you can come up with.

Remember that func_door_rotating can be used for much more than just plain old doors. With different angles, you can achieve some very interesting effects. If you want some ideas of what can be done with the func_door_rotating entity, think of the fact that the brush-based entity does not have to be a block. This seems obvious, but a lot of level designer's limit themselves by some subconscious boundary that doors are all rectangles.

More on Doors

It is important to remember that doors are entities. Of course you knew that, so why am I telling you this? Because doors can be either in an open or a closed position. No, I'm not on some rhetorical streak, this all has a deeper meaning. Let's take a door that has a bright light on one side, and total darkness on the other. The door can be either in an open or a closed position. The Half-Life engine does not calculate how the light will look in both positions. Instead, it calculates how the light will look when the door is open, or not present, and uses that for both positions of the door. Keeping this in mind, light effects on two sides of a door should generally look similar to avoid really unrealistic-looking doors. That's not all, the speed of your level depends on doors in a way. Without getting technical, everybody knows that the more objects you presently see in a game, the slower it is. This is why level designers are encouraged to make corridors and rooms over rooms. The doors come in when somebody thinks that they can separate two large complex zones in a level with a door. Logically, there's nothing wrong with this: a door will prevent you from seeing one of the complex areas, and the level should be speedy. However, keeping in mind that doors are entities, and the engine calculates everything as if they weren't physical structures (which they aren't), this won't work. Therefore, when vis processes the above described level, the door entity separating the two complex zones is not taken into consideration as a view-blocking structure, and the end result is a slow-running levels. To summarize, don't use entities (doors, func_walls, etc.) to separate calculation-heavy zones or zones with drastically different lighting.
This article was originally published on 69th Vlatitude.
TWHL only archives articles from defunct websites. For more information on TWHL's archiving efforts, please visit the TWHL Archiving Project page.

Comments

You must log in to post a comment. You can login or register a new account.