We all love getting items while playing games, but some of them really only have one use. Wouldn’t it be fun to include some items that work one way in battles and do something else when exploring a map? So today let’s take a look at how to create a bomb that damages enemies in battles and can also open up holes in map walls.
There are quite a few ways we could make our bomb item work outside of battles, for this tutorial let’s learn two ways we can do it: using a conditional branch to check if we have a bomb and using a common event to check if an event can be blown up. First up, we’ll do the simpler conditional branch version.
No matter which method we’re using, the first thing we need is a bomb item. We’ll make this one a Regular Item with its Scope set to ‘All Enemies’ and its Occasion set to ‘Battle Screen’. The damage formula depends on the rest of our battle balance, so we’ll go with a simple 150 points of HP damage for this example.
With the item set up, we can quickly test it in-battle and make sure that it’s working and doing the amount of damage that we want.
Once we’re happy with the bomb in battle, we can move on to using it outside of battle. For our bomb’s effect, let’s make it break open a crack in the wall to reveal a secret passage that reaches a treasure chest. Since our walls (including the ceiling tile) are three tiles high we’ll need two events to cover the movement through the secret passage, one to enter the treasure room and one to exit it.
Our cracked wall event to enter the room needs two pages to work. The first page is where we need to check if the player has a bomb item in their inventory. If they don’t have one, then a simple message plays letting the player know something is strange about that crack. If they do have a bomb, then they are given the choice to use it on the wall. Choosing to use a bomb leads to the Change Items command removing one bomb, Show Animation playing a simple explosion, and the event’s self-switch A being turned On so that the second page is activated.
The second page is simply a move route to send the player into the treasure room. To make it look like our hero is passing through the hole in the wall, we need to set our player to Through On so they can pass right through the wall tiles. By having them Move Up once before turning Transparent On and moving up three more times it can look like they’re passing through the secret passage before popping back into view in the treasure room by turning both Through and Transparent Off.
Now our players can get into the treasure room, we need to give them a way to get back out. The return event is similar to our cracked wall’s second page, making use of the Through, Transparent, and Move Down move route commands to put them right in front of the cracked wall event.
With our secret passage events made and a bomb in our inventory, we can playtest to make sure it works well.
Our bomb item now has different functions inside and outside of battle, but it doesn’t feel like we’re giving complete control of the bombs to our player. So let’s look at another way we could event this so that our player needs to select the bomb to use it on a cracked wall event.
To get our bomb item usable outside of battles we need to decide how it will know what events to blow up and which to ignore. There are a few ways we could do it, such as checking each map and event id to see if it’s one we want effected, but for this item let’s have it check the event’s notetag section for a <boom> label. If the <boom> is there, then the event can be blown up by a bomb.
But to do that, we’ll need to make some changes in the database. First thing is to change its Occasion to ‘Always’ so that we can pick it both in and out of battle. We also need to have it call a common event that can perform the notetag check.
The last major change is to take our 150 in our damage formula and make it $gameSwitches.setValue(1, true); 150 . We’re turning a switch on so that we can see if the bomb is being used in battle or out of battle, because this switch will only be turned on if it's used in battle.
Checking if the bomb is used inside or outside of battle is really important, since by default item common events play after the damage is done… Which means that if you use a bomb to defeat all the enemies, the common event tied to it would play once you’re back on the map! By having the damage formula turn a switch On, then we can include a simple conditional branch at the start of the bomb’s common event to see if that switch is On and turn it Off and end the common event right there. If the switch isn’t On, then that means the item was used outside of battle and we can move forward in the common event.
After that conditional branch, we can get to the meat of the common event: checking for an event’s <boom> notetag. Before we can check for the notetag though, we need to figure out which event we’d be checking. Since our cracked wall event will only show up on a wall we only need to check the tile above our player, which we can do by setting variables to the player’s map X and map Y, and then remove 1 from the Y variable. Once those variables are set, we can use the Get Location Info to check for any event id at that spot.
This only checks for an event located on the tile above the player. If we wanted to check for an event on the tile the player is facing, then we’d need conditional branches that check which direction the player is facing and adjust our X and Y variables accordingly.
Now, there’s an important thing to keep in mind: if there isn’t an event where we’re checking, Get Location Info will return a 0. Since if there’s no event there isn’t a reason to check for a notetag, right after the Get Location Info command we should include a conditional branch to see if our variable is 0. If it is, then we can include a Jump to Label command to jump to the end of the event (which only plays if the bomb can’t be used there).
The label we’d be jumping to simply wraps up the event by informing the player that the bomb can’t be used there. Since our bomb item is consumed when we use it in the menu, we also need to replace it with the Change Items command so that our players can’t accidentally waste all their bombs.
If there is an event where we check then we can move along with the rest of our common event, where we check the event for the <boom> notetag. The script call to check an event’s notetag for <boom> is $gameMap.event(ID).event().meta.boom , where we can replace ID with the variable our Get Location Info command. That makes our script call $gameMap.event($gameVariables.value(1)).event().meta.boom
When the event doesn’t include the <boom> notetag, then the end of our common event plays and the player is informed that the bomb can’t be used there. But when the event does have the <boom> notetag, then we need to blow that wall up! To play an animation on that event, we’ll need to use the $gameTemp.requestAnimation([targets], animation); script call, where targets is where the animation will play and animation is the database number of the animation we want to play. So we need to replace targets with $gameMap.event($gameVariables.value(1)) and animation with 3, making our complete script call $gameTemp.requestAnimation([$gameMap.event($gameVariables.value(1))], 3);
To turn our event’s self-switch A On, we’ll use a script call we’ve used in previous tutorials, $gameSelfSwitches.setValue([$gameMap._mapId, $gameVariables.value(1), 'A'], true); . When both of those script calls play, our cracked wall event should properly explode and open up.
Last thing we need in this conditional branch is an Exit Event Processing command, so that the common event stops there and doesn’t try to play the very end of our event (since that should only play if the bomb can’t be used).
If we were to test our bomb as it currently is, we’d notice a problem almost right away: the bomb can be used on our cracked wall repeatedly, wasting our bomb supply! That’s because notetags are tied to the full event, not to pages, so our event only knows that the <boom> notetag is there and not that the wall has already been broken. So to save our player’s bomb inventory, we should include a second conditional branch that uses the script call $gameSelfSwitches.value([$gameMap._mapId, $gameVariables.value(1), 'A']) == true; to check if the event’s self-switch A is On. If it is, then we can use the Jump to Label command to jump to the end of the event (to tell our player that they can’t use their bombs there again).
All together, we end up with an event that looks like this:
With our common event ready, we just need an event to use it on. Our setup to get in and out of the treasure room is similar to our first version, with the cracked wall event having two pages and our return event being the same move route. The biggest difference is that our cracked wall event needs to have <boom> in the Note section.
Then we just need to playtest and make sure our bomb works properly. If we try to use it anywhere except in front of a cracked wall event, it should warn us that it can’t be used there. And if we do use it in front of the cracked wall, it should open up our secret passage.
What other ways could you use some of these mechanics in your 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…