121 lines
9.2 KiB
Plaintext
121 lines
9.2 KiB
Plaintext
<!--210429,210402-->
|
|
<h1>follow a moving target </h1>
|
|
june 10, 2021<br>
|
|
#ai #character #movement <br>
|
|
<br>
|
|
After redesigning the movement system to support <a href="../entries/210429">patrols</a>, I realized the path remains static even if the target moves. Time to tweak the design again. <br>
|
|
<br>
|
|
<h2>what must be done </h2><br>
|
|
Autopathing to attack targets, skill targets, and item targets still partially relies on an old version of the movement system. Also, characters never update their pathfinding, so they cannot pursue moving targets. With some changes, the movement system can officially support following any of these targets, no matter where they go. <br>
|
|
<br>
|
|
For now, I'll update the movement system so the character can autopath after a moving item then pick it up once within reach. Since autopathing to items works identically to the others, the fix will be the same, too. <br>
|
|
<br>
|
|
<h2>upgrading the movement system </h2><br>
|
|
I can keep the same system more or less, but one function is going to have to be rewritten: the character's path_to_object method. <br>
|
|
<br>
|
|
Before, it only set the next waypoint and built a path between the character and the waypoint. <br>
|
|
<br>
|
|
<h3>old path_to_object </h3><br>
|
|
<code># Set Dots Between Character + Given Object<br>
|
|
func path_to_object(goal):<br>
|
|
if goal.is_in_group("waypoint"):<br>
|
|
set_next(goal)<br>
|
|
else: <br>
|
|
room.add_waypoint(goal.get_gpos())<br>
|
|
path_to_position(goal.get_gpos())<br>
|
|
<br>
|
|
# Set Dots Between Character + Given Position<br>
|
|
func path_to_position(goal_pos):<br>
|
|
set_dots(find_dots_pos(goal_pos))</code><br>
|
|
<br>
|
|
In order to follow moving targets, it needs to use the goal object itself. Also, it needs to be know when to only rebuild part of the path. <br>
|
|
<br>
|
|
<h3>the character receives a waypoint instead of the target, so he is unaware of his target's movement </h3><br>
|
|
It took waypoints instead of the goal in the first place for consistency's sake. Since a target can either be a position (as with click-to-move) or an object (as with autopath-to-item) and the movement system only has one entry point, the old system only accepted objects. So when clicking-to-move, a Position2D waypoint is generated at the global mouse position. <br>
|
|
<br>
|
|
I took the consistency a step further and also generated waypoints at the position of object targets. If the character only has a waypoint, though, he cannot know whether the target is moving. Fortunately, the system only requires an object with a global position, not a waypoint in particular. Providing the goal directly to the character not only resolved issues but also simplified my code. <br>
|
|
<br>
|
|
<h3>constantly updating the path overwhelms the character </h3><br>
|
|
If the target is moving, pathfinding needs to be reassessed periodically. However, it isn't as simple as calling the pathfinding method every tick. <br>
|
|
<br>
|
|
For one, the first point in the path will always be the character's starting position. If pathfinding is performed more quickly than the character can register arriving at the first point, he will either be frozen in place or jittering wildly. <br>
|
|
<br>
|
|
For two, it's bad for performance. Generally, the efficiency of a lightweight Godot game on modern hardware is not a critical concern, but I did manage to bog down the performance with some lazy pathfinding one time. Probably best to avoid extra pathfinding operations when possible. If the target hasn't moved at all, no need to recalculate anything. If the target has moved closer to the character, maybe only the farthest points need to be reconsidered. <br>
|
|
<br>
|
|
The next playable release after the bingo version will have a teleporting boss, so I'll probably need to be more thoughtful about pathfinding then. For now, though, these two fixes should do it... <br>
|
|
<br>
|
|
<h3>new path_to_object </h3><br>
|
|
# Set Dots Between Character + Given Object<br>
|
|
func path_to_object(goal):<br>
|
|
# Next Waypoint<br>
|
|
set_next(goal)<br>
|
|
var goal_pos = goal.get_gpos()<br>
|
|
var dots = get_dots()<br>
|
|
var cd = get_current_dot()<br>
|
|
# If no current dot, set dots between user and goal<br>
|
|
if cd == null:<br>
|
|
set_dots(find_dots_pos(get_gpos(), goal_pos))<br>
|
|
MessageBus.publish("moved", self)<br>
|
|
return<br>
|
|
var last_dot = cd if len(dots) == 0 else dots.back()<br>
|
|
# Make sure goal has moved significantly<br>
|
|
if goal_pos.distance_to(last_dot) <= get_intimate_space():<br>
|
|
return<br>
|
|
# If goal moved further away<br>
|
|
if get_gpos().distance_to(last_dot) > find_distance(goal):<br>
|
|
# If no dots, generate new ones<br>
|
|
if len(dots) == 0:<br>
|
|
set_dots(find_dots_pos(get_gpos(), goal_pos))<br>
|
|
MessageBus.publish("moved", self)<br>
|
|
return<br>
|
|
# If dots, only recalculate part of the path<br>
|
|
var near = get_dots()[0]<br>
|
|
for dot in get_dots():<br>
|
|
if dot.distance_to(goal_pos) < near.distance_to(goal_pos):<br>
|
|
near = dot<br>
|
|
var i = get_dots().find(near)<br>
|
|
set_dots(get_dots().slice(0, i - 1) +<br> find_dots_pos(get_dots()[i-1], goal_pos))<br>
|
|
# If goal moved closer<br>
|
|
else:<br>
|
|
set_dots(find_dots_pos(last_dot, goal_pos))<br>
|
|
MessageBus.publish("moved", self)</code><br>
|
|
<br>
|
|
<h2>testing </h2><br>
|
|
Now let's test it. I don't have any items that move around, so I'll quickly throw that in. I'll add some movement based on a sine wave into the _process method.<br>
|
|
<br>
|
|
<code>var time = 0
|
|
|
|
func _process(delta):
|
|
time += delta
|
|
var mod = Vector2(delta, cos(time) * 2)
|
|
set_gpos(get_gpos() + mod)</code><br>
|
|
<br>
|
|
<br>
|
|
<h3>the character never stops autopathing, even after picking up the item </h3>
|
|
<br>
|
|
Okay, one more fix, then I'll have it. <br>
|
|
<br>
|
|
Previously, the movement AI relied on conditional statements in its process to detemine arrival at the goal. Instead, the <a href="../entries/210402">achievement system</a> handles arrival for the new movement system. Since the process is called faster than the event handlers can function, the old AI system picked up and queue_free'd the floor item before the new system could recognize it had arrived at the goal. This meant the character never truly arrived and never knew to halt the movement process or clear movement variables. <br>
|
|
<br>
|
|
Moving the conditional statements from _process to the function that handles the outcome of movement events. <br>
|
|
<br>
|
|
<h3>new result code </h3><br>
|
|
<code>#enum MOVED {ARRIVED, NOT_MOVING, TOO_SLOW, WRONG_DIRECTION}<br>
|
|
func handle_moved_result(result, new_user):<br>
|
|
if result == 0:<br>
|
|
new_user.think("UserMove/Arrived")<br>
|
|
if get_user().get_target() != null:<br>
|
|
if track:<br>
|
|
if get_user().find_distance_to_target() <= get_user().get_intimate_space():<br>
|
|
emit_signal('item_arrived')<br>
|
|
get_waypoints().pop_front()<br>
|
|
new_user.clear_movement()<br>
|
|
return</code><br>
|
|
<br>
|
|
<h2>just a few changes makes a big difference </h2><br>
|
|
<center>
|
|
<img src="/static/img/ent/follow.gif" alt="(image: Angel adjusts her pathfinding to follow a moving item.)"></center><br>
|
|
<br>
|
|
Last Updated June 12, 2021
|
|
<br>
|