*Note: I created the most of the tutorials using the Roboblitz and Gears of War editors. Based on the engine, and the version, some properties specified may be in slightly different locations than what is displayed in the screenshots.

If you need to learn how to create a basic map I would reccomend:
For UT99, UT2K3 & UT2K4: the Unreal Wiki.
For UT3: Waylon's Tutorials.



Common Interactives - Button Doors



I have set up a simple test map consisting of a slab of BSP, a skylight, a playerstart, a skydome, and a directional light.

I will only be using default editor assets which can be found in the EditorMeshes and EditorMaterials packages.

I will be using Movers/Interpactors (the terms are interchangeable) that are sometimes animated through Matinee. If you need to learn Matinee, I would recommend Hourences' Tutorial on them as a starting point.

I added the default mesh cube as a static mesh to the map, converted it to an interpactor, and then made it very thin. The pivot is in the center so I will only animate it up and down, or side to side. A door turning on its hinge requires both a pivot on one side of it, and some forethought to where the player will be so as not to squeeze them against a wall.

*Note: Pivots/Origin points on StaticMeshes serve as the 'hinge points' for interpactors. If you need to create a door, or other moveable object that revolves, rotates, or swings on an edge, you'll need to be aware of the mesh's pivot/origin location. It is impossible to re-assign this pivot permanantly in the engine. For mesh placement, you can currently temporarily assign the pivot to a new location, but when you're done, the pivot will be back at the origin. If you find a mesh that you want to use as a swinging door, and its pivot is in the center, you are out of luck. The origin is determined when the mesh is created in a 3D Modeling application - not in the Unreal Editor.

Button Doors: This kind of door is opened when a player interacts with a button to activate/deactivate a door. I've set up a very simple system.

Let's use the 'Cooking' analogy I outlined in the Applications introduction to set this up:

1) What are we making? A Button Door.

2) Gather the ingredients:
Trigger
Trigger Used Event
Mover (Door)
2 Movers (Buttons)
Matinee

3) Put it together:
In the level, I've created two walls and placed a thin mover between them. I also added a smaller interpactor for the button off to the right, on both sides of the door, and triggers over them with small radii. I overrode the interpactor's material with a brighter one.




On the kismet side of things, I used the triggers to create 2 Trigger 'Used' events, and a matinee. I hooked the outs into the play of the matinee, and added a delay so that 3 seconds after the door is open, it will trigger the door to reverse and close again. Then I keyframed the matinee to move the door to the side. Whenever the used event goes off, the door will open, allowing the player through. I used a MaxTriggerCount of 0 so the player can do this again and again, and I turned off the 'AimToInteract' to make it easier to hit the trigger. The key to activate the trigger when in-game should be the general 'Use' key in the game's configuration. I hid the unused connectors on the matinee.




4) Test it. Go in game and test it out. It worked fine for me.

5) Refine it. First, think about the collison and lighting and get those fixed. Then consider any potential issues. What happens if its closing while the player is running through it? Does it squash the player, or re-open? What happen if you activate the trigger again while the door's still opening/closing? Let's steal something from the 'Mover' Event to help with this.

Select the interpactor door and add a 'Mover' event in kismet. Delete the new matinee it creates, and on our existing matinee, unhide all connectors. Now, hook the 'HitActor' of the move event up to the 'change dir' on the matinee. Now, whenever the door hits a player, it will change direction. You could easily hook the 'HitActor' event up to a cause damage in addition to the change direction, or just cause damage.




But what about a player hitting the buttons again and again? I tested this, and the door will stay open as long as the player keeps hitting the trigger. Well, I don't want this to happen. I want the buttons to be 'deactivated' until the system is back to it's start. A simple way to do this would be to set the ReTriggerDelay on the triggers to the amount of time it takes for the system to complete. But since we're allowing the player to interrrupt the time by bumping the door, we don't know how long it will take to complete the system. Also, we can't hook something up to the completed of the matinee, since it goes off twice - once when open, and once when closed - or even more if the player bumps it and opens it again. So I am going to duplicate the matinee and seperate the open movement and close movement. To turn 'off' the use events until the door is back to its start I'll add a gate. The triggers will fire into the gate, which shuts itself off with an autoclose count of 1. When both matinees are complete, they will re-open the gate, thus allowing the trigger signal through once again. I'll re-keyframe the 'close door' matinee to do this and I also selected both matinees and turned on 'rewindonplay' in their properties, and made their movement World Frame instead of relative to initial. Lastly, the hit actor event was causing some problems - the close matinee wouldn't complete once the mover changed direction. So I added a delay that's the total length of the matinee, and hooked that into the play. Now, the matinee will change direction when bumped, and then will play again and attempt to close.




Normally, if we wanted to add sounds, we could add them through the interpactor itself. However, since we have two matinees set up, it might not function properly. So I'll add event tracks to the matinees, and trigger the sounds manually through PlaySound actions. One will be for the open, one for the close, and I'll add one more for the change direction. I'll target the door itself for the sounds to play from. If the player bumps the door, I'll also have to turn off the sound of it closing and activate a re-open sound. I've also hidden unused connectors to try and keep it looking less complicated.




The system seems to be working ok, but I'd like to add a visual cue that the buttons are activating/deactivating. This is why I originally converted them to interpactors. If we really wanted to go all out, we could create matinees for each of them and have them sink into the wall slightly, as if they've been pressed, but instead, I'll simply do a SetMaterial switch on them between a light and a dark material. We want them to darken when they cannot be pressed, and lighten when they can. So when the Use is triggered, will set the material to something dark. When the gate is opened again and they can be used, we'll set the material back to light. We'll set the target of the material swap to the button interpactors.




At this point, the system is pretty much where I want it to be. We have a door activated by a button, that will re-open if a player gets in the way, sounds correct, and the buttons visually indicate if they can be used or not.

6) Adjust it for Single/Multiplayer. As you may have read in the SinglePlayer/Co-op/MultiPlayer section, there are many considerations to take into account for whichever system you're setting this up for. The system as it stands might be ok for single-player and multiplayer both. But you chould still ask yourself some questions. What happens if two players are fighting through the door? Actually, it looks like that might be ok. What if they both hit the button? Well, it will open again from either side so... that seems ok. If you want enemy NPCs to open the door, you'll need to add something that allows AI to interact with the button. Otherwise, the system looks pretty complete as is. Unless you want to add dynamic lights or emitters to the system...