Calling an Elevator in Unity (2.5D Platformer)
I recently worked on this little elevator calling logic for the 2.5D platformer I’ve been working on. I’ve probably made parts of it a bit more complicated than they needed to be, but ultimately I’m quite happy with the end result 😉 For a step-by-step guide:
1.On an elevator panel GameObject, make sure there’s an invisible collider with ‘isTrigger’ set to true (in my case, I used a BoxCollider). We can then adjust the scale of this to create the area in which the player can be detected in order for them to press the ‘E’ key and call the elevator.
2. Create and add a new ‘Elevator_Panel’ script. We can use OnTriggerStay or a combination of OnTriggerEnter and OnTriggerExit (most likely with some sort of ‘_playerEntered’ bool) to keep track of whether the player’s currently within the bounds of our collider. I’ve opted for the latter, along with the Update method, simply because I found this to work more reliably for me.
In this Update method, we can check to see whether the player’s pressed the ‘E’ key using Input.GetKeyDown, and can also check via the Player script whether they have the desired number of coins to call the elevator. If they have, I’m then calling this brief SetButtonColour method (which changes the colour of the material on the button) and am calling a CallElevator public method on a dedicated Elevator script.
3. For the elevator itself, I’m using some very similar logic to the logic used with the moving platforms in a previous article. Here, the CallElevator method flips a _movingDown boolean and changes the colour of the panel button to green (just to signify the lift’s currently moving/being called). Then in FixedUpdate, I’m either moving towards targetA’s position or targetB’s position, and am checking each frame to see whether I’ve reached it (in order to change the button’s colour back to red).
As with the moving platforms, I use a couple of dedicated methods to handle some of this, although I’ll admit the ‘MoveToPosition’ method comes from laziness (I just don’t like writing out methods with more than one argument multiple times unless I have to ;P):
4. To set these target transform variables, we can hop back into Unity, duplicate the elevator a couple of times, and then position these accordingly. We can then remove their components and any child objects, then rename these to ‘TargetA’ and ‘TargetB’ respectively. Once these and any of the other public or serialised variables are set in the inspector, most of the logic we need to run the elevators should be ready to go.
5. Finally, we can add another collider with isTrigger set to true, this time positioned where the player stands on the elevator. We could add this logic to the Elevator script itself, but I ended up separating these at the time, creating a dedicated Elevator_Collider script which communicates with the Elevator. This script allows the player to press the ‘E’ key while on the lift (to change its direction) and, more importantly, sets the player object’s parent to either the elevator or to null. Whether or not this logic goes here or in the Elevator script, it’s still an important step for reducing the jitter we’d otherwise see when the elevator tries to move the player.
If we just specify that _elevator variable in the Inspector, you should end up with a working elevator system. The public _coinsNeeded variable on the panel will also let us decide on the number of coins the player needs to collect before being able to call this lift/progress 😉