I’d like to congratulate you for making it this far. This is the final chapter of the book. It has been an awesome journey full of learning experiences! Of course, this book is just a taste of the full potential of RPG Maker VX Ace (RMVXA). I urge you to continue reading and learning more about what makes this game-development engine tick. What better for a final chapter than a melting pot of tips and tricks that you can apply to your own games? The exercises in this chapter will use variable amounts of scripting, depending on what is needed. Without further ado, let’s walk this final leg of our journey together.

Forcing Certain Party Members to Participate in a Battle

Our first exercise for this final chapter is inspired by a common role-playing game (RPG) convention: forced party compositions. If you have ever wanted to create a boss fight in which a certain party member must be present in the active party, this should be relevant to your interests. In RMVXA, the maximum active party size is four. A possible fifth (or more) party member is placed into the party reserves.

You can use the Formation option in the in-game menu to switch between your party members. Party members that are in the reserves gain a share of the experience gained in battle if (and only if) the Reserve Members’ EXP check box is toggled in the System tab of the Database. In any case, here’s our hypothetical situation:

Overview

For this exercise, you’ll need the following:

• A new test map (the tileset and the size do not matter). Then, copy-paste the Gemini event from the first dungeon to our test map.
• An Autorun event that is only active when a switch is flipped. This event will use a scripted conditional branch to determine whether Noah is in the active party. If he is, we process the battle against Gemini. If he isn’t, we have Noah say some words and use the Open Menu command to allow the player to change his/her active lineup.
• The Autorun will keep running until Noah is in the active party.

This is a rather easy event. The only thing that should even give you a second of pause by now is the single line that we have to use as a conditional branch. To find it, we must figure out how RMVXA handles party members internally.

Finding Out How RMVXA Handles Party Members

A good place to start figuring that out is the conveniently named Game_Party. We needn’t go far, as we already see some promising code by line 70. Look at the following to see lines 63 to 74 of the Game_Party class.

#--------------------------------------------------------------------------
# * Get Battle Members
#--------------------------------------------------------------------------
def battle_members
  all_members[0, max_battle_members].select {|actor| actor.exist? }
end
#--------------------------------------------------------------------------
# * Get Maximum Number of Battle Members
#--------------------------------------------------------------------------
def max_battle_members
  return 4
end

In fact, the method we need happens to be battle_members. In essence, what the single line of code within that method does is find every available party member and then take the first one to four of them and place them into an array. This array is $game_party.battle_members.

Now, the next question is: How do we use that array? Click Help in RMVXA’s Main Menu toolbar and run a search for Array. The first search result will be thus named. This is one of RMVXA’s many Ruby reference pages. The array method we want to use is called include? (the question mark is not a typo). Figure 15-1 is a screenshot of what the reference file has to say about this particular method.

That means our expression currently looks like this: $game_party.battle_members.include?(val). So close, yet so far. What do we put in val? We have to know if Noah is in the active party, so we must check for his actor ID. Recall from Chapter 12 (and, briefly noted, again in the previous chapter) that actor information arrays are called in RMVXA in the form $game_actors[actor_id]. So, Noah’s array would be $game_actors[10]. That is the value we need to check for.

Creating the Forced Party Member Event

Following, I have placed the event commands belonging to the second half of page 1 of Gemini’s event. It has been tweaked, so that, instead of calling a Battle Processing command, it flips on a switch that will trigger our Autorun event.

@>Text: 'Evil', 3, Normal, Bottom
:     : Heh, think you can surpass the power
:     : that has been granted to me? Prepare to
:     : suffer!
@>Change Battle BGM: 'Dungeon9', 100, 100
@>Control Switches: [0038:activepartymember] = ON
@>

When the activepartymember switch has been flipped on, this activates the Autorun event on the map, which will check to see if Noah is in the active party.

@>Conditional Branch: Script: $game_party.battle_members.include?($game_actors[10])
   @>Battle Processing: Gemini
   @>
: Else
   @>Text: 'Actor5', 6, Normal, Bottom
   :     : I wish to participate in this battle.
   @>Text: -, -, Normal, Bottom
   :     : Use the Formation option from the menu to add
   :     : Noah to your active party.
   @>Open Menu Screen
   @>
: Branch End
@>

The conditional branch uses the Script option and reads as follows:

$game_party.battle_members.include?($game_actors[10])

You can fit it all in the single line provided, but it will appear cut off in the event’s contents list. This has no negative effects on the event itself. We can toggle “Set handling when conditions do not apply,” to get the else statement to work with when Noah is not included in battle_members. Alternatively, we can have another conditional branch that reads: $game_party.battle_members.include?($game_actors[10]) == false. In either case, when Noah is not in the player’s active party, he expresses a wish to participate in the battle at hand, and then a system message is displayed. You can add a color change command to that text (C[n]; n is the value of color you wish to use). I’m partial to green for system messages (that would be n = 3), but you can use the color of your preference. After the message is displayed, we have the in-game menu pop up, allowing the player to bring in Noah from the reserves.

To properly test this event, you’ll want to have an event that gives the player a full party and then adds Noah to the end of the party as a reserve. Check the following code for a sample event:

@>Change Party Member: Add [Natalie]
@>Change Party Member: Add [Terence]
@>Change Party Member: Add [Ernest]
@>Change Party Member: Add [Noah]
@>

You can place a nonplayer character (NPC) with these commands anywhere on the test map. You can talk with said NPC first, to fill up your party, and then test the rest of the events at leisure.

With all that said and done, this is the final chapter, and I have not yet discussed play-testing features. This is a good a time as any to do so.

Play-Testing Features

RMVXA has a pair of convenient and helpful features that are only available during play-testing. The first is known as the debugger. During play-testing, pressing F9 will bring up a screen similar to the one shown in Figure 15-2.

The debugger contains a complete list of switches and variables present in your project. More important, you can see the state of each switch and variable and even tweak it for testing purposes. Perhaps you want to set Tree to 5 in our game off the bat, to see if the Autorun event triggers correctly. Maybe you want to see if Amanda acts appropriately once the player has beaten the appropriate rank of the arena. Instead of having to actually play through all of that, you can use the debugger to flip switches or change the value of variables. It is also a helpful reference when things go wrong in eventing, and you want to see what isn’t setting itself properly. The other feature, while not as flashy, is useful all the same. By holding down the Ctrl key, you can clip through otherwise impassable terrain. My favorite use of ignoring passability is when I have accidentally made certain squares impassable when they should be passable. I can keep the squares in mind and just use Ctrl to bypass the accidental obstacles, instead of having to fix them then and there. Depending on what you are play-testing, this can be quite a time-saver. It’s time for another exercise! If you want to make a desert that requires precise movement to get through successfully, you’re going to love this one.

Of Deserts and Ghostly Locations

Deserts are a video game constant. Deserts that penalize the player who does not know the correct route to traverse them seem to be everywhere in games as well. You might be surprised to know that we can recycle events used in previous chapters to pull this off without a hitch. Don’t believe me? Take a look at Figure 15-3, to see the map I’ll be using for this exercise.

The Desert Event

We need the following things to complete this exercise:

• A Region ID (I’m using 3) that will trace an invisible border around the map. Crossing that border will send the player back to the start of the area.
• A pair of Regions (1 and 2) that will transfer the player out of the desert area
• Some doodads to dot the map. I use cacti.
• A Parallel Process event that will handle all of the region-based shenanigans

As everything else is already established in the screenshot of the map, let’s skip ahead to our Parallel Process event. It isn’t anything that we haven’t done before, as you’ll quickly see.

@>Control Variables: [0002:X] = Player's Map X
@>Control Variables: [0003:Y] = Player's Map Y
@>Get Location Info: [0004], Region ID, Variable [0002][0003]
@>Conditional Branch: Variable [0004:Region] == 3
   @>Text: -, -, Normal, Bottom
   :     : You get lost in the desert!
   @>Transfer Player:[031:CHAP15EXE2] (004,028), Up
   @>
: Branch End
@>Conditional Branch: Variable [0004:Region] == 2
   @>Comment: Insert transfer event here.
   @>
: Branch End
@>Conditional Branch: Variable [0004:Region] == 1
   @>Comment: Insert transfer event here.
   @>
: Branch End
@>

If you can make teleportation puzzles, you can make deserts that cause the player to get lost and send him/her back to the start of the area as well! You may have noticed that I didn’t use Region 4 at all. You could have a desert nomad sell the player some goggles or breathing apparatus that allows him/her to explore the inner parts of the desert. In that case, Region 3 would no longer warp the player back to the start of the area. That task would be transferred to Region 4, as it were. That lets the player explore the oasis, among other things. Let’s move on to a similar exercise.

Forest Event Overview

Suppose you wanted to make an area like the Lost Woods in some of the Legend of Zelda games. That is to say, one in which you can move in one of several directions, only one of them correct. Going the wrong way will send you back to the start of the area. We can use Regions for that as well. However, what if I told you that we could pull this off using a single 17×13 map? Seems crazy, right? Let’s get started!

For this exercise, we’ll need the following:

• The aforementioned 17×13 map (Figure 15-4). It should have one Region for each cardinal direction, as in the following screenshot.

  

  Figure 15-4. A screenshot of the map that must be traversed in a certain order

• A Parallel Process event that handles what happens when the player steps on a certain Region at a specific time
• A variable to quantify the player’s progress, given that we’re only using one area

That does it for needs, although we’ll also probably want some graphics that appear, based on the player’s progress into the labyrinth. We’ll call the variable WoodsLocation. If the player goes in the correct direction, we increase the variable’s value by one; otherwise, we zero it out. If the player can successfully get through five areas in a row, then he/she will have cleared the labyrinth. The reward can be reaching the inner part of the area or a treasure chest filled with a rare item. You’ll want the Parallel Process event to have five pages. Each one will require that the WoodsLocation variable be at a value one higher than the page before. In other words, page 1 is unconditional, while page 2 requires the variable to be equal to 1. Page 3 requires the variable to be at 2, and so forth, up to page 5, which needs the variable at a value of 4. With all that said, we need to figure out what order the player has to walk through the labyrinth to clear it. I personally decided on right, right, left, down, up. Region-wise, that is 2, 2, 4, 3, 1.

Creating the Forest Event

Now that we know what we want our mysterious forest to do, all that’s left is to actually write out the appropriate events.

Following is the template for what each page of the Parallel Process event should look like:

@>Control Variables: [0002:X] = Player's Map X
@>Control Variables: [0003:Y] = Player's Map Y
@>Get Location Info: [0004], Region ID, Variable [0002][0003]
@>Conditional Branch: Variable [0004:Region] == 1
   @>Transfer Player:[032:CHAP15EXE3] (008,006)
   @>Control Variables: [0029:WoodsLocation] = 0
   @>
: Branch End
@>Conditional Branch: Variable [0004:Region] == 2
   @>Transfer Player:[032:CHAP15EXE3] (008,006)
   @>Control Variables: [0029:WoodsLocation] += 1
   @>
: Branch End
@>Conditional Branch: Variable [0004:Region] == 3
   @>Transfer Player:[032:CHAP15EXE3] (008,006)
   @>Control Variables: [0029:WoodsLocation] = 0
   @>
: Branch End
@>Conditional Branch: Variable [0004:Region] == 4
   @>Transfer Player:[032:CHAP15EXE3] (008,006)
   @>Control Variables: [0029:WoodsLocation] = 0
   @>
: Branch End
@>

When the player walks to the eastern exit (Region 2), the value of WoodsLocation is increased by 1. Otherwise, the variable is zeroed out. In either case, the player is transferred back to the center of the area. For each page, the correct entrance should be the one that increases the value of WoodsLocation.

I added several plant events (using the Small Sprouts graphic in tab B of the Dungeon tileset) that are only visible when the value of WoodsLocation is at a certain number or higher. This will give a visual representation to the player that he/she is progressing. Figure 15-5 shows what the labyrinth looks like when WoodsLocation is equal to 5.

That concludes this pair of exercises. A little information about vehicles follows, before we perform our next exercise.

Vehicles

I never covered vehicles during the course of creating our game, as we never had occasion to use them. Quite a few RPGs make do without a single vehicle, and others have vehicles that are not player-controlled. So, don’t feel like you have to have vehicles in your game. RMVXA has three types of vehicles, the graphics of which can be changed in the System tab of the Database. Each one of them can be used to navigate different types of terrains. In order of freedom of movement, they are as follows:

• Boat: To be honest, the default graphic is more of a canoe. In any case, the boat can cross shallow water (Pond and Sea in the Field tileset).
• Ship: A full-fledged vessel, such as in all of those pirate movies! The ship can cross shallow water and deep water.
• Airship: The default airship is more of a blimp or dirigible. The airship can travel over any terrain but can only land on solid ground. Additionally, an airship can fly over events. Airships are on a higher layer than even Above Characters events, so you’ll want to use Parallel Process events for events involving them.

If you want to experiment with tweaking the passability of boats and ships, the relevant vehicle logic is handled in the Game_Map class. Figure 15-6 is a screenshot showing a test map that I created for the purpose of displaying each of RMVXA’s vehicles.

You can set the starting position of a vehicle much as you can the player characters themselves. In addition, you can move a vehicle from one location to another instantly, by using the Set Vehicle Location event command. This is useful when you have the plot move the player from one part of the world to another instantly. It would only make sense that his/her ship would be docked at the new town and not stranded at the previous port (assuming, of course, that your player took the ship to the new port in the first place). The other vehicle-related event command is Get On/Off Vehicle, which does as the name implies.

Next, let’s touch upon an enemy-related exercise. Mainly, making a battle in which there are two enemies, both of whom must be defeated on the same turn; otherwise, the survivor will revive his/her comrade.

Two of a Kind

In RPGs, this type of battle falls under the broad umbrella of what are considered to be gimmick battles. Basically, a gimmick battle is one in which only a certain strategy (or a limited number of strategies) can bring the player victory. A fight with a pair of twins, in which one revives the other, dissuades unfocused attacks and promotes a calculated approach to the task at hand. For this exercise, we’ll use a pair of skeletons. For the sake of differentiation, copy the Skeleton entry in the Database into an empty slot and use the hue setting to change the graphic’s colors a little. Then, change the new enemy’s name to something else (such as Skeleton Lord or Skeleton Knight). Last, increase the new enemy’s stats a bit. For reference, you can see a screenshot of the Skeleton Knight in Figure 15-7.

Next, let’s create a troop that has one Skeleton Knight and one Skeleton. In the troop event, you’ll want to have a pair of event pages, one for each of the enemies. We will use double conditionals for the events themselves. (See Figure 15-8).

With that set up, we can fill out the pages themselves. Both of the pages will have a Span of Turn (so that they trigger once every turn) and a single Force Action event command.

Page 1's Force Action command is: [2. Skeleton], [Reanimate], Index 1.
Meanwhile, Page 2's Force Action command is: [1. Skeleton Knight], [Reanimate], Index 2.

To create Reanimate, I took the Raise spell and copied it to a new slot. Then, I zeroed out its MP cost and changed the damage formula from b.mhp/10 to b.mhp (turning the 10% HP heal into a full heal). That concludes this exercise! Let me end this section with a few interesting notes about Force Action.

• A skill used with Force Action can be executed even if the user doesn’t have the MP to cast it.
• Similarly, the user doesn’t even need to have the skill in his/her list to be forced into using it. I confirmed this particular fact by having Eric throw Thunder II spells around with Force Action.
• You can have a skill force the user to use another skill. If you’re not careful, you could create a loop of skills that keep triggering infinitely until the battle is done or otherwise unwinnable (depending on what the skill in question does).

A Full House

While we’re on the subject of troops and enemies, there’s one other thing I’ve neglected to mention up to now. If you right-click a specific enemy’s graphic within a troop, you get a single option named Appear Halfway. Clicking it causes the enemy to appear translucent in the troop display at the Database. If you begin a battle with some of the enemies in that state, they will not appear in the encounter. As the name of the option pretty much blurts out, you can use this to have enemies that appear during the course of a battle. This is useful in situations such as the following:

• A battle in which enemy reinforcements arrive at regular intervals
• An enemy that has a skill that causes allies to appear
• A battle with multiple waves of enemies. Defeat one wave to cause the next one to appear.

For this exercise, we will create a troop containing five Orcs. The first, third, and fifth Orcs will be present from the start of the battle. The second and fourth Orcs will appear in response to their defeated allies. Take a look at Figure 15-9.

The first troop event page should execute at the start of the battle. It gives the first and fifth Orcs the Immortal state. The second page is triggered when the first Orc drops to 0% HP or less, causing the second Orc to appear and the first one to be defeated. The last page is triggered when the fifth Orc drops to 0% HP or less, causing the fourth Orc to appear and the fifth one to be defeated. I will let you translate this into the relevant events. Just keep in mind that your event pages should have a span of Battle, as you don’t want them to trigger more than once during the battle. Also, keeping in mind that death is prioritized over every other battle event in RMVXA, you want the new enemy to appear before the old one loses its immortality; otherwise, a clever player could use a skill that hits all enemies, bypassing the reinforcements completely by defeating all of them at the same time.

Amusingly, that used to happen all the time with older RPGs, given the limitations of programming. Players would just find sneaky ways to prevent reinforcement waves from appearing, by overtaxing the battle logic or employing any other such shenanigans.

Ye Olde RPG—A Treatise on Quest Experience

Japanese RPGs (with most of the exceptions being relatively recent titles) tend to give the player characters most, if not all, of their experience via combat. That was part of the reason why older Japanese RPGs were notorious for their grinding (repeatedly fighting monsters in the same area to get gold, experience, and items) and overall difficulty. Can’t defeat any of the monsters outside of town? Don’t have the gold to get items? Tough luck! Classic Western RPGs, such as Wasteland and the Ultima series, were actually somewhat better about that. Usually. That leads to my next topic.

Think back to the Rat Tail quest we created in the port town of Seaside for our players to complete. The player got gold out of it, but what if we wanted to offer experience as well? We could use the Change EXP event command to accomplish that task. Change EXP allows you to give experience points to (or take away from) a certain party member or the entire party (you can designate a specific actor ID using a variable as well). The value of EXP given or taken can be a fixed value or that of a variable. Last, you can toggle the “Show Level Up Message” check box, which will prompt the game to display the level-up box, if the experience gained from the command is enough to bump the character up one or more levels.

Using those two event commands, you give the player even more incentive to complete sidequests and also a way to progress in the game without having to battle monsters ceaselessly.

The Other Actor Event Commands

As it turns out, I’ve covered most of the event commands contained in the Actor section of the list. With that said, I haven’t covered all of them. Here’s a bulleted list of the ones I have glossed over until now.

• I didn’t really mention Change HP or Change MP, as our only instances of out-of-combat healing were covered neatly by Recover All. However, those two commands are more versatile, as they allow you to increase or decrease the relevant stat. You could have a poisoned well that injures the party when it drinks from it, or a floating fairy that recovers the entire party’s MP. The one thing to note is that you can make it so that damage inflicted with Change HP can’t knock out its victim (by not toggling the “Allow Knockout” check box).
• Change State: This is something that you probably won’t be using constantly. Most instances of adding or removing states from an actor are covered by skills and items on both sides of a battle. This could be useful for a damage floor that additionally inflicts a status effect, however.
• Change Parameters: In addition to experience and states, you can also permanently change an actor’s stats, for better or worse. The minimum for any stat except MP is 1. MP can be zeroed out. An interesting use of this event command could be for a dungeon that disallows magic. Just make it so that the MP of every party member is set to 0 (ensuring that you write the value of each party member’s MP to a specific variable beforehand), and you’re set. It would probably be easier to just make a Silence state and inflict it on the party when it enters the dungeon, to be fair.
• Change Skills: These allow you to give or take away skills from a party member. For an actual video game example of this happening, see Garnet from Final Fantasy IX. She starts the game with a, quite frankly, ridiculous number of Eidolons (entities that can be summoned for powerful effects). The plot takes them away from her until a time when she regains them. You could have a similar thing happen in your game. Maybe your party’s mage gets amnesia from witnessing a horrible event and forgets how to cast everything save the simplest cantrips. Or perhaps the game’s villain seals away the knowledge of the one spell that could defeat him, forcing the party to find a way to unseal it, so that the party’s magician can learn it once again.
• Change Equipment: This is perhaps the Actor event command I use least. It has its situational uses, but I’m not a huge fan. Essentially, it allows you to change an actor’s current equipment. This is good to use when a member of your party is going to leave it permanently or semipermanently (in which case, losing the items it had equipped would be bad). Just have Change Equipment commands remove all of its gear and you’re set. Note that this doesn’t make items appear out of thin air. If you want to use this command to equip an actor with a new weapon he/she has found, it must actually be in his/her inventory (by use of Change Weapons), before you call for it to be equipped.
• In hindsight, we could have used Change Name instead of the script equivalent for our riddles back in Chapter 11. Basically, you choose which actor whose name you want to change and choose their new name. It’s basically Name Input Processing, but without giving the player a chance to decide on the new name. Change Nickname is the same thing, but for nicknames instead of names.
• Last, Change Class allows you to change an actor’s class. It’s a bit quirky, because it drops your actor’s level back to 1 (with the respective drop to parameters that this would cause) but doesn’t cause him/her to forget any skills. This could be pretty neat for a class system like that of Dragon Warrior III. Imagine if Eric could learn every skill available to every class in the game!

The Bridge

As an interesting hypothetical situation, say that you want to make a bridge that meets both of the following conditions:

• It allows the player to walk under it.
• It allows the player to cross it.

If you were to place your bridge using map tiles, you would meet the second condition but not the first. If you were to use events to create your bridge, you’d run into a different problem. Namely, you would have to check for two different conditions. How do we solve this problem? We’ll need the following items:

• A Parallel Process event that checks the player’s location
• An event that has a graphic that will serve as our bridge tile

The first order of business is to figure out how the player will interact with the map containing the bridge. For example, take a look at Figure 15-10, to see the map I’m using for this exercise. The player’s starting position is at the top of a staircase. While the player is atop this ledge, he/she should be able to walk on the bridge tiles. While the player is on the lower part of the area, he/she should be able to walk under the bridge. We need the bridge tile events to have two pages. Page 1 will have no conditions and will have a Below Characters priority. The second page will require that a certain switch be flipped on and have an Above Characters priority. The Parallel Process event will flip the switch on when the player walks down to the ground level and turn it back off when the player ascends to the ledge.

The first bridge uses the horizontal stone bridge tiles, while the second bridge uses the vertical stone bridge tiles. You can find both of the tiles in tab B of the Exterior tileset

@>Control Variables: [0002:X] = Player's Map X
@>Control Variables: [0003:Y] = Player's Map Y
@>Conditional Branch: Variable [0003:Y] == 5
   @>Conditional Branch: Variable [0002:X] >= 2
      @>Conditional Branch: Variable [0002:X] <= 4
         @>Control Switches: [0040:BridgeAbove] = OFF
         @>
      : Branch End
     @>
   : Branch End
   @>
:Branch End
@>Conditional Branch: Variable [0003:Y] == 6
   @>Conditional Branch: Variable [0002:X] >= 2
      @>Conditional Branch: Variable [0002:X] <= 4
         @>Control Switches: [0040:BridgeAbove] = ON
         @>
      : Branch End
      @>
   : Branch End
   @>
: Branch End
@>

BridgeAbove is the switch that must be flipped on for the bridge tiles to allow the player to pass under them. You could also have a dungeon in which the player has to pull a lever, press a button, or otherwise cause a switch to be flipped. Once the switch is flipped, a bridge to advance deeper into the dungeon appears. All you would need in that case are the bridge tiles with a Below Characters priority and a requirement for a switch to be flipped, and the event that would flip that switch.

The Town Map

This is the end of the end. After this section, I will close out this chapter with the summary, and we will be done with the book. (You’ll want to check the Appendix for helpful resources related to RMVXA and other such things.) How better to end a book about an RPG development engine than by explaining how to create a map? To complete this exercise, we’ll need the following:

• A screenshot of the area for which we wish to have a map
• A picture of a symbol/marker denoting the player’s location on the map
• A pair of common events governing the map logic
• An item to execute the map logic

I will be using the Port Town exterior for this exercise.

Preparing Our Map Pictures

The first order of business is figuring out how big the map has to be. Taking a screenshot of the game while you are play-testing will give you a fairly close estimate (I got 546×417). Next, go to the map editor and switch to Region Mode (this will conceal any events you have placed on the map).

If not having doors displayed in the screenshot is unacceptable to you, there is a workaround.

1. Go into the Resource Manager (Hotkey: F10) and find the Graphics/Characters folder.
2. From there, scroll down to the !Door1 graphic set.
3. Click it and export it to the location of your choice.
4. Then, click Graphics/Tilesets.
5. Click Import and then find the !Door1 graphic set that you exported.
6. Last, go to the Tileset tab of the Database and assign !Door1 to the D tab of the Exterior tileset.

Now you can place doors to cover the entrances, for your screenshot needs. Just make sure to erase the graphics afterward! After concealing the map’s events, zoom out the map until you can snap a screenshot of it in its entirety. (For the port town, a 1/2 scale will be sufficient.) Then, use your image editing software of choice (any will work, including Windows’ own Paint application) to resize it to 546×417. Next, you’ll want to make a picture that can be used as a marker for the player’s current location. It should be small enough that it doesn’t take up an excessive amount of space on the map, yet big enough that it can actually be seen. The marker that I created is 30×30 in size. Once we have both of our pictures, we need to add them to our Resource Manager. Find the Graphics/Pictures folder in the manager (curiously, RMVXA comes with no stock pictures) and import your two images to that folder accordingly.

Using the Show Picture Event Command

With that set up, it’s time to use the Show Picture event command. Take a look at Figure 15-11 to see a screenshot of the event command, as displayed within RMVXA.

You can assign a picture a control number. As the tool tip in RMVXA states: “Control number of the display picture. Those with the largest screen display number take precedence.” Think of it like a stack of papers. The lower a picture’s number, the deeper it is located within the stack. So, if we want our marker to be placed on top of the map, it must have a higher control number. With that said, you can pick any number from 1 to 100. The map could be 99, and the marker could be 100. To keep it simple, I’ll give the map a 1 and the marker a 2. We can set which graphic is shown by selecting it with Picture Graphic. If you hadn’t imported the two images to Graphics/Pictures accordingly, the browser window would be empty. For Display Position, we’ll want the automap to be positioned at 0,0, with an Upper Left origin. Origin determines how the image is placed on the screen. If you choose Center, then it will be the map’s center that is placed at 0,0. We don’t want that. For our map marker, we will also use an Upper Left origin, but it will be positioned with the use of variables. Last, you can set Blending options. The lower the opacity of your picture, the more translucent it will appear. You can have additive or subtractive types of blending as well, which influence how the picture’s colors look.

Creating Our Town Map Common Events

This is where it gets interesting. The general idea for our common events is the following:

• When the player uses the Map item, we want to determine the player’s x and y coordinates. After that, we apply a multiplier to the X and Y variables.
• Afterward, we use a pair of Show Picture commands to display the map and the map marker.

What multiplier do we need? We have to correlate the pixel size of the map picture (546×417) with the tile size in the map editor (39×48). This is as easy as dividing the first value by the second for both X and Y. The multiplier for X is (546/39 = 14) and the multiplier for Y is (417/48 = 8.6875), which I rounded to two digits in the following code. Here’s the first common event:

@>Control Switches: [0039:TurnOffMap] = ON
@>Control Variables: [0002:X] = Player's Map X
@>Control Variables: [0003:Y] = Player's Map Y
@>Control Variables: [0002:X] *= 14
@>Control Variables: [0003:Y] *= 8.69
@>Show Picture: 1, 'automap', Upper Left (0,0), (100%,100%), 255, Normal
@>Show Picture: 2, 'x', Upper Left (Variable [0002][0003]), (50%,50%), 255, Normal
@>

I used a 50% zoom for the map marker, as, when displayed, 30×30 looks clunky on the map. As it stands, you can create a suitable item to hold the Map common event and then start up the game. However, you’ll find that using the Map event will cause the screen to display the area map and map marker without a way to remove the pictures. That is what the TurnOffMap switch is for. When the switch is on, the second common event is processed. I give it a Parallel Process trigger, so that it is running concurrently until needed. The only role that the second common event has is to erase the pictures that have been created and flip off the TurnOffMap switch until it is needed once again.

@>Conditional Branch: The X Button is Being Pressed
   @>Erase Picture: 1
   @>Erase Picture: 2
   @>Control Switches: [0039:TurnOffMap] = OFF
   @>
: Branch End
@>

Erase Picture asks for a control number and erases the displayed image that has said number. That concludes this exercise. Give the player a Map item and test it out!

Variants on the Map Exercise

This is good and all, but following are some possible variants for you to think about as well.

1. Make it so that the map marker moves as the player does.
   • As you have almost certainly noticed, you can still control the character when the map is displayed.
   • To pull this off, all you need to do is copy-paste the part of the first common event that handles the X and Y variables and add a Move Picture event command directly below that.

     @>Control Variables: [0002:X] = Player's Map X
     @>Control Variables: [0003:Y] = Player's Map Y
     @>Control Variables: [0002:X] *= 14
     @>Control Variables: [0003:Y] *= 8.69
     @>Move Picture: 2, Upper Left (Variable [0002][00003]), (50%,50%),  255, Normal, @15

2. Make a mini-map of the area.
   • I’m thinking in a manner similar to that of the Grinsia mini-map, where you have a semitransparent map in the upper-left corner.
   • This is actually relatively simple. We render the same map picture with the Upper Left origin but set the Zoom to 25% (which will shrink it to a quarter of its size). This drops it down to 137×105. Additionally, we set its Opacity to 128, as we want the mini-map to be somewhat see-through.
   • Then, we quarter the multipliers (which would become 3.5 and 2.17 for X and Y, respectively) for the map marker as well. I also dropped the marker’s Zoom down to 25%, to keep it in line with the smaller map.
   • You could make an item that reveals an area’s map to the player for a certain number of steps.
   • Keep in mind that you’ll need a picture for each individual area in which you plan to have a mini-map. How would you handle an area like our interior structure map for the port town, where there are multiple different areas on the same map? That’s an exercise for you.

Summary

This chapter covered a range of miscellaneous topics that were not covered in the book’s previous chapters. Among them were creating a battle that requires a certain party member to participate, having encounters in which some of the enemies appear during the battle rather than at the start, and creating mazes within a single map, with the use of variables and Regions.