So Many Pieces – Challenge Solution

A few weeks ago I issued a challenge: populate your game with three different-colored chests, and to open then, require a player to have 50 fragments of the right color of key. We solved a single key problem all within the chest event, but here I asked you to do it with a common event that runs each time a chest is opened.

Why? Well, what if you find that 50 key fragments are just way too many to ask a player to get, and want to change it to 10 for your entire game. If you have any more than a dozen chests, you’re going to curse the day you decided to have all of that information contained in each chest event.

And we’re going to solve the problem with Ruby. Don’t be afraid! This one is easy. So let’s get to it! I’ve created three items in my database, one for each key fragment, and they are items 4, 5, and 6 (you can check for your item IDs in the game Database, it’s the number to the left of the item name). Red, blue, and green, respectively. I also need a variable, a switch, and a common event.

  • I call my variable “Key to Check” – this is different than before, when we wanted to know how many of an item the player had in their inventory. Instead, we’re storing in this variable the item ID for the chest. 4 for red, 5 for blue, you get the idea.
  • My switch is named “Chest Can Open” – if it’s on, the chest will open. If it’s off, the chest will remind us we need more key fragments.
  • My common event is called “Open Chest Check” – it’s the event that will process all chests and decide whether to open them.

I’ll set up my chest with a conditional branch, just as we did before. It’s just that the things we do in advance are a little different. We’ll need to set our “Key to Check” variable based on the color of our chest, and then we’ll need to call our common event. Finally, the conditional branch is based on our switch. Like so!

To think only a few weeks ago we were pickle hunting in this forest.

To think only a few weeks ago we were pickle hunting in this forest.

Note that because it’s a red chest, the Key To Use is set to 4 – the item ID of my Red Key Fragment. Now we build our common event. Choose “script” from the trigger editor to open a scripting window, and add the following.

Just a few lines of code will process all of our chests in the game.

Just a few lines of code will process all of our chests in the game.

Ok, let’s go through that line by line:

  • id = $game_variables[5] : here, we’re just setting whatever the value is in our “Key To Use” to an easy name, “id.” The script editor inside a common event doesn’t play nicely when you don’t name your variables.
  • key = $data_items[id] : now that we have our id, it’s easy to actually match the id up to an item. We’ll call our item “key” (even though it’s really a fragment, we don’t win points for being literal).
  • itemamt = $game_party.item_number(key) : a built-in RPG-Maker function, this allows you to find out how many of a given item the party has. In this case, we’re “giving” it key, which we defined in the line before.
  • if itemamt >= 50 : this is just like a conditional branch in the trigger editor. We’re asking, if the player has 50 or more of whatever item we’ve chosen.
  • $game_switches[1] = true : set our “Chest Can Open” switch to ON
  • $game_party.lose_item(key, 50) : another awesome built-in, we tell RPG Maker which item to lose (here, it’s “key”) and how many to lose (here, “50”)
  • else : just like the else in conditional branches in the trigger editor
  • $game_switches[1] = false : set our “Chest Can Open” switch to OFF
  • end : make sure to end your if/else statement

And that’s it! Doing it this way has two VERY nice features:

  • If you want to change the amount of key fragments from 50 to 10, you only have to change it in two places. You can probably tell where they are in the script!
  • If you want to add a yellow chest, no problem! No need to reprogram anything, just make a yellow key fragment and you’re off to the races – this common event doesn’t care what chest you’re opening.

Happy scripting!

 

 

Class Warfare

Reddit user kraegar wanted the player to choose 2 class for her party at the start of the game, but wanted to prevent her from duplicating the first class. The set-up was simple: in room 1, the player encountered 10 NPCs each representing a class, and the player would chose one for her first party member. In room 2, she encountered 9 NPCs – the classes, with the already-chosen one conspicuously absent. Kraegar set Variable 1 “Player 1 Class” to a number, 1-10, based on what you picked, and Variable 2 “Player 2 Class” the same. But how to make the NPC in room 2 disappear, as oppose to tell you “Sorry, you’ve already chosen my class?”

The answer is event pages!

First, let’s set up our first room, with all ten classes. When you talk to the NPC, we’ll give the player a choice to accept that class, and then if they do, assign the variable accordingly. Set up your event page like this:

We set variable 1 to "6" to represent healer. Just make sure you remember the numbers for each class!

We set variable 1 to “6” to represent healer. Just make sure you remember the numbers for each class!

 

We might even make every NPC tell you to advance to the next room once you’ve chosen a class. Let’s get comfortable with using different event pages. Once you’ve set up your NPCs, click “New Event Page” at the top, and for that page set it up something like this (I chose a different class this time – you’ll want each event to only deal with a single class).

The circle indicates what the page's number is. Number is critical to determining order.

The circle indicates what the page’s number is. Number is critical to determining order.

A few notes here. Sure, we could’ve put all of this in one event page, but in order to change the dialogue depending on your class we’d need nesting conditional branches. As you get more complex with your events, these conditional branches can run right out of the window, and can make it incredibly difficult to follow your event logic. Where possible, use event pages!

Second, it’s important that this event page be numerically higher than the previous one. That is, the page when you’ve already made a choice cannot be number 1, while the page prompting you for your choice is number 2. Why?

RPG Maker always displays the highest numbered event page where all of the conditions are true.

So long as Player 1 Class is 1 or above, this second page will be on display. If we flipped them, our prompt page would be on display no matter what – it has no conditions! Any page with a lower number would never be displayed.

Ok, we’ve chosen our class, and we’re well on our way. It’s surprisingly simple to set up the next room. The only difference is that we need a few event pages! The first will be the nearly the same as before – copy and past from your old room, just change the text and variable setting to reflect that this is your second choice.

If you only want to copy a page, and not the entire event, there's a button for that.

If you only want to copy a page, and not the entire event, there’s a button for that.

Now, we want our Bard to show up in this room only if Variable 1 is not equal to 9. As you might’ve guessed, make a new event page. This time, set the condition to “if Variable 1 is 9 or above” and leave the entire thing – graphic and all – blank. Like so:

Make sure blank event pages like this one are set to "Below Characters" - otherwise, you'll create an invisible wall.

Make sure blank event pages like this one are set to “Below Characters” – otherwise, you’ll create an invisible wall.

But wait, what if Variable 1 is 10 – the pugilist? We solve it with, you guessed it, another event page. Copy and paste the first one, into slot three, and set the condition to Variable 1 is 10 or above.

Our Bard is rather full of himself, isn't he.

Our Bard is rather full of himself, isn’t he.

And that’s it! Now when you enter this room, if Variable 1 is equal to 9, you won’t see the Bard. We can do the same for all of our classes, to have a seamless class picking setup.

A Little Ruby

Don’t be scared of learning how to script in RPG Maker a little at a time! While this approach works for some, you may have reasons for not wanting to store a class ID in a variable. Oftentimes in complicated games, you can end up with thousands of switches and variables, and so just grabbing the class ID of a character is preferable to accessing a variable. We can do this! To get the class of any given actor, you use:

$game_actors[actor_id].class_id

This will get you the class id of the actor identified. You can find both of the numbers in your game’s database. While event pages don’t have script conditions built in, this can still be a powerful tool to use.

Once it's a script, we can start to dynamically change a lot of things. We can even change a party member's class on the fly.

Once it’s a script, we can start to dynamically change a lot of things. We can even change a party member’s class on the fly.

Bridges – Tutorial and Supplement

William The Unpro Pro has a video on how to make bridges, and it’s a great scriptless way to have a character go both under and over bridges, depending on levels! Check it out! As a supplement, Reddit user warboy3 had some difficulty implementing the events William described in his video. The trick he was missing – and one not specified in William’s video – is shift clicking. When RPG Maker VX Ace generates a roof tile – like the one warboy3 was using – it autotiles the roof accordingly. What this means is, if your roof tile has a ground tile to its north, then the roof’s northern edge will be a border. Putting aside bridges and events and all of that jazz, this is what happens when you make a roof:

Bridge Tutorial

See those dark green borders circled in red? Those are autogenerated by RPG Maker at the edge of the roof so that you don’t walk onto the roof from its side.

As awesome as the bridges are, they won’t change that fact. Which is why our hapless player was able to walk across the bridge, but only if the bridge extended past the auto-generated border. That looks dumb, as he rightfully complained, so instead, lets get rid of the border entirely! Shift rightclick on any roof tile that is surrounded by roof tiles, say…that one:

Bridge Tutorial

The circled tile is surrounded by roof on all sides, so RPG Maker hasn’t generated a border.

Then shift leftclick on the entrance/exit to your bridge. It’ll look like this, notice a slight change?:

Bridge Tutorial

Take a look at the left roof, where we might have a bridge connect.

Shift-clicking copies exactly the source tile, auto-generated borders and all. Our bridge is going to connect to the roof on the right, but see the tile where we’ll step out? We’ll probably want to keep the top border, and just eliminate the left border. Thoughts as to how to do that?

Once you’ve got the map set up, follow William the Unpro Pro’s tutorial, and you’ve got yourself a bridge, son!

Bridge Tutorial

We’re going all over – and under – this bridge. It’s gonna be awesome.

Incidentally, Neon Black has an awesome script to handle bridges, and it uses region tags, if you’re into that sort of thing.