Layout
- Part 1: The naive approach ⇐ You Are Here
- Part 2: Our approach
- Part 3: Interruptions and smooth reversals
The problem
So there you are. You’ve modeled a door and a door frame, and presumably, the player or an enemy will need to walk through it at some point. In order for that to happen, you’re going to need some animations, so you press Ctrl-6 and open the Unity Animation Window and get cracking. Before long, you’ve got 4 animations and an Animator that looks like this:
For the transitions leading from the Opened and Closed states, you configure your conditions to include one of two triggers: “Open” and “Close”, and link them up to an Opener.cs script that will trigger those when needed.
“Ah yes,” you think to yourself, “the classic diamond. It’s beautiful. It’s elegant. It works. I can even write a script to generalize the opening and closing of doors and use an Animation Override Controller so that I can reuse this diamond on other doors with different open/close animations”
But soon, you start noticing problems and limits to the system. The diamond is good, but there’s a host of things you can’t do:
- Start in either the closed or the open state, depending on a boolean exposed in the Opener.cs script
- Stop the animation if the door bumps into the player or another object that is allowed to interrupt door motion
- Continue the animation or start the opposite animation from the stopped location if the player wishes to resume or reverse the process of opening the door after it has been interrupted.
- Expose what state the door is currently in for other scripts. For instance, the door can be Open, Opening, Closed, Closing, or Interrupted While Opening and Interrupted While Closing. Additionally, some doors can be Locked, and sometimes that comes with its own set of animations (for instance, jiggling the handle without the door opening).
In the next post we’ll introduce our solution and how it addresses all of these points.
Recent Comments