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!

Boss Battles – The Elemental Shifter

A great resource for those interested in old-school RPG Maker design is a blog called “Final Boss Blues.” Whenever I think about that name, I immediately start thinking about, well, bosses. Endemic to RPG Maker VX Ace are a host of terrible boss fights. Boss fights typically just become longer versions of the random encounter variety, with different music and more powerful enemy attacks. But what makes a good boss fight isn’t more of the same – it’s really a test of skill. Oftentimes, that skill is one that the player can ignore in random encounters, but now becomes essential.

Today I want to talk about one particular fun boss mechanic – an element shifting boss. They’ve been around since elements were in RPGs, and they’re quite easy to do in RPG Maker! Let’s get to it – I’m going to make a boss that flits back and forth between a “fire” aspect and a “thunder” aspect. You can adopt this to as many elements as you want.

A Tale of Two States

A element shifting boss is governed by states, just like Poison or Ice Force. These states allow us to control a lot about the boss. I’ve created two states, “Aspect of Fire” and “Aspect of Lightning.” For each, I’ve given it a little text (so the player knows what element the boss is in when it changes), and I’ve used the Features box to reduce the damage done by that element to 0%, and increase the damage done by the opposing element.

You can guess that the other one just changes the text and elements involved. The notes are just that, notes – they don’t do anything.

Now, we need to give our boss the ability to self-apply these states. Create two skills, each one adding a state and removing the other, like so.

Make sure your skills are certain hits. It would be extremely embarrassing for a lightning god to fumble on applying his elemental state.

You can also create any other skills you want your boss to have the ability to use, assuming the defaults don’t fit your boss.

Setting Us Up The Boss

When establishing what skills an enemy can use, you’ve probably twiddled with the “Rating” a lot. It’s what determines how often the enemy uses the attack, so that it’s not casting Ultima every single turn. But there are also a lot of conditions you can set, including…state! State asks whether the attacking enemy has a particular state. This means that we can say “boss can cast Thunder, but only if it has Aspect of Lightning applied.” So let’s do that.

Fill in as many as you want; variety is the spice of life.

We need to add two more skills – the ones we created before which allow us to flip. Remember to set the condition so that the skill which applies fire state requires thunder state; and vice-versa.

Start Him Off

Finally, if the boss were run like this, we’d end up with a boss that just keeps attacking and does nothing else. Why? Because all of his attacks are state dependent, and he doesn’t have a state. So at the start of battle, pick a state and add it.

When you set the Span to “Battle” it means this is just going to happen once this battle. Which is exactly what we want.

And there you have it! Our elemental boss will shift between Fire and Lightning with ease, and do appropriate attacks.

Improving the Boss

If we allow ourselves to use a tiny bit of script, we can really improve this boss in the following ways:

• Change his graphic so that the player knows which element he’s in just by looking at him
• Have him absorb elemental damage rather than negate it

We’ll explore that and some other options next week!

Resisting Death

Reddit user Dynamex had the most standard of RPG quests in his game – kill 10 rats. He had troops with 2 rats, and would slay them with gusto, but whenever he fought them, the quest would only register one kill. He was script-phobic, and was looking for a fail-proof way to count that second rat. And one that did not involve changing his game design.

There’s a solution, but it’s tedious. Fortunately, it can be used for so much more than rats.

Dynamex’s problem was something inherent in RPG Maker VX Ace. The very second the last enemy in a troop dies, RPG Maker will start running its end-of-battle code. Anything that’s supposed to trigger when an enemy dies will be forgotten with respect to that enemy. So how do we solve this problem?

• If your enemies are events on the screen that trigger when you run into them, this can be handled in the battle processing event branch. But what if they aren’t?
• If you’re willing to use a script, Hime has a script for you. But what if you aren’t?
• If you change this to a “turn in 10 rat tails” quests, and have the rat drop a rat tail 100% of the time, your problem is solved. But who wants to clutter their inventory like that?

Well then, we’ll just need our monsters to cheat death long enough to run our events.

Avoid Death State

The first “state” in the database – regardless of what you call it – is the Death state. It will be applied to an enemy the second it reaches 0 HP. We need to prevent this from happening for a little bit, and the trick is another state that we’ll make ourselves. Make a state called “Avoid Death”, clear most of the fluff from it, but under Features add “State Resist: Death.”

No need to have a message appear – we don’t want the player to know what goes on behind the curtain.

Troops

Now let’s set up our troops. For our purposes, troops of 1 rat, 2 rats, and 3 rats should do it. If rats traveled in packs larger than 3, my guess is that whoever gave us the quest would be asking us to kill way more than 10.

Troops, like events, have pages. Here you can have events trigger during the battle. Let’s set up one which applies our new Avoid Death state to every enemy as soon as the battle starts.

Happily, there’s a copy event page and paste event page. Make sure this goes in any troop where it matters.

For condition, we’ve added Turn No. 0 to make sure it happens right at the start. “Span” really refers to frequency – can the event happen once per battle, once per turn, or repeatedly? We only want this happening once per battle, so we’ve set it to battle.

Now, if any rat’s health drops below 0 HP, nothing happens. Battle will continue, and we’ve got a serious undead rat problem on our hands. So let’s take care of that. Make a new event page, which triggers as soon as the enemy’s HP is down to 0. We’ll do three things:

1. Increment our rat killer counter
2. Remove Avoid Death
3. Add Death

Like so!

Can’t we just find a troop of 10 rats so I can get this over with?

Unlike the first event page, which applies to the entire troop, we’ll need a separate event for each rat in the troop. Change the event page accordingly – so when enemy 2’s HP is 0% or below, enemy 2’s states should change, etc.

Beginner Challenge

I noted this has more utility than you’d think. Create a battle against a Chocobird (I’m not about to get sued for trademark/copyright infringement). Set it up so that when a Chocobird dies, there’s a 10% chance that an over-powered Devourer shows up  to fight you.

Advanced Challenge

There are plenty of scripts out there to handle things like “magic points” or “action points.” But without scripts, use this system to assign a new type of point/experience at the end of battle, where the amount of points you receive is assigned in each troop.

Check back in two weeks for some solutions!