Friday Script – Modern Algebra’s Message Options

If you want to get the most out of RPG Maker, learn Ruby. In the meantime, lots of talented scripters have done the work for you. Every Friday, The Iron Shoe features a fun script and goes into detail about how to use it. It also covers a little bit of Ruby each time so you can make even more out of the script.

Yanfly isn’t the only scripter with a message manager. Modern Algebra has come up with an amazing way to let you change the position of text boxes so you’re not so limited to top/middle/bottom. Coupled with dynamically adjusting window-sizes, this message manager may be exactly what you need to make your game look, well, less out-of-the-box. Today I’m talking about the “Message Options” script (I’ve linked you to a bunch of Modern Algebra’s dialogue options). Download the script, add it to your project, and let’s get started!

Options

There are a whole lot of features in this script, and each one has it’s own customization options. Roughly speaking, we can do the following:

  • Have text follow-on or “append” to the previous text. That is, if you have two “Show Text” commands in an event, one right after another, the manager will appear to connect them in a box.
  • Scroll within your message box at variable speeds, line by line, and allow scrolling up so a player can see earlier parts of the conversation
  • Have various sound effects, including dialogue start, pause, stop and typing
  • Name plates
  • Automatically place the message window to not obscure certain characters or NPCs.
  • Shrink the window to the minimum size necessary to contain the text
  • Position the text in relation to an event on the screen
Look for this section of the script where you can edit the defaults. But all of the defaults can be changed on a message-by-message basis.

Look for this section of the script where you can edit the defaults. But all of the defaults can be changed on a message-by-message basis.

Here are some of the interesting ones:

  • append_text: when set to true, all commands to add text to the message window will be shown consecutively, that is, scrolling in the same window. If this still doesn’t make sense, set it to true and give it a spin so you can see  what it’s like! False would return to default.
  • Pause_before_scroll: combined with append, you’ll get a nice crisp pause before the next page scrolls into your window.
  • letter_sound_on: play a typing sound as the text starts to appear. It’s like Phoenix Wright!
  • message_windowskin: with this, you can actually change the window skin used dynamically in your game. Use a different skin for different contexts!
  • do_not_obscure: this is an awesome feature. Put the ID of the player or event that you want to make sure is visible on screen, and the message window will never obscure that player or event. Really helpful when building cutscenes.
  • fit_window_to_message: this will change the size of the window box every time so it’s only as big as necessary.

A note about combining fit and append. Suppose you have several dialogue boxes in a row in your event, like this:

Here's an example conversation from Vidar - let's beef it up.

Here’s an example conversation from Vidar – let’s beef it up.

If append is on, even if fit is on, the window isn’t going to change size from text to text – it’s going to be as large as necessary to accommodate the biggest text. So definitely four lines tall. And then probably as long as “a tunnel to dig from our yard that would” which is several boxes down. This means that “What is it?” is going to be in a much larger box than necessary. It’s not bad, it’s not good – you should just be aware!

Example Dialogue

In the example above, we have a conversation from Vidar between two characters – Dorottya and Katarina (who affectionately call each other Dorry and Kat). Even if we’ve set up some of our presets in our script, we can (and probably want to) change them here where it’s not just on NPC yapping at us, it’s a conversation.

First, we want to add name boxes so we know who is talking. We can prefix each dialogue with a command to insert a name box using \nb{Name}. So something like this:

Even though the characters have nicknames, better to be more formal in the name block.

Even though the characters have nicknames, better to be more formal in the name block.

As we put this in, we see that each character gets 1 command, and then it passes to another. Even if we’re using append throughout the game, it would make very little sense to use it here – each character should really get their own box. We can use a script call to turn off append for just this event.

ats_all(:append_text, false)

We’ll want to call the same thing at the end of our conversation, subbing in true, to set us back to the default.

Next is a really fun feature – dynamically setting the position of the box. Now, we can move the dialogue box to above the NPC that’s actually talking so it looks more like a conversation! First we need the event numbers of our NPCs – you can get it at the top of the event page for the character itself.

Even if you change the name of the event, the event number is still at the very top of the window.

Even if you change the name of the event, the event number is still at the very top of the window.

Then in our conversation event, we add yet another command – \et[EVENT NUMBER]. The message box will be above the event – you can use \eb for below, \el and \er for left and right. Add them right before the namebox command.

Caption

Don’t put any spaces between \et[x] and \nb{Name} – that space will show up at the start of your text, and you don’t want that.

Combining all these elements, we can get a really cool effect that makes the game look less…defaulty.

Our first NPC talks...

Our first NPC talks…

...and our second picks up the conversation. Visual cues tell the player who is talking when.

…and our second picks up the conversation. Visual cues tell the player who is talking when.

Now just write some good dialogue!

Elemental Shifter Revisited – Hime’s Feature Manager

Last week I showed you how to make an element-shifting boss using only the database. There are some improvements I identified at the end; today we’ll tackle them with scripts. Specifically, let’s have the enemy absorb elemental damage rather than negating it; and let’s have the graphic of the enemy change to represent the current elemental affinity.

Elemental Absorbtion

This is almost a waste of Hime’s Feature Manager, which has powers far beyond elemental absorption, but nevertheless it’s the best tool for what we’re going to do today. The nice thing is, once it’s installed in your game, you’ll have a million other options for how to use it, and it might inspire you. So go copy and paste it into your game, and let’s pick up where we left off.

As it turns out, it’s extremely easy to make anything absorb elements using Hime’s Feature Manager. An actor or enemy can just, by default, heal from ice damage. But we want to make our boss absorb fire only when he is attuned to that element. So we put it in – you guessed it – the state we created. The code you need is:

<ft: element_rate x -1>

Replace “x” with the ID of the element you want to absorb. And we put this in the “Notes” section of our state:

Thanks Hime for the incredibly useful script!

Thanks Hime for the incredibly useful script!

What this little note call does is apply a new “Element Rate” to anything with this state. It applies it to Element X (which you’ve set), and the rate is set to -1. This last number is a percentage, and we use a negative to indicate healing. So, “-1” means that the enemy will heal for 100% of fire damage dealt to it. If we want to make it heal, but for less than the full amount of damage, we might set it to something like -0.5. Anytime we’re at 0 (no damage, no healing) or some positive number (damage), we can use RPG Maker’s built-in editor instead.

Set this up for both of your states, and remove the damage immunity we had built in before. That’s all there is to it!

Elemental Coloring

You might’ve noticed that RPG Maker VX Ace has an extremely handy tool when it comes to designing enemies – the hue tool. When choosing the graphic for your battler, you can easily recolor an enemy just by sliding a bar. It’s perfect for reskins, which is how pretty much every RPG ever has saved on graphics.

The God of Fuchsia and Fabulous

The God of Fuchsia and Fabulous

We’re going to use this feature to change our enemy’s hue depending on what state he adopts. That’s right, we can change the hue mid-battle. And it’s actually pretty easy. First, we need to do a teeny bit of tinkering with the RPG Maker Code. “Battler Hue” is something that the engine expects is set once and then forgotten. As such, it calls it a “reader” attribute – something that can be read, but not modified. We want to change this to an “accessor” attribute. Open up your script window, go to Game_Battler and find around line 33 where it says “attr_reader :battler_hue.” Change it to “attr_accessor :battle_hue.” It should look something like this:

Element5

Now that we can tinker with the hue, let’s. Set up two common events – one for each “shift.” The code to change an enemy’s hue is:

$game_troop.members[x].battler_hue = y

Where x is the ID of the enemy in battle (0 for the first, 1 for the second, and so on),and y is the hue you want to set. You’re going to have to tinker with your hue value to get what you want. In my case, for lightning, I’m aiming for a yellow. 45 looks just about right. Since my boss is the only enemy in the troop, I replace x with 0 (he’s the first and only battler).

Element4

Do the same for shifting to your other color. Again, you’ll come back to change those hue numbers as you test it out. Use the hue slider in the database to help guide your adjustments as you go.

Now all we need to do is to call the correct common events when your boss changes his elemental state. Go back to the skills which allow him to change states, and add one more line in “Effects.” The line is “Call Common Event,” and you’ll want to call the correct one of the color shifting events we just created. So, if the skill is “apply fire,” then we want to call the common event “set fire color.”

Element6

The only other modification you’ll want to make is this: make sure your battler’s starting hue (as set in the database with the hue slider, like normal) is the same as the first state you gave him when we set him up last week.

Happy shifting!

Element2

Friday Script Or Not – Fomar’s Skill Master / Learn By Doing

If you want to get the most out of RPG Maker, learn Ruby. In the meantime, lots of talented scripters have done the work for you. Every Friday, The Iron Shoe features a fun script and goes into detail about how to use it. It also covers a little bit of Ruby each time so you can make even more out of the script.

Everyone loves to make their RPG stand out just a little bit, and one amazing way to do that is with a unique skill system. Today I want to talk about one option – a learn-by-doing system where you increase your skill ability based on the number of times you’ve used it! This is a Friday Script post, and we’ll delve into Fomar’s awesome and succinct Skill Mater scriptBut first, we’re going to do it all without scripts. In fact, you can make this system with events alone.

Skill System By Events

There are a few basic components we need to create in the database. The first is, for every skill that can be leveled, we need a variable corresponding to each actor that can use it. Based on your game design, this could be a lot of variables! You’ll need one final variable that the ID of the caster. Make a note of which one that is (here, 16)

Multiple actors could have access to the same skill - or not! Whatever you want!

Multiple actors could have access to the same skill – or not! Whatever you want!

The second is to build the skills, as many levels of them as we want. So, if we want “Spin Attack I”, “Spin Attack II”, and “Spin Attack III,” we make each skill with higher damage amounts, higher MP costs, etc.

Learn By Doing

Skills can do more than one thing. Just use the ; to separate lines of code.

Note that in my damage formula box, I have a normal damage formula, followed by:

; $game_variables[16] = a.id

Variable 16 is my Caster ID variable. What I’m asking the damage formula box to do is first deal damage, then set the variable to who is casting. We’ll use this in the next step. It’s important that every skill that you want to level has this little line after it’s damage formula. You can copy and paste it – it’s the same variable, same everything for every skill.

Third, we make a common event for each skill that’s going to be leveled. One for Spin Attack level, one for Fireball, etc. In each one, we’ll need to take yet another variable that represents which actor cast the spell, and based on that, increment the correct variable. We’ll also need to ask if that variable is above a certain threshold – if it is, our actor should learn the new, powerful level of the skill! (and take away the weaker one if you’d like).

You'll need one for every chain level of skill, and nesting options for each actor that could use that skill.

You’ll need one for every chain level of skill, and nesting options for each actor that could use that skill.

Let’s walk through the logic of this common event. We have a series of conditional branches which ask “who is the casting actor?” If it’s 1, then increase the skill variable assigned to that actor by 1. If that brings us to 50 or above, ask if Eric’s already learned the next step. If he has, do nothing. If he hasn’t, teach it to him.

And finally, in each of our skills, we need to set the casting actor variable, and call our leveling common event.

Remember to make sure you've already set the caster ID!

Remember to make sure you’ve already set the caster ID!

It’s pretty easy logic, but is extremely tedious. We need potentially dozens of variables, numerous common events. To simplify, we can use Fomar’s script. Download and install it, and open it up. All of our work happens in that script.

Skill System By Script

From above, we still need to keep all of the different skills. So our skill table in the database will be quite long. But we don’t need the variables and we don’t need the common events.

Look for this area in Fomar’s script:

When you get here, delete the example SKILL[3] line. Otherwise you'll end up with something wonky.

When you get here, delete the example SKILL[3] line. Otherwise you’ll end up with something wonky.

There, we’ll add all of our leveling skill scripts. We do it like this:

SKILLS[original] = [new, uses, replace]

We’ll replace the terms original, new, and uses with numbers. And we’ll replace ‘replace’ with true or false. Specifically:

  • “Original” is the id of the skill being used. So for our Fire I, it’s 9
  • “New” is the id of the next level skill. Fire II’s id is 10
  • “Uses” is how many uses it takes to get from the original skill to the new skill. Choose what you’d like.
  • “Replace” is either true or false – if it’s true, the new skill replaces the old; if false, the new skill is added to the list without altering the old.

We list each skill that has the possibility to “evolve” so-to-speak, and separate them with new lines. Something like this:

Using # in our code means anything we type after on that line has absolutely no impact. It's called a "comment," and I use it here to keep track of what each line is doing. Make sure to keep your games organized!

Using # in our code means anything we type after on that line has absolutely no impact. It’s called a “comment,” and I use it here to keep track of what each line is doing. Make sure to keep your games organized!

Beginner Challenge

Sometimes, it’s nice to have branching paths in our skill tree. We also occasionally let players keep a set of earlier skills because, while they do less damage, they cost less, and the strategy inherent in that decision is more interesting than just always blasting away with the highest level fireball. Using Fomar’s script, how can we make our Fire I spell teach you Fire II after 25 uses, but also teach you Fire All after 50 uses (encouraging you to use Fire I even after you get the upgrade)?

Advanced Challenge

There are two classes an actor can be – Witch and Spellsword. Both can cast Fire, and Fire upgrades to Fire II and Fire III. But the Spellsword takes twice as many uses as the Witch does. Using events, how can we achieve this?

We’ll discuss answers in a few weeks!

Friday Script / Dev Blog – Calling Reset

If you want to get the most out of RPG Maker, learn Ruby. In the meantime, lots of talented scripters have done the work for you. Every Friday, The Iron Shoe features a fun script and goes into detail about how to use it. It also covers a little bit of Ruby each time so you can make even more out of the script.

 

This week we look at another Yanfly script – the Menu Engine! After exploring its use a bit, I’ll show you how I’m using it in Vidar.

Grab the script, install it, and let’s make an awesome menu.

What It Does

The menu manager lets you do two very important things: change the look of your menus, and change the contents of your main menu.

Makeover

One of the fastest ways to identify an RPG Maker game is to open the menu. They all look the same unless some work has been done, and this is the fastest way to give your game a fresh look. At the top of the script, you’ll see a few variables you can change.

“HELP_WINDOW_LOCATION ” set this to put the help window in your menus at the top, middle, or bottom

“COMMAND_WINDOW_ALIGN” you can’t move the command window itself, but you can determine how the text inside it is aligned.

The green circle is the "Help Menu."

The green circle is the “Help Window.” The red circle is the “Command Window.” You might remember Erik’s skills from an earlier post 😉

“MAIN_MENU_ALIGN” text alignment for the main menu

“MAIN_MENU_RIGHT” move the menu around on your screen!

“MAIN_MENU_ROWS” eliminates that extra space at the bottom of

 

This is what we mean by "Main Menu."

This is what we mean by “Main Menu.”

Changing the location of things is quite simple!

More Commands

We can also add and remove commands to our main menu (shown above). By default, RPG Maker gives us:

  • Items
  • Skills
  • Equipment
  • Status
  • Formation
  • Save
  • Game End

Some of these may not apply to our game, and it’s a simple matter of deleting them in Yanfly’s script. But we can also add our own unique entries that call a common event. Look for this area of the script, around line 121:

Yanfly's demos give you a good idea how to use the area. Just a title, two optional switches, and a common event to call.

Yanfly’s demos give you a good idea how to use the area. Just a title, two optional switches, and a common event to call.

Those two “events” are just demos. What you need is this: an event name (preceded by a : ), an arrow, and a bracketed list of 4 things. Those 4 things, in order, are the name to show in your menu, an enable switch, a show switch, and the common event to call.

What are enable and show switches? Here you supply a switch id (you know, the number next to a switch in your Big List of Switches). If the switch in the show switch slot is ON, the item will show up in your menu, otherwise it won’t. If the switch in the enable switch slot is ON, the player can use the menu item, otherwise it will be grayed out. Don’t want to bother with these functions? Just set the ID to 0.

Dev Blogging

About 6 weeks ago, I released a demo of Vidar which was roughly the first fifth of the game, although without many puzzle options. In that demo, I included puzzles which use a concept I’m currently calling Purple Ice – a normal ice tile which breaks when you pass over it. This adds an extra challenge, forcing the player to use certain tiles only once, and anticipate when they’d need them. But what happens when they failed? Not only would I need to reset them at the entrance (which is handled in every ice puzzle), the purple tiles would have to be reset.

For the demo, I put together a reset funciton I made in about 30 minutes. Predictably, it broke often and made the later portion of the demo nearly unplayable.

The past few days have been spent making the reset function more robust. First, each option now keeps track of its own reset function, which gives me more adaptability going forward into the other biomes.

Second, and more important to the topic of this post, I’m using Yanfly’s Menu to build my own menu. I don’t need most of RPG Maker’s defaults, so those have been removed, and in their place, I’ve added a reset function.

Vidar's Reset menu option.

Vidar‘s reset menu option.

The menu item only shows up at all once you’ve reached puzzle 7, when you receive a short note about resetting a puzzle in case you get stuck. It’s only enabled if the “Reset Available” switch is on – in sidequest caves, and in the town, it’s disabled and grayed out. And it calls a common event.

The common event prompts the player with a confirmation screen, and if the player chooses yes, reset is finally called.

How I get from there to the puzzle option is a little gross right now, and is perhaps best saved for another dev blog post once I’ve fleshed it all out.

Friday Script – Dash Control

If you want to get the most out of RPG Maker, learn Ruby. In the meantime, lots of talented scripters have done the work for you. Every Friday, The Iron Shoe features a fun script and goes into detail about how to use it. It also covers a little bit of Ruby each time so you can make even more out of the script. And that’s just what we’re gonna do today!

Sometimes we do complicated scripts like building new quest journals, exporting images from RPG Maker, or fine-tuning control over the camera.

And then other times we just want control over dashing ability.

You might know that each map allows you to control whether the player dashes or not. Oh, you don’t? Well it’s right here:

Check the box to stop a player from dashing on the map.

Check the box to stop a player from dashing on the map.

But we want fine tuned control over our dashing! What if it’s not so simple to do a map-by-map control? Well you can find the script in Game_Player. Just control f for script and you’ll find this little section:

Here is where the magic happens; where you add anything you want to dash a player's dreams of dashing.

Here is where the magic happens; where you add anything you want to dash a player’s dreams of dashing.

This script controls the player’s dash. It won’t dash under the following circumstances:

  • Something is forcing the player to move (like an event, controlling you in a cutscene)
  • The map has “disable dash” on (well duh)
  • The player is riding a vehicle

But who is to stop us from adding more? Consider something like this:

Label your switch in the trigger editor as "Dash Available" or something similar, otherwise you'll forget the importance of this switch.

Label your switch in the trigger editor as “Dash Available” or something similar, otherwise you’ll forget the importance of this switch.

Now we have a switch that controls whether dashing will work. If switch 10 is off, dashing is off. How cool!

We can do this with variables, and we can ask if those variables are too big or too small. Which means we can prevent dashing when a player’s inventory is too big (carrying too much).

We can do this by looking at the party makeup, so that dashing is disabled unless our rogue/thief is in the lead position.

You can add a short-term burst dashing system the same way!

You can add a short-term burst dashing system the same way!

There’s really no limit! What other creative ways of limiting/allowing dash can you come up with?

Friday Script – Yanfly’s Gab Bar

This gab uses Liberty's amazing ghost sprite edits - check out the end of the post for a link!

This gab uses Liberty’s amazing ghost sprite edits – check out the end of the post for a link!

If you want to get the most out of RPG Maker, learn Ruby. In the meantime, lots of talented scripters have done the work for you. Every Friday, The Iron Shoe features a fun script and goes into detail about how to use it. It also covers a little bit of Ruby each time so you can make even more out of the script.

Yanfly is one of the Great Scripters for RPG Maker VX Ace, from overhauling combat, to customizeable skill sets. Truly using Yanfly’s scripts one could finally implement their dream jobs/abilities/materia?/weapon/talent tree system. But today I want to talk about something far more frivolous, and yet just as important. Yanfly’s Gab Bar!

The Gab Bar allows you to post ambient dialogue that’s not important enough to warrant a full box, or any response from the player. It helps you set the scene and convey story in an easily digestible way. Got a wall of text that the player needs to understand your game? Consider instead the Gab Bar, in your tutorial or intro level; have some soldiers give some background, and your player will thank you.

Download the script from Yanfly’s blog – and while you’re there, browse his other scripts! They’re all quite useful! Add it to your game, and away we go!

Gabbing

Calling the gab window requires a script call. It’s pretty easy:

gab(string)

Where you replace string with what you’d like to say. A very straight forward example is:

Make sure your dialogue is in quotes!

Make sure your dialogue is in quotes!

When we talk to our soldier, rather than opening a dialogue box, our soldier’s text will show up on the top of our screen, in a little gab window. The window won’t impede our player’s progress; she can walk around and play the game without having to “respond” to the dialogue. This can often prevent players from just rapid-fire clicking through conversation. It also separates “chatter” from important dialogue, encouraging players to pay attention when there *is* a dialogue box.

We can go one step further with a slightly different script call:

gab(string, spritesheet, index)

Here, in addition to the gab, you’ll get a little actor sprite indicating who actually said it. For example,

If you're looking for the name of the sheet, it's on the left side of the window when you pick the graphic for your NPC.

If you’re looking for the name of the sheet, it’s on the left side of the window when you pick the graphic for your NPC.

Spritesheet refers to the file name with the character’s graphic – here, “People4”. Index tells you which character on the sheet he is.

As you might imagine, the gab bar is hardly limited to talking to an NPC. You can use this script call in a parallel process in, say, a crowded bar. Every so often, a patron might pipe up with a comment about recent political events, a cave north of here with legendary treasure, or a rumor about a monster’s weakness. This doesn’t even require the player to interact with something or someone, instead just adding chatter to give the player guidance and create a more lively world.

It can also be used to build inter-party dynamics, and that’s what our challenges are based on:

Beginner Challenge

Set up a common event parallel process that, every five minutes, chooses a random party member and has them say a catch phrase unique to that party member.

Intermediate Challenge

As above, but add a variety of catch phrases for each member, and have one chosen at random.

Advanced Challenge

As above, but instead of a catch phrase, create a dialogue between two present party members.

We’ll go over the answers in a few weeks! And you can grab Liberty’s ghost edits – along with a good deal more gorgeous artwork – over on the RPG Maker forums.

Friday Script – Map Image Generator

This thing is huge - and was a snap to export using Omegas7's script!

This thing is huge – and was a snap to export using Omegas7’s script!

If you want to get the most out of RPG Maker, learn Ruby. In the meantime, lots of talented scripters have done the work for you. Every Friday, The Iron Shoe features a fun script and goes into detail about how to use it. It also covers a little bit of Ruby each time so you can make even more out of the script.

Today’s script is mercifully easy to implement, and is an insanely powerful tool. Whether you’re parallax mapping, setting up map flow, or promoting your game, you’ll want high-resolution images of an entire map. A 17 x 13 screenshot just won’t cut it. So to get that, all we need is Omegas7’s Map Saver! Download, copy/paste the script into your game, and away we go!

Setting up the File

First things first, the script requires a blank canvas to drawn on. Take a look at the size of the map you’re trying to export, and multiply by 32. You can find it at the bottom right of your map:

40 x 50 gives you the grid, but remember that each square is 32 x 32 pixels. So our blank canvas will need to be 1280 x 1600 pixels

40 x 50 gives you the grid, but remember that each square is 32 x 32 pixels. So our blank canvas will need to be 1280 x 1600 pixels.

Using any graphics program – including Paint – make a file that is the correct pixel size. Name it “Blank.png” and put into the “Graphics/System” folder of your game (note: despite the comments in the script itself, you don’t want to put it in just “System” – you’re looking for a subfolder of “Graphics”). With that, you’re ready to set up the script call

Setting up the Event

You’ll need a single event for this script, with two pages. Follow the directions in the script, or just look at the following two images and make sure yours looks the same:

Make sure the trigger is set to Autorun, and that you turn on self switch A after the script call.

Make sure the trigger is set to Autorun, and that you turn on self switch A after the script call.

 

Again, make sure this is on autorun, and make sure the conditions are set to self switch A.

Again, make sure this is on autorun, and this time, make sure the conditions are set to self switch A.

 

One last little bit. Make your starting position the bottom left corner of the map.

Run Your Game

Boot up your game. As soon as you start a new game, the script will take over, scanning and generating. Soon you’ll have a beautiful map file like the one at the top of this post. You can find it in your game folder. The blank image will remain, in case you’d like to use it again!

Happy mapping!