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.

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.

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.

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.

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.

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…

…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!

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

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:

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).

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.”

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!

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 script. But 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!

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.

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.

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!

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.

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!

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 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.”

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.

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.

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.

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.

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.

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!

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!

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!

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.

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!

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.

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.

 

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!

Friday Script – Galv’s Camera Control

Camera control will pan to the puzzle, and stay centered there until we tell it otherwise.

     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 Galv’s amazing Camera Control! RPG Maker’s camera controls are clunky at best. Calling “scroll map” can be tricky when you don’t know where the player is starting from, and what if you want the map to stay put while the player moves?? For all of you planning grandiose cut scenes, Galv’s Camera Control will do the work for you.

Copy/paste the script just above “main” in your list of scripts, and away we go!

Changing the Camera From Inside an Event
Once you’ve added Galv’s Camera Control, any event – be it an NPC on the map or a Common Event – has access to a trigger called “script call.” This allows you to access the camera control script. In this window, you can type a few things:

• cam_follow(eventid, speed) – use cam_follow to have the camera follow an NPC – or any event – instead of your character. Don’t actually type “eventid,” instead use the number found at the top of the event. Same with speed, don’t type “speed.” Instead, you’ll choose a number from 0-6. This will determine the speed at which the camera pans from you to the NPC, before locking onto the NPC. 1 is very slow, 6 is very fast. 0 is a special case, it’ll snap the camera to the NPC, rather than panning to them. You can choose not to use speed at all, in which case it will default to 6. That is, typing cam_follow(3) is the same as typing cam_follow(3,6). Both will cause the camera to pan to event 3 at speed 6, then follow it.

• cam_set(x,y,speed)  – use cam_set to lock the camera to a specific coordinate. “X” and “Y” should be replace with the map x and map y (not screen x or screen y!) that you want to lock to. Speed functions the same way as above. Again, speed isn’t necessary, it will default to 6.

• cam_center(speed) – set the camera back on the player, in good ol’ default RPG Maker mode. Again, speed isn’t necessary – feel free to type cam_center()

The most basic setup – if a player steps on this tile, lock the camera to a coordinate.

A Note About Speed

As mentioned above, speed can be 0-6. 0 is a special condition which “snaps” the camera, but what about 1-6? If you open up the “scroll map” trigger in any event in RPG Maker, you’ll notice that the speeds listed all have a number associated with them – Galv’s 1-6 are the same numbers! So if after years of playing with RPG Maker you just know that “normal” speed is what you want, then set your speed to 4.

Digging Deeper With Ruby

These 3 script calls have infinite application, and you aren’t bound to use numbers at all. Consider the following example:

Player Peter just leveled up, and got an awesome new ability called Shadow Form. This ability allows his spirit to leave his body. The spirit can walk through walls and even activate switches, but only lasts for 5 seconds! It also has a pretty small range – you wouldn’t want your spirit wandering off too far.

     There are a lot of components to building this ability, but let’s talk about what the camera is doing during this time. As the game progresses, the camera follows Peter as normal. But when activating Shadow Form, the camera stays focused on Peter’s body, while the player controls Peter’s spirit, wandering around in a 17×13 screen for a few short seconds.

There are a few ways to do this, but for teaching purposes let’s do it this way; set the camera to an x,y based on a variable. In the event editor, when Peter activates Shadow Form, we’ll set two variables (for my purposes, variables 1 and 2) to Peter’s x and y respectively. Then we can call the following in a script:

x = $game_variables[1]

y = $game_variables[2]

cam_set(x,y)

     This way, wherever Peter was when the event was called, the camera will stay there! On expiration, we’ll call cam_center. Those experienced with Ruby might ask why I didn’t just write the following:

cam_set($game_variables[1], $game_variables[2])

     Script calls in RPG Maker events have trouble processing multiple items in a line. This line will actually crash your game. While it’s acceptable in the full blown script editor, it’s no good in an event’s script call.

We should build a return function too, or Peter might never return!

Intermediate Challenge

We could’ve used Galv’s amazing script to make Peter’s Shadow Form without setting any variables. Using cam_follow, how might we do that?

Advanced Challenge

Let’s say you’ve got the cam set for an extended period of time, and in the middle of it the player quits. When you reload the game, the camera will no longer be set. How might we fix it so that saving/loading preserves the camera position?

Post your thoughts / screenshots / walkthroughs concerning either challenge in the comments section, and we’ll reveal the answers to both in 2 weeks!

Friday Script – Quest Journal!

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.

Gone are the days of the Super Nintendo, where players were just expected to remember the objective and the myriad side quests in a game. We no longer put our players through that torture. Instead, we help them along with objective markers, glowing items, and of course – quest logs! This Friday let’s explore Modern Algebra’s Quest Journal.

Add it to your scripts list and away we goo!

Making Quests

Before really digging into activating, deactivating, and all that jazz, we’re first going to have to make a quest. This is done in the body of Modern Algebra’s script, but don’t get scared! Basically no coding knowledge is required. First off, look for the following around line 760:

Add your quests after the green text – the “comments.” That green text shows you the format of how to set all of the attributes of your quest.

Here’s where you’ll enter all of the information for all of your quests. Quests in this script can have the following:

• Name – be it punny or direct, a good quest always starts with a good name
• Icon – choose anything from your current item/armor icon set to display next to your quest. A scroll, a shield, you name it.
• Level – sometimes a player gets a quest to kill the level 18 Ice Wolf when they’re level 2. Let your player know that they should hold off a bit.
• Description – a little bit of flavor text goes a long way in explaining the quest.
• Banner – an extra to use as the header for your quest journal; maybe you’ve got a fancy graphic for each one!
• Objectives – the nuts and bolts of a quest. Go here, do this, kill him, come back, tell everyone.
• Categories – some quests are Main, some are Side, some are Culinary and some are In Town. Make your own categories and go wild.
• Client – who issued the quest?
• Location – where the f do I do this quest?
• Rewards – the only reason you’re doing the quest

You don’t have to use all of these, but you can! Modern Algebra has provided a delightful sample quest so you can see how to make your quest. For each one, you’ll need to type “when N” but replace the N with a unique, sequential number. After that, setup any and all quests you’d like.

In Vidar, each quest’s fail condition is also an objective – and it’s listed in the prime objectives. If your quest giver dies, the quest is auto-failed.

 

A note about objectives and prime objectives. They’re the meat of your quest. As with quests, within a quest each objective must be unique and sequential. They’ll show up in the order you add them, so consider game progression as well. Prime objectives are just a critical list of objectives. If any one of the objectives listed in prime objectives is failed, the quest will automatically fail. If all of them are complete, the quest will be marked complete.

Wait, this fails quests? I thought it was just a log! By fail or complete quest, we’re talking changing the font to red or green, respectively, so that the player knows there’s been a change. Additionally, the quest will move to a separate menu so that the player isn’t haunted by their failure for 20 more hours of gameplay.

Updating Quests

This log ain’t gon’ run itself, child. Every time you want to update a quest, you’ll need a script call in your event. You’ve got a few options, all listed at the top of the script. Let’s talk about some:

• reveal_objective(quest_id, objective_id) – reveals an objective. A few notes. (1) if the quest isn’t revealed, it’ll reveal that too. (2) “quest_id” refers to the “N” in “when N” discussed above. That “N” is that quest’s unique ID, so use it in place of “quest_id” in your script call. (3) Same goes for objective_id!
• complete_objective(quest_id, objective_id) or fail_objective(quest_id, objective_id) – betting odds you can figure this one out on your own.
• reset_quest(quest_id) – got a quest where it’s an all or nothing, but you can try multiple times? Just call reset_quest on it in your script call.
• manually_complete_quest(quest_id) – sometimes relying on the prime objectives system won’t cut it, and that’s just fine. You can complete and fail quests by hand.

So how might we call one of these scripts?

At a time when his neighbors, friends, and family are dying around him, Robert just really needs that flower.

Checking Quests

You can also use objectives and quests to control events. While “event flow” is typically handled with switches, organizing them can be a mess. And if you’re just going to have a switch that is “quest 2 objective 0 complete” – why bother? The script will handle it for you!

Non-scripters may have missed a wonderful little built-in for the conditional branch – a script call. That’s right, your conditional branch can do a script call all on its own. Check it out!

There! Any script that evaluates to “true” or “false” can be put in that little line!

With our new fancy-pants journal, in that box we can add the line

objective_complete?(2,0) 

and it’s the same as saying “if switch ‘quest 2, objective 0 complete’ is on”. How nifty!

Digging Deeper With Ruby

As you might imagine, we can have some great fun with these quests well beyond what Modern Algebra has set up for us. Truly the sky is the limit. Take the following example.

Piper has asked Peter Player to pack a peck of peppered pickles, but he’ll have to pick them from a pickle tree first. Piper estimates that a peck could hold ten pickles, so he’s asked Peter to go into the pickle forest and pick 10 pickles.

You can imagine how to set up a quest like this, with 10 pickle events throughout the forest. When you interact with them, you get a pickle, and when you talk to Paul with 10 in your inventory, you’ll get your reward. An easy way to give the player an objective in Modern Algebra’s quest log is “Pick 10 pickles.” But let’s do one better and say “Pick X pickles” where X is the number of pickles remaining. Let’s also add another objective, shown to the player only when he succeeds in picking all 10 pickles – something like “Return to Piper to peck your pickles.”

Dynamically changing the text of a quest in the quest log is easy. Let’s track our pickles with a variable, let’s say Variable 2, we’ll call it “Pickles Remaining”. When you receive the quest, set Variable 2 to 10, like so:

Piper seriously cannot get enough pickles – peppered or not.

Then for each pickle, reduce the variable by 1. But we want this information quickly reflected in the quest log as well. Not to fear! Using \\V[2] in the quest objective, we can display the value of Pickles Remaining right in the objective! (remember to use two slashes here, not one).

Using \\V[2], we can access the variable Piper just created for us.

On picking up a pickle, ask whether Variable 2 is equal to 0. If it is, complete that objective, and move onto the next objective, like so:

The RPG Maker resource pack doesn’t come with a pickle. Someone alert Enterbrain of this egregious bug in their program immediately.

Beginner Challenge

When Peter Player arrives at the pickle forest, he finds a sentient pickle tree that offers him a deal. Pick no pickles, and take instead 10 rotten pickles back to Piper. Tell her they are freshly picked and she’ll get sick, but it will save the pickle tree’s pickles. How might you change the description of Objective[0] in our quest log to reflect this new option and change in circumstance?

Advanced Challenge

Piper’s penchant for pickles is insatiable. While she’ll give you a potion for 10 pickles, the rewards will be much better for 20, 30, or even 40 pickles. How might we display all of the possibilities in the Quest Log?

Check back in 2 weeks for the answers to both challenges!