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 vertically.
The pivot is in the center and I will only animate it up and
down.
*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 Lifts: This kind of lift raises and/or
lowers when a player interacts with a button to activate the
lift. 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 Lift.
2) Gather the ingredients:
Interpactor (lift)
Interpactor (button)
Trigger (button)
Trigger Used Event
Matinee
3) Put it together. I've created a wall with an
indentation and placed the interpactor at the bottom of the
indentation. I also added a smaller interpactor for the button
off to the right with a trigger over it with small radii. I
overrode the interpactor's material with a brighter one.
|
|
On the kismet side of things, I am going to create a matinee
to control the mover. I'll also create a trigger Used
Event to fire it off. I'll deactivate the aim to interact and
playeronly, and I'll set the max trigger count to 0 so the player
can use it repeatedly. Now, what happens if a player sits at
the trigger and hits use repeatedly? To prevent this screwing
up the matinee, I'll add a gate to 'turn off' the signal to
the matinee, and a delay to turn it back on which I'll set to
twice the matinee length - one for up and one for down. I'll
also add a delay to the end of the matinee and loop that into
the reverse to bring the lift back down after the delay time.
Finally, since the switch is outside the lift, I'll put a delay
after the use event so the player has time to get on the lift.
Instead of a gate I could use two toggles - one to turn off
the Used event after it's fired, and one to turn it back on.
Same functionality, different scripting.
|
|
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? 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 lift 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 if the player stands under the lift causing it to change
direction, but then starts hitting the button? The 6 second
delay I have will get used up and the player will be able to
send the lift back up before it reaches the bottom again. To
prevent this, I am going to add some booleans to help the system
determine if the lift is open or closed, and therefore control
when the button can be used again. I'll also remove the 6 second
delay. Now, when the trigger is used, it will compare the boolean.
If the answer is false, it reads the elevator as 'Up' and will
do nothing. If the elevator is down, which it is by default,
it will allow the signal through to the 2 second delay, and
will will set the boolean as 'Up'. The rest is pretty much the
same, except that the boolean will be set to 'Down' only after
the matinee is aborted - at the end of the lift moving down.
Now, even with the change direction if a player is underneath
it, the boolean will only go back to 'Down' when the mover reaches
the bottom. The player can hit the Use button as much as they
like, but the lift will only work in its down position.
|
|
Normally, if we wanted to add sounds, we could add them through
the interpactor itself. However, since we have a matinee with
the possibility of interruptions - the change dir - 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 up, one for the down, and I'll
add one more for the change direction. I'll target the lift
itself for the sounds to play from. If the player bumps the
lift, I'll also have to turn off the sound of it lowering and
activate a raising 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 button is 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 Used is triggered, it will set the material
to something dark. When the system is open again and it can
be used, we'll set the material back to light. We'll set the
target of the material swap to the button interpactors. I'll
also add a toggleable light and place it in front of the button
to match up with the activate/deactivate of the material swap.
|
|
At this point, the system is pretty much where I want it to
be. We have a lift activated by a button, that will re-open
if a player gets in the way, sounds correct, and the button
visually indicates if it 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 while the lift is moving? Actually,
it looks like that might be ok. What if there's a button at
the top too and they both hit the button? Well, if the second
button is set up properly with the compare boolean, it should
only send one signal through so... that seems ok. If you want
enemy NPCs to operate the left, 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 attach items
or emitters to the system...
|
