extra
parent
46c50c1a27
commit
130a564035
@ -0,0 +1,41 @@
|
|||||||
|
<!--210610,200429-->
|
||||||
|
<h1>how to attack a moving target </h1>
|
||||||
|
july 8, 2021<br>
|
||||||
|
#ai #character #combat #design #movement <br>
|
||||||
|
<br>
|
||||||
|
Househunting has been unexpectedly time-consuming, but I'll share the tentative design for the attack-movement loop. Hopefully now that an offer was accepted, I'll find some time to iron out the design before packing and moving begins. <br>
|
||||||
|
<br>
|
||||||
|
The attack-movement loop needs to allow the character maintain attack range while attacking. The flow is complicated to follow, but this is how it works for now: <br>
|
||||||
|
<center><a target="_blank" href="/static/img/ent/attack-movement-loop-diagram.png">
|
||||||
|
<img src="/static/img/ent/attack-movement-loop-diagram.png" alt="(image: diagram of the attack movement loop)" width="500" height="233">
|
||||||
|
</a><br></center>
|
||||||
|
The code is color-coded by object. Warm gray is input, orange is the character's action module, yellow is the character, yellow-green is the character's equipment module, blue-green is the attack handler, blue is the AI's attack module, purple is the AI's movement module, pink is the AI, brown is the KnowledgeBase's MessageBus, and cool gray is the character's kinematic body. <br>
|
||||||
|
<br>
|
||||||
|
<h2>the loop explained </h2><br>
|
||||||
|
Upon attack input, the character sets up for attacking and creates an attack timer. On timeout, the character's weapon swings. If the character is out of range, the "out_of_range" signal is emitted. Otherwise, the weapon successfully swings, either emitting "target_dead" or "hit." <br>
|
||||||
|
<br>
|
||||||
|
The AI receives these signals. If the target was out of range, it sets up to follow attack target. <br>
|
||||||
|
<br>
|
||||||
|
Every AI tick, it prompts the character to pathfind to the target then sets the character's velocity to the current_dot (the first node the character is trying to reach in path) minus the character's global_position. <br>
|
||||||
|
<br>
|
||||||
|
Every frame, the character's _process(delta) method calls move_and_collide with velocity * speed * delta. If the character's velocity isn't 0,0, the "moved" event is published to the Knowledge Base's MessageBus. <br>
|
||||||
|
<br>
|
||||||
|
The movement handlers are subscribed to "moved," and will emit signals if the character reached either the next waypoint (the target or the chosen goal point at the end of the path) or the current dot (the first point along the pathfinding between the character and the goal point). <br>
|
||||||
|
<br>
|
||||||
|
The AI receives these signals. If the next waypoint is reached, it's removed from the list of waypoints, the "arrived_at_attack_target" signal is emitted, and movement is cleared. <br>
|
||||||
|
<br>
|
||||||
|
Then the AI receives the "arrived_at_attack_target" signal and prompts the character to begin the attack all over again. <br>
|
||||||
|
<br>
|
||||||
|
<h2>in-game </h2><br>
|
||||||
|
It works in-game, too, but it's pretty janky, especially without animations. If the slime is slow enough, the player character attacks until it gets too far away, moves back in range, and continues attacking. If it's too fast, though, she never gets to attack and jitters constantly after the slime. <br>
|
||||||
|
<br>
|
||||||
|
Too fast: <br>
|
||||||
|
<center><img src="/static/img/ent/attack-follow.gif" alt="(image: Angel follows slime)"></center>
|
||||||
|
<br>
|
||||||
|
I'll work it out sooner or later, dependent on how hectic moving turns out to be. <br>
|
||||||
|
<br>
|
||||||
|
(By the way, that's my first gif recorded and edited entirely in ffmpeg. It's not pretty, but at least I could write my bash script without relying on copypasta code from forums this time. I was trying to follow the documentation website before, but it's unreadable. The man page is so much easier to understand and search through.) <br>
|
||||||
|
<br>
|
||||||
|
<br>
|
||||||
|
Last Updated July 10, 2021
|
||||||
|
<br>
|
@ -0,0 +1,41 @@
|
|||||||
|
<!--210610,200429-->
|
||||||
|
<h1>how to attack a moving target </h1>
|
||||||
|
july 8, 2021<br>
|
||||||
|
#ai #character #combat #design #movement <br>
|
||||||
|
<br>
|
||||||
|
Househunting has been unexpectedly time-consuming, but I'll share the tentative design for the attack-movement loop. Hopefully now that an offer was accepted, I'll find some time to iron out the design before packing and moving begins. <br>
|
||||||
|
<br>
|
||||||
|
The attack-movement loop needs to allow the character maintain attack range while attacking. The flow is complicated to follow, but this is how it works for now: <br>
|
||||||
|
<center><a target="_blank" href="/static/img/ent/attack-movement-loop-diagram.png">
|
||||||
|
<img src="/static/img/ent/attack-movement-loop-diagram.png" alt="(image: diagram of the attack movement loop)" width="500" height="233">
|
||||||
|
</a><br></center>
|
||||||
|
The code is color-coded by object. Warm gray is input, orange is the character's action module, yellow is the character, yellow-green is the character's equipment module, blue-green is the attack handler, blue is the AI's attack module, purple is the AI's movement module, pink is the AI, brown is the KnowledgeBase's MessageBus, and cool gray is the character's kinematic body. <br>
|
||||||
|
<br>
|
||||||
|
<h2>the loop explained </h2><br>
|
||||||
|
Upon attack input, the character sets up for attacking and creates an attack timer. On timeout, the character's weapon swings. If the character is out of range, the "out_of_range" signal is emitted. Otherwise, the weapon successfully swings, either emitting "target_dead" or "hit." <br>
|
||||||
|
<br>
|
||||||
|
The AI receives these signals. If the target was out of range, it sets up to follow attack target. <br>
|
||||||
|
<br>
|
||||||
|
Every AI tick, it prompts the character to pathfind to the target then sets the character's velocity to the current_dot (the first node the character is trying to reach in path) minus the character's global_position. <br>
|
||||||
|
<br>
|
||||||
|
Every frame, the character's _process(delta) method calls move_and_collide with velocity * speed * delta. If the character's velocity isn't 0,0, the "moved" event is published to the Knowledge Base's MessageBus. <br>
|
||||||
|
<br>
|
||||||
|
The movement handlers are subscribed to "moved," and will emit signals if the character reached either the next waypoint (the target or the chosen goal point at the end of the path) or the current dot (the first point along the pathfinding between the character and the goal point). <br>
|
||||||
|
<br>
|
||||||
|
The AI receives these signals. If the next waypoint is reached, it's removed from the list of waypoints, the "arrived_at_attack_target" signal is emitted, and movement is cleared. <br>
|
||||||
|
<br>
|
||||||
|
Then the AI receives the "arrived_at_attack_target" signal and prompts the character to begin the attack all over again. <br>
|
||||||
|
<br>
|
||||||
|
<h2>in-game </h2><br>
|
||||||
|
It works in-game, too, but it's pretty janky, especially without animations. If the slime is slow enough, the player character attacks until it gets too far away, moves back in range, and continues attacking. If it's too fast, though, she never gets to attack and jitters constantly after the slime. <br>
|
||||||
|
<br>
|
||||||
|
Too fast: <br>
|
||||||
|
<center><img src="/static/img/ent/attack-follow.gif" alt="(image: Angel follows slime)"></center>
|
||||||
|
<br>
|
||||||
|
I'll work it out sooner or later, dependent on how hectic moving turns out to be. <br>
|
||||||
|
<br>
|
||||||
|
(By the way, that's my first gif recorded and edited entirely in ffmpeg. It's not pretty, but at least I could write my bash script without relying on copypasta code from forums this time. I was trying to follow the documentation website before, but it's unreadable. The man page is so much easier to understand and search through.) <br>
|
||||||
|
<br>
|
||||||
|
<br>
|
||||||
|
Last Updated July 10, 2021
|
||||||
|
<br>
|
@ -0,0 +1,41 @@
|
|||||||
|
<!--210610,200429-->
|
||||||
|
<h1>how to attack a moving target </h1>
|
||||||
|
july 8, 2021<br>
|
||||||
|
#ai #character #combat #design #movement <br>
|
||||||
|
<br>
|
||||||
|
Househunting has been unexpectedly time-consuming, but I'll share the tentative design for the attack-movement loop. Hopefully now that an offer was accepted, I'll find some time to iron out the design before packing and moving begins. <br>
|
||||||
|
<br>
|
||||||
|
The attack-movement loop needs to allow the character maintain attack range while attacking. The flow is complicated to follow, but this is how it works for now: <br>
|
||||||
|
<center><a target="_blank" href="/static/img/ent/attack-movement-loop-diagram.png">
|
||||||
|
<img src="/static/img/ent/attack-movement-loop-diagram.png" alt="(image: diagram of the attack movement loop)" width="500" height="233">
|
||||||
|
</a><br></center>
|
||||||
|
The code is color-coded by object. Warm gray is input, orange is the character's action module, yellow is the character, yellow-green is the character's equipment module, blue-green is the attack handler, blue is the AI's attack module, purple is the AI's movement module, pink is the AI, brown is the KnowledgeBase's MessageBus, and cool gray is the character's kinematic body. <br>
|
||||||
|
<br>
|
||||||
|
<h2>the loop explained </h2><br>
|
||||||
|
Upon attack input, the character sets up for attacking and creates an attack timer. On timeout, the character's weapon swings. If the character is out of range, the "out_of_range" signal is emitted. Otherwise, the weapon successfully swings, either emitting "target_dead" or "hit." <br>
|
||||||
|
<br>
|
||||||
|
The AI receives these signals. If the target was out of range, it sets up to follow attack target. <br>
|
||||||
|
<br>
|
||||||
|
Every AI tick, it prompts the character to pathfind to the target then sets the character's velocity to the current_dot (the first node the character is trying to reach in path) minus the character's global_position. <br>
|
||||||
|
<br>
|
||||||
|
Every frame, the character's _process(delta) method calls move_and_collide with velocity * speed * delta. If the character's velocity isn't 0,0, the "moved" event is published to the Knowledge Base's MessageBus. <br>
|
||||||
|
<br>
|
||||||
|
The movement handlers are subscribed to "moved," and will emit signals if the character reached either the next waypoint (the target or the chosen goal point at the end of the path) or the current dot (the first point along the pathfinding between the character and the goal point). <br>
|
||||||
|
<br>
|
||||||
|
The AI receives these signals. If the next waypoint is reached, it's removed from the list of waypoints, the "arrived_at_attack_target" signal is emitted, and movement is cleared. <br>
|
||||||
|
<br>
|
||||||
|
Then the AI receives the "arrived_at_attack_target" signal and prompts the character to begin the attack all over again. <br>
|
||||||
|
<br>
|
||||||
|
<h2>in-game </h2><br>
|
||||||
|
It works in-game, too, but it's pretty janky, especially without animations. If the slime is slow enough, the player character attacks until it gets too far away, moves back in range, and continues attacking. If it's too fast, though, she never gets to attack and jitters constantly after the slime. <br>
|
||||||
|
<br>
|
||||||
|
Too fast: <br>
|
||||||
|
<center><img src="/static/img/ent/attack-follow.gif" alt="(image: Angel follows slime)"></center>
|
||||||
|
<br>
|
||||||
|
I'll work it out sooner or later, dependent on how hectic moving turns out to be. <br>
|
||||||
|
<br>
|
||||||
|
(By the way, that's my first gif recorded and edited entirely in ffmpeg. It's not pretty, but at least I could write my bash script without relying on copypasta code from forums this time. I was trying to follow the documentation website before, but it's unreadable. The man page is so much easier to understand and search through.) <br>
|
||||||
|
<br>
|
||||||
|
<br>
|
||||||
|
Last Updated July 10, 2021
|
||||||
|
<br>
|
@ -0,0 +1,41 @@
|
|||||||
|
<!--210610,200429-->
|
||||||
|
<h1>how to attack a moving target </h1>
|
||||||
|
july 8, 2021<br>
|
||||||
|
#ai #character #combat #design #movement <br>
|
||||||
|
<br>
|
||||||
|
Househunting has been unexpectedly time-consuming, but I'll share the tentative design for the attack-movement loop. Hopefully now that an offer was accepted, I'll find some time to iron out the design before packing and moving begins. <br>
|
||||||
|
<br>
|
||||||
|
The attack-movement loop needs to allow the character maintain attack range while attacking. The flow is complicated to follow, but this is how it works for now: <br>
|
||||||
|
<center><a target="_blank" href="/static/img/ent/attack-movement-loop-diagram.png">
|
||||||
|
<img src="/static/img/ent/attack-movement-loop-diagram.png" alt="(image: diagram of the attack movement loop)" width="500" height="233">
|
||||||
|
</a><br></center>
|
||||||
|
The code is color-coded by object. Warm gray is input, orange is the character's action module, yellow is the character, yellow-green is the character's equipment module, blue-green is the attack handler, blue is the AI's attack module, purple is the AI's movement module, pink is the AI, brown is the KnowledgeBase's MessageBus, and cool gray is the character's kinematic body. <br>
|
||||||
|
<br>
|
||||||
|
<h2>the loop explained </h2><br>
|
||||||
|
Upon attack input, the character sets up for attacking and creates an attack timer. On timeout, the character's weapon swings. If the character is out of range, the "out_of_range" signal is emitted. Otherwise, the weapon successfully swings, either emitting "target_dead" or "hit." <br>
|
||||||
|
<br>
|
||||||
|
The AI receives these signals. If the target was out of range, it sets up to follow attack target. <br>
|
||||||
|
<br>
|
||||||
|
Every AI tick, it prompts the character to pathfind to the target then sets the character's velocity to the current_dot (the first node the character is trying to reach in path) minus the character's global_position. <br>
|
||||||
|
<br>
|
||||||
|
Every frame, the character's _process(delta) method calls move_and_collide with velocity * speed * delta. If the character's velocity isn't 0,0, the "moved" event is published to the Knowledge Base's MessageBus. <br>
|
||||||
|
<br>
|
||||||
|
The movement handlers are subscribed to "moved," and will emit signals if the character reached either the next waypoint (the target or the chosen goal point at the end of the path) or the current dot (the first point along the pathfinding between the character and the goal point). <br>
|
||||||
|
<br>
|
||||||
|
The AI receives these signals. If the next waypoint is reached, it's removed from the list of waypoints, the "arrived_at_attack_target" signal is emitted, and movement is cleared. <br>
|
||||||
|
<br>
|
||||||
|
Then the AI receives the "arrived_at_attack_target" signal and prompts the character to begin the attack all over again. <br>
|
||||||
|
<br>
|
||||||
|
<h2>in-game </h2><br>
|
||||||
|
It works in-game, too, but it's pretty janky, especially without animations. If the slime is slow enough, the player character attacks until it gets too far away, moves back in range, and continues attacking. If it's too fast, though, she never gets to attack and jitters constantly after the slime. <br>
|
||||||
|
<br>
|
||||||
|
Too fast: <br>
|
||||||
|
<center><img src="/static/img/ent/attack-follow.gif" alt="(image: Angel follows slime)"></center>
|
||||||
|
<br>
|
||||||
|
I'll work it out sooner or later, dependent on how hectic moving turns out to be. <br>
|
||||||
|
<br>
|
||||||
|
(By the way, that's my first gif recorded and edited entirely in ffmpeg. It's not pretty, but at least I could write my bash script without relying on copypasta code from forums this time. I was trying to follow the documentation website before, but it's unreadable. The man page is so much easier to understand and search through.) <br>
|
||||||
|
<br>
|
||||||
|
<br>
|
||||||
|
Last Updated July 10, 2021
|
||||||
|
<br>
|
@ -0,0 +1,41 @@
|
|||||||
|
<!--210610,200429-->
|
||||||
|
<h1>how to attack a moving target </h1>
|
||||||
|
july 8, 2021<br>
|
||||||
|
#ai #character #combat #design #movement <br>
|
||||||
|
<br>
|
||||||
|
Househunting has been unexpectedly time-consuming, but I'll share the tentative design for the attack-movement loop. Hopefully now that an offer was accepted, I'll find some time to iron out the design before packing and moving begins. <br>
|
||||||
|
<br>
|
||||||
|
The attack-movement loop needs to allow the character maintain attack range while attacking. The flow is complicated to follow, but this is how it works for now: <br>
|
||||||
|
<center><a target="_blank" href="/static/img/ent/attack-movement-loop-diagram.png">
|
||||||
|
<img src="/static/img/ent/attack-movement-loop-diagram.png" alt="(image: diagram of the attack movement loop)" width="500" height="233">
|
||||||
|
</a><br></center>
|
||||||
|
The code is color-coded by object. Warm gray is input, orange is the character's action module, yellow is the character, yellow-green is the character's equipment module, blue-green is the attack handler, blue is the AI's attack module, purple is the AI's movement module, pink is the AI, brown is the KnowledgeBase's MessageBus, and cool gray is the character's kinematic body. <br>
|
||||||
|
<br>
|
||||||
|
<h2>the loop explained </h2><br>
|
||||||
|
Upon attack input, the character sets up for attacking and creates an attack timer. On timeout, the character's weapon swings. If the character is out of range, the "out_of_range" signal is emitted. Otherwise, the weapon successfully swings, either emitting "target_dead" or "hit." <br>
|
||||||
|
<br>
|
||||||
|
The AI receives these signals. If the target was out of range, it sets up to follow attack target. <br>
|
||||||
|
<br>
|
||||||
|
Every AI tick, it prompts the character to pathfind to the target then sets the character's velocity to the current_dot (the first node the character is trying to reach in path) minus the character's global_position. <br>
|
||||||
|
<br>
|
||||||
|
Every frame, the character's _process(delta) method calls move_and_collide with velocity * speed * delta. If the character's velocity isn't 0,0, the "moved" event is published to the Knowledge Base's MessageBus. <br>
|
||||||
|
<br>
|
||||||
|
The movement handlers are subscribed to "moved," and will emit signals if the character reached either the next waypoint (the target or the chosen goal point at the end of the path) or the current dot (the first point along the pathfinding between the character and the goal point). <br>
|
||||||
|
<br>
|
||||||
|
The AI receives these signals. If the next waypoint is reached, it's removed from the list of waypoints, the "arrived_at_attack_target" signal is emitted, and movement is cleared. <br>
|
||||||
|
<br>
|
||||||
|
Then the AI receives the "arrived_at_attack_target" signal and prompts the character to begin the attack all over again. <br>
|
||||||
|
<br>
|
||||||
|
<h2>in-game </h2><br>
|
||||||
|
It works in-game, too, but it's pretty janky, especially without animations. If the slime is slow enough, the player character attacks until it gets too far away, moves back in range, and continues attacking. If it's too fast, though, she never gets to attack and jitters constantly after the slime. <br>
|
||||||
|
<br>
|
||||||
|
Too fast: <br>
|
||||||
|
<center><img src="/static/img/ent/attack-follow.gif" alt="(image: Angel follows slime)"></center>
|
||||||
|
<br>
|
||||||
|
I'll work it out sooner or later, dependent on how hectic moving turns out to be. <br>
|
||||||
|
<br>
|
||||||
|
(By the way, that's my first gif recorded and edited entirely in ffmpeg. It's not pretty, but at least I could write my bash script without relying on copypasta code from forums this time. I was trying to follow the documentation website before, but it's unreadable. The man page is so much easier to understand and search through.) <br>
|
||||||
|
<br>
|
||||||
|
<br>
|
||||||
|
Last Updated July 10, 2021
|
||||||
|
<br>
|
Binary file not shown.
After Width: | Height: | Size: 41 KiB |
Loading…
Reference in New Issue