We spent the last chapter talking about the use of switches and variables within RPG Maker VX Ace (RMVXA). What was mentioned there is just the tip of the iceberg in terms of what you can do with them, but it’s time to start populating our role-playing game (RPG) world. One thing every video game needs is a character for the player to control. Even the simplicity that is Pong has the player controlling a paddle and trying to get a ball past an opponent’s own paddle. We have been controlling RMVXA’s default character for the entirety of the last chapter. It’s time we got to know him a little better. Make your way to the Database (by pressing F9 or finding it in the Tools item of the menu toolbar) and make your way to the Actors tab. When you first install RMVXA, your first foray into the Database will automatically lead you to the Actors tab, but recall that we already poked our heads in there to change some of the game’s terms. Take a look at Figure 3-1.

In RMVXA, player characters (those that the player can mix and match in his/her party) are called Actors. As you can see at the upper left of the preceding screenshot, the program comes with ten premade actors. If you’re using the full version, you can change the maximum number of characters and add some more of your own. With either version, you can edit or erase the ones present, for the same effect.

There are various things to cover here, so let’s work our way through this part of the Database.

• General Settings cover an actor’s basic information and are largely self-explanatory. Of note is Class, which will be discussed when we reach the appropriate tab of the Database.
• You can tweak an actor’s initial level, which will determine at what level he/she joins the party when placed in the game. You can also change an actor’s max level as well, limiting his/her growth, if you should have a reason to do so. One common use of limiting a character’s maximum level is when you have a temporary party member. You can set his/her initial level equal to its maximum, and he/she will stay at the same level for the duration.
• There is a pair of graphics. The one to the left is the character’s sprite set, which covers his/her appearance as well as his/her movement patterns, while the one to the right is his/her character portrait.
• Starting Equipment determines what items a given actor starts with. A character should generally start with some manner of equipment, although there are times when it would not be appropriate (such as when a protagonist starts the game as a prisoner; he or she might have the clothes on his/her back and nothing else).
• Features are kind of a big thing in RMVXA. You’ll quickly see that the ten actors have a blank Features list, and that’s because the default characters have all of their features contained within their classes and not themselves. The way RMVXA manages this by default is fine, although there are niche cases in which it would be best to have some differentiating features at the Actor level. If you have two characters of the same class, and they are not identical twins, you could differentiate some of their stats through the use of Features at the Actor level. For example, you could give one of the characters the [HP] * 80% and the other [MP] * 110%.
• Finally, Note is just a notepad of sorts. If you have to make notes about a certain character, you can write them here. Most parts of RMVXA have a Note section. It’s awfully convenient, if I may say so myself.

That covers the Actors tab. Feel free to take a look at the other nine default characters and see how they differ from Eric. Afterward, let’s move on to the Classes tab (see Figure 3-2).

The ten actors each have their own class. Eric’s class is Soldier. Take a look at each of the classes and note how its features, parameter curves, and skills differ. RMVXA prefers to place character-defining features within the Classes tab, as an actor’s class highly defines him/her. Case in point, look at everything that is governed strictly by class.

• EXP Curve: EXP is short for “Experience.” If you click the “ . . . ” button to the right of the bracketed numbers, you’ll see what those four values relate to and how you can use them to tinker with the rate of advancement. You can make levels easier or harder to get, via the use of this property. By default, the ten premade classes all have the same experience curve. If you want actors to level up based on their class, you can tweak their curves here. To take a predominantly pen-and-paper example, Advanced Dungeons & Dragons (video game adaptations of that ruleset include Dark Sun and Baldur’s Gate) had an experience system in which classes leveled up at a rate proportionate to their power. So, the spellcasters, who, arguably, had more power, took a longer time to gain a single level, while the “weaker” classes, such as Thief, leveled up faster, to compensate for their lower overall power level.
• Parameter Curves: These affect the rate at which a given class gains its stats. You can edit a parameter by double-clicking it, which will bring up a graph. There are eight stats in RMVXA.
  1. MHP (Maximum Hit Points). If these drop to 0, the character is dead and requires some form of revival.
  2. MMP (Maximum Magic Points). Used to cast all manner of magic spells
  3. ATK (Attack). Influences the amount of damage that a character does with his/her weapon of choice
  4. DEF (Defense). Influences the amount of damage that a character suffers from enemy attacks. The default damage formula for the basic Attack command is [ATK * 4 - DEF * 2]. Essentially, the basic formula favors boosting your attack over your defense.
  5. MAT (Magic Attack). Can be used in spell formulas to determine damage
  6. MDF (Magic Defense). Can be used in spell formulas to determine damage mitigation
  7. AGI (Agility). The higher a character’s AGI, the sooner he/she acts in a given battle turn.
  8. LUK (Luck). Much as it is in many other games that have such a stat, Luck in RMVXA is the wildcard stat. The official help file for RMVXA states that Luck “affects the chance of adding a state or debuffing a parameter.” The default formula is [Chance (%) = 100 + (user’s luck – target’s luck) ÷ 10].
• Skills: These are one of the most intrinsic aspects of an RPG character. If a character did not have any skills, it would only be able to attack with its weapon, and that would probably get boring after a while. Some examples of skills include healing spells and power attacks. Eric’s class specializes in powerful attacks that inflict great physical damage.
• Features: These define many miscellaneous, but important, aspects of a certain class. Let’s break down the Soldier class, feature by feature.
  1. TGR is short for “TarGet rate” and marks the rate at which a member of this class is targeted by enemies. The default rate is 100% and can be increased or decreased as desired. A particularly large warrior might warrant a higher TGR, while a smaller thief would probably warrant a lower TGR. Say you have a party of three: a large warrior with 200% TGR, a normal-sized guard with 100% TGR, and a small thief with 50% TGR. It is four times more likely that the warrior will be attacked than the thief. It is half as likely that the thief will be attacked than the guard.
  2. HIT is short for “HIT rate.” In RMVXA, a character’s accuracy is equal to its HIT plus any HIT it is gaining from its equipment. A character’s ability to land its attacks and skills is negatively modified by any EVA (Evasion) the enemy has. The stock functionality of RMVXA is set up so that the game calculates first to see if an actor lands its attack and, if so, checks if the enemy dodges the attack.
  3. CRI is short for “Critical rate.” When a character lands a critical hit, it deals triple the normal damage. An actor’s chance to land a critical hit is reduced, based on the enemy’s CEV (Critical Evasion rate).
  4. Add Skill Type is a feature that allows a chosen class to use a category of skills. In this case, Soldiers can use Special-type skills. By default, RMVXA has two skill types: Special and Magic. A class requires access to a skill type to be able to use skills from that type.
  5. Equip Weapon/Armor are both fairly self-explanatory. They define what kinds of weapons and armor a given class can use. If you don’t assign any Equip features to a class, it will be unable to equip anything (which, to be fair, might be good for a completely unusual player character type, such as a wolf or a yeti).

From the Classes tab, let’s move on to the Skills tab, which has a lot of information. The first time I laid eyes on that part of the Database, I nearly fainted. Rest assured that it is not as overwhelming as it initially seems. Let’s break up this tab into two parts. Check Figure 3-3 for the first half.

We’re looking at the very first skill in the list of 126 (!) provided by default within RMVXA. If you’re following along with the Lite version, you will have to edit/erase skills to make room for your own, as you are disallowed from tweaking the maximum value. Skills 1 and 2 are internally important for RMVXA, so take care not to edit them, unless you’re sure of your changes. The first skill in RMVXA is the basic attack.

• General Settings provide basic, yet essential, values to be tweaked. Skill Type denotes what type of skill category must be unlocked for a player to use that skill. As Attack is a generic basic attack, anyone can use it. Similarly, it has no MP cost or TP (Technique Points). A character gains TP from taking damage and using skills, including Attack.
• Scope defines what gets affected by said skill. The basic attack hits a single, targeted enemy.
• Occasion toggles when a skill can be used.
  1. Always. The skill can be used in and out of battle.
  2. Only in Battle – The skill can only be used in battle.
  3. Only from the Menu. This is the character menu that we accessed back in Chapter 1, to be precise.
  4. Never. Seems pointless, but it’s actually useful for a skill that you only want to be used under highly specific circumstances. (You would probably want to create an event to trigger the skill, in that case.)
• Damage: Besides having a marginally misleading name (as you can use the formula for healing spells as well), this has a few intricacies of its own.
  1. Type. The type of effect you want this skill to have. To confuse the issue even more, you have HP and MP Recover as two of the seven possible options. The None type can be useful for skills that cause status effects but do not do any actual damage in causing them.
  2. Element. Determines the elemental typing of the skill. Normal Attack is its own special element, which leads me to believe that it is coded in that way so that Attack can benefit from the elemental properties of a character’s weapon, to take one example.
  3. Formula. That little box you see there carries nearly infinite potential. Entire forum threads have been filled throughout the Internet on making unconventional damage formulas for seemingly anything you can think of in RMVXA. I’ll be showcasing some of the ones I’ve personally used, later on. For now, you should know that the user of a skill is expressed by a (a.atk in the case of Attack) and the target of a skill is expressed by b (b.def, for this skill). Leaving your cursor over the formula box for a few seconds will cause a very helpful tool tip to appear, so I’ll leave that as a short exercise for you. The Quick button underneath the formula box allows you to nearly instantly crunch basic damage formulas, based on the criteria it gives you.
  4. Variance. Determines the range of values a skill returns. Attack has a variance of 20(%). To give an example, a character able to do 100 damage with Attack would actually do anywhere between 80 and 120. I prefer my skill variance to be low, but then again, I prefer my characters to have low stats rather than the high stats that the default characters come with in RMVXA.
  5. Critical. Determines whether a skill can land a critical hit or not.
• Effects: These are to skills what Features are to actors (and, as we’ll see later, enemies and other items as well). When used, Attack has a special effect to add a state named Normal Attack. I wouldn’t tamper with that. You can add other effects to the basic attack if you’re curious, though.

The Database Skill tab doesn’t seem so intimidating now, does it? We’re more than half done looking at it as well! Take a look at Figure 3-4, for the other half of the Skills tab.

• Invocation: This affects the use of the skill itself.
  1. Speed. This adjusts the user’s AGI upward or downward when using the skill. (Speed can be a negative value.) You can make a skill that’s guaranteed to strike first by giving it high Speed. You can also make a skill that causes its user to act last by giving it highly negative Speed.
  2. Success %. The chance of the skill to actually connect. I tend to use a non-100% Success rate for skills that cause nasty status effects, such as instant death or petrification.
  3. Repeats. How many times the skill is triggered when used once. Most skills should only trigger once, but multi-hit skills work precisely by repeating.
  4. TP Gain. The amount of TP a character gains from skill use is governed by this value right here. So, you could easily make a skill with the sole purpose of boosting your character’s TP to 100. (TP caps at 100, unlike MP, which can go all the way to 9999.) Likewise, you could make a skill that doesn’t grant TP to its user.
  5. Hit Type. There are three possible hit types for any given skill.
     • Certain Hit: A skill with this hit type ignores the user’s accuracy and the target’s evasion stats. The only determinant of whether a Certain Hit skill will work is its Success %.
     • Physical Attack: A skill with this hit type connects based on the user’s hit rate and is affected by the target’s evasion rate, as well as its own Success %.
     • Magical Attack: A skill with this hit type connects based on the target’s magical evasion rate and the skill’s Success %.
  6. Animation: What is displayed when you use the skill in battle.
• Using Message: This is fairly self-explanatory. The only thing I would note is that you need a single space before your skill message. Take a look at the message for the Attack skill and you’ll see what I mean. Otherwise, in-game, it will look like “Characterattacks!” instead of “Character attacks!” when you use the skill.
• Below Using Message, there are three buttons: casts *!, does *!, and uses *!. The tool tip for the buttons is “Generate Use Message: A button that automatically sets the message.” Clicking one of those buttons replaces the text in the Using Message text boxes with predetermined text. For Attack, the text would read “casts Attack!”, “does Attack!”, and “uses Attack!”, respectively.
• Required Weapon: This is the last item in the Skills tab, and it does what it implies. You can adjust it so that a certain skill requires a certain weapon type (such as a rain of arrows ability requiring a bow or crossbow). You can be strict and leave it at one weapon type or relax the restriction a little and add a second weapon type. (A powerful swing of your weapon can be done with both a sword and an axe, for example.)

You can see a screenshot of the Items tab (Figure 3-5), but you’ll probably understand why I’m going to gloss over the details rather than actually explain it. It holds many similarities to the Skills tab. (Neat fact: Internally, Skills are also considered items, so this is merely a case of the stock functionality matching the code.) So there’s only one or two new things to even mention.

• Item Type: These are subdivided into Normal (very nearly every type of item you could think of) and Key Items. Key Items are important things that the player acquires and should never get rid of (or is required to use for a specific purpose). A potion, food, and a smoke bomb are but three examples of Normal items, while an ancient key or a royal missive are good examples of Key Items.
• Price: Items, weapons, and armor can have a set price (in in-game currency). Items with a value of 0 cannot be sold (but, you can have an item that costs 0 for sale in a shop; I usually don’t recommend that, mind you). Items sell for half of their value.

• Effects: Much as in the case of skills, your items can have a variety of effects. If you’d prefer, you can even use the damage formula for curative items or consumable damage items (think bombs and throwing stars).

As you can see, it is pretty much identical to the Skills tab. For those of you with RMVXA Lite, you are stuck with a 16-item limit. It is, perhaps, one of the more painful restrictions, as you will probably use many different types of items for your game. In any case, I will be elaborating on the Weapons tab and glossing over the Armors tab for the same reason that I skimmed over the Items tab. Refer to Figure 3-6 for a screenshot of the Weapons tab.

Just as items have two different types, you can define your weapon (and armor, for that matter) type as well. The Weapon Type drop-down menu will be populated with the terms listed in the Terms tab for that category. What makes weapons and armor different from items is their ability to be equipped by eligible actors. As equipment, they grant parameter changes (usually bonuses, but you could have cursed items that reduce stats as well) and have features that further add to their properties. In the case of weapons, you have to define their attack element. Most weapons do physical damage, but a flaming blade would do fire damage, while a bow of Ice could inflict extreme cold or water damage. In the case of RMVXA’s Hand Ax, it also has a HIT penalty (making the wielder more inaccurate) and an attack speed penalty. (Similar to skill speed, attack speed adds or subtracts from the character’s artificial general intelligence [AGI] to determine how fast it acts when using a normal attack.)

The Armors tab is essentially identical. (See Figure 3-7.)

The main difference is that the Armors tab also has an Equip Type. As you can see, shields and accessories are also considered armor in RMVXA (the former making sense, while the latter is a bit odd).

Time for Enemies!

Yes, indeed. An RPG wouldn’t be much of one if there weren’t foes to serve as obstacles for the player and his/her companions. If you have RMVXA Lite, the monster limit is 30. Check Figure 3-8 to see a screenshot of the Enemies tab.

In the preceding figure, we can see Slime, one of the Japanese RPG genre’s weakest but most iconic monsters. The Dragon Quest series has cute slimes, while RMVXA’s rendition is more of an amorphous blob. Like actors, enemies have eight stats. They also confer rewards—in experience and gold—when defeated and can also potentially drop items for the player. Slime has no items to drop, however. You can set up to three items for an enemy to drop, with a probability of 1/X (where X can be any number from 1 to 1000). I personally don’t recommend drop rates lower than 1/128, but that’s mostly because I have not played an RPG in which most of the item drops are rarer than that (Dragon Quest 8, if I recall correctly, had a few 1/256 drops, but they were situational at best).

Action Patterns are what give an enemy most of its bite. The lowly Slime can only use the basic attack that we saw a few pages back. With its 12 ATK, it won’t be winning any damage records in the near future. I’ll be discussing Ratings in detail later in the chapter. Last, Features are back and used for enemies in much the same way that they are for actor classes. Slime has a 5% chance of missing on its attacks (95% HIT), as well as a 5% chance of dodging physical attacks (5% EVA). Its attacks render physical damage, and it suffers double damage from ice-based attacks. You can give enemies resistances and immunities to types of damage and status effects (defined with States in RMVXA). This discussion has been a bit long, so let’s touch on one last section before applying all that we have talked about so far. Figure 3-9 shows off the Troops tab. You could design a thousand monsters, but you must actually form them into a troop for them to initiate a valid encounter. The RMVXA Lite troop limit is 30. The very first troop in the list is a pair of Slimes. Let’s talk a bit about each of the commands available.

• Autoname names the troop based on the number and type of monsters contained within. The default troops are all named in the Autoname style.
• Change Battleback allows you to change the background during battle testing. This has no effect on the Battlebacks in your game.
• Battle Test allows you to create a party of up to four actors equipped with items you choose to face off against the currently selected troop. During a Battle Test, the party gains 99 copies of every item in the Database.
• Add allows you to include a monster in a troop while, clicking an individual monster and pressing Remove clears it from the troop. If you want to Clear out the troop completely, that would be the option to click.
• Dragging on a monster placed in a troop allows you to change its in-battle position. This is merely for aesthetic purposes and has no actual effect on combat. You can use Arrange to return all monsters to their default positions.
• Events return with a vengeance in the Troops tab, in the form of Battle Events. They have six different conditionals, available from the drop-down menu.
  1. If you don’t use any of the conditionals, the event will default to Don’t Run. As implied, an event with Don’t Run will never trigger.
  2. When the end of turn  - An event with this conditional will trigger after all battlers (party members and enemies) have taken their turn.
  3. Turn No. Allows you to set a determined turn for the event to trigger. You will see that there are two number boxes. The first determines the turn in which the event triggers, while the second defines the interval at which the event repeats. (You can leave that blank, and the event will only trigger once.)
  4. Enemy’s HP is X% or Below. You have to specify a specific enemy within the troop for this conditional. When that enemy reaches the HP value you designated, the event will trigger.
  5. Actor’s HP is X% or Below. Same as the preceding, but for actors instead of enemies. You can declare an actor that doesn’t even exist within your game (as long as the actor exists within the Database), so be mindful of that.
  6. Switch X is ON. Switches! This is really useful for a boss monster in the style of Zoma from Dragon Quest 3, who was nigh unbeatable, unless you used the Orb of Light. You can flip a switch, based on any relevant conditions elsewhere that causes your boss monster to be a weaker version of its peers (by lowering their stats permanently, for example).
• Battle Events also have three types of Span, determining how many times the event triggers.
  1. Battle. An event with the Battle span triggers only once per battle, even if its conditions continue to be met throughout combat.
  2. Turn. An event with this span triggers once per turn, even if its conditions are met multiple times within the same turn.
  3. Moment. An event with this span triggers repeatedly, once conditions are met. I rarely use this type of span, as it has a fair chance of causing your game to hang in an infinite loop if you mess up.

Playing with the Database

There you have it. We have seen most of the Database by now, so let’s integrate into an exercise all that we have learned.

Objectives:

• Change Eric so that he can use bows as well as axes.
• Erase skill 126 (Mystic Spell) and create a skill that requires the use of a bow.
• Give Eric the skill that you have created.
• Erase items 15 and 16 (Speed Up/Luck Up). Create a normal item that can be used to attack enemies and is consumed on use and a key item.
• Erase weapon 60 (Etherblast Gun) and create a bow for Eric to use.
• Erase enemy 30 (Demon God) and come up with a new enemy.
• Erase troop 30 (Demon God) and make a troop containing one Slime and one of the new enemy you create.

Given the information already provided, the preceding should be fairly easy to accomplish. Take some time to read the various things in each tab, so that you can make a more measured decision in tweaking your creations, and it should be as easy as counting. RMVXA is nothing if not intuitive. Let me write up the changes that I made.

• Change Eric so that he can use bows as well as axes. To do this, you can add the Equip Weapon (Bow) feature to Eric or his class, and it will have the same overall effect for our purposes. I chose to add it to his class.
• Erase skill 126 (Mystic Spell) and create a skill that requires the use of a bow.
  1. I made a new skill that I named Arrow Rain. It is of the Special skill type and costs 10 MP per use. It has a scope of All Enemies and can only be used in battle. Its hit type is Physical Attack, while its animation is 013: Pierce Physical. As intended, I set it to require the use of a bow.
  2. For my skill’s damage formula, I used the default of [a.atk * 4 - b.def * 2]. It does Physical HP Damage with a variance of 10 and can inflict Criticals. It has no special effects.
• Give Eric the skill that you have created.
  1. To add a skill to a class, double left-click (or right-click and then select Edit) within the Skills list of that class. You can do the same on an already added skill, to edit or erase it.
  2. Because we want to add the new skill, let’s add it to the blank slot directly below Giant’s Rampage. For the purposes of this exercise, let’s set the level at which to learn our bow skill at 1. That means that Eric will have that bow skill level from the start of the game.
• Erase items 15 and 16 (Speed Up/Luck Up). Create a normal item that can be used to attack enemies and is consumed on use and a key item.
  1. My normal item is a Bomb. It deals exactly 50 physical damage to all enemies when used (you can write in numbers into the damage formula). It is Consumed when used and costs 200 gold to purchase from a shop (which means that it sells for 100 gold). It has a Physical Hit Type and the 059: Fire All 1 animation.
  2. My key item is an Old Key. It has no price, cannot be consumed, and has a scope of None and an occasion of Never. Such an item seems useless at first glance, but it can be used in conjunction with the Item conditional. It is mainly used for events involving locked doors/gates, to allow players to open them, if they have the appropriate key item.
• Erase weapon 60 (Etherblast Gun) and create a bow for Eric to use.
  1. I created a new bow called Eric’s Bow and, after looking at the Longbow and Crossbow, decided to give it an attack value halfway (33) between the two bows.
  2. It has no value, so it cannot be sold, and it has the Pierce Physical animation.
  3. For Features:
     • Does physical damage
     • Grants a bonus of 5% HIT to its wielder
     • Prevents shields from being used (via the use of the Seal Equip feature) at the same time as the bow
     • Grants a 5% bonus to the wielder’s CRI

• Erase enemy 30 (Demon God) and come up with a new enemy.
  1. I made a new enemy called the Hill Orc. I used Hue to make the Orc graphic have a tinge of reddish pink. Using Hue is awesome for the shameless, but necessary, RPG convention of having recolored enemies. Rather than have to manually recolor the same sprite multiple times, you could just have a single sprite and tweak it with Hue within RMVXA.
  2. It has 110 MHP, no MMP, 24 ATK, 10 DEF, 8 MAT, 8 MDF, 8 AGI, and 12 LUK.
  3. The Hill Orc gives 20 EXP and 30 Gold when defeated and has a 1/8 chance of dropping a Bomb.
  4. For features, it has 95% HIT, 5% EVA, and physical damage for its normal attacks.
  5. Its attack pattern consists solely of attacking normally.

I Want My Monster to Do More Than Just Attack with a Weapon!

A good wish—and easy to do as well. Let’s take a closer look at Action Patterns. As you have probably noticed by now, many lists in RMVXA can be edited in the same way. That is, double left-click or right-click and select Edit. When you do the same in the Action Patterns area of an enemy page, Figure 3-10 shows what comes up.

• Skill is a drop-down menu that allows you to select the skill that you want the enemy to use.
• Rating is a value that does nothing in of itself. However, when an enemy has multiple skills, it looks to its rating value to determine what to use. I’ve always felt that the official explanation for Rating is ridiculously clunky yet somehow manages to convey the intended message. RMVXA says: “Actions 1 rating point away from the highest priority rating will be used 2/3 of the time and those 2 rating points away will be used 1/3 of the time. If there are actions with the same ratings, their probability of use will be the same.”

An Explanation of Ratings

Confusing, isn’t it? I’ll do my best to explain! Suppose we give our new enemy two new skills. Let’s just call them Skill A and Skill B. So now, the enemy has Attack, Skill A, and Skill B in its action pattern list. If we leave Attack’s rating at 5, give Skill A a rating of 4, and Skill B a rating of 3, here is how the probabilities work.

• Attack: The standard/baseline for the action pattern, as it has the highest rating
• Skill A: Will be used two-thirds of the time, as compared to Attack
• Skill B: Will be used one-third of the time, as compared to Attack

Doesn’t seem like my explanation helps, but let’s go deeper. If our hypothetical enemy uses a total of 100 actions, we can roughly expect the following number of uses of each skill:

• Attack: 50/100 uses
• Skill A: 50*2/100*3 = 100/300. When we simplify that, so it becomes 33.3(repeating)/100. Let’s call that 33/100.
• Skill B: 17/100 (to add up to 100 actions)

If we go back to the previous set of bullets, we realize that the math checks out. Attack is used most frequently, followed by Skill A, and, last, by Skill B.

Okay, what happens if the rating difference is more than two points? Skills that have a rating more than two points lower than the highest usable skill will never be used. Never, ever.

How about those conditions? Do they affect rating? They most certainly do. The game checks for usable skills. So, if you have a skill with rating 10 and a condition to only be used on every third turn, then it doesn’t matter what rating any other skills have on the other, non-third, turns. Let’s take our initial example and add a Skill C that relies on such a conditional.

• Skill C—Rating 10: 100% chance to use on every third turn; 0% chance on every non-third turn
• Attack—Rating 5: 50% chance to use on every non-third turn;.no chance to use on every third turn
• Skill A—Rating 4: 33% chance to use on every non-third turn; no chance to use when Skill C’s turn rolls around
• Skill B—Rating 3: 17% chance to use when Skill C is unavailable; nil on those chances when Skill C is usable

Feel free to test the rating system for yourself, by giving Slimes extra skills and using Battle Test to see how often Slimes use each ability.

By skillful use of conditionals, you can create enemies that have predetermined patterns of attack. For example, here’s a boss pattern I came up with when working on my own game. The pattern in Figure 3-11 is for a Sand Scorpion. It attacks on the first turn, then skips a turn, and then uses a power attack (Poison Tail). That sequence is repeated until the player or the boss is defeated. The turn skip is a skill that has no effects save for displaying a message (in that particular case: “is about to unleash a powerful attack!”).

Let’s finish this exercise!

• Erase troop 30 (Demon God) and make a troop containing one Slime and one of the new enemy you create.
  1. Highlight Slime on the list to the right of the troop graphic and click Add. Afterward, highlight your new enemy and repeat the action.
  2. You can manually name the troop or use Autoname (screenshot of my new troop provided on the next page).

There you have it! Look at Figure 3-12 to see the finished troop. We now have several new things to make the game just a bit more unique. Before we move on, make sure to edit the treasure chest on the second map, so that it gives the player the new bow we created before, instead of the stock Longbow.

With that done, let’s add the new content to the map.

• To add the new troop to the map, you’ll have to go to the second map’s Properties by right-clicking its name in the map screen and selecting Map Properties. We have not covered map Encounters yet, but they are plug and play. Basically, interact (as usual, double left-click or right-click and then select Edit) with the currently empty list, and you’ll get the following pop-up (see Figure 3-13).

• Troop is a drop-down menu that lets you select which troop of enemies you wish to add to the encounter table. Scroll all the way down to the bottom and select the new troop you created.
• Weight determines how often the encounter appears. As we have just the one encounter, the actual value of Weight is unimportant. When you have multiple encounters, the chance of encountering any particular troop is equal to [Troop Weight ÷ Total Weight]. So, if we had three troops with the same weight, the chance to encounter each troop would be 1 in 3.
• Range specifies whether the troop can be encountered anywhere on the map or if its absence/presence is determined by a particular Region (I’ll cover Regions in the next section). Let’s make it so that our troop only has a chance to appear from Region 1. Click Specify by Region ID, and you’ll see the three number boxes brighten. You can specify up to three regions in which that troop can be encountered on the current map. Let’s just write in a 1 in the first box. You’ll notice that the Range of the troop is 1. Had you set the range to Whole Map, it would indicate “Whole” instead.

Regions

As already noted, Regions define where certain troops of enemies can be found. RMVXA allows you to place up to 63 distinct regions on a single map, although you’ll be hard-pressed to use that many anywhere but on a larger world map. You can reach the Region Editor by pressing F7 or clicking the icon to the right of the Event editing mode icon. Find a solitary corner of your map and make a small square or rectangle Region 1. Following is my own map, for reference (see Figure 3-14).

Let’s play-test the game with the appropriate changes! If you did not set an appropriate battleback beforehand, the combat screen will look something like Figure 3-15.

The Strange Battleback

Indeed it is. That’s RMVXA’s attempt to try and generate a battleback based on the available terrain. As you can see, it’s a bit . . . underwhelming. And swirly. So, close your play-test and make your way to the second map’s properties once again. Find Specify Battleback, toggle the check box, and browse through the graphics. I used Grassland for both the foreground and background, but feel free to choose something different. When you encounter the troop once again, you’ll see that the battleback is now an actual defined background and not a strange swirl.

We’re nearing the end of this chapter, but I think it’s time to have a little discussion about damage formulas.

Damage Formulas

Up to now, we have created one new skill, as well as one item that used the damage formula box. However, we have used the default formula. What if we wanted to use different formulas? If you take a look at the many premade skills in RMVXA, you’ll see that not all skills are created equal. Following are some examples of different circumstances that can be covered by different damage formulas.

• An attack that pierces the enemy’s defense: If you want to alter the basic formula, use [a.atk*4] instead of [a.atk*4 - b.def*2]. A skill that doesn’t factor in an enemy’s defense in the damage formula will do damage based on the user’s attack. Likewise, you can make a spell in the format [a.mat], instead of [a.mat - b.mdf], to have a magic defensive piercing skill.
• An attack that does damage based on the target’s HP: You can plug MHP (Maximum HP) and HP (current HP) into formulas as well (MMP and MP too). What if you wanted to make a gravity attack in the vein of Final Fantasy’s Demi spells? Gravity skills, by definition, cannot kill their target. So, let’s use HP. Writing in [b.hp/4] would result in a skill that causes damage equal to a quarter of the enemy’s remaining HP. If we were to switch HP with MHP, said skill would do a quarter of its maximum HP in damage instead.
• A skill that boosts the user’s stats while damaging the enemy: If you look at the stock functionality of RMVXA, you’ll notice that this is seemingly impossible. If you create an attack and use Effects to add states or buff/debuff stats, you’ll see that the target will get them as well. But, perhaps I want a skill that increases my AGI for two turns every time I connect with it. We can use .add_buff() to accomplish that (.add_debuff() lowers a stat instead). So, a skill that boosts the user’s AGI for two turns while damaging an enemy would look something like this: [a.add_buff(6,2); a.atk*4 - b.def*2].

What’s with the numbers in the .add_buff parentheses? Perhaps I should explain, eh? When you add buffs or debuffs via the damage formula box, you can declare the parameter (stat) to affect, as well as the turn duration. Parameter 6 is AGI, and the turn duration is 2.

Parameter Abbreviations

If you head into the Script Editor (in which your functionality is essentially nil, if you’re using RMVXA Lite), you will see a bunch of code. Make your way to Game_BattlerBase under the Game Objects section of the available code and left-click it. If you scroll down that page of code, you’ll find a list of parameters and their internal values. Take a look at the following code, which shows which parameter the numbers refer to.

  #--------------------------------------------------------------------------
  # * Access Method by Parameter Abbreviations
  #--------------------------------------------------------------------------
  def mhp;  param(0);   end               # MHP  Maximum Hit Points
  def mmp;  param(1);   end               # MMP  Maximum Magic Points
  def atk;  param(2);   end               # ATK  ATtacK power
  def def;  param(3);   end               # DEF  DEFense power
  def mat;  param(4);   end               # MAT  Magic ATtack power
  def mdf;  param(5);   end               # MDF  Magic DeFense power
  def agi;  param(6);   end               # AGI  AGIlity
  def luk;  param(7);   end               # LUK  LUcK
  def hit;  xparam(0);  end               # HIT  HIT rate
  def eva;  xparam(1);  end               # EVA  EVAsion rate
  def cri;  xparam(2);  end               # CRI  CRItical rate
  def cev;  xparam(3);  end               # CEV  Critical EVasion rate
  def mev;  xparam(4);  end               # MEV  Magic EVasion rate
  def mrf;  xparam(5);  end               # MRF  Magic ReFlection rate
  def cnt;  xparam(6);  end               # CNT  CouNTer attack rate
  def hrg;  xparam(7);  end               # HRG  Hp ReGeneration rate
  def mrg;  xparam(8);  end               # MRG  Mp ReGeneration rate
  def trg;  xparam(9);  end               # TRG  Tp ReGeneration rate
  def tgr;  sparam(0);  end               # TGR  TarGet Rate
  def grd;  sparam(1);  end               # GRD  GuaRD effect rate
  def rec;  sparam(2);  end               # REC  RECovery effect rate
  def pha;  sparam(3);  end               # PHA  PHArmacology
  def mcr;  sparam(4);  end               # MCR  Mp Cost Rate
  def tcr;  sparam(5);  end               # TCR  Tp Charge Rate
  def pdr;  sparam(6);  end               # PDR  Physical Damage Rate
  def mdr;  sparam(7);  end               # MDR  Magical Damage Rate
  def fdr;  sparam(8);  end               # FDR  Floor Damage Rate
  def exr;  sparam(9);  end               # EXR  EXperience Rate

Mind you, buffs and debuffs only apply for the first eight in the list (in other words, MHP through LUK).

So, States Work in the Same Way, Right?

Mostly. You can declare .add_state(X), where X is the database entry for the state you wish to use. The number of turns a state will last is determined by the state’s properties in the Database. So, if we have the default list of states (of which there are 25), we can make an attack that poisons the user and damages the enemy as follows: a.add_state(2); a.atk*4 - b.def*2.

It is good to note that you only really need to use the commands when you want to apply effects to both the user and the target. If you have a healing spell that also increases AGI, you can cover that just fine with a damage formula and the Add Buff Effect (or you could use a Recover HP effect for the healing part of the spell as well).

With all that said, let’s take a peek at the States tab of the Database (Figure 3-16).

As previously noted, using .add_state requires that you set which state you actually want to add, and it looks at the database value to determine what to add. So, Death is 1, while HP Regen is 14, for example. States have one or two new things, but not much that we haven’t seen in a similar form already.

• Restriction defines what happens to someone affected by the state. Most of them are more forced actions than restrictions. In the case of Death, the actor or enemy cannot move (logically, as they are dead!). However, you also have None, Attack an enemy, Attack anyone, and Attack an ally.
• Removal Conditions define when a state is removed. This is more important for actors, given that enemies cease to be after you are done battling with them. If you don’t define any removal conditions, the only way to remove the state would be to have an item or event that does just that.
  1. Remove at Battle End is self-explanatory. Once the battle ends, so does the state.
  2. Remove by Restriction, on the other hand, is downright misleading. The RMVXA tool tip says: “Automatically remove a restriction if [Restriction] has been set to anything other than [None]”. That’s a bald-faced lie. The tool tip contradicts what Remove by Restriction implies. How it actually works is that a state with that condition will be removed if its owner is affected by another state that causes a restriction. For example, you can have a Rage state that is affected by restrictions so that, if your actor affected by Rage is stunned or otherwise hindered, he/she loses the state.
  3. Auto-removal Timing allows you to set whether the state is removed automatically after a certain number of turns or not. Action End means that the state will be removed after the affected actor or enemy takes a certain number of actions. Turn End means that the state will be removed after a certain number of battle turns.
  4. Duration in Turns can only be edited if you have selected Action End or Turn End in Auto-removal Timing. The first box defines the minimum number of turns the state will last, while the second box notes the maximum number of turns.
  5. Remove by Damage gives a percentage chance based on the number placed in the appropriate box to remove the state when the actor or enemy suffers damage.
  6. Remove by Walking. The state is automatically removed after the actor takes a certain number of steps on the map. You can have any number from 0 to 9999 in that box.
  7. There are four kinds of messages you can edit. They display when an actor is affected by a state, an enemy is affected by a state, the end of a turn when an actor or enemy is still affected by a state, and when the state is removed.
  8. Last, Features return once again but don’t bear additional explaining, as they do mostly the same that they do in other sections. One thing that does bear mentioning is that state 001 is a special state that is automatically applied whenever a character’s HP reaches 0. By default, it is called Death.

Back to Damage Formulas?

Back to damage formulas! We already scratched the tip of the figurative iceberg by noting the existence of add_buff() and add_state(). Incidentally, remove_buff() and remove_state() exist as well. The remove methods only accept a single parameter within their parentheses. In the case of remove_buff, you declare which of the eight main stats you wish to remove a buff for. For remove_state, you define which state is to be removed.

You may have noticed that, in my use of those mentioned methods, I used a semicolon to divide them from the damage formula. There is a little-known rule about damage formulas that is not mentioned within RMVXA, but here it is: In any formula, you must end the formula with a damage value (or healing, as the case applies). The easiest way to prove or disprove that assertion is by editing the damage formula of your new bow skill and adding a semicolon after the damage with an add_state or add_buff command (remember that “a” before the command denotes user, while “b” denotes target). If you did it correctly, you’ll see that your skill now does nothing except apply the buff or state. Now, switch the two halves of the formula around, and you’ll do damage again.

Here are some other neat things you can do with damage formulas:

• Making a skill that does more damage based on the target’s active states: Say you want an enemy that poisons the player’s party and then tries to consume that poison to do massive damage to its victims. You could have a formula like so: if b.state?(x); b.remove_state(x);Winter.phys(1.0,a,b);else 0;end.
  1. state? is another method within RMVXA. As the name might suggest, state? checks if the target has x state, where x is the number of the state in the Database.
  2. If the target has x state, the skill removes the state and then applies a custom damage formula I came up with (that’s the Winter.phys part). If you are using the full version of RMVXA, I’ll be covering how to add extensive damage formulas into the script editor for you to call as in the preceding.
  3. If the target does not have x state, then the skill does 0 damage.
  4. The end terminates the formula.

Those of you with programming experience (especially in Ruby, but even if not) will probably recognize the preceding formula as an if conditional branch. The damage formula box is fully robust. It will hold any amount of Ruby you can fit in there.

So, About That Winter up There . . .

Okay, first let’s list some extra exercises for you to do. Then, I will cover what that strange method up there involves.

1. Make a troop with a single monster that says some words before dying.
   • Death is prioritized over any other consideration in battle, so you’ll have to make the enemy immortal (there’s a default state in RMVXA that covers exactly that), have a conditional that triggers when the monster drops to 0% HP, have the monster say its words, and then remove the Immortal state, so that Death can trigger.
   • This troop event can be done with two event pages. The first one should have a Turn No. 0 conditional and a Battle Span (as we only want this event to execute once per battle). You can use the Change Enemy State event command to set the monster’s Immortal state.
   • The second event page for this exercise should have a Condition of HP 0% or below and a Battle Span. Because Death is prioritized, the monster must say its words before you remove the state.
2. Create an enemy with five different skills (including the normal Attack skill). Have one skill require the enemy to be in a state to use, and have another one of its skills grant that state.
3. Create an enemy that uses a single skill on a three-turn countdown.
   • Perhaps the best way to do so within the confines of RMVXA is to create one “skill” for each countdown turn, much like I did for the Sand Scorpion attack pattern I showed you some time ago. If you look at the message box for a skill, you’ll see it has two lines. On line 1, you can write “is charging up a massively powerful attack,” and on line 2, you can write the appropriate number (3, 2, or 1).
   • Remembering the whole thing about ratings and conditional uses of skills, you can also have the monster use a normal attack pattern that changes to the countdown when the monster is down to half HP or less.
4. Create a damage formula that includes a variable.
   • A variable has to be expressed in the form $game_variables[n], where n is the variable’s ID.
   • Remember that a variable is, after all considerations, a number. You can use the variable as an attack multiplier, for example.

If you’re following along with the Lite version of RMVXA, you will not be able to perform this next exercise, so feel free to skip ahead to Chapter 4, as this will be the last thing I post within this chapter. For the rest of you, let’s go.

You may be wondering the purpose of writing your formula somewhere else and calling it via code, instead of just typing it into the formula box. Well, as I have noted already, the damage box has limited space. Take a look at the formula that I used at one point in a game I was making using RMVXA.

a.atk>b.def ? a.atk*0.5*(1.0+(1.0-(b.def*1.0/a.atk*1.0))) : a.atk*0.5*(a.atk*1.0/b.def*1.0)

And that’s after I applied some basic Ruby to shorten the expression. The above formula is written as a ternary expression. In simpler terms, it’s another way to write out an if conditional branch. It reads out as such.

• If a.atk > b.def
• then a.atk*0.5*(1.0+(1.0-(b.def*1.0/a.atk*1.0))
• else (if a.atk < b.def) a.atk*0.5*(a.atk*1.0/b.def*1.0)

The damage formula may seem alien, but the net effect that it achieves is that a character can never deal more damage than its total Attack stat (which is the sum of a character’s Attack and the Attack that it receives from its equipment). This formula favors lower stats a lot better than the default formula does. A similar formula is used for games in the Dragon Quest series (where the HP cap is 999 instead of 9999, as in Final Fantasy, and thus damage/healing has to be lower across the board).

Of course, as cool as the formula is, writing it out completely within the damage box takes up very nearly every inch of space there is. So, I read up a bit and decided to create a module within the Script Editor instead. How do we do that?

• From the main map screen, press F11 or click Tools and find the Script Editor option.
• Enter the Script Editor and then scroll all the way down to Materials. You will see a single option titled “(Insert Here).” Click it and read what it entails.
• Afterward, do as the help note recommends and insert a new page under the Materials section of the Script Editor by right-clicking Insert Here. Here’s what the filled out page looks like for me:

module Winter
   module_function

   def phys(p, a, b, v = $game_variables)
      if a.atk > b.def
         return (a.atk*p*(1.00+(1.00-(b.def*1.00/a.atk*1.00))))
      else
         return (a.atk*p*(a.atk*1.00/b.def*1.00))
   end
end

#Express in the form Winter.phys(p, a, b)
#p is the power multiplier for the ATK stat of the caster.

def sitva(bd, p, a, b, v = $game_variables)
   return ((bd + a.mat*p)*(a.mat*1.00/b.mdf*1.00))
end

#Express in the form Winter.sitva(bd, p, a, b)
#bd is the base damage of the Sitva
#p is the power multiplier for the MAT stat of the caster.

end

It’s not much to look at, but it is basic-level Ruby programming at its finest. You’ll be happy to know that you can copy-paste this for use in your game. However, programming is, at its heart, a journey of problem-solving and discovery. Let me walk you through these lines of code.

• We are creating a module to contain methods related to damage formulas for use in our game.
• This particular module is named Winter (you could rename it anything else, and it would be fine).
• module_function is needed for the module to work correctly. Alternately, you could add self to each of the method definitions (def self.phys, for example) for the same effect.
• Below we have def phys along with parentheses filled with several variables. Methods are expressed in the form method (parameters). Notice that the method is on a higher indentation level compared to module Winter. Indents are necessary in Ruby coding, to determine what goes where. Everything below the module is part of it, so it has to be indented. Likewise, everything under def phys until the second end is contained within said method; hence, it is a higher indentation level than def phys.
  1. As noted a few lines later in a comment tag, p is the power multiplier for the user’s ATK stat.
  2. a and b are the standard uses in a damage formula (user and target).
  3. v is used for any variables you decide to use within a formula. You can use the value of a variable by expressing it as $game_variables[n] within a damage formula.
• Next, we have an if statement that’s true if a.atk is greater than b.def. If the statement is true, then the first formula is the one to be used, If the statement is false, then the second formula is used instead.
  1. return is used within Ruby to exit a method early (in a case such as the one preceding, where we have the formula we want already). While it is not strictly necessary to use at any point of the code I placed in the previous page, it does no harm either, so I left it as is.
  2. The first end in the method terminates the if statement. The second end terminates the method itself.
• def sitva is the other method present here. Sitva is what I called magic in my own game. You can rename sitva to magic, and it will make no difference.
  1. As noted in the comment tags following this method, bd represents the base damage of the spell in question, and p is the power multiplier for the caster’s MAT stat.
  2. You’ll notice that there’s no if statement for this method, as there’s only the one damage formula to plug. I took my inspiration from many Japanese RPGs, in which spell damage tends to be a little more constant than physical damage. (So, barring the target having a massive amount of MDF compared to the user’s MAT, damage spells should always do some good damage.)
  3. Because you have only the method itself, you only need the one end statement.
• Last, you’ll notice a solitary end past the def sitva comment tags. That end closes out the module itself.

See Figure 3-17 for two examples of damage formulas using my new methods.

• As you can see, the code is called in the form Module.method. So, you have Winter.sitva and Winter.phys, respectively, in the two preceding examples. Compare the expressed methods with the code listed previously, and you’ll see that we utilize every variable within the method parentheses. For sitva, we have base damage, the MAT multiplier, a, and b, in that order. For phys, we have the ATK multiplier, a, and b.

Summary

During the course of this chapter, we covered a great part of the Database. The Database is required to create playable character, enemies, and items for the player to collect. We created new items for our protagonist to use. In addition, we touched upon the Region tool and used it to create an area in which the player can engage a newly created troop. That concludes this chapter. In the next chapter, we will work on fleshing out our game a little more. How, you may wonder? We’ll be adding more locations to the game!