Visible enemy encounters can make planning when to battle a lot easier, but that’s not their only upside. Since visible enemies are events we can add all sorts of extra commands that can affect battles! So let’s learn how to make a preemptive strike QTE that can add states to our enemies.
Before we can start eventing our preemptive strike QTE we need to decide how we want it to work. To keep things simple, let’s plan for our QTE to work by having a popup appear and our player needs to hit the ‘OK’ button before the popup disappears for the effect to happen. There are a few possible effects a successful preemptive strike could have, like damaging the enemy HP or buffing our party, but for this tutorial let’s have it add a state to the entire enemy party.
Since we want to use popups, we’ll need to add some images to our picture folder so that we can have them appear. It’s easy enough to resize a few default icons to use:
And while we’re resizing the icons, we could make them even larger to work as message box faces so our player knows exactly what’s happening at the start of battles:
With a basic idea for the QTE decided on and our popup pictures added to our project, we can get to the eventing!
First thing our QTE needs is to have the popup appear. Since we’re using an image as the popup, the show picture command will work perfectly. We could have the popup appear in the center of the screen when it’s activated, but why don’t we have it appear right above the enemy event our player is about to fight?
To do that, we’ll need two variables we can set to the event’s X and Y position on the screen. We can set the variables to the Screen X or Screen Y through the Game Data option, which will give us the pixel location that our show picture command needs.
With both the X and Y variables set, we can have our popup appear over the event.
But there’s a problem! If we use only the event’s X and Y, our picture ends up covering most of the event on the screen. That’s because the Screen X/Y is determined by the bottom of the event, not from the center of the sprite.
Luckily there is an easy fix, we just need to subtract 48 (or however much you want) to have the popup look like it’s floating above the event.
Now that our popup is appearing in the right spot, we can get to the quick time portion of our QTE.
To get our QTE working properly, we’ll use a loop with a conditional branch that checks for a button press. If the button is hit then we can visually show it by increasing the popup’s size as well as set a variable so that we know the player was successful.
Though it’s not much of a QTE without a time limit, so before the loop starts we need to set a variable to however long we want the QTE to last (in this case 20 frames) and subtract 1 from that variable and add a 1-frame wait to the end of the loop to count down. Then we can add a conditional branch that checks if our time variable has hit 0 and if it has then the loop is broken and the QTE was failed.
Now we can make a common event where the popup appears, the QTE loop occurs, and then it wraps up by removing the popup picture.
Since it’s all set in a common event, we can easily add it to any visible enemy encounters that need it.
Of course, setting up the preemptive strike means nothing if it doesn’t affect the enemy! So we need to add in a Battle Event to all of our troops that can be affected by the preemptive strike. We want the effect to occur at the start of the battle, so we need to put the event condition to Turn 0.
The battle event itself is pretty simple for this tutorial, we need a conditional branch to check if the variable we used to check for a successful ‘OK’ button push is 1, and if it is then the preemptive strike’s effect occurs. Our effect has a battle animation and a message show to explain to the player what the preemptive strike did, along with affecting the entire enemy troop with the Confusion state.
We also want to reset the variables we used to keep track of the timer and if the button was pushed back to 0, so they’re ready to be reused elsewhere.
Now that our QTE and battle events are ready, we can playtest to see it in action. You may need to tweak parts of the event such as the QTE’s time to make it work well with your own project, but the only way to know that is to playtest and get feedback on the timing.
We could leave our preemptive strike QTE as-is and it will work perfectly well in-game, but our players may end up getting so used to having to hit ‘OK’ before a battle starts that they don’t even think about spamming ‘OK’ when they run into an enemy. That’s fine for some games, but what if we wanted to make sure our player needs to think before reacting?
One way we can keep our players from spamming ‘OK’ is to have multiple possibilities when it comes to the preemptive strike effect. Instead of it always adding the Confusion state to the enemy troop, we could have the effect buff the enemies instead if the player hits ‘OK’ when it’s a negative popup.
Much of this event will be similar to our first version, with just a few changes to work our new negative popup into it. We can find the popup’s location the same way but instead of just showing the popup picture we need to use the control variables command to randomly pick a number between 1 and 2 (since we only will have two possible popups in this example). We can use the same variable we used as the “‘OK’ was hit” variable in the first version, so that we can keep our enemy troop battle event the same as before with minor additions.
When the variable is 1 our positive preemptive strike popup will appear, and when the variable is 2 our negative popup appears.
The loop portion of the event doesn’t need too much extra work, though we need to adjust where we set the “‘OK’ was hit” variable. Since we already set the variable to 1 or 2, we don’t want to change it if ‘OK’ is pressed. Instead, we will set it back to 0 if the QTE is missed, so nothing will occur at the start of the battle.
All together, our new common event looks pretty similar to the first version:
With the common event playing before the battle starts, the last thing we need is to add the negative preemptive strike’s effect to the battle event. It will be contained in a conditional branch that checks if the variable is 2, and if it is then the Buffed state (which ups attack and defense) is given to the enemy troop, making them harder to defeat.
All that’s left is to playtest and make sure both popups are working.
Now that we know how to make a preemptive strike QTE, what effects would you give it for your own games?
Whenever I start a new project, my first thought when seeing the world map tiles is “Nah, I won’t need that here”... if I want a world map, I’d probably parallax it to have it really fit the world I have in mind. But on the other hand, it’s a shame to just neglect these neat tiles, even if you don’t plan on having an actual world map. So let’s have a look at 6 ways to (mis)use these tiles!
For the past month, you’ve been hard at work on your absolute best game, one that will showcase the apex of your skills and the RPG Maker MZ engine. You’ve created assets, worked on maps, and struggled through events. You’ve had many sleepless nights, pushing yourself, your abilities, and your caffeine tolerance to their limits. But now your hard work has paid off…