This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
ff3:ff3us:tutorial:events:action [2017/12/15 00:41] lockirby2 |
ff3:ff3us:tutorial:events:action [2019/02/12 10:38] (current) |
||
---|---|---|---|
Line 1: | Line 1: | ||
===== Action Queues ===== | ===== Action Queues ===== | ||
- | One question that you may have been asking yourself is "How do I make the characters move"? Action queues contain a set of actions that you want a character to perform. | + | One question that you may have been asking yourself is "How do I make the characters move?" |
- | ===== Starting an Action Queue ===== | + | ==== Starting an Action Queue ==== |
Starting an action queue works just like executing any other event command, although the number of parameters can vary depending on how many actions you want the character to take. Any command between $00 and $34 will start an action queue for one character. | Starting an action queue works just like executing any other event command, although the number of parameters can vary depending on how many actions you want the character to take. Any command between $00 and $34 will start an action queue for one character. | ||
Line 10: | Line 10: | ||
* $10 - $2F: Non-player characters. | * $10 - $2F: Non-player characters. | ||
- | {{: | + | {{ : |
- | {{: | + | {{ : |
* $30: The camera. | * $30: The camera. | ||
* $31 - $34: The characters in the party. | * $31 - $34: The characters in the party. | ||
- | ===== The Second Byte ===== | + | ==== The Second Byte ==== |
The main purpose of the second byte is to tell the game how long the action queue will be. Most of the time, you should decide what actions you want to put in the queue before filling in this byte. You can have up to $7F (127 in decimal) actions in a queue, but it's unlikely that you will need anywhere near that many. | The main purpose of the second byte is to tell the game how long the action queue will be. Most of the time, you should decide what actions you want to put in the queue before filling in this byte. You can have up to $7F (127 in decimal) actions in a queue, but it's unlikely that you will need anywhere near that many. | ||
Line 22: | Line 22: | ||
This byte also allows you to tell the game whether you want to finish the character' | This byte also allows you to tell the game whether you want to finish the character' | ||
- | ===== The Actions | + | ==== The Actions ==== |
- | This is the main meat of the action queue, containing the actions that you want the character to perform. | + | This is the meat of the action queue, containing the actions that you want the character to perform. |
- | By default, a character will actually take footsteps when they are told to move somewhere. | + | By default, a character will actually take footsteps when they are told to move somewhere. |
- | You should also take note of the E0 command. | + | You should also take note of the $E0 command. |
- | All action queues need to be ended with the $FF command. | + | All action queues need to be ended with the $FF command. |
- | ===== Our First Action Queue ===== | + | ==== Our First Action Queue ==== |
- | It's finally time to fix our problem from earlier. In order to prevent the event from repeating, we want the party to step off the event tile before the event ends. We could use $00 to begin an action queue for Terra, but we don't know who will be leading the party when the player steps on the event tile. If the player were to switch Biggs to the front of the party, our event would fall apart. | + | It's finally time to fix the repetition of the cutscene. In order to prevent the event from repeating, we want the party to step off the event tile before the event ends. We could use $00 to begin an action queue for Terra, but we don't know who will be leading the party when the player steps on the event tile. If the player were to switch Biggs to the front of the party, our event would fall apart. |
We'll come back to the second byte later. | We'll come back to the second byte later. | ||
Line 40: | Line 40: | ||
The body of this queue is very straightforward. | The body of this queue is very straightforward. | ||
- | Now we need to fill in the second byte. Our action queue only contains two bytes ($80 and $FF), so we'll start with $02. We also want to wait for the party' | + | Now we need to fill in the second byte. Our action queue only contains two bytes ($80 and $FF), so we'll start with $02. We also want to wait for the party' |
And that's it! The resulting action queue is 31 82 80 FF. As of now, this is the whole event:\\ | And that's it! The resulting action queue is 31 82 80 FF. As of now, this is the whole event:\\ | ||
{{: | {{: | ||
+ | |||
+ | ==== A Larger Example ==== | ||
+ | |||
+ | Right now, the event uses a red flash to indicate that the guards are approaching. | ||
+ | |||
+ | As before, our first goal is to determine which action queue to begin. | ||
+ | |||
+ | The NPCs aren't easily noticed because they are all in the top-left hand corner. | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | Now we can cross-reference this with the Event Commands Document, which states that we can use $10 to move NPC #0 and $11 to use NPC #1. We will need to create a separate action queue for each of the two guards. | ||
+ | |||
+ | First of all, we need to move the two guards to the bottom of the screen, which can be accomplished by using the $D5 command in the action queue. | ||
+ | |||
+ | Presumably, the guards would be running towards the Magitek Armour, ready for attack. | ||
+ | |||
+ | === NPC #0 === | ||
+ | |||
+ | Let us say that NPC #0 is the one who will appear at (37, 58). This guard won't be able to approach all the way to the Magitek Armor because there is a steam wheel in his path. This means that we will need to break down his movements into several actions: | ||
+ | |||
+ | - Take four steps upwards, approaching the steam wheel | ||
+ | - Take one diagonal step up/right, in order to avoid the steam wheel | ||
+ | - Take one more step upwards to get closer to the party. | ||
+ | |||
+ | The sequence of commands that can accomplish this is 8C A0 80. | ||
+ | |||
+ | Finally, we need to calculate the second byte. After some counting, we can determine that the action queue is eight bytes long. In this case, we do **not** want to add $80 to the second byte. We should not wait for this guard to finish walking because we want the second guard to move at the same time. | ||
+ | |||
+ | The entire action queue for the first guard is 10 08 D5 25 3A C3 8C A0 80 FF. | ||
+ | |||
+ | === NPC #1 === | ||
+ | |||
+ | This guard could simply run up towards the party and stop somewhere. | ||
+ | |||
+ | - Walk up three steps | ||
+ | - Turn left | ||
+ | - Delay for a moment with the E0 command (so that the player can see the guard looking left) | ||
+ | - Turn right | ||
+ | - Delay for a moment | ||
+ | - Walk up four steps | ||
+ | |||
+ | That's quite a few steps, but it's easy to piece together with the Movement Action Commands page as a reference. | ||
+ | |||
+ | === Finishing up === | ||
+ | |||
+ | Now that we have the action queues sorted out, we need to look at some of the nuts and bolts to make it all work. Before the action queues are started, the NPCs need to be " | ||
+ | |||
+ | After the queues have ended, there is one issue to be sorted out. We want to wait for both guards to reach the player before initiating the dialogue box. We wait for NPC #1's action queue to finish before continuing, but we don't wait for NPC #0. For all we know, NPC #0 will still be walking when NPC #1 finishes moving. | ||
+ | |||
+ | Finally, we want to erase the NPCs after the battle is fought. | ||
+ | |||
+ | After all the changes we have made, this event is starting to look hefty in size. Here is the finished product: | ||
+ | {{: |