A Little Bigger Title Screen

Hi friends!

You know what we haven’t done in a super long time? An RPG Maker VX Ace tutorial! ::kermit arms::

Reddit user EraldoCoyle asks: “I’d like to make the command window on the title screen bigger. How? …The little window where you select what to do on the title screen is too small and I’d like it bigger.”

Listen, I get it. You’re advancing in age. Things get harder to read. You need clearer direction about what to do. You are constantly confronted with your own mortality. I can’t fix most of these things. I can fix your title screen, however.

To do this, however, will require modifying some of the base scripts. Don’t fret, it’s just a few small changes.

Line Padding

The developers of RPG Maker VX Ace got about halfway to coding dynamic window creation before they gave up. What do I mean? Well, the nice thing is that when you create a command window, it automatically determines the height of that window by calculating the height of each command in that window, summing it all up, adding a little padding, and returning that value as the height. That’s great! That means we don’t have to do the math ourselves, and we can be confident that the window will be the correct height if we add or remove additional commands.

So what’s the problem? Well, RPG Maker assumes that every command line will just be size 24 font. So even if you increase the size of the font of your command, you’ll get something like this:

titlescreentutorial2

And that looks downright silly. So we’re going to make the height more dynamically calculated by changing a line. In your scripts, open “Window_Base” and scroll down a little to line 29, to the function “line_height.” You’ll see it just always returns the number 24. Boo. Replace that 24 with “Font.default_size” to always get the correct font size for this number.

Change the Font Size for Title Scene

Scroll down further to “Scene_Title” and take a look at the function “create_command_window.” It’s around line 91. Before we create our window, we want to increase the size of the font. So before that first “@command_window…” line, add another line before it that says something like “Font.default_size = 32” – you can replace 32 with whatever size you want the font to be here.

We need to make sure that it only applies to the Title Screen. So there are two functions – starting a new game, and using continue – where we want to reset the font size. Head to “command_new_game” and “command_continue” and add “Font.default_size = 24” to the end of each of them. Your script should now look like this:

TitleScreenTutorial3.png

Change the Window Width

Finally, if you want to change the width of the window, open the script Window_TitleCommand and find the function “def window_width” around line 21. The number after return is the width of your window, in pixels. Change that to whatever you want.

Test it Out

titlescreentutorial1

You may find you want to toy with numbers like the Font and the Width. You should know where to do that now!

Integrating Chat Mapper: Part IV

So it’s come to this, we’re finally ready to take our dialogue tree – which we’ve painstakingly crafted in Chat Mapper and exported and converted to a file RPG Maker can understand – and do something with it! For this part, you’ll need the most important script, the parser. You can download it here. For this script, I ask that you give credit to Matthew Canterbury anytime you use it, whether commercial or non-com. Put this somewhere in your materials folder, like you would any other off-the-shelf script.

FACES: A Detour

But before we do that, there is one little customization option we have to consider – whether or not we’re going to use faces in our Game Messages. You must do one of the two options below.

1. Yes, I want faces: Your project should have a directory called Graphics/Faces. This is where the parser looks for face files to combine with the text in your Message Window. The hitch is that it expects one file per “Actor,” and I use that term not as RPG Maker uses it, but as Chat Mapper uses it (check out Part I for all of that stuff). Which means that if you have this in Chat Mapper:

We set up the Actors in Part I of the Chat Mapper tutorial

We set up the Actors in Part I of the Chat Mapper tutorial

Then in order to draw a face, you need to have a file called “Cecilia.png” in the Graphics/Faces folder. That file should be 4 faces wide by 2 faces high (just like the default RPG Maker templates) but for right now, really only concern yourself with the Top Left. I’ve just copied and pasted the same face 8 times for completeness. And my Graphics/Faces folder looks like this:*

Why did I do this? For features yet to come of course!

Why did I do this? For features yet to come of course!

If you don’t do this step for every actor you have in your Chat Mapper project, you’re going to get an error. So make sure everyone is there.

Sometimes, though, one of your dialogue boxes is just “Got a Lantern!” and you don’t want a face for that single box. What to do? In Chat Mapper, make a new Actor that has a completely blank name, and use them as the actor for that one box. Remember, even though the conversation has a default Actor, you can always change it from box to box. There’s no need to create a blank graphics file in your Graphics/Face folder – the parser will know just not to put a face when it comes to this box.

The dialogue boxes above and below this one will show a face - this single one will be faceless.

The dialogue boxes above and below this one will show a face – this single one will be faceless.

2. No, I don’t want faces: In the parser you just added, go find the section that reads:

if actor != nil && actor.name != ''
     $game_message.face_name = actor.name
else
     $game_message.face_name = ''
end

And replace all 5 lines with:

$game_message.face_name = ''

Remember, you must do one or the other from above. If you don’t do number 2, the parser will expect graphics for all of your Chat Mapper actors!

Load the File

Next, we need to ask RPG Maker to load the .rvdata option we spent all last week making. Create another script section in your RPG Maker file below where you inserted the Dialogue Parser. Add a single line:

DialogTree::load_dialog_file(" ")

And in the ” “, add the file path to the .rvdata file you made. Remember to start the path from the top folder of your project. This means you omit, for example, C:/Program File/RPG Maker/Honey Boo Boo’s Projects/My Game 1 ……all of the junk that comes before your actual project. If you just put the .rvdata file in the “Data” folder, you’d write: “Data/Dialogue.rvdata” – assuming your file is named Dialogue. Got it?

Make sure this runs AFTER the dialogue parser, but BEFORE main.

Make sure this runs AFTER the dialogue parser, but BEFORE main.

Curious as to what the rescue => e nonsense is in the screenshot? If you’re trying to figure out what error is happening, this prints out an error message to the console. It’s particularly helpful for scripting, and if you’re not getting something in all of these scripts and integrations to work, it’s an invaluable tool for your belt.

Call the Parser

It all boils down to a single script call. After everything we’ve done. In your NPC’s event page, where you would’ve had all of these conditional branches, Show Message commands, scripts, switches, variables – we’re going to replace all of it with a single script call:

DialogTree::run_conversation('ConversationName')

That’s it. You’ll obviously need to replace the ConversationName with, well, the name of the Conversation you want from Chat Mapper. Remember wayyy back when, we said that each “tree” is a separate conversation? So basically, you’re picking a tree.

The result is an event that looks something like this:

Elek is ready to converse!

Elek is ready to converse!

What’s fun about the script is that it’ll print to the console as it travels through your tree. So you’ll get to see each condition, and whether it evaluates to true or false. Hime has a post on his blog about how to enable the console.

And that’s it! Those are the steps to integrating Chat Mapper with RPG Maker. Remember, Part III lists all the steps you need to do to make edits to your tree and re-export. If you’ve done everything right, you won’t have to repeat any of the stuff in this post ever again!

The rest of this week we’ll be talking about Vidar, but next week we’ll pick this up again and look at some advanced ways to integrate with various off-the-shelf scripts that change your messaging system. We can use those for positions, for name blocks, for colors, for all sorts of things!

 

*You might be saying, Dean, this is a really weird way to save these graphics, why not have a face sheet with 8 different faces? Soon, the script will support using Chat Mapper’s “mood” function (most of it’s already built), and we’ll be able to do things like “Cecilia’s Sad Face” for just this bit of dialogue, then “Cecilia’s Angry Face” for the next. You’d have 8 emotions on the same sheet to do this.

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!

Dev Blog – Switches 1

I thought it worthwhile to do a series on how Switches are handled in Vidar. In this series, when I use the capitalized-S Switches, I’m not talking about those numbered global booleans that you can access in the trigger editors. I’m talking about things you interact with that you expect to do something, like these:

To make matters more confusing, these are called "Switches" in the RTP Character Sheets.

To make matters more confusing, these are called “Switches” in the RTP Character Sheets.

I’ll use the lowercase-s switch to refer to the boolean that you set. Any basic dungeon will end up having a Switch like the one above that opens a door. And it’s easy to have an event page for your Switch look like this:

This is typically accompanied by a page 2, which has as its condition, "Open Door 1"

This is typically accompanied by a page 2, which has as its condition, “Open Door 1”

And then your door would have 2 pages; one where the door is closed, one where it’s open and the conditional is that “Open Door 1” switch. And then you’ll use another switch in another Switch for “Open Door 2,” and another for “Open Door 3…”

This is a bad habit. Stop doing it.

What you’re doing is creating global booleans that only get used once. Not only are you cluttering your list of switches, there’s a strong chance you could accidentally call it with something else, a chance that something gets moved or deleted. Once you have more than 10 doors, you’ve got a headache. These switches are really good for massive plot-moving periods in your game, because they’re an easily referenced marker – use switches for things like “Cave Boss Defeated” or “Fire Summon Available.” Don’t use them for Switches and Doors.

Vidar in particular can’t use switches like this. Why?

  1. There are hundreds of possible doors in Vidar, making tracking them tedious
  2. Which doors are actually spawned at the beginning of the game are chosen randomly, making tracking them really tedious

Plus, it’s bad practice. There’s a much better way. For the second page of your door, instead of using a global switch, use a self-switch. Something like this:

Now your door isn't dependent on some switch in your list that you might accidentally click; it's dependent on its own self-switch.

Now your door isn’t dependent on some switch in your list that you might accidentally click; it’s dependent on its own self-switch.

As it turns out, your Switch can tell the door to turn on its own self-switch. Just use this:

$game_self_switches[[mapid, eventid, "A"]] = true

So instead of using one of those global switches, our Switch page would just look like this:

Since we're not using a global switch, we need to trigger 2 self-switches; the door and the Switch itself.

Since we’re not using a global switch, we need to trigger 2 self-switches; the door and the Switch itself.

Why is this so desirable? Because it’s flexible. We can replace all of those variables dynamically. We can run this thing through a for loop. We can have dynamic control over every door.

So, for example, if we have a room with a puzzle that has 100 doors, we could do something like:

100.times {|i| $game_self_switches[[5,i,"A"]]= $game_self_switches[[5,i,"A"]]? false : true}

which would “toggle” all 100 doors – open all closed ones, close all open ones. With one line of code, and not 100  event calls, nested in if-then statements. And without 100 different switches in our global switch list, which we have to navigate for months to come. Even if you’re not going to do something in-depth, you can easily clean up your game using this method instead of one-off global booleans.

This is the starting point for Switches in Vidar. There’s obviously a lot more – Switches do different things depending on the puzzle they’re in, and having them know what function to call is its own can of worms, but we’ll save that for another day.

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?