WEEKLY NARRATIVE
This week was relatively light so far in development. I had to focus a little more on my work for Experimental Games and Senior Design, but I managed to put in some time for finally updating the way our doors work.
Initially, our doors were straightforward; they were rotating meshes with box colliders on them. When the doors were closed, obviously, they would block the navmesh and the player, and when they weren’t, they wouldn’t. This created a few issues:
- Doors that open close to walls are capable of pushing the player or the enemy through the nearby wall, forcing them out of the level.
- When a player was closing a door defensively, the animation time of the door closing determined the success of the action. If the door closed to slowly, the enemy would make it into the doorway and actually be pushed toward the player faster.
- Players who were spamming the open/close button could make the door flicker back and between open/close, and often end up doing the opposite of what the player needed enough to be panic-spamming.
At first I was only thinking about the first two issues, and I suggested moving the collider off of the rotating part and having the collider remain static in the doorway, and be toggled on and off when the door opened and closed. This way the transition would be instant, and would not cause collision glitches to push the player out of the level.
After discussing the idea in class, Tony pointed out another issue related to door collision - what should be done when the player wants to close the door while an entity was in the doorway? We adjusted the plan to also include a moment where the door checks for entities within its space.
I ended up building a door with three colliders:
- The collision-collider: this i (obviously) the one that gets activated when entities should not be able to pass through the doorway. It is not attached to the mesh that rotates around the hinge axis.
- The activate-collider: this is a large box surrounding the door on both sides which will toggle the door’s open/close state when the player is within it.
- The block-collider: this is a much smaller box that covers contains the doorway and the space the door swings through when it opens. If the door is closed while there is an door-blocking entity within the collider, the door will not be closed.
Additionally, the door ignores input for one second after the state is toggled, to prevent players from hurting themselves by spamming the activate button.
Here’s what that looks like:
CONTENT WITH HOURS
- Perforce maintenance (1 hours)
- Weekly Meeting (2 hours)
- Art Meeting (1 hour)
- Improved Door Script (4 hours)
WORKFLOW EXAMPLES
Nothing exciting this week.
POSITIVE OUTCOMES
- Now that we’ve pushed to make sure everyone is up to date on perforce, and I’ve added info about Macs to our setup guide, we’re all much more consistently productive.
- Took a break from working with shaders and particles to something a little less mystifying, and it was nice.
NEGATIVE OUTCOMES
- A few other projects are ramping up and I haven’t had as much time for this project
- I’ve been coming back the Xray portal visual on and off frequently but I haven’t managed anything visually attractive yet
NEXT TASKS
It’s been a little too long that i’ve been learning about shader without focusing on completing assets and working through the things that don't look good yet in our game. Now that i’ve learned a lot and done a whole bunch of tutorials it’s time to build visuals!
No comments:
Post a Comment