So, when last we left off our role-playing game (RPG) story, Eric and Noah defeated the latter’s brother in (not-so) gruesome combat. What follows next? Well, as a longtime RPG player and overall gamer, my first reaction would be to return to Seaside and see what (if anything) has changed and then decide on my alter-ego’s next course of action. That is the initial topic for this chapter. The first order of business is to update the Seaside nonplayer characters (NPCs), to reflect recent events.

Updating Our NPCs

In true RPG convention, our intrepid hero and his mysterious companion will find that news of their endeavors travels faster than they do. To update any NPC, all you need to do is make a new event page for it that requires the BossDefeated switch we created last chapter. Let’s have the barkeeper tell the player of the new tidings. Here’s a short setting blurb that you can use to tweak the barkeeper’s conversation:

As in any good RPG story, we had previous events lead the player into new ones. In this case, and as you’ll recall, Gemini gave away a plot hook after being defeated by Eric and Noah. He spoke of the dark master that would “avenge him,” as it were. What better place to house a dark master than in another dungeon? Now you may be wondering why I would have two dungeons in a row. Well, I finished Part 1 with a dungeon, so it felt appropriate to start Part 2 with the same. With that said, it is also a good chance to show off some more advanced eventing than we’ve seen up to now. As a minor teaser, think about the following situation:

Do the possibilities boggle the mind? Well then, let us hurry toward that particular exercise. First, however, we must create our dungeon maps. This time, we’ll have three levels to our dungeon and each map occupy its own slot (if only to vary a bit from what we designed for the first one).

The First Two Floors of Our Second Dungeon

The map we’re using is Tower of the Void F1F, with quite a few changes. First of all, I closed off the starting area, allowing the player to advance no farther unless he/she has the Old Key with which to open the tower’s door. Players that fancy themselves explorers can see and enter the tower ahead of time but will be unable to get past that first room. If they do have the relevant item, they can open the door, which acts as a transfer event to the middle of the map. Take a look at Figure 6-1, to see the ground floor.

There’s a little recessed area a few spaces below that sends the player back to the other side of the passage. (Trapping your players is usually a very bad idea, except when it’s not, but that’s something experience will teach you.)

I left the top and west stairs intact but removed the eastern stairs and placed a new set of stairs that can be seen from the dungeon entrance. I also removed all other stairs on the ground floor, save for the ones slightly to the northeast of the entrance, in addition to completely sealing off the top two wedges in the central part of the map. You can see the dungeon’s second floor in all of its edited glory in Figure 6-2.

This is Tower of the Void F4F. As I skipped F2F and F3F completely, I had to do quite some tweaking to the terrain. I removed stairs that didn’t link appropriately to the ground floor and sealed off certain areas to change up how the player explores the dungeon. I placed treasure chests next to the four pillars located within the top two wedges of the central area, as well as a fifth chest in the gap to the south of the top staircase. As noted in the teaser a few pages preceding, there’s a dragon statue here that I decided to use as fuel for our latest eventing exercise.

Interacting with the Dragon Statue

What we want to do here is make it so that the player can interact with the dragon statue from every adjacent square, using only two events. Doing this the wasteful way would spend two extra events (four in total). The larger the object in question, the more efficient these pairs of events will be, as compared to having one event per square. As I tend to note, eventing is just like programming, which is all about problem-solving. So, we have a problem and want to solve it.

• We need an event to keep track of the player’s position while he/she is around the dragon statue.
• We need the other event to act as the interaction event (this is, the one that will be Same As Characters/Action Button).
• We have to make sure that the player is actually looking at the statue. It wouldn’t do for the player to be looking in the opposite direction and getting the dragon statue information when he/she presses the Action Button.

We actually have all that is called for in the preceding three bullet points, even if it does not appear to be so. We’ve used the first event several times already, but for transfer events. All we will do is change what we’re going to use it for.

Drawing a Perimeter

Our first order of business is noting which squares are around the dragon statue. That will be our perimeter, if you will. Take a look at Figure 6-3.

Figure 6-3 is a highly zoomed-in screenshot of the dragon statue and its surrounding squares. You’ll want the X and Y values to draw the effective perimeter. Check the following code to see what I did for that first part.

@>Control Variables: [0002:X] = Player's Map X
@>Control Variables: [0003:Y] = Player's Map Y
@>Conditional Branch: Variable [0002:X] >= 43
   @>Conditional Branch: Variable [0002:X] <= 46
      @>Conditional Branch: Variable [0003:Y] >= 25
         @>Conditional Branch: Variable [0003:Y] <= 27
            @>Jump to Label: Step 2
            @>
          : Branch End
         @>
       : Branch End
      @>
    : Branch End
   @>
: Branch End

So, as usual, we write the player’s position into a pair of variables and then check against the current map coordinates to see if they are in the dragon statue’s perimeter. If they aren’t, nothing happens. If they are, we have a label called Step 2 that continues the event. Here’s the next part of the event:

@>Conditional Branch: Variable [0078] >= 999
   @>Label: Step 2
   @>Conditional Branch: Variable [0002:X] == 43
      @>Conditional Branch: Variable [0003:Y] >= 25
         @>Conditional Branch: Variable [0003:Y] <= 26
            @>Control Variables [0002:X] += 1
            @>Set Event Location: [DragonTopic], Variable [0002][00003]
            @>Jump to Label: Done
            @>
          : Branch End
         @>
       : Branch End
      @>
    : Branch End
   @>
: Branch End

Moving Our Interaction Event

We have two new things in the perimeter-establishing event that are of interest.

• First, we have a dummy variable (that has a set value of 0), and we have the system try to resolve the branch if said variable is greater than or equal to 999. As we are not writing anything there, this branch will never be true. So, why have it at all? Remember: Events execute from top to bottom, unless prevented from doing so. We have this dummy branch here so that the rest of the event will only execute when we use the Jump to Label command to jump to Step 2 inside of the branch itself.
• Second, we have the engine of what will make this whole event work in the first place. In this portion of the event, we’re checking to see if the player is standing on the two squares to the left of the dragon statue. If he/she is, we add one to the value of X and use a new event command.
• Set Event Location allows you to change the position of any event (including the triggering event itself, if you would want to do so for any reason) on the map. What we want to do is have the Action Button event used for the dragon statue move to meet the player’s movement. It’s a sneaky little trick that gets the job done in this case. See Figure 6-4 for a screenshot of what the command entails.

From here, you can select which event to move. Then you can choose to designate a specific location for the event, use variables to determine the location, or exchange it with another event’s location. In the case of events with graphics, you can also determine whether they retain their former facing or change to a different direction. You can probably already tell what that +1 to X is about. Because the player is standing one space to the left of the statue, we have to move the event one space to the player’s right, so that he/she can interact with it while facing eastward. Now that you understand the logic behind this event, can you figure out how to do the other two? The northern squares are blocked by a wall, so you don’t have to take them into consideration for the purposes of this exercise. To clarify, you need to account for the player being below the statue and to its right. If you think you have it (or otherwise need the help), here’s the final part of the Parallel Process event:

@>Conditional Branch: Variable [0003:Y] == 27
   @>Conditional Branch: Variable [0002:X] >= 44
      @>Conditional Branch: Variable [0002:X] <= 45
         @>Control Variables: [0003:Y] -= 1
         @>Set Event Location: [DragonTopic], Variable [0002][00003]
         @>Jump to Label: Done
         @>
       : Branch End
      @>
    : Branch End
   @>
: Branch End
@>Conditional Branch: Variable [0002:X] == 46
   @>Conditional Branch: Variable [0003:Y] >= 25
      @>Conditional Branch: Variable [0003:Y] <= 26
         @>Control Variables: [0002:X] -= 1
         @>Set Event Location: [DragonTopic], Variable [0002][00003]
         @>Jump to Label: Done
         @>
       : Branch End
      @>
    : Branch End
   @>
: Branch End
@>Label: Done
@>

The first set of branches is called when the player is below the statue, and the second set is used when he/she is to the right side of the statue. You’ll also see the Jump to Label that trigger once a single branch has been executed. They are there merely as an extra precaution to make sure nothing strange happens when the event runs. We’re done with one-half of this exercise. Now we need the event that will actually trigger when the player attempts to interact with the statue. First, right-click any one of the squares that makes up the dragon statue and creates the event. Looking back at the zoomed picture, you’ll note the following:

• The player may only interact with the top-left and top-right squares by facing right and left, respectively.
• For the lower two squares, the player has two possible facings.

Checking Our Player’s Directional Facing

We need a way to make sure that the player is facing the right way. Enter the Conditional Branch once again. Up to now, we have been using conditional branches almost exclusively to check against variable and switch values. However, there are three more pages full of things that you can check against. If you click page 3 of the conditional branch command, you will find the Character X is Facing Y conditional. X defaults to the player but can also check for every single event on the current map, and Y is the direction the player or event in question is facing. Here’s the first part of the relevant event from my end:

@>Conditional Branch: Player is Facing Right
   @>Conditional Branch: Variable [0002:X] == 44
      @>Text: -, -, Normal, Bottom
      :     : You see a majestic dragon statue. It hums with
      :     : power.
      @>Text: 'Actor5', 6, Normal, Bottom
      :     : I sense immense power emanating from this
      :     : statue. Be mindful. It would be best to
      :     : return at a later time.
      @>Text: -, -, Normal, Bottom
      :     : Touch the statue?
      @>Show Choices: Yes, No
      : When [Yes]
         @>
      : When [No]
         @>
         : Branch End
      @>
    : Branch End
   @>
: Branch End

We set up a conditional branch to ensure that the player is facing to his/her right. Afterward, we make sure that X is equal to 44 (which it will be, if the player is standing next to the statue’s two left squares, which is assuming, of course, that you have not tweaked the size of that particular map). If both conditions check out, we display the relevant text and give the player a choice. As you can already tell, I have left both possible answers empty. I’ll leave that as an exercise for you for now. We’ll revisit this one much later in the book, as we put the finishing touches on our game. Anyway, take a look at Figure 6-5 for the tweaked third floor of our second dungeon. The base sample map used was Tower of the Void F5F.

From there, I split off the western half, changed the position of the staircase in the southwest wedge of the central area, opened some areas, and closed others. I decided to go with a deteriorated-structure feel for the top floor, with holes and such. The biggest change was adding a bookcase and some red carpet to that left area. I have a particular plan for that bookcase. But first, let’s create this dungeon’s boss. Given how we’ve been replacing monsters from the bottom up, that leaves the highest non-altered enemy at #28. I think the Demon could serve as a good second boss for our game. However, we have to tweak his stats. Take a look at Figure 6-6 for a comparison of the Demon’s base stats and his adjusted stats.

Our Second Boss

In Figure 6-6, the left side is unadjusted, while the right is the tweaked version for our game. It will probably be necessary to tweak the Demon even further, but that’s something we can do when play-testing. Of note is the Demon’s weakness to Holy.

Creating a Bookcase Interaction Event

Let’s give Noah an item that allows him to capitalize on the Demon’s weakness to Holy. There are two bookcases on the top floor, and we want the right-most one to grant the book. Let’s use the same pair of events that we used for the dragon statue. This time, however, it will be a lot easier. See, the dragon statue is a 2×2 graphic. Our line of bookcases, on the other hand, is a straight line. Thus, all we have to do is make sure the relevant item is placed on the right bookcase, and we’re set. Here’s the event to set the book interaction:

@>Control Variables: [0002:X] = Player's Map X
@>Control Variables: [0003:Y] = Player's Map Y
@>Conditional Branch: Variable [0003:Y] == 18
   @>Conditional Branch: Variable [0002:X] >= 13
      @>Conditional Branch: Variable [0002:X] <= 15
         @>Control Variables: [0003:Y] -= 1
         @>Set Event Location: [BookTopic], Variable [0002][00003]
         @>
       : Branch End
      @>
    : Branch End
   @>
: Branch End
@>

Much cleaner than the dragon statue equivalent, right? Here’s the interaction event as well:

@>Conditional Branch: Player is Facing Up
   @>Conditional Branch: Variable [0002:X] >= 13
      @>Conditional Branch: Variable [0002:X] <= 15
         @>Text: -, -, Normal, Bottom
         :     : You see an ancient bookcase filled with old books.
         @>Conditional Branch: Variable [0002:X] == 15
            @>Conditional Branch: Self Switch A == OFF
               @>Text: -, -, Normal, Bottom
               :     : Noah appears to be lost in thought as he runs a
               :     : hand through the bookcase.
               @>Text: 'Actor5', 6, Normal, Bottom
               :     : I feel warm power coming from one of
               :     : these books.
               @>Text: -, -, Normal, Bottom
               :     : Noah passes a finger over each book, eventually
               :     : landing on an otherwise unassuming red book.
               @>Text: 'Actor5', 6, Normal, Bottom
               :     : I'll be taking this book. It feels like
               :     : we'll have a need for it soon.
              @>Play SE: 'Item3', 80, 100
              @>Change Armor: [Book of Light] + 1
              @>Text: -, -, Normal, Bottom
              :     : Obtained C[2]Book of LightC[0]!
              @>Control Self Switch: A =ON

Not noted: several branch ends that are ultimately irrelevant to the event. First, we make sure the player is facing the bookcases (in this particular case, merely a precaution, as there’s only one way to face to actually interact with them). Then we make sure that the player is at the correct location. If so, we show a text box describing the bookcase. Additionally, if the player is interacting with the right-most bookcase for the first time, we have Noah find our new item. (I replaced armor #60 to create that Book of Light, which is equipped to the accessory slot.) While Noah has the Book of Light equipped, it gives him 5 MAT, 5 MDF, 10 MMP, and the ability to cast God’s Will, a default skill in RMVXA that deals Holy damage to its targets. Of course, because we don’t want this sequence of events to repeat more than once, we have the relevant self-switch flip on, so that the event skips through the self-switch conditional on subsequent interactions.

Creating Our Second Boss Event

Once we have created the bookcase event and the Book of Light item, all we have to do is create the boss event on the top floor and set up the area’s random encounters. Because we already created an Action Button boss event, let’s make this one rely on Autorun.

What we’ll need:

• A Parallel Process event (You can use the transfer event for this, and you want to check for the player’s x and y coordinates in any case.)
• An Autorun event that activates when a particular switch is flipped on. This switch would be toggled when the player walks near the boss.
• A graphic that represents the boss itself, to be used in a third event

Here are the commands I appended to the end of the Parallel Process transfer event.

@>Conditional Branch: Variable [0003:Y] == 29
   @>Conditional Branch: Variable [0002:X] >= 24
      @>Conditional Branch: Variable [0002:X] <= 26
         @>Conditional Branch: Self Switch A == OFF
            @>Control Self Switch: A =ON
            @>Control Switches: [0005:Boss2Encounter] = ON

As with the bookcase event, we only want this snippet to trigger once, so we set an extra conditional that only allows the branch to be executed if self-switch A is off and then turn it on. We then flip the aptly named Boss2Encounter switch.

Creating the Boss Encounter

Our second event is an Autorun that only triggers if that switch is on. It contains most of the meat of the boss encounter, hence the descriptive heading. Page 1 of this event looks like this:

@>Tint Screen: (-68,-68,-68,0), @60, Wait
@>Fadeout BGM: 3 sec.
@>Wait: 60 frame(s)
@>Text: 'Actor4', 0, Normal, Bottom
:     : What's going on?
@>Wait: 60 frame(s)
@>Text: -, -, Normal, Bottom
:     : A cackling sound pierces the strangely silent air.
@>Text: -, -, Normal, Bottom
:     : So, you are the two who defeated my servant.
@>Text: -, -, Normal, Bottom
:     : Eric and Noah advance to the source of the voice.
@>Conditional Branch: Variable [0002:X] == 24
   @>Set Move Route: Player (Wait)
   :               : $>Move Right
   @>Jump to Label: Center
   @>
: Branch End
@>Conditional Branch: Variable [0002:X] == 26
   @>Set Move Route: Player (Wait)
   :              : $>Move Left
   @>Jump to Label: Center
   @>
: Branch End
@>Label: Center
@>Set Move Route: Player (Wait)
:               : $>Move Up
:               : $>Move Up
:               : $>Move Up
:               : $>Move Up
:               : $>Move Up
:               : $>Move Up
:               : $>Move Up
:               : $>Move Up
:               : $>Move Up
:               : $>Move Up
@>Text: 'Monster1', 3, Normal, Bottom
:     : Welcome humans. I am glad to make your
:     : acquaintance. I would have you join my
:     : cause.
@>Text: 'Actor4', 0, Normal, Bottom
:     : No.
@>Set Move Route: [Boss] (Wait)
:               : $>Move Down
:               : $>Move Down
:               : $>Move Down
@>Text: 'Monster1', 3, Normal, Bottom
:     : Heh. Was worth a try.
@>Control Self Switch: A =ON
@>Change Battle BGM: 'Dungeon9', 100, 75
@>Battle Processing: Demon
@>

Take a look at Figure 6-7 to see the boss area of our second dungeon.

The Autorun starts with the screen being tinted using the Dark filter. Afterward, the background music fades out over the next three seconds. A one-second pause precedes Eric wondering what’s happening, and another one-second pause is triggered afterward. Some flavor text is displayed, and then the player is told that the party advances toward the source of the voice. If he/she is not standing on the center square (the center part of that black rectangle in the preceding screenshot), we move him/her one space to the side, so that he/she is. Then we have the player move up a total of ten squares, to where the monster continues speaking. We have the event that represents the boss move three squares down (so that it is directly in front of the player), turn on self-switch A, change the battle music, and start the boss fight. Page 2 of the Autorun event has the “self-switch A equals on” conditional and is completely blank. (Make sure that the trigger for page 2 is not Autorun).

The Aftermath of the Boss Encounter

Page 3 of our second boss encounter event has a conditional that uses a switch that is toggled when the boss is defeated (I called that particular switch Boss2Defeated) and is another Autorun page.

@>Text: 'Monster1', 3, Normal, Bottom
:     : Tch. You two are messing with forces
:     : beyond your ken. I am but one of many
:     : pledged to the will of the All Master.
@>Text: 'Monster1', 3, Normal, Bottom
:     : Push farther then, fools. One of the
:     : Three awaits at a castle far to the
:     : north of here. Defeat him and see the
:     : truth of this world!
@>Fadeout Screen
@>Change Battle BGM: 'Battle1', 100, 100
@>Control Switches: [0007:PlotAdvance2] = ON
@>Control Self Switch: B =ON
@>Wait: 60 frame(s)
@>Fadein Screen

Once the monster has finished speaking, we fade out the screen, restore the battle music back to its default, and flip on two switches. The first one we will use to make the boss graphic event disappear, and the second one allows us to create the fourth and last page for this event. The last page will require self-switch B to be on and will be completely empty with an Action Button trigger (much like page 2 was). The third and final event is the boss graphic and is two pages long. The first page has the boss graphic and no conditional. The second page has no graphic and requires PlotAdvance2 to be switched on.

Summary of Our Second Boss Event

That will conclude our most recent boss event. To summarize, we used three events.

1. A Parallel Process event to determine when the player walks into the boss’ domain. It used a self-switch conditional to make sure that it cannot trigger multiple times (really important when dealing with a Parallel Process event).
2. An Autorun event that made up the meaty portion of this exercise. It spans four pages, with the first one activating thanks to the switch flipped in the Parallel Process event. The second page has a conditional that is met right before the boss attacks the party, while the third requires that the boss be defeated to be automatically executed. Last, the fourth page is the one that remains after the boss is defeated.
3. A simple event meant to hold the boss graphic and nothing else. This exists until the boss has finished talking after the battle and then disappears.

There are three more things to cover before I end the chapter. The first is that we must set the random encounters for our second dungeon. We want the game’s encounters to become progressively more difficult, so let’s bump up the bar as compared to the previous dungeon. Second, we’ll need to add our dungeon to the world map and create a relevant transfer event. Last, I need to list where each staircase leads in our tweaked dungeon.

The Second Dungeon’s Random Encounters

On the first floor of the second dungeon, Wisps will appear half the time, while a pair of Jellyfish will appear 3/10ths of the time. A trio of Ghosts is the rare encounter on the first floor, with a 2-in-10 chance of being encountered (Figure 6-8).

On the second floor, we have the encounter table as presented in Figure 6-9.

Wisps have been phased out completely, making Ghosts the common encounter on this floor. Skeletons are encountered with the same frequency as Imps, a new foe in this dungeon, while the rare encounter is a trio of Zombies, another new enemy type. I decided against having encounters on the top floor, but you could consider using the same encounter table as the second floor, but with altered weights to make the weaker monsters rarer and the stronger monsters more common. Last, but not least important, we want to keep Eric and Noah progressing nicely in terms of gear. I added the following gear to some of the treasure chests I placed in the dungeon: Bardiche, Bronze Plate, Crossbow, Runed Robe, and Spike Shield. You don’t have to make every treasure chest item an upgrade, mind you. In fact, the Bronze Plate is a downgrade, compared to the Hard Leather we placed in the first dungeon.

Placing the Second Dungeon on the World Map

All of the work that has been done in this chapter is for naught if we don’t actually allow the player to visit the dungeon, right? So, I’m going to add an appropriate tower graphic (the left-most Tower in tab B of the Field tileset) on the map. I’ll place the base of the tower at 13,76. See Figure 6-10 for a screenshot of how it should look once placed.

Once that is done, all that is left to do is create the transfer event, like so:

@>Conditional Branch: Variable [0002:X] == 13
  @>Conditional Branch: Variable [0003:Y] == 82
    @>Transfer Player: [007:Tower of the VoidF1F] (025,049), Up
    @>
  : Branch End
  @>
: Branch End

Place that code within your preexistent Parallel Process event and make sure to add an appropriate transfer event within the dungeon to allow the player to leave.

The Staircases of the Second Dungeon

The second dungeon has quite a few staircases, so it’s a good idea to have a table that lists what staircase goes where. See Table 6-1 and note that, when you create the relevant transfer events, you need to move the destination location off of the staircase or you’ll trap the game in an infinite loop.

Summary

This chapter covered the creation and population of our game’s second dungeon. We used RMVXA’s Sample Maps to great effect once again to create a foreboding tower housing a powerful demon for our player to defeat. The dragon statue was the host of a particularly neat application of Parallel Process events to allow a single Action Button event to be used for interaction purposes. In the next chapter, we will have some fun with arenas and other such minigames!