During the course of the past two chapters, I’ve covered many basic but important aspects of RPG Maker VX Ace (RMVXA). Now it is time to build on what you have learned, to start making our very own game. The first order of business is to add a few more maps, as we only have the two we created so far. To make sure that we are using the same content, and also to show off the relevant feature, let’s use some premade maps.

Adding Content to Our Game World

Two role-playing game (RPG) mainstays are towns and dungeons. Additionally, most RPGs have a world map that connects the various locations that the player can visit during the game. So, on that note, let’s add three new maps from the premade selection that RMVXA has available.

1. From the main map screen, right-click your project’s name on the lower-left corner and select Load Sample Map.

   You could have done the same thing by right-clicking MAP001 or your second map. That would have caused the new map to be placed under the previous map. Doing so is rather useful for organizing maps that share a similar purpose. Figure 4-1 shows an example of what I mean.

   

   Figure 4-1. A screenshot of a sample map list

    Note  In a sense, nesting related locations makes it easier to see what goes where on a meta level. This becomes more important as the size of the game increases. This is not actually necessary but can be a time-saver.

2. After clicking Load Sample Map, you’ll see a wide variety of maps to use. First, let’s choose our world map. I picked Field 3, a world map with many smaller continents and islands.
3. Next, let’s add a town map. Right-click Field 3 and select Load Sample Map. Given that the world map has plenty of water, let’s use the Port Town for our very first town.
4. Last, let’s add a dungeon. Right-click Field 3 again and load up the sample map list. The Goblin Cave is a nice and simple dungeon layout, so let’s select Goblin Cave F1F.

Now, what if I told you that I want you to place both of the Goblin Caves within the same map? Sounds like a cue to painstakingly spend a few hours drawing Goblin Cave FB1, right? Actually, wrong! It took me longer than I care to admit to realize that you can copy-paste terrain as easily as you can an event. How do we do this?

1. First, right-click Goblin Cave F1F and use Load Sample Map to add Goblin Cave FB1 to your project. Note that it is a 46×46 map.
2. Next, let’s prepare Goblin Cave F1F to receive its own basement level. Go to Goblin Cave’s map properties and increase its width by 56 (FB1’s width plus 10 more squares, to effectively split the two maps). You’ll see transparent tiles fill the extra space.
3. Now, switch over to Goblin Cave FB1 and display the map in 1/4 scale.

You can find scale buttons for 1/1 (default), 1/2, 1/4, and 1/8 to the right of the map drawing tools.

1. After making sure that you’re in Map editing mode and using the Pencil tool, right-click the upper-left corner of Goblin Cave FB1 and drag the cursor all the way to the lower-right corner. If done correctly, your cursor should now be moving around a huge white square.
2. Switch back to F1F and scroll to the part of the map filled with transparent tiles. Once you have the square in a good spot, left-click once. Like magic, you’ll see Goblin Cave FB1 appear. You can fill in the transparent tiles with the Darkness tile from tileset A, or just leave them as they are (transparent tiles show up black in-game). Your Goblin Cave map should look like Figure 4-2. (This screenshot was taken at 1/8 map scale).

Populating the World Map

Now we are ready to start populating our game world. Let’s make our way to Field 3. RMVXA’s premade maps come with already defined terrain but none of the other trappings that make a world map what it is. What we’re going to do is place appropriate graphics for our newly created town and dungeon and our previously created map. I’m placing the three doodads on the southern end of the largest landmass of the world map. (It’s the left-side continent that’s two parts dirt and one part grasslands.) All of the graphics are on the B tab of the Field tileset. Take a peek at Figure 4-3 to see what the area looks like after adding the new content.

The giant tree to the northwest of the port town is the location from where our protagonist will exit the second area. I placed the dungeon entrance in a conveniently sized hole to the northeast of the port town and the giant tree.Of course, for as cool as they look placed as they are on the map, we must still create transfer events that actually take us to our new locations. If there was ever a place to use the Parallel Process event I mentioned back in Chapter 2 to cut down on overall event use, the world map is definitely it. Think back to your last RPG and how many locations you could reach from its world map. You’re going to run out of events in a hurry, even if you’re using the full version of RMVXA that has a much more lenient restriction on the number of events per map. You can copy-paste the relevant event from the second map and tweak it for the world map. We want the giant tree to take the player to the second map, the town graphic to take the player to the port town, and the cave graphic to take him/her to the Goblin Cave. It should look something like this:

@>Control Variables: [0002:X] = Player's Map X
@>Control Variables: [0003:Y] = Player's Map Y
@>Conditional Branch: Variable [0002:X] == 18
   @>Conditional Branch: Variable [0003:Y] == 88
      @>Transfer Player: [002:Second Area] (011,012), Up
      @>
   : Branch End
   @>
: Branch End
@>Conditional Branch: Variable [0002:X] >= 20
   @>Conditional Branch: Variable [0002:X] <= 21
      @>Conditional Branch: Variable [0003:Y] == 91
         @>Transfer Player: [004:Port Town] (019,004), Down
         @>
      : Branch End
      @>
   : Branch End
   @>
: Branch End
@>Conditional Branch: Variable [0002:X] == 28
   @>Conditional Branch: Variable [0003:Y] == 82
      @>Transfer Player: [005:Goblin CaveF1F] (020,043), Up
      @>
   : Branch End
   @>
: Branch End
@>

Once you have done that, you can fix the Transfer event in the second map to allow the player to reach the world map. I will leave those tasks as exercises for you. Let’s move on to the port town. It’s time to populate it! (Take a look at Figure 4-4 to see a picture of RMVXA’s premade port town).

Populating the Port Town

As you can see in Figure 4-4, the port town has two shops set in place, as well as an inn, a pub, and a temple. RMVXA has premade maps for all of the above-mentioned locales, as well as several house templates.

Of course, if we were to make one map for each of the buildings, RMVXA Lite users would run smack-dab into the map limit. Also, it’s rather more efficient (in terms of map slots) to have all of the buildings contained within the same map. In the case of our port town, we save eight map slots (as we have nine locations) by doing so. Generally, I prefer to use a single map for town interiors, as they tend to have the largest amount of locations. For dungeons, I usually have one map per floor (with the obvious exception of the Goblin Cave, but I did that to illustrate the concept of having multiple locations in one map).

So, let’s create a new map of a whopping 500×500 in size that uses the Interior tileset. Then, using premade maps and copy-paste, add all of the following to said map:

• An inn with two floors
• An item shop
• A pub
• A weapon and armor shop
• Two houses
• A temple

Keep in mind that you’ll want to separate each individual building by roughly 10 spaces; otherwise, the player will be able to see the different buildings present on the same map if he/she strays too far to the left or right. What I usually do to make sure the gap between two buildings is exactly 10 squares wide is draw a line of distinct terrain to the right of the first building. Then you place the new building adjacent to the end of the line. Once you’re done placing your buildings, you can erase the lines you made. The first three buildings mentioned above are available as premades (the pub is covered by the Drinking Bar premade map). For the weapon and armor shop, I took the weapon shop premade and tweaked it a little to show off armor and place a second seat for the armor vendor. (See Figure 4-5).

As for the two houses, there are several premades that you can use. I’m going to use House A and House B. Finally, the temple exterior looks more like the Church premade than the Temple, so let’s use the former instead of the latter. Once you’re done, you can reduce the size of the map. As I lined up all my buildings in one row, I went from 500×500 to 225×40. Figure 4-6 is a 1/8 scale screenshot.

Now let’s get to work populating the port town! We’re going to want non-player characters (NPCs) for each of the buildings. For the inn, you need the innkeeper. For each of the shops, you need shopkeepers. The pub needs a barkeeper, and the temple needs a priestly-type character. This is as good a time as any to use the character generator that RMVXA provides, so make your way to the Tools tab of the menu toolbar and click the Character Generator.

Creating Characters to Populate Seaside

This section will take you through the process of creating an NPC and placing him/her in the game world. You should be looking at the Character Generator at the moment. (See Figure 4-7).

As mentioned earlier in the book, the Character Generator is awesome for making a diverse range of characters without any graphical know-how. Mess around with the settings for a bit and note how each feature change affects the character’s face and sprite. Once you’re done, you can save the character sprite by clicking Output Character and writing a file name in the prompt that appears. I don’t usually have character faces for my less important characters, but you can save your character’s face via Output Face, if you wish. Make a total of eight characters. Once you’re done, placing a character on a map is as easy as switching to Event Mode, creating a new event, and adding your freshly made character sprite to the event. Here is where we’re going to place the character events:

• Place one character on the stool behind the counter at the inn. That character will be your innkeeper. Place a second character on one of the stools on the inn’s second floor.
• Place a character on the stool at the item shop. This will be the item shopkeeper.
• Place two characters at the pub/drinking bar. One of them will be the barkeeper, so place him/her behind the counter. Place the second in front of the piano.
• Place a pair of characters at the weapon/armor shop, one for each type of equipment.
• Place one character at each of the two houses.
• Place two characters at the temple. Leave the area behind the altar empty. We have special plans for the priestly type character (we’ll be using a stock graphic for him).

After all that is said and done, we have to link the buildings to the port town exterior. Use a Parallel Process event, as we have already, and plug in the relevant Transfer events. With that done, make your way to the port town map. We have some tweaking to do! First of all, we have to add doors to the top buildings. Doors, as noted in Chapter 2, are a type of transfer event used for buildings. Add a door event to each of the buildings, making sure to link it to the correct destination on the other map. Figure 4-8 is a screenshot example of where the player should land after being transferred to the port town’s inn interior.

As you can see, there is one square below the player in the inn. We can use that square in the Parallel Process event on that map to serve as the inn’s exit. You’ll also want to connect that staircase with its sibling on the inn’s second floor.

Going back to the port town map, if we scroll down, we’ll see four buildings with two-square-wide entrances. What we’re going to do is decrease the size of the entrances to one square and then place door events on two of them. For the other two houses, you’ll want to create an event with a door graphic that tells the player that the door is locked. To do that

1. Create a new event covering the entrance with a door from the !Door1 graphic set. You’ll notice that as soon as you set a graphic for the event, its priority will default to Same As Characters. In this case, that’s exactly what we want. In other cases, such as the button event we created back in Chapter 2, we’ll want to revert the event to Below Characters.
2. For the sake of consistency with the door transfer events, set the “locked door” events to Player Touch.
3. Afterward, add a Text Box that says: “This door is locked.”

Now we have two houses that are linked to the interior map and two houses that give a message for the player when he/she tries to enter. Make three more characters using the Character Generator and place them as so:

• Place one at the longer pier, between the two mooring bollards (in simpler words, the two things that look like pins).
• Place one at the plaza at the northern end of town.
• Place the last one looking over the well to the east of the temple.

So, we’ve done a lot of character placing throughout the exterior and interior of the port town. But what are the NPCs doing there? What should they say to the player when he/she talks to them? Here’s some setting info you can use to flavor what they could be talking about:

The only things I’ll require are the following:

• That the barkeeper inform the player of the threat of monsters from the nearby cave, explaining that they are threatening the town’s livelihood. Set a switch to ON after the initial conversation and then have the barkeeper talk about something else, if the player speaks to him/her again. You can use Show Text events for the greater part of the conversation and Show Choices when you want the player to weigh in with a response.
• Noah is the tenth premade actor in RMVXA. Use his graphic as an event placed behind the altar at the temple. If the player has already talked to the barkeeper (the relevant switch is ON), have Noah join Eric’s party. If the player has not, Noah should recommend that they speak to the various townsfolk, to get a feel for what’s going on. This should be a three-page event, with the third page removing the Noah event from the screen after he is added to the party. You can use the Change Party Member event command to have Noah join the player’s party.

If you’re unclear on how to tackle those two character events, I will explain them in detail later in the chapter. With that said, I should take some time to cover how to make the various NPCs that will be running the inn and the shops. If you check the third page of the Event Commands list, you’ll find a command called Shop Processing. Clicking it brings up a relatively simple window (as shown in Figure 4-9).

Essentially, Shop Processing allows you to create a list of items that the shopkeeper will then sell in-game. Double-click to add a new item. You can also set the item price here, if you want it to differ from the standard. The check box at the bottom allows you to create a shop that disallows selling. Here’s a simple example of how the item shop NPC event could look like:

@>Text: -, -, Normal, Bottom
:     : What can I do for you, sir?
@>Shop Processing: [Antidote]
:                : [Potion]
:                : [Dispel Herb]
:                : [Hi-Potion]
:                : [Stimulant]
:                : [Magic Water]
:                : [Elixir]
@>

In the same way, you can use a similar event for the weapon and armor shop NPCs. As for the innkeeper, there’s no Inn Processing equivalent in the event command list, but Inns are a Quick Event. Clicking the Inn Quick Event will bring up the following window (Figure 4-10).

Rather unassuming, isn’t it? Select the character graphic that you designated to be your innkeeper, change the cost of staying the night if you wish, and then click OK. Next, take a look at the event that was created. Quite a few things in there, aren’t there? The most important thing to note is the pair of screen fade commands. When the player pays the innkeeper for the room, the screen fades out, music is played, and then the screen fades back in. You could use a similar fade-out/fade-in coupling to add Noah to the player’s party without showing the event disappearing simultaneously (as that would look clunky, at best). So, let me explain how I laid out the events I required.

• The barkeeper
  1. Right-click any square behind the counter of the drinking bar and create the new event.
  2. Create a conversation between Eric and the barkeeper whereby a switch is turned on after the player accepts the quest.

Take a look below for the conversation that I created, complete with an old RPG trope: the false choice.

@>Text: -, -, Normal, Bottom
:     : Hello there, young one. What brings you to fair
:     : Seaside?
@>Text: -, -, Normal, Bottom
:     : Eric explains what has happened recently.
@>Show Balloon Icon: This event, Exclamation, Wait
@>Text: -, -, Normal, Bottom
:     : Could it be?
@>Text: 'Actor4', 0, Normal, Bottom
:     : What is it?
@>Text: -, -, Normal, Bottom
:     : Legends speak of a hero that was sealed within a
:     : glen in times long past.
@>Text: -, -, Normal, Bottom
:     : We have dire need of a hero, lad. This port town is
:     : in danger, you see. Monsters have taken up residence
:     : at the cave to the northeast and are affecting our
:     : livelihood. Farmers live on the far end of this
@>Text: -, -, Normal, Bottom
:     : continent and provide for our many food-related
:     : needs. Traders have not visited Seaside for nearly
:     : a decade. Ships that we send out do not return.
:     : Please aid us, hero!
@>Label: Repeat
@>Text: -, -, Normal, Bottom
:     : What say you?
@Show Choices: Yes, No
: When [Yes]
   @>Text: -, -, Normal, Bottom
   :     : Thank you very much, lad! Please speak to Noah at
   :     : Seaside's temple. He has been searching for someone
   :     : to aid him in defeating the monsters.
   @>Control Switches: [0002:PlotAdvance] = ON
   @>
: When [No]
   @>Text: -, -, Normal, Bottom
   :     : But thou must!
   @>Jump to Label: Repeat
   @>
: Branch End

As usual, I took the time to add a few new things for us to look at.

• Show Balloon Icon is a neat little event command that places a balloon over someone’s head. (You can choose between the player, the current event, or another event on the same map). In this case, the barkeeper gets an exclamation point, for reasons that make themselves obvious a few lines of text later. That Wait after Exclamation means that the game will wait until that event command has resolved to continue event processing. If you don’t toggle that option, the conversation will continue as the balloon appears.
• Label (and the subsequent Jump to Label) are a pair of event commands that let you control event processing. Normally, events work much like regular computer programs. That is, they start resolving from the top of the code and end at the bottom. However, there are many situations in which we don’t want this to be the case. For example, here we want the player to accept the quest given. Of course, it wouldn’t be much of a game if he/she decided to say no. So, we invoke one of RPG’s most classic tropes and pull a literal “But thou must!” on them if they do say no. The Jump to Label command then finds the designated label (in this case, called Repeat) and rewinds back to that point.
• Show Choices is what allows us to set the yes/no question in the first place. This event command can hold up to four choices and allows you to decide what to do when the player tries to opt out of the choice branch (with the Esc key, for example). You can set the choice branch so that the player cannot opt out of it, designate the choice to be picked if the player opts out, or create another branch when the player tries to opt out of the first one.

With that done, let’s add Noah to the game! First, make your way to the Actors tab in the database and increase Noah’s starting level to 5. Next, go to the port town building map that you created and make your way to the temple. Behind the altar, add a new event with a total of three pages.

Page 1 should look like this:

@>Conditional Branch: Self Switch A == OFF
   @>Text: 'Actor5', 6, Normal, Bottom
   :     : What brings you to this temple, traveler?
   @>Wait: 60 frame(s)
   @>Show Balloon Icon: This event, Exclamation, Wait
   @>Text: 'Actor4', 0, Normal, Bottom
   :     : Everything all right?
   @>Text: 'Actor5', 6, Normal, Bottom
   :     : Yes, you looked like somebody familiar.
   :     : That is all.
   @>Control Self Switch: A = ON
   @>
: Branch End
@>Conditional Branch: Self Switch A == ON
   @>Text: 'Actor5', 6, Normal, Bottom
   :     : If you'll be staying with us, you might
   :     : wish to speak with the barkeep over at
   :     : the local pub. He has eyes and ears all
   :     : over the continent.
   @>
: Branch End
@>

Remember to set Noah’s character graphic, as well as keep the event trigger as Action Button. As the preceding event page displays, there is a Wait event command that can be used when you want to force the game to pause for a certain amount of time. Sixty frames is equal to a single second for Wait’s purposes.

For page 2, you’ll want to set a conditional for PlotAdvance to be ON (the switch I used during the conversation with the barkeeper). Then, once you have done that, take a look at the next page to see what you should add.

@>Text: 'Actor5', 6, Normal, Bottom
:     : I can see it in your eyes. The barkeep
:     : has told you of my wishes. I would see
:     : the monsters felled as soon as possible.
:     : When do we leave?
@>Play ME: 'Item', 100, 100
@>Text: -, -, Normal, Bottom
:     : Noah has joined your party!
@>Fadeout Screen
@>Wait: 120 frame(s)
@>Change Party Member: Add [Noah]
@>Control Self Switch: B =ON
@>Fadein Screen
@>

The first half of the event leading up to Fadeout Screen is pretty self-explanatory. What the second half does is create a transition that allows Noah to join the player’s party without making it obvious that you’re removing the event version of him. The screen fades out with a two-second delay, and Noah is added to the party via the use of the Change Party Member event command (which, incidentally, can also be used to remove party members, should the need arise). After that, we switch on the B Self Switch and have the screen fade back in. However, if we leave the event at that, you will have two Noahs. The third event page will have a conditional of “Self Switch B = ON” and nothing else, not even a character graphic. Once Noah has joined your party, the related event will, for as far as the player knows, cease to exist. Internally, though, it still does.

Now that we are done with that, I will list the items I have placed for sale from each of the shop NPCs (Figure 4-11). The left-most list is the item shop, the center list is the weapon shop, while the right-hand list is the armor shop.

Those are the most important things to do within this port town.

Creating Random Encounters for the World Map

Next, let’s add some random encounters to the part of the world map to which we currently have access. For this, we can use Regions. (See Figure 4-12).

Region 1 encompasses the entirety of the area’s grasslands. We have Region 2 for the forests and Region 3 for the hills. Let’s add some encounters to each region. In this particular case, I numbered the areas based on encounter difficulty, which is a good way to go, so that you can remember what you want appearing in a certain area. If you take a look at the Monsters tab, you’ll notice that the monsters are roughly subdivided for such a purpose already. Monsters 001 through 005 all have similar power levels, then 006 (the Wisp, by default) is much stronger than 005 (the Rat). Similar power spikes appear at regular intervals. I’m going to use troops with the first six unit types to create my encounter tables for this part of the world. See Figure 4-13 for a list of encounters that I set for the world map as of now.

As you can see, I made the total weight of the encounters 100, although that is not strictly true. For example, there are only three total encounters available in Region 1, with a total weight of 70. That means that you have a 30/70 chance of meeting two Slimes, a 20/70 chance of seeing two Bats, and a 20/70 chance of engaging three Rats (the Rat typo is present by default in RMVXA; it’s as easy to fix as a single press of Backspace, should it particularly bug you). Wisps, being the strongest enemy type by far, are a rare sight in Region 3 (5/25 chance of seeing them, as compared to a 20/25 chance of seeing Rats). Now, we need to speak more about battlebacks.

A Discussion on Battlebacks

Up to now, we’ve had a single area with a single encounter. When you have a map that has uniform terrain (much like most dungeons), you can just set the area’s battleback in the map properties. However, the world map is a conglomeration of various types of terrain (a cursory peek at Field 3 reveals snow and lava areas). It would be rather odd to have a forest battleback for a brawl in the snow, wouldn’t you say? So, what we can do is apply past knowledge in a neat little exercise.

How do we go about this? If you think back to Chapter 2, we used a Parallel Process event that wrote the values of the player’s X and Y to variables to determine map boundaries for area transitions. Here, we can use the Get Location Info event command in conjunction with Control Variables, conditional branching, and Change Battleback within a Parallel Process to make sure the battle background is always appropriate to the area in question. As Change Battleback is pretty much equivalent to just setting a default area battleback in a map’s properties, let me speak a little more of Get Location Info. Figure 4-14 is a screenshot of that event command.

As you can see, Get Location Info first asks for the variable in which you wish to store your relevant information. I created a new variable named Region just for this occasion. Next, you have to use the second drop-down menu to define what information you wish to write to said variable. Region ID is preselected here, but it is the last item on the Info Type list. The others are

1. Terrain Tag. If you go to the Tilesets tab in the Database, you’ll notice a series of buttons on the right-hand side of the screen that range from Passage at the top to Terrain Tag itself at the bottom. Terrain Tags are a minor, but useful, way to define different areas, without the use of Regions. All tiles default to 0 and can go up to 7. A little more on this (and more general terrain considerations) later.
2. Event ID. If the player is currently on top of an event square, using this option will write the specific Event ID to your variable of choice.
3. Tile ID (Layers 1–3) are the final three items before Region ID. This refers to the tile’s ID internally. I’ll leave it as an exercise to you to figure out uses for this particular command. (I prefer Terrain Tags, to be honest.)

Last, we want to select Designation with Variables, as we want the event to poll the player’s position on a continuous basis.

As for the rest of the event, you can use Conditional Branches to check for the player’s current region and change the battlebacks accordingly, like so:

@>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
   @>Change Battle Back: Grassland & Grassland
   @>
: Branch End
@>Conditional Branch: Variable [0004:Region] == 2
   @>Change Battle Back: Grassland & Forest1
   @>
: Branch End
@>Conditional Branch: Variable [0004:Region] == 3
   @>Change Battle Back: Grassland & Cliff
   @>
: Branch End
@>

RMVXA Lite has only a sampling of the total backgrounds that the full version contains. Still, the preceding battlebacks should give some form of differentiation of locales for the player’s benefit.

Adding Transfer Events to the World Map

While you’re on the world map, you should add another Parallel Process event for area transfers as well, given that we have three locations on this map already. Now, let’s take some time to go back to our first two maps and add to them. We want to give the game a coherent direction in plot, rather than just dump the player in the middle of a map unceremoniously. So, on the first map, let’s add an Autorun event with no conditionals. That means that it will activate as soon as the player enters the game. The first order of business is fading out the screen. Then, use transparent text boxes aligned with the center of the screen to give a relevant backstory. Just make sure you don’t start the game with an overly long text dump, as most players hate that. A paragraph or two should be enough. Here’s what I did:

@>Fadeout Screen
@>Text: -, -, Transparent, Middle
:     : A young man awakens from his slumber. He knows only
:     : that his name is Eric. He knows not where he is, nor
:     : why. What adventures await him? It is time to find
:     : out!
@>Wait: 60 frame(s)
@>Control Self Switch: A =ON
@>Fadein Screen
@>

Make sure you create a second page within the event that is empty and only active once that self-switch has been turned on, or your game will loop that event page forever. On the second map, add an NPC blocking the road that speaks of the five trees that block access to Eric’s Bow and then disappears. Here’s what I did:

@>Text: 'Actor'4, 0, Normal, Bottom
:     : Who are you?
@>Text: -, -, Normal, Bottom
:     : Me? I am but a man who used to be a king, in ages
:     : long past. Your bow has been sealed within this
:     : glade for as long as you. Examine the five trees
:     : and claim your birthright. Fare thee well.
@>Text: 'Actor'4, 0, Normal, Bottom
:     : Wait, what are you-
@>Fadeout Screen
@>Text: -, -, Normal, Bottom
:     : Before Eric can finish his sentence, the enigmatic
:     : figure disappears.
@>Control Self Switch: A =ON
@>Fadein Screen
@>

As in the previous event, have a second blank page after this one. We need to do two more things. First, to the Treasure Chest event, add a new switch that is set to ON once Eric opens the treasure chest revealed by the trees. Have a text box appear telling the player to head to Seaside once he/she receives the bow. Second, add a conditional to the Parallel Process event on this map that requires said switch to be turned on. This prevents the player from leaving before taking the chest’s contents. Once all is said and done, the player will know that he/she is a mysterious being awoken from a deep slumber and has a first objective in the game world.

Our next task is to populate our very first dungeon, but that is a subject best left to its own chapter. Before ending this chapter, however, let’s talk a little more about tilesets and terrain tags, as promised previously.

A Little More on Terrain Tags and Tilesets!

To talk about Terrain Tags is to talk about tilesets, as they are intrinsically linked. As mentioned previously, each tile can have a Terrain tag value between 0 and 7. Off the top of my head, here are a few of the cool things that terrain tags allow you to do:

• You can have a Parallel Process event running that turns all floor tiles with a certain terrain tag into damage floor tiles.
• You can have a minigame, in which you have to step on tiles in a certain order, just by setting the terrain tags of each set of tiles to a different number.
• You can have skills that have differing effects, based on the current terrain tag, similar to Geomancy from some of the Final Fantasy games. A skill could do more damage in the grasslands but have a chance to freeze victims in the snow.

For a little number, terrain tags sure can do a lot, eh? Of course, the Tilesets part of the Database is as robust as any other. Given that we have not looked at it yet, let’s take some time to do so. Look at Figure 4-15.

While Name in General Settings is self-explanatory, Mode is far from it. I leave it as an exercise to you to read up on Resource Standards in the Help file, as RMVXA itself recommends in the Mode tool tip. Most of that will be of little interest to you, unless you want to add your own custom tilesets (whether created by yourself or purchased from a graphic designer) to RMVXA. What is most relevant to beginner-level RMVXA users is those buttons I mentioned a few pages back when talking about Terrain Tags. Let’s start from the top.

• Passage determines whether or not a player character can walk over the specific tile.
• Passage (4 dir) is for specific tiles. On tiles that allow the use of this property, you can control from which directions the player is allowed to enter that square of terrain. This is really useful for maps such as desert areas with rapidly moving sand that only allow movement in certain ways.
• Ladder, as the name implies, is used for ladder-type graphics. Basically, whenever you want the character to climb, you use the ladder property.
• Bush makes it so that the bottom part of the character is obscured when passing through a tile with that property.
• Counter is of particular interest. You probably noticed that we have placed several NPCs behind counters at the port town. If you have been doing some experimentation on your own, you will know that you must be standing adjacent to an event to trigger it via the use of Action Button/Player Touch/Event Touch. However, if your event is separated from the player by a tile considered a counter, you can still interact with him/her. It allows us to have NPCs like the barkeeper, who are otherwise trapped, but permits interaction with the player nonetheless.
• While you can use Terrain Tags for the same effect, there is a specific terrain property for Damage Floors. Designate a tile as a damage floor, and it will damage players who pass over them for 10 damage.

A Discussion of Floor Damage

How do I know how much damage such tiles cause? Well, it’s all contained within a few lines of code (which you cannot edit unless you own the full version of RMVXA). To note: These lines are contained within Game_Actor.

#--------------------------------------------------------------------------
# * Get Base Value for Floor Damage
#--------------------------------------------------------------------------
def basic_floor_damage
   return 10
end

You’ll probably be interested to know that you can have variable floor damage, depending on the type of floor. Here, let me illustrate with some code that I hammered out in about a minute on my full version of RMVXA.

#--------------------------------------------------------------------------
# * Get Base Value for Floor Damage
#--------------------------------------------------------------------------
def basic_floor_damage
   return 2 if $game_variables[3] == 1
   return 5 if $game_variables[3] == 2
   return 10 if $game_variables[3] == 3
   return 25 if $game_variables[3] == 4
end

Instead of a single global value for floor damage, we can have multiple values, as set by a particular variable. In this case, $game_variables[3] (where 3 is the variable ID in the Database), signifying the variable containing the Region ID, is the one I chose to use. You could consider leaving a simple return value (like the default number) for damage floors set within the Tileset tab and then have other damage floors marked by regions or terrain tags.

Additional Exercises

Here are some final exercises for you to close out this chapter with a bang!

1. Expand the innkeeper so that you can choose to rest in the morning or nighttime.

   Having night in your game is as simple as applying a filter on the graphics. The Tint Screen command is perfect for this and, in fact, even has a specific color setting for nighttime. However, if you want nighttime to influence random encounters, that is quite a bit harder. It takes a small amount of scripting, and a fair amount of eventing, to have different encounters based on the time of day. Even so, you can stop the player character from leaving town and have certain events happen only at night.

   I recommend having a Daytime switch and a Nighttime switch, if you’re going to do this. Then, you can differentiate what events trigger when using the relevant conditionals. Just make sure you set one of the switches to on at the very start of the game. (Switches default to off and variables to 0 when a new game is created).

2. Have some NPCs in Seaside give the player items when they’re talked to.

   You have already used Change Party Member to add Noah to the player’s party in Seaside. However, there are four other event commands in the Party category, and they can be used to grant items, weapons, gold, or armor to the player. Treasure chest events actually use those event commands to give items.

   A common mistake is to give players an item and not tell them that they received it. Make good use of the Show Text command!

3. Make it so that the player cannot access the dungeon until Noah has joined the party.

   This is as easy as adding a conditional branch to the relevant transfer event. If Noah is in the player’s party, then they are transferred to the dungeon. Otherwise, they take a step back from the dungeon entrance on the world map and say that they would rather find help first.

4. Make it so that the player cannot even see the dungeon until Noah has joined the party.

   Event slot conservation be darned, at this point you’ll probably want to eliminate the dungeon transfer part from the main Parallel Process event. Then, you make a two-page event at the dungeon location where the first page is blank, and then the second page has the relevant graphic and only appears when Noah is in your player’s party. The second page would be Below Characters, with a Player Touch trigger taking them to the dungeon as normal.

Summary

This chapter took us from a two-map prototype to the beginnings of an actual RPG. We added a port town and the foundation of our first dungeon to the game. We populated the port town with shops, a plot hook for our player to grab, and a new companion. In the next chapter, we will be populating our first dungeon with treasure chests and enemies.