This chapter is going to cover common events. You have probably seen the relevant tab within the RPG Maker VX Ace (RMVXA) Database already and are probably wondering what it’s about. Well, here’s the summary:

• A common event can be called using the Call Common Event command from any other event.
• It is useful for eventing things that you will repeat many times over during the course of your game. You can probably already think of two or three occasions on which this is true in the game we’ve been making throughout this book.
• A common event can have an Autorun or Parallel Process trigger, contingent on a certain conditional switch being on, as defined in the Common Events tab.
• Common events have a limit of one page—no more, no less.
• Common events are the only way to trigger events on item and skill use.

The final point is most important to what we want to do in the next chapter. Of course, this is as good a time as any to show off the Common Events tab itself. (See Figure 9-1.)

Not much to it, literally. That should not come as a surprise, given that common events are just another type of event. A common event can have a trigger of None (in which case, it will always trigger when called), Autorun, or Parallel Process. In the latter two cases, the conditional switch has to be on for the common event to trigger. We could have a two-line common event that contains the two Control Variable commands we use for our Parallel Process transfer events. There’s a particularly neat item concept I learned how to event some time ago that I’m going to share in this chapter. Do you want to Escape from a dungeon automatically?

The Exit Item/Skill

Envision this scenario: The player has gotten through a particularly long dungeon and defeated the boss at the end. His/Her resources were sorely diminished, and he/she needs to get back to town. Most role-playing games (RPGs) include a skill that automatically returns the player to the entrance to the dungeon, thereby bypassing the trip back.

To create an item or skill that will allow the player to exit a dungeon automatically, we’ll need the following:

• A common event that checks to see which dungeon the player is currently in. If the player is not inside a dungeon, the event will return an error message. (You can also make it so that you can’t escape from certain dungeons.)
• We have to update the world map’s transfer event, so that it writes the dungeon location to a variable.
• We have to update our dungeons’ relevant transfer events, so that, in the case of the player exiting to the world map manually, the dungeon location variable is set to its default value.
• Last, we must actually create the item or skill that will hold this event.

Updating Our Transfer Events

First of all, we currently have two dungeons. (Given that the subquest well is right in town, let’s not count it for the sake of this exercise.) The dungeon where the player finds Gemini will be 1, and the tower will be 2. I’m going to call the variable in question DungeonLocation, for the sake of clarity. In the world map’s transfer events, you’ll want to find the two that lead to our dungeons and insert the appropriate Control Variable command, like so:

@>Conditional Branch: Variable [0002:X] == 28
   @>Conditional Branch: Variable [0003:Y] == 82
      @>Control Variables: [0011:DungeonLocation] = 1
      @>Transfer Player:[005:Goblin CaveF1F] (020,043), Up
      @>
   : Branch End
   @>
: Branch End
@>Conditional Branch: Variable [0002:X] == 13
   @>Conditional Branch: Variable [0003:Y] == 76
      @>Control Variables: [0011:DungeonLocation] = 2
      @>Transfer Player:[007:Tower of the VoidF1F] (025,049), Up
      @>
   : Branch End
   @>

Then, in both of the dungeons, we find the transfer event that leads the player to the world map and have DungeonLocation set itself to 0 in those.

Creating the Exit Scroll

Next, let’s create the item that will call the common event we want to make. Take a look at Figure 9-2 for details.

The Exit Scroll is occupying slot 17 in the Database (hurray for lifting those Lite version restrictions). We have it set so that it can only be used from the menu and is not consumed when used. Why? It’s easier to handle item consumption within the event itself. Instead of just having the item consume itself, it will prompt a choice when used. It asks the player if he/she wants to leave the dungeon. If the player says no, then the item is left intact. On the other hand, when the player says yes, the event determines what dungeon the player is currently in and transfers the player to its entrance, consuming one Exit Scroll in the process.

Creating the Exit Event Logic with Common Events

I use two common events for the exit event logic. Here’s the first common event:

• Name: ExitEvent
• Trigger: None

@>Text: -, -, Normal, Bottom
:     : Would you like to leave the dungeon?
@>Show Choices: Yes, No
: When [Yes]
   @>Call Common Event: [ExitEventBranches]
   @>
: When [No]
   @>
: Branch End

It’s nice and simple. We ask the player if he/she would like to leave the dungeon. If the player says no, we exit out of the event. If the player says yes, we call the second common event. I do it this way to reduce the clutter within one event. You could have a chain of common events, each calling the next one. The rest of the current common event is executed as applicable. For example, if you were to add a Control Variables command directly below the common event call, it would be processed before switching events. If you’re using Autorun or Parallel Process events, you have to be particularly careful of chaining common events in that way, as it could get messy really fast. Here’s the second common event called by the first:

@>Conditional Branch: Variable [0011:DungeonLocation] == 0
   @>Text: -, -, Normal, Bottom
   :     : You cannot use that here!
   @>
: Branch End
@>Conditional Branch: Variable [0011:DungeonLocation] == 1
   @>Change Items: [Exit Scroll], -1
   @>Control Variables: [0011:DungeonLocation] = 0
   @>Transfer Player:[003:Field 3] (027,082), Left
   @>
 : Branch End
@>Conditional Branch: Variable [0011:DungeonLocation] == 2
   @>Change Items: [Exit Scroll], -1
   @>Control Variables: [0011:DungeonLocation] = 0
   @>Transfer Player:[003:Field 3] (013,077), Down
   @>
 : Branch End
@>

DungeonLocation is equal to 0 at any time that the player is not within an applicable dungeon. If that is the case, then the player will get an error message, and the event will end without consuming an item. When DungeonLocation has a value, the player is transferred to the entrance of the dungeon equal to that value, but not before consuming an Exit Scroll and setting DungeonLocation to 0. What if we wanted an item to allow the player to return to the last visited town? We could have another variable to store the value of the last town visited by the player and then transport him/her directly inside when the item is used. You could even combine the DungeonLocation and TownLocation variables to make it so that you can only teleport to town if you are not inside a dungeon. That pretty much covers the use of common events, but this wouldn’t be much of a chapter if I ended it this quickly, right? Instead, I’m going to write up some other ideas that I’ve created over time that involve the use of common events. But first, have a skill version of Exit (Figure 9-3).

Creating an Enemy with a Shifting Anti-element Barrier

Some of the most classic RPG battles involve a boss that has the ability to become immune to a certain element. That is as easy as creating a skill that grants an appropriate state. However, what happens if we want a shifting barrier? That’s where common eventing comes in. Here’s what we’ll need:

• Creating the skill: It will have no other effects besides executing a common event.
• A monster to use the skill: We’ll want it to begin battle with an anti-element barrier already, as the shifting skill changes the barrier that the user already has.
• Three states that represent the elemental barriers: Taking a look at Noah, we see that he has relatively easy access to Earth, Thunder, and Water magic, so let’s have states for a barrier for each of those types.
• The common event to govern the skill itself
• A small troop event for the monster that will use the barrier change skill

I have future plans for the monster we’re creating. (They’ll be added as an encounter in Chapter 10.) For now, let’s complete this exercise. Check Figure 9-4, to see our Barrier Change skill.

Besides a simple message being displayed when someone uses the skill and calling the Barrier Change common event, the skill does nothing else. Check Figure 9-5 to see the monster that will use the Barrier Change skill.

As you can see, we have it so that the Spirit Essence will use Barrier Change starting on turn 3 and will recast it every third turn after that. Heal is used when the monster is at 40% HP or less, and Ice II will be used when it is at 50% HP or lower. Next, let’s create the appropriate states for our Barrier Change skill. I’ll show off the first one and leave the other two to you. Take a look at Figure 9-6, to see the first state.

The Anti-Earth barrier is automatically removed at the end of a battle but will also auto-remove itself if five turns have passed. As per its name, someone affected by this state will sustain no damage from Earth-based attacks. You can copy this state to do the same for Anti-Thunder and Anti-Water. The common event isn’t much more of a hassle, to be honest. We want the skill, when used, to change the monster’s active barrier, as previously noted. The relevant listing follows. You’ll quickly notice the Jump to Label command used to great effect. A cursory look at the common event will show that Anti-Water Barrier would be up pretty much permanently, if we did not have those label jumps, as the conditions for each branch are met in the branch preceding it. The blank 1 in Change Enemy State represents the first enemy placed in a particular troop. For ease of use, we’ll have our Spirit Essence be an army of one.  

@>Conditional Branch: [1.] is [Anti-Earth Barrier] Inflicted
   @>Change Enemy State: [1.], - [Anti-Earth Barrier]
   @>Change Enemy State: [1.], + [Anti-Thunder Barrier]
   @>Jump to Label: Done
   @>
: Branch End
@>Conditional Branch: [1.] is [Anti-Thunder Barrier] Inflicted
   @>Change Enemy State: [1.], - [Anti-Thunder Barrier]
   @>Change Enemy State: [1.], + [Anti-Water Barrier]
   @>Jump to Label: Done
   @>
@>Conditional Branch: [1.] is [Anti-Water Barrier] Inflicted
   @>Change Enemy State: [1.], - [Anti-Water Barrier]
   @>Change Enemy State: [1.], + [Anti-Earth Barrier]
   @>Jump to Label: Done
   @>
: Branch End
@>Label: Done

Last, let’s create a troop containing a single Spirit Essence and then add the following troop event:

Condition: Turn No. 0
Span: Battle
@>Change Enemy State: [1. Spirit Essence], + [Anti-Water Barrier]
@>Force Action: [1. Spirit Essence], [Barrier Change], Random
@>

We want the initial barrier to be Anti-Earth. However, if we apply the state without using the Barrier Change skill, we won’t get the skill use message. So, we intentionally start one step away at Anti-Water and then force the Spirit Essence to use Barrier Change as the battle starts, setting it on the correct state. You can Battle Test this new troop with a Noah at level 15 or so (so that he has access to the elements that the Spirit Essence can block) and then use the elemental spells, to make sure that the monster is shifting barriers correctly. It’s time for something a little more complicated.

Sneaky Like Ninjas: Creating the Smoke Bomb

I once had occasion to want to create an item that allows the player to escape combat without fail. My initial attempts were functional but overly complex. After getting quite a bit of help, I learned of a solution that requires only a tiny bit of scripting. Suffice it to say that using the Escape effect available for items and skills is actually a bad idea. See, that will allow the player to flee any battle. Fighting the final boss? I’d rather not. Let’s just Smoke Bomb out of there like ninjas. As you can already see, that’s a terrible idea. We want the player to be able to use the Smoke Bomb at any time he/she would be able to select the normal Escape command in the battle menu. As already noted, if you give an item the special Escape effect (you’ll want to give the item itself a scope of User), the player will be able to retreat from any battle. To counter that, we need a way to make sure that the player is allowed to escape the battle. Make your way to the Script Editor and take a look at the BattleManager module. Near the top of the page, you’ll see a particular variable named @can_escape. That variable shows up within the can_escape? method in BattleManager and determines whether or not the player can escape from a particular battle. By default, the player can escape from every randomly generated battle and all event-created (Battle Processing) battles that have the Can Escape check box toggled. Conversely, escape from an event battle with Can Escape untoggled is impossible. Now, let’s create the common event that will handle the Smoke Bomb logic. Of particular note is the fact that you can use script code within conditional branches to the same effect as the more standard uses I have covered up to now. To call a method using a script, you use the format Module.method. That’s why we have BattleManager.can_escape? in the following code.

@>Conditional Branch: Script: BattleManager.can_escape? == true
   @>Comment: Escape = TRUE
   @>Change Items: [Smoke Bomb], -1
   @>Text: -, -, Normal, Bottom
   :     : You distract the enemy with the Smoke Bomb and
   :     : escape!
   @>Abort Battle
   @>
: Else
   @>Comment: Escape = FALSE
   @>Text: -, -, Normal, Bottom
   :     : You can't escape from this fight!
   @>
: Branch End
@>

When the player uses a Smoke Bomb, we check to see if he/she can escape the fight in question. If the @can_escape variable returns true, the player can escape. In that case, we consume one Smoke Bomb, display a message, and abort the battle. If the player cannot, he/she will receive an error message saying as much, and the item will not be consumed. I’ll leave the creation of the item up to you. Now, there are two more things to discuss before the end of this chapter. Thing the first . . .

Making Specific Random Battles Inescapable

We have created an item that can be used to escape from a battle with no fail rate, so long as the player is allowed to escape it normally. Now, that brings up an interesting question: What happens if we want to make certain random battles inescapable? It’s as easy as creating a new method within the BattleManager module.

module BattleManager
  def self.set_can_escape(bool)
    @can_escape = bool
  end
end

The preceding method is a simple one-liner. The bool inside the parentheses is a method parameter (recall our use of these back in Chapter 3 with the custom damage formulas). Because @can_escape is meant to be either true or false (an assertion that you can verify by seeing how it is used within BattleManager), those are the values you should use for the method parameter. How do you use that new method? The easiest way is to have a troop event that triggers on Turn 0 and uses a script call for the new method. So, if you want to make it so that the player cannot escape from Slimes (for whatever reason), all you have to do is structure the troop event as follows:

Condition: Turn 0
Span: Battle
@>Script: BattleManager.set_can_escape(false)

Once the battle begins, you’ll notice that it is impossible to escape, whether via the Escape command or the use of Smoke Bombs. In this way, it is possible to make troops that prevent the player from escaping when encountered.

Additional Exercises

Before we end this chapter, I’ll leave some more exercises for you to tackle concerning common events.

1. Create a note that someone would write before embarking on a long journey. Leave it on a table for the player to find and add to his/her inventory.
   • You can have the note display its text when the player grabs it. Then, you make it a key item that cannot be consumed and have the common event, if the player ever wants to read its text again.
2. Make a troop with three enemies, in which one enemy gives a random anti-elemental barrier to its allies.
   • You can cover random with a variable similar to the seed we used for the treasure chest minigame. Just have the variable roll from 1 to 3.
   • Create one skill for each type of anti-elemental barrier.
   • The common event would have conditional branches for the three possible results. When the enemy with the skill uses it, the common event will trigger. The type of barrier will depend on the value of the variable and will be applied by means of Force Action. (Make sure you’re applying Force Action to the skill user; it will be best if you only have one enemy that can use this skill.) Following is some sample code:

@>Control Variables: [0018:BarrierUp] = Random No. (1...3)
@>Conditional Branch: Variable [0018:BarrierUp] == 1
   @>Force Action: [1.], [Anti-Earth Barrier], Last Target
   @>
: Branch End
@>Conditional Branch: Variable [0018:BarrierUp] == 2
   @>Force Action: [1.], [Anti-Thunder Barrier], Last Target
   @>
: Branch End
@>Conditional Branch: Variable [0018:BarrierUp] == 3
   @>Force Action: [1.], [Anti-Water Barrier], Last Target
   @>
: Branch End
@>

Summary

In this chapter, I covered common events and several applications related to them. Among these applications are creating a Smoke Bomb item that allows guaranteed escape from non-forced encounters and a shifting barrier skill. In the next chapter, I will cover all sorts of hidden things, such as treasures and passages.