blogging; capitalize blessfrey in boxes
chimchooree
4 years ago
parent
99112ab82f
commit
119a4fc3c9
@ -1,6 +1,34 @@
|
||||
<!--210429,210402-->
|
||||
<h1>how to get a character to follow a moving target </h1>
|
||||
<h1>how my characters follow a moving target </h1>
|
||||
june 10, 2021<br>
|
||||
#ai #character #movement <br>
|
||||
<br>
|
||||
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>
|
||||
<br>
|
||||
<h2>the current movement system </h2><br>
|
||||
(diagram of movement) <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>
|
||||
<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>
|
||||
<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>
|
||||
<br>
|
||||
|
||||
Loading…
Reference in New Issue