Guards: Use walk behaviors #1880
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Play this branch at https://play.threadbare.game/branches/endlessm/guard-behavior. (This launches the game from the start, not directly at the change(s) in this pull request.) |
manuq
force-pushed
the
guard-behavior
branch
2 times, most recently
from
4f66e1d to
fdb64a1
Compare
Collaborator
Author
|
Day 3: I finally extracted a walk behavior for the patrolling, although some things were left broken in the process and I need to bring them back again. My test scene works fine but not the lore stealth game. The guard is walking while in the editor always, not just when the debug option "move while in editor" is enabled. The cost of doing these kinds of refactors is too high! |
Collaborator
Author
|
In the last commits I was able to use reusable behaviors for all guard states. I used:
Next, I need to test this further in existing levels and bring back the "walk while in editor" debugging. recording.webm |
Add a timer node, and remove the custom time handling from the guard movement.
Unify it with _process
Move the change (stopping the movement) from the process function to the state setter.
The destination point was being set on every process loop.
This walk behavior is based on the original guard's patrolling implementation.
To see the guard walking in the editor canvas when the "move while in editor" debug option is enabled.
Remove the now uneeded methods or properties.
The timer node might not be ready. This fixes the current stealth level.
Use a PointsWalkBehavior and dynamically create the path from the breadcrumbs. Go back to patrolling after walking through all the breadcrumbs. That is, when the path end is met.
Use a FollowWalkBehavior for it.
manuq
force-pushed
the
guard-behavior
branch
from
6b088f4 to
a1b5c1c
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refactor the guards to use walk behaviors.
To maintain the existing implementation as much as possible, add a new PointsWalkBehavior. In a PointsWalkBehavior, the character moves in straight lines between the points of a Path2D.
Use a PointsWalkBehavior for the patrolling state.
Use another PointsWalkBehavior for the returning state. This one is created dynamically from the breadcrumbs dropped while investigating.
Use a FollowWalkBehavior for the investigating state. And add a helper Node2D that is repositioned to the player's last seen position. The Node2D is used as target for the FollowWalkBehavior.
Use a Timer node for the waiting state.
Note: The detecting state is a bit confusing because it uses the patrolling walk behavior until the player is out of sight for the first time, and the investigating walk behavior for the rest. In the future this "detecting" state could be merged into both patrolling and investigating.
Fix #1265