After redesigning movement to support <a href="../210429">patrols</a>, I realized the path remains static even if the target moves. Time to tweak the design and debug. <br>
<h2>what must be done </h2><br>
Patrols was the last significant feature I wanted to add before making a playable HTML5 release. Now I want to clean up the movement system, add Tutorial Bingo back into the game, and iron out any bugs that prevent shipping. <br>
<br>
Autopathing to attack targets, skill targets, and item targets still rely 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'm going to update the movement system so that the character can autopath after a moving floor item and pick it up once within reach. <br>
<h2>what must be done </h2><br>
Autopathing to attack targets, skill targets, and item targets still partially rely 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>
<h2>the current movement system </h2><br>
(diagram of movement) <br>
For now, I'll update the movement system so that 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 for them 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 . It needs to . <br>
Before, it only set the next waypoint and built a path between the character and the waypoint. 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>
<h2>flaws + fixes </h2><br>
<h3>the character receives a waypoint instead of the target, so he is unaware of his target's movement </h3>
A target can either be a position (as with click-to-move) or an object (as with autopath-to-item). For consistency's sake, the single entry point for movement for the old system only accepted objects. When clicking-to-move, a waypoint Position2D object is generated at the global mouse position and fed to the character. <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>
<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>
For more consistency, I took it a step further and also generated waypoints at the position of object targets. However, the system doesn't require a waypoint, only an object with a global position. Providing the goal directly to the character instead of a waypoint not only resolved issues but also simplified my code. <br>
<br>
<h3>the character never stops autopathing, even after picking up the item </h3>
Previously, the movement AI relied on conditional statements in its process to detemine arrival at the goal. Instead, the <a href="../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. <br>
<br>
This meant the character never truly arrived and never knew to halt the movement process or clear movement variables. Moving the conditional statements from _process to the function that handles the outcome of movement events. <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="../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>
<h2>just a few changes makes a big difference </h2><br>
<li>Kitty loves supervising all chores, but his favorite is changing the bedding. He loves when I make waves with the sheets. </li>
<li>Finally, the character follows a moving target. </li>
</ul>
<br>
<h3>thursday, june 10 </h3>
<ul>
<li>I got groceries at Target, so I had to peak into the Gamestop next-door. What happened? Even the Nintendo game section is small now, and 70% of the store is dedicated to Star Wars and anime clothes and toys. It's been trending this way for years, but at least they had a wall of Nintendo games before. They only had a few used games and controllers, and I didn't see any consoles at all. It looks like Hot Topic now, minus band merch. </li>
<li>Target had lots of corpo pride displays scattered through the store, but Gamestop didn't have any at all lol. </li>
chimchooree
4 years ago