If you have any amount of programming experience, you’re probably familiar with the use of switches and variables (especially the latter) in coding programs.

Switches? Variables? Pizza?

Yes. Yes. With pepperoni, please. Seriously, though, let me explain. Switches and variables in RPG Maker VX Ace (RMVXA) are similar to boxes in real life. They both hold information you would want to use later on. They are ubiquitous in video games as well. Don’t believe me? Here’s a small list of things that, with the use of switches and variables, you can influence in any video game:

• The ability to keep track of the number of chests opened during the course of the game (variables)
• The ability to determine whether a boss has been defeated or not (switches)
• Preventing the player from accessing a certain area without a key or some other device (switches)
• Changing a quest reward based on the method the player used to complete the quest. For instance, you could give a 300 gold reward for killing a group of bandits, and give a reduced reward if the player drives them off, sparing them, instead. (variables)
• Counting the amount of enemies left on a certain screen (variables)
• Counting the amount of steps your party has taken. (variables) This has several applications, such as causing a nonstandard Game Over when the player exceeds a certain number of steps or granting the player an achievement or skill. You could use a variable to increase or decrease the power of a skill as well.

As you must have noticed, you cannot make a video game without switches and variables!

Switches and Variables Do the Same Thing, Then?

Mostly, but there are differences. For switches, think of a light switch that has an on and an off state. You can set conditionals that only trigger when a certain switch is on or when said switch is off. Variables, on the other hand, can hold a number—any number that you can think of. Want to have-327 contained within a variable you call Bob? Sure, go right ahead! Basically, both switches and variables are used for storing relevant game information, but they are best used in different types of situations.

It is best to use a switch when you want to create a button/lever/switch in-game that is binary (that is to say, has exactly two states). It is best to use a variable when you have a situation that cannot be covered with a simple on/off state. For example, if you wanted to count how many goblins a player has defeated, you would have to store that information in a variable. On the other hand, if someone gave your character a quest to slay five goblins, you could have a switch flip to the “on” state after the fifth goblin is defeated.

While switch and variable theory is nice and all, let’s take some time to apply it.

Objectives:

• Add a button to the previously made map that creates an exit through which our intrepid hero can reach another map. After all, if I were him, I wouldn’t want to be cooped up in a single 13×17 map for eternity!
• Create the exit itself.

So, how do we go about adding the necessary items to the map? We are finally going to start dabbling with the functionality that gives RMVXA its reputation as a robust game-development engine that even a novice can use. If you look directly below the Game item on the menu toolbar, you’ll notice a trio of icons (they are to the left of the drawing tool icons).

• The first icon, which should have an orange square around it, if you haven’t interacted with these icons previously, is Map Mode. As the name suggests, having Map Mode selected allows you to add/remove tiles on your currently selected map. You can press F5 to switch to Map Mode at any time.
• The second icon is the Event Editing Mode. (You can also press F6 to switch to that mode without having to click the icon.) Events form a large part of RMVXA’s stock functionality.
• An event is an object that occupies a single square on an RMVXA map and carries out processing for pretty much all essential game functions. For example, we can create a shop run by a horse or a doorway that requires a key. Without events, you won’t be able to do much, if anything, at all. All nonplayer characters (NPCs) are events, for example.
• The final icon is for Region Editing Mode. I will elaborate on what Regions do in RMVXA, once it becomes relevant. (Teaser: It involves encounters with monsters). You can also press F7 to switch to this mode without having to click the icon.

Click the Event Editing Mode icon (or press F6), and you’ll notice that a grid appears on the map. If you right-click any square of the grid, you’ll see a menu pop up, as seen in Figure 2-1.

The available options are as follows:

• New Event: This allows you to place a new event on the map. We’ll be using this frequently throughout the course of this book.
• The editing tools (Cut/Copy/Paste/Delete) are grayed out because there is no event in the selected square.
• Quick Event Creation: RMVXA comes with four quick events for things that are essential to any RPG experience.
  1. Transfer. Creates an event that allows you to transfer a player from one place to another
  2. Door. A situational type of transfer event, usually used for entrances to buildings
  3. Treasure Chest. Creates an event that gives items or currency (default name “gold”) to the player when he/she interacts with it
  4. Inn. Heals the player and his/her party (if applicable) for a predefined cost in currency
• Set Starting Position: Allows you to set the starting position for the player character and three types of vehicles (boat, ship, airship). Setting a starting position for the player character is mandatory, but starting vehicle locations is optional.

Click New Event and you’ll wind up on a large blank slate, as seen in Figure 2-2.

There are many aspects to the Event screen, so let’s break them down.

• In the upper-left corner, you have several Conditions. If you don’t set any event conditions, the event in question will always be active.
• The checkerboard directly under Graphic can be double left-clicked to display a list of graphics present within the project. You can then choose a graphic to represent the event. For example, you could use a graphic for a villager or a monster. We’ll be using a button graphic later in the chapter.
• Below the checkerboard, you have a list of four Options.
  1. Walking Anim. is short for “Walking Animation” and displays character movement. If you turn off Walking Anim. and have an NPC that moves, the character will appear to be sliding on the ground.
  2. Stepping Anim. is short for “Stepping Animation.” When the check box is ticked, the NPC will walk in place. A neat use of Stepping Anim. is if you want to simulate gesturing during conversations.
  3. Direction Fix. As the option implies, clicking this check box will cause the event to be unable to switch directions. You could use this for a shooting gallery–type of mini-game, in which you want the player to face forward no matter what arrow key he/she presses.
  4. Through. The player character can pass through an event that has this option toggled on. Logically, the event can also pass through the player character (in the case of a mobile event such as an NPC). This is cool for ghosts and other such apparitions.
• Autonomous Movement is divided into three functions.
  1. Type. Defines what kind of movement the event uses. There are four types of movement.
     • Fixed: An event with this type of movement will remain in its starting location. This is perfect for the many kinds of immobile things that you will need for your RPG.
     • Random: Events with a random movement type will wander wherever they feel like, with no rhyme or reason. I’d use this movement type sparingly, as it can cause some annoying situations if you have thin corridors in your game.
     • Approach: An event with this movement type will try to approach the player character. It is good for making a scene involving enemies chasing your players.
     • Custom: This allows the Move Route button to be clicked, which, in turn, lets you set a movement pattern for the event in question.
  2. Speed. This sets how quickly the event executes its movement pattern. The higher the speed, the quicker the event will step.
  3. Freq. Short for “Frequency.” Sets how frequently the event executes its movement pattern. The higher the frequency, the more often the event takes a movement action.
• Priority defines what graphical layer an event is rendered on, relative to the player character.
  1. Below Characters. Means that the event is located beneath the player character’s feet. This is good for floor switches and staircases.
  2. Same As Characters. Means that the event is located on the same graphical layer as the player character. This is perfect for NPCs and inanimate objects, such as cabinets and trees.
  3. Above Characters. Means that the event is located over the player character’s head. This is useful for chandeliers and ceilings, among other things.
• Trigger defines how the event can be activated.
  1. Action Button. An event that activates via the use of the Action Button (spacebar or Enter, by default) when appropriate. If the event has Below Characters priority, the player character will have to stand on top of the event, to activate it. If the event has Same as Characters priority, the player character will have to stand next to the event while facing it, to activate it. Last, if the event has Above Characters priority, the player character will have to stand under the event, to activate it.
  2. Player Touch. An event that activates when the player character touches the event by walking into it. It is affected by Priority much like the Action Button.
  3. Event Touch. An event that activates when it touches the player character. It is similarly affected by Priority as the previous two options. I prefer to use Player Touch, but you’ll need Event Touch on the map, if you’re trying to make moving projectiles that your players must dodge, for example.

      Note  An easy way to determine if you need Player Touch or Event Touch is the following: for something that you want the player to trigger at his/her convenience, use Player Touch. For something that the player must avoid or is otherwise triggered outside of his/her control, use Event Touch.

  4. Autorun. An event with the Autorun trigger is always on and will repeat its actions until interrupted somehow. This is probably the easiest way to crash your game when you’re just starting out in RMVXA. I generally only use it for cinematic sequences (such as events in which you have the game auto-control the player character in an in-game cut scene).
  5. Parallel Process. Similar to an Autorun trigger, a Parallel Process event is always on. However, it will not interrupt other game functions. This is the type of event you should use to handle large-scale area transitions, among several other things.
• The entire right half of the New Event screen contains its Contents. By right-clicking (and left-clicking Insert) or double left-clicking anywhere inside of the window boundaries, you’ll find yourself looking at a large list of event commands. They represent the many things that we can do with RMVXA without having an inkling of Ruby knowledge. I will be covering a few of these later in this chapter and many more throughout the book.
• At the very top of the page, you’ll see five buttons involved in the creation and deletion of Event Pages. A single event can have up to 99 pages.

An Event Can Have 99 Event Pages!

Yes, seriously. I’m hard-pressed to think of any situation in which you’d have to make use of all 99 pages, but most events you create for your RPG will require more than one. Multiple event pages are how you can make NPCs change conversations as you progress within the game, to name but one thing you can do with them. As a matter of fact, the button event I will create shortly is going to have two pages.

Ready?

Let us begin. First of all, check Figure 2-3 for the end result.

That’s a green button three steps to the player character’s right and the exit located five steps to the north. The button event is two pages, and the exit event is one page. Before I explain what commands to add, let’s think about the situation critically. Our player starts the game and sees nothing of note, save a single button. You want the player to press the button and receive some sort of feedback after the fact, so that he/she knows he/she did. So, page 1 of the button event will have a graphic of the green button in a raised position, while page 2 of that event will have a graphic of the same button in a lowered position. We will inform the player via a text box that the button has been pressed, before we do that.

Pressing the button will reveal the exit to the north. You are starting to see how this will all work out. In essence

• We want a button that the player can press to reveal an exit.
• We do not want the exit to be revealed before the player presses the switch.
• We want the switch to reflect the fact that the player has pressed it.

How do we do that? With a switch! The final results for the pages are shown in Figures 2-4 to 2-6. We’ll step through the required instructions for reaching this state next.

@>Text: -, -, Normal, Bottom
:            : You stepped on the switch!
@>Play SE: 'Jump1', 80, 100
@>Control Switches: [0001:Switch] = ON

@>Text: -, -, Normal, Bottom
:            : You see a button pushed into the earth.

@>Transfer Player:[001:MAP001] (008,001)

Creating the Events

• While in Event Mode, right-click the square three grids to the right of the player’s starting position and then left-click New Event. We’ll be making the button first.
• On the blank event page, you can rename the event on the upper-left corner. It is currently unimportant, but if you make your own game, you’ll want to have your events properly identified. Trust me when I say that trying to figure out which of your 38 events on a map is supposed to represent a rolling boulder is nigh impossible when they’re named EV001, EV002, EV003, etc.
• Right-click the @ sign in the Contents part of the event page and then left-click Insert. Alternatively, you can double left-click to achieve the same effect.

Now you can see a large list of appropriately named Event Commands. There are three pages full of many useful commands for your eventing needs. The first command we need is called Show Text. Show Text will allow you to write in some text that will be displayed in a box when the event is triggered; see Figure 2-7.

As you can see in Figure 2-7, there are a few things you can do with this command.

• You can add a character portrait to the text box. Keep in mind that doing so reduces the amount of text that you can fit in each line.
• On that note, you may have already noticed the pair of arrows on top of the text box. The left arrow marks the limit of text that can be displayed in a line if you have a character portrait, while the right arrow marks the limit if you do not have a portrait in the box. If you had a character portrait, the preceding line would read roughly as follows in-game: “This is merely a test message for everyone re.” Otherwise, it would read, “This is merely a test message for everyone reading this bo.” You can use Enter to break up your lines, so that they don’t hit that limit. A text box can fit up to four lines of text.
• The Batch Entry option can be toggled to allow you to write more than four lines of text. (It adds a scrollbar to the right of the text box). Additional Show Text commands will automatically be created after every fourth line of text that you have, once you select OK.
• Background affects the appearance of the text box itself. The default is Normal Window, which will display the text box in the color set within RMVXA. The default is -34 Red/0 Green/68 Blue and can be changed with the use of the Change Window Color event command. You can also set the text box to Dim Background and Transparent. Transparent can be quite useful if you have a scene in which you have blacked out the screen and just want to show the text, without the accompanying text box.
• Position is fairly self-explanatory. You can set the position of the text box on the screen when it is displayed. It defaults to Bottom and can also be set to Middle or Top, as desired.

Let’s write “You stepped on the switch!” and then click OK.

• The next step is not strictly required but adds a little atmosphere to the event. By using the Play SE command (available on the second page of the Event Command list), you can set a sound effect to be played after you step on the switch. I chose the Jump1 SE and left it at default volume and pitch. You can play around with one or the other, to see how they affect the sound effect in question.
• Last, we toggle the switch! The Control Switches event command is on the first page of the Event Commands list.

When you click on it, it will show you the screen shown in Figure 2-8. The Control Switches command is rather simple. You choose a single switch or a batch of switches to flip, and then you decide whether you want to set them to on or off. You can press the button labeled “...” to change the switch you are affecting (as well as give the switch a proper name, as all switches and variables default to having a blank name). Here, I’ve given Switch #0001 the name of Switch, but you can rename it to something like “ButtonPress” or “ButtonSwitch.” Once that is ready, all you have to do is set the other options, so that they match mine shown following:

• Options
  • Toggle on Walking Anim.
• Autonomous Movement
  • Type: Fixed
  • Speed: 3: ×2 Slower
  • Freq 3: Normal
• Priority: Below Characters
• Trigger: Player Touch

That concludes the first event page for the button. Now, what you need to do is click New Event Page. You will see a new tab numbered 2 appear. Make sure to toggle the conditional, as I did, and set the relevant options, as shown following:

• Conditions: Switch 0001: Switch is ON
• Priority: Below Characters
• Trigger: Action Button

I also added some text reading: “You see a button pushed into the earth.” Once that is done, you can press OK, which will place you back at the map screen.

Finally, right-click the square five steps to the north of the player’s starting position and set the parameters for the Exit Event as I have done below.

• Conditions: Switch 0001: Switch is ON
• Options: Toggle on Walking Anim.
• Autonomous Movement
  • Type: Fixed
  • Speed: 3: ×2 Slower
  • Freq: 3: Normal
• Priority: Below Characters
• Trigger: Player Touch

As for the contents of the exit event, there are two ways to create a transfer event, as follows:

1. Create it manually. You should do so for the practice, but keep in mind option 2 for the future.
2. Use the Quick Event Creation Transfer option to achieve the same effect.

If you prefer to do it the long way, Transfer Player can be found on the second page of the Event Command List. Clicking on Transfer Player in the event command menu will present you with an image similar to that shown in Figure 2-9.

For now, just leave the settings as displayed in Figure 2-9. We’ll expand on this in the next section. Once all is said and done, you can play-test the game in its current state. Feel free to move around and interact with the button. If you have set up the map events correctly, all of the following should be true.

• Walking onto the button will cause the button event to trigger a text box pop-up, as well as the sound effect to play and the switch to sink into the ground.
• After the switch is pressed, you should see the exit reveal itself at the upper part of the screen.
• Pressing the spacebar or Enter when you are on top of the pressed button will give you the relevant text, telling you that the button is already pressed.
• Walking into the exit will just place you back on top of the exit.

Creating Your Second Map

You may have noticed beforehand that the destination for the map exit has been set to the same coordinates as the exit itself. What we need to do now is create a new map and change the Transfer event command to send us to the new map. To do that, take a look at the lower-left corner of the map screen, shown in Figure 2-10.

You should see something similar to the preceding screenshot. On your end, Test will be whatever you decided to call your project. MAP001 is the default 13×17 map that automatically gets inserted into every new project. Right-click MAP001, and you’ll see the following options:

• Map Properties (Hotkey: Space): Allows you to edit the currently selected map
• New Map (Hotkey: Ins): Creates a new map
• Load Sample Map (Hotkey: N/A): RMVXA comes with a wide range of premade maps that will allow you to see how to lay out many areas typical of the standard RPG experience.
• Copy/Paste/Delete: These are the editing tools available when dealing with maps.
• Shift (Hotkey: Ctrl+T): Allows you to move the map a certain number of squares in the direction you choose
• Generate Dungeon (Hotkey: Ctrl+D): Randomly generates a maze, based on the map size and a selection of wall and floor tiles. I should note that exceedingly small maps will result in a dungeon that has only one or two rooms, as RMVXA is very liberal with creating a wall border (it’s something like 10 squares big) around the maze.

For now, let’s click New Map. You will land on the screen shown in Figure 2-11.

As with several of the preceding screenshots, I have tweaked it, so that it can fit neatly within the confines of this page. I’ve left out the Encounters section on the right side of the window. Encounters are relevant to monster spawning, and I will be touch on them at a later time. Anyway,

• Name is the internal name of your map, that is to say, the name the map has while you’re working on your game in RMVXA. This can be edited, if desired. For example, MAP001 is the internal name of the default map included in all RMVXA projects when they are created.
• Display Name is the name of the area as displayed in-game. When your player reaches an area that has a non-blank display name, the game will display the area name in a small box near the upper-left corner of the screen.
• Tileset: If you’re using RMVXA Lite, the four tilesets available will be the only ones you can use. In the full version of RMVXA, you can add more tilesets of your own choosing. In any case, and as you might imagine, each tileset is created with a distinct graphical goal in mind. The map properties default to Field, which is the tileset you would use for a world map.
• Width/Height control the map’s size.
• Scroll Type allows you to make a map that loops in on itself horizontally, vertically, or both. This is very good for a world styled much like our own planet.
• Specify Battleback allows you to set a background that will be displayed during combat with enemies.
• Auto-Change BGM/BGS: This pair of options allows you to change the background music and sounds when the player first enters the new map.
• Disable Dashing: Players can move in double time during game play by holding down the Shift button as they move. You can disable this functionality on a map by toggling this check box.
• Parallax Background: This can be used to make a dynamic background that moves when the player moves. It can be used for such things as simulating an elevator going up or down floors.
• The Notes field is pretty much self-explanatory. It can be used to write down things related to the map in question. If you want to write up a list of important events that occur on a certain map, this would be the perfect place to put it.

Those are the relevant options. Let us set them, like so:

• Name/Display Name: Second Area
• Tileset: Exterior
• Width/Height: 30/30
• Auto-Change BGM: Field3

When you’re ready, press OK. You will be greeted with a large checkerboard of nothing.

Why Is the Map Empty?

While MAP001 comes with water tiles already set, subsequently created maps are completely blank (to be precise, that’s the transparent tile). To answer the question posed by the section heading, it’s just the way RMVXA works. Worthy of note is the fact that 30×30 is large enough a map size to require you to use the scrollbars (even if you’ve been following this book while using RMVXA full-screen). Make sure your editing mode is set to Map Mode (click the relevant icon or press F5) and then draw a rectangle with the Meadow tile that starts at (0,0) and ends on (23,15).

Tips

• As a reminder, the rectangle drawing tool for tiles is directly to the right of the pencil tool.
• You can find the specific coordinates for a certain square on your map by looking near the lower-right corner of the map screen while your cursor is over said square.
• I specified (23,15), as this is the limit of how much of the map I can see while keeping RMVXA in a non-maximized form and not using the scrollbars. If you can see more or less of the map, you may have to drag, squish, or expand your program size to be able to use the rectangle as I intend.

As you can see, the tileset for Exterior has different tiles than the Field tileset. Find (11,0) on the new map and the Dirt (Meadow) tile and draw a vertical line to (11,4). After that, take some time to add some terrain and play with the tileset.

Notes

• Adding certain types of terrain, such as ledges and walls, will cause small shadows to be rendered automatically. This is meant to simulate the effects of sunlight. You can use the Shadow Pen (the final drawing tool I have not mentioned as of yet) to remove those shadows or add some more of your own.
• Tilesets have multiple pages. The Exterior tileset has three pages. Page A of a tileset is dedicated to major terrain, such as grass/dirt/snow, ledges, and structures. Other pages contain doodads to flesh out what would otherwise be a fairly dull map.

You can find my rendition of the 23×15 area in Figure 2-12. Make sure your road is in the right place (and I’d highly recommend having at least the ledges directly to the sides of that road as well). Once that is done, switch to Event Mode and right-click (11,0). It’s time to create another transfer event.

Don’t forget to switch the event trigger to Player Touch; otherwise, the player will have to press spacebar or Enter to activate the event. Set the destination to one square south of the exit on MAP001. (You can left-click the map list within the Transfer Player menu to change which map you are looking at.) If you have followed the book up to now, that should be (8,2). Then, left-click MAP001 in the main map screen, to return to the first map. Right-click the Exit event and then left-click Edit. What you want to do is edit the Transfer Player command so that it points to the dirt road in our second map. For the sake of this tutorial, let’s place the destination at (11,2). Right-click the Transfer Player command and choose Edit, to make the appropriate changes. What you don’t want to do is place it right where you have the event to transfer to MAP001, as that has the potential to cause issues.

If you have done all of the above, you are now set. Play-test the game and see what happens.

Cool! Now, About Those Variables . . .

Okay fine, you’re right. Let’s apply the usage of variables before we end this chapter and move on to meatier subjects. Take a look at your second map. Place five trees (wherever you like, so long as you stay within that 23×15 area we populated with grass) around the area. If you managed to copy the map I created earlier, then the five trees you already have will be perfect.

What we’re going to do now is have each tree increase the value of a variable by one when the player interacts with them. We have to make sure that the player can’t just interact with the same tree five times. In other words, each tree can only be counted once. So, how do we do this? There are several ways, but I’m going to take advantage of the fact that this is the switches and variables chapter to talk a little about self-switches.

Each event can contain up to four self-switches. While switches and variables have global scope (that is to say, the value of a switch or variable can be accessed from any other part of RMVXA), self-switches are local in scope. The rest of your game’s events care not if Event #441 on Map #72 has its self-switch B (self-switches go from A to D) set to the “ON” state. It only holds importance to that one specific event itself.

So, we need an event that does the following:

• Displays a text box telling the player a little about the tree.
• Increases the value of the Tree variable by 1, if it is the first time the player has interacted with that tree. Otherwise, do nothing.

With that said, if you like a challenge or have previous coding experience, I invite you to try and figure this one out by yourself. You’ll need to keep in mind the following:

• The tree is a solid object, unlike the cave entrance/clearing we have used as our pair of exits so far during the book. That means the player will not be able to step on the event square.
• It is preferable that the player interact with the tree rather than having to run into it to trigger the event.
• You will need a new Event Command called Conditional Branch to check for the self-switch.
• On that note, you’ll have to make use of Control Variables as well.
• And Control Self Switch. Otherwise, using the Conditional Branch command would be in vain.
• You’re essentially using the same event five times.

Did you figure it out? If you think you have (or are stumped), let’s resume. The crux of this particular exercise is in those new event commands that I have not explained yet. I wholeheartedly recommend experimentation throughout your use of RMVXA. After all, video game design is basically one long sequence of problems to be solved. (The same can be said of programming.) With that in mind, let’s take a look at the Conditional Branch command shown in Figure 2-13.

The Conditional Branch command in RMVXA automatically defaults to the switch option. Click the self-switch bubble and then set it so that the branch check for A is OFF. There’s a check box I didn’t include in Figure 2-13 that’s titled “Set handling when conditions do not apply.” It defaults with a check mark, but I usually untoggle it. Why, you may ask? I find it generally easier to make a pair of conditional branches rather than having to handle the exception (in this case, A is ON) within a single branch. As you work in RMVXA, you’ll realize that my way of working with conditional branches actually results in less clutter. In any case, we won’t need the Else that leaving that check box checked would create, as we don’t want the event to execute anything within that branch if the self-switch is already on.

The second new event command we should take a look at is Control Variables. See Figure 2-14 for an image of the Control Variables menu, as seen when accessed.

Like Control Switches, Control Variables allows you to manipulate a single variable or a batch (group) of variables at the same time. Unlike Control Switches, there are many more things you can do with a variable. This is mostly owing to the fact that a variable can hold any number, while a switch can only hold an off or an on state. In what may seem as a rather meta thing, you can have a variable be affected by the value of another variable. Final Fantasy uses variables in such a way to great effect. For example, a certain character’s weapon in Final Fantasy IX causes greater damage the more dragons it has killed during the course of the game. While making a weapon stronger based on such a variable requires scripting in RMVXA, you can create a skill that does much the same, and it does not require scripting.

For this exercise, all we have to do is name the variable in question (I called it Tree), change the operation to Add, and set the Operand to Constant with a value of 1. If you leave the operation on Set, it will make the value of the variable 1. You want the variable to gain 1, not stay at 1, when the player interacts with a tree. To summarize, when the player performs an action on the tree the first time, the variable “Tree” will be increased by 1.

Finally, we need to add a Control Self Switch event. Control Self Switch is a simple enough event command that I won’t use an image on it. All you can do with that command is select one of the four self-switches and set its state to ON or OFF. Set self-switch A to ON, and there you have it.

In simpler terms, here’s the solution. Figure 2-15 shows the necessary Priority and Trigger settings.

@>Text: -, -, Normal, Bottom
:            : This tree looks rather peculiar.
@>Conditional Branch: Self Switch A == OFF
   @>Control Variables: [0001:Tree] += 1
   @>Control Self Switch: A =ON
   @>
: Branch End
@>

• As noted earlier, an event with the priority “Same as Characters” exists on the same graphical layer as the player.
• On that note, you won’t be able to step on top of the event’s square, so the trigger should be Action Button.
• The conditional branch checks to see if the event’s self-switch A is off. If it is, then it adds one to the value of Tree and turns self-switch A on, preventing a single tree from adding more than one to the variable.
• Copy-paste this exact event to the four other trees you have placed on the map, and you’re done. You can do this by right-clicking the event on the map editor and selecting Copy, then right-clicking the square you wish to paste the event to and selecting Paste. Alternatively, you can use the Copy Event Page button within the event properties.

What’s the Point?

There is no greater honor than botany. No? Okay, fair enough. Let’s add a final event that requires the Tree variable to be at 5. We’ll make it a treasure chest, to show off the relevant Quick Event.

• First, find a nice unoccupied space on your second map.
• Right-click and select the Treasure Chest event from Quick Event Creation.
• Because the quest involved trees, let’s give the player something made with wood as a reward. Select the Longbow from the list of weapons and then press OK.

• Now, right-click that event and click Edit. What we want to do is make it so the chest is invisible until the player has taken a look at all five of the trees. To do that, check the Variable condition on the first page of the event and set it so it says “Tree is 5 or above.” Once that is ready, you’re done!

Check Figure 2-16 to see how the relevant part of the second map looks for me. Besides the five trees and the road, your map will probably look different.

Before I close this chapter, here’s one final application of variables that will most likely be of great use to you as you work on your RMVXA game.

Advanced Challenge: Using Variables to Handle an Area Transition!

Up to now, we have dealt with area transitions that are one square wide. However, what happens if we make an expansive area, such as a desert, and want to make exits for the player? It could take dozens of events to cover a single direction. For those of you following this book using the Lite version of RMVXA, that is unacceptable (as RMVXA Lite only allows ten events to be placed per map). Truly, it is unacceptable, period, even if you have the full version. Why spend 10–40 events for area transitions on a single map when you can cover them all in one? This exercise requires the use of the following:

• The Parallel Process event trigger
• A pair of variables to hold the character’s coordinates
• Liberal use of the Conditional Branch event command

First, switch to Event editing mode. Then, find a nice spot in the second map that the player cannot reach. In my case, I’ll be using one of the squares on the mountaintop. Afterward, create a new event at that square. Set the event trigger to Parallel Process. Next, we’ll have to check for the player’s x and y positions at all times. That is the reason why we use Parallel Process. (Remember: Autorun is meant more for cinematic sequences. Trying to use it for an event such as this will only cause the game to hang.) The secret lies in the Control Variables command, specifically the Game Data category of operand. The Game Data category defaults to Map ID. Click the button labeled “...” on the far end of the bar, to change what type of data you want to assign to your variable.

Once you click the button, you’ll notice a slew of possible things you can plug into a variable. What we’re looking for is the player’s position on the map (a.k.a. his/her x and y coordinates). Thus, we click the Character option, which defaults to Player’s Map X. Exactly what we need! Select that, then make sure you’re saving the value to a new variable (I’m calling it variable 2 X and variable 3 Y). Afterward, create a new Control Variable command and repeat the process up to the point where you are looking at the Player’s Map X setting. Click the arrow on the drop-down menu for Map X, and it will reveal four more settings. The one we want, of course, is Map Y.

Here’s where it gets interesting. I’m going to recommend that you lower the map size down to 23×15 (the size of the grass rectangle we made in starting our second map). To be fair, it doesn’t particularly matter for this exercise, but it’ll help you visualize the boundaries in-game. Now what you have to do is figure out the boundaries of each side of the map on which you want to have area transitions. Let me use some Region numbering, shown in Figure 2-17, to help you visualize what I mean.

We have a single transition marked by the number four to the north. Additionally, we have 11 squares on the left, 21 squares on the bottom, and 12 squares on the right. That would be 45 transition events, if we did them one by one. So, let’s not.

Let’s Crunch Those Map Boundaries, Shall We?

The topmost square of the left boundary is (0,3), while the bottommost square of the left boundary is (0,13). The left-most square of the bottom boundary is (1,14), while the right-most square of the bottom boundary is (21,14). The topmost square of the right boundary is (22,2), while the bottommost square of the right boundary is (22,13).

What does this mean? Well, we can see some trends.

• When you trace a horizontal boundary, you will find that the value of Y stays the same.
• When you trace a vertical boundary, the value of X stays the same.

Thus, our conditional branches should read as follows:

@>Control Variables: [0002:X] = Player's Map X
@>Control Variables: [0003:Y] = Player's Map Y
@>Conditional Branch: Variable [0002:X] == 0
  @>
: Branch End
@>Conditional Branch: Variable [0003:Y] == 14
  @>
: Branch End
@>Conditional Branch: Variable [0002:X] == 22
  @>
: Branch End
@>

Keeping in mind that == is the equal sign when used in this context (a single equal sign means that a value is assigned in programming), you can probably tell what is going on. Note how every conditional branch event ends with a Branch End. The first conditional branch covers the left border. The second branch covers the southern border, and the third branch covers the right border.

But You Don’t Have Anything Inside the Branches!

Keen eye! Indeed, you would be correct. Feel free to put in transfer events, as you see fit, to wherever you want them to lead. The best use of such a transition in practice is to send the player to the world map (on which it doesn’t particularly matter where the player exits from, only that he or she exits the area map from a certain direction).

@>Control Variables: [0002:X] = Player's Map X
@>Control Variables: [0003:Y] = Player's Map Y
@>Conditional Branch: Variable [0002:X] == 0
  @>Transfer Player: [001:MAP001] (013,006), Left
  @>
: Branch End
@>Conditional Branch: Variable [0003:Y] == 14
  @>Transfer Player: [001:MAP001] (008,011), Up
  @>
: Branch End
@>Conditional Branch: Variable [0003:Y] >= 2
   @>Conditional Branch: Variable [0002:X] == 22
  @>Transfer Player: [001:MAP001] (004,006), Right
  @>
: Branch End
@>

Summary

That concludes this chapter on switches and variables. Here are two more exercises for you to stretch your mind with.

1. Using an event with Autorun, create a two-page event that greets the player with a text box upon arriving at the second area.
   • As with Parallel Process events, I recommend you place this event somewhere that the player cannot access.
   • Only the first page of the event should be Autorun. The second page should be blank, with a trigger that is not Autorun or Parallel Process. Flipping a self-switch on page 1 and using it as a conditional on page 2 would probably work best.
2. Using an event with Autorun, use the Fadeout and Fadein event commands to cause the screen to black out momentarily and then reveal the treasure chest, instead of it popping immediately into being.
   • The easiest way to accomplish this is by cheating a little. The chest is set to appear when Tree is equal to 5. Make it so that the chest appears when Tree is equal to 6. Then, with Fadeout, you can create an Autorun when Tree is equal to 5, add 1 to the value of Tree, and Fadein, in that order.
   • The use of a self-switch also comes recommended for this event. An Autorun left unchecked will hang your game.
3. Tweak the five tree events so that they also display a text box that tells players how many trees they have looked at up to that point.
   • Tool tips are your friend here. Place your cursor over the text box in the Show Text event command and leave it there until the tool tip appears. You’ll see a text option that allows you to print the value of a variable as text.

Next, let’s talk about a large part of what makes RPGs what they are: characters and enemies!