Creating Skills with Different On-Map and Battle Effects
August 31, 2021
August 31, 2021

Creating Skills with Different On-Map and Battle Effects

Creating Skills with Different On-Map and Battle Effects



August 31, 2021

Many of us have played a Pokemon game and seen HMs in action both in battles and on maps, making the moves extra useful. But what if we wanted to do something similar in our own RPG Maker games?

We’ve gone over making an item that does different things in battles and on maps in a previous tutorial, but after finishing that one up I wondered if there was another way to set up the common event, and if the same thing could work with skills.

But before we get into the common event version, let’s check out a simpler event-based one.

Checking if a Party Member Knows the Skill

For this example, let’s make a bush that can only be cut down if a party member knows the skill Cut. If one of them does know Cut, then the player can choose whether or not to use it on the bush. When Cut is used, then the bush event’s self-switch A will be turned on so that its second page will be active and allow the player to pass by the now-removed bush.

First thing we need is our Cut skill. We just need a normal skill for this situation, so our Occasion can be set to ‘Battle Screen’ and the damage formula only injures the enemies.

With the skill ready, we can move on to the bush event. The most important part of the event is the conditional branch that will check if a party member knows the skill or not. For this example, let’s just see if Priscilla knows Cut. If we wanted to check other party members then we would need to make sure that each actor has their own conditional branch.

If Priscilla does know Cut, then we can have a simple yes/no choice to let the player decide if they want Priscilla to cut the bush down or not. If they choose ‘yes’, we can play an animation on the bush event and turn its self-switch A On. At the end of that we’ll need to add an Exit Event Processing command since we don’t want the event to move on to the next possible actor if the bush has already been cut down.

While it’s not included here, we could also remove Cut’s MP cost when the bush is cut down to keep the player from being able to spam it on all the possible bushes on the maps.

The last thing we’ll add to the bush event is a message at the end that will run if none of the checked actors know Cut or if the player decides not to use Cut, just so that we can be sure they know that the bush can be cut down.

Then we just need to playtest and make sure that our event works.

We need to make sure that it works properly when Priscilla knows the Cut skill and when she doesn’t, so adding a nearby extra event to add/remove Cut from each actor who can learn it while testing is a good idea.

Now that we know one way to use skills on maps, let’s take a look at a version where the players need to choose when and where to use the skills.

Setting up Our Skills and Events

First thing we’ll need are the skills and the events that can be affected. Let’s make two skills this time, Cut for getting rid of tall grass and Smash for removing boulders. We’ll be making use of eventing tricks we learned in the bomb tutorial for this, so make sure you’ve read that for more detailed explanations of certain lines of code.

We can make the Cut skill target any number of enemies for whatever cost feels fair to our games (in this example, it’ll hit all enemies for 10 MP). The most important thing is to set its Occasion to ‘Always’, so that we can use it in and out of battle. We also need to make sure that the skill calls our common event that will control the skill’s effect outside of battle. Then we just need to set up the damage formula.

The damage formula includes an important condition before the actual damage is calculated. The code if ($gameParty.inBattle()) {$gameSwitches.setValue(1, true)}; , lets us check if the skill is being used in battle and if it is then switch 1 is turned On. We’ll be using that switch in the common event to judge if the player is on the map or not later. After the semicolon, we can include the actual damage formula for this skill.

Having the Cut skill ready means nothing if we don’t have some tall grass to cut though, so let’s put our grass event together. The first page has a message that lets the player know how to get rid of the grass, and its second page (which appears when its self-switch A is turned On) is set so that the player can walk over it. The most important piece is the <cutable> notetag, which we’ll need to check in the common event.

Our Smash skill is similar to Cut, with the main difference being the Scope being ‘1 Enemy’ and MP Cost changed to 5. But the damage formula, with the battle check, and the common event called is the same.

And with our Smash skill existing, we need our boulder event. Its two pages are set up like the grass event, with the main difference being its <smashable> notetag.

With our skills and events ready, we need to move on to the common event that will let our skills actually affect the events.

Creating the Common Event

Our common event is where all the on-map things will happen, so the first thing we need to have is a check for if switch 1 is On. If it is On, then that means the skill was used in battle and we don’t want the on-map parts to play. So we can just turn switch 1 back off and end the event right there.

If we get past that first conditional branch, then that means the skill was used on a map and we need to look at the possible event in front of the player. To make sure we’re checking the tile right in front of the player we need to check their direction and use that to determine what tile should be checked. The code $gameMap.eventIdXy($gamePlayer.x, $gamePlayer.y) gets us the event id of any event right where the player is standing, so we can use that as a base to check the tile in front of the player by adding or subtracting 1 from the X or Y amounts. For example, if the player is facing down then that means the tile we need to check is located at Y + 1, and if the player is facing left then we need to subtract 1 from the X.

We’re having both Cut and Smash call the same common event, so we need to make sure our event knows which skill was used, which is easy enough to do by saving the skill id into a variable. And since each actor has their own skills, we also want to save who actually used the skill so that we can check that later.

If there isn’t an event in front of the player, then we can skip over all the skill checks and jump right to the end where we refund the player for the skills’ costs since the skill isn’t actually used.

Now we’ve reached the point in the event where we need to check if the skill was used in the right place. Since our Cut skill’s id is 6, we need to check if the skill id variable we previously saved equals that (and if it doesn’t, then that means Cut wasn’t used so we can ignore everything in the conditional branch). If Cut was used, then we need to check the event for the <cutable> notetag using the script call: $gameMap.event($gameVariables.value(1)).event().meta.cutable

When the event does include the <cutable> notetag, then we just need to do one final check to see if the event has already been cut down, and therefore has its self-switch A set to On already, with the script call:

$gameSelfSwitches.value([$gameMap._mapId, $gameVariables.value(1), 'A']) == true;

If the self-switch is already On, then we need the event to jump to the end of the event to refund the skill cost. But if the self-switch is Off, then we can safely destroy the event in our way! To play the default slash animation on the event and turn its self-switch A On, we need to have a script command with two script calls in it:

$gameTemp.requestAnimation([$gameMap.event($gameVariables.value(1))], 6);

$gameSelfSwitches.setValue([$gameMap._mapId, $gameVariables.value(1), 'A'], true);

With the grass event cut, we can reset our switches and variables used in this common event so that they’re ready to be used later (though since the switch should already be Off, it’s not actually needed here). Then all that’s left is to end the event since we don’t want to refund the skill after actually using it.

The Smash version will be very similar, with the main differences being that skill id variable needs to be set to Smash’s id (7 here), the notetag being checked is <smashable>, and the animation played is something fitting a boulder breaking.

The end of the common event is important to keep our player from accidentally draining all their actor’s MP or TP by trying to use the skill where it’s not needed. Since each skill has its own costs, we need to set up a conditional branch for each to give the skill’s user a refund. This is where the actor id variable we set up earlier comes into play, so that we give the right actor the refund.

All that’s left is to put it all together…

And playtest to make sure the skills are working right. If it’s used where it shouldn’t do anything, then the user should be refunded the right amount of MP.

And when Cut is used in the right spots then the grass events should be cut down.

Now our skills can do separate things inside and outside of battle! What would you make your skills do on maps?

Recommended Posts