A Critique on the Default Target System

Help spread the word!Share on FacebookShare on TumblrTweet about this on TwitterShare on Google+Share on LinkedInShare on RedditFlattr the author


This article discusses the targeting system in the default battle system in RPG Maker VX Ace. The purpose of this article is to understand how the target system works, and determine whether it is designed well. I provide a number of examples of different game mechanics that I use to put the target system to the test.

What is Targeting

In the context of battle actions (or actions in general), targeting refers to the object that an action will be used on. For example, you want to cast a Heal spell on your ally. We say that the ally is the target of your healing spell. Similarly, if you want to attack a Slime, we say the Slime is the target of your attack.

Target Scope

All items and skills have a scope. You can see the list of default scopes in the database editor. Check the help file for a description of each one, but they should be self-explanatory,


The scope determines who you may select as a target.

The Ally and the Enemy

The scope uses terms like “ally” and “enemy” to describe who the targets are. Recall that the default battle system consists of two units of battlers: the party and the troop. The party holds all of the actors, and the troop holds all of the enemies.

Every battler has their own idea of who an ally is, and who an opponent is. For actors, allies are members in the party, and opponents are members in the troop. You can verify this in the Game_Actor class

def friends_unit

def opponents_unit

For enemies, the opposite is true. You can verify this in the Game_Enemy class.

Overview of the Targeting Workflow

Now that the basics are out of the way, we look at how targeting is implemented. This is the general workflow in the default battle system, supposing that you want your actor to attack an enemy.

  1. Battler’s turn comes up
  2. Battler selects a skill (eg: Fire)
  3. The engine checks the scope of the skill and determines that it may target “one enemy”
  4. The engine brings up the target selection window asking you to select a target
  5. The battler chooses to cast fire on the first enemy
  6. A Game_Action object is created with the index of the target (zero, because Ruby) and the skill set as the action
  7. When the action is executed, the information is used to apply the skill to the correct enemy that you’ve selected

This sounds straightforward: you pick an enemy, and the skill is applied on the enemy. That is exactly the behaviour you expect. Let’s look at some of these steps in detail.

Target Selection

When you select an item that allows you to select your target, a target window will appear. There are two separate windows: an actor selection window, and an enemy selection window. Depending on whether the scope targets allies or enemies, the appropriate window will appear.

If an actor selects a skill that targets allies, then the actor selection window will appear showing all of your allies


If the skill targets enemies, then the enemy selection window will appear showing all of the enemies that can be targeted


Target Index

Once you have selected your target, the engine determines the target’s index. In the default engine, every unit has an index. The index represents their position in the unit. If you think of your party’s formation, the leader is in the first position (index 0), the first follower is in the second position (index 1), and so on.

Your index is not necessarily related to where you appear on the screen. Indeed, enemy indices are based on the order that they are added to the troop (you can read more about troops in this tutorial), but you can place them wherever you want on the screen.

Action Target Adjustment

Recall that the target index is stored with the action when the action is created. In the default battle system, actions not executed immediately. Instead, they are queued up and will be executed when the battler’s “action phase” comes around.

When the action is executed, a separate set of methods are used to determine the actual battler which the action’s skill or item will be applied to. Furthermore, if the target is no longer available, the battler doesn’t simply cancel their action. Instead, the action will automatically be applied to the next available target. If no available target exists, then the action will be canceled.

So for example, you wanted to heal a wounded ally. However, before you could cast your spell, the enemy attacks and your ally dies. Now, when you try to cast your heal spell, the target is already dead…but the skill doesn’t apply to dead allies, so it will try to find the next available ally that is alive and automatically sets that as the target.

You can refer to the make_targets method in Game_Action to see how it is done.

Analysis of the Default Target System

If we assume that no one will ever have any need for a different battle system or battle mechanics, then our target system works well and does not need to consider anything else.

Likely assumption.

The requirements of a game engine is far more looser than the requirements of specific game, and building a game engine around a pre-defined set of game mechanics only serves to limit what you can do with the engine.

I will provide a review of the targeting system using examples of mechanics that are fairly common, but are made impossible to achieve because of the way it is designed.

Targeting both actors or enemies

Suppose you want to use a skill. Is it fairly unrealistic that you can ONLY attack enemies, or ONLY heal allies. It is much more realistic that you can use a heal spell on an enemy, or you can attack an ally, or even yourself. If you were fighting some undead monsters who are vulnerable to healing spells, you kind of want to be able to use your regular healing spells on the enemies as well.

Unfortunately, our scopes do not provide support for “one actor or enemy”, and neither does our selection window. There is no selection window that allows you to choose any actor or enemy.

Given the fact that the only piece of information that the engine has to determine which battler you wanted to target is an index, there’s no way for it to know whether you meant an ally or an enemy. This is where the scope comes in:

def make_targets
  if !forcing && subject.confusion?
  elsif item.for_opponent?
  elsif item.for_friend?

If the scope targets opponents, then it uses the index to look up an enemy. If the scope targets allies, then it uses the index to look up an ally. If you could manually override the scope of your action, then that would work. However, in the  current state, you can only target an enemy or an ally, but not both at the same time.

Targeting Empty Positions

You can’t.

There is no concept of “empty positions” in the first place. You can only target valid indices, and valid indices are defined to be battlers that can be targeted. So you must pick a battler to target. Want to swing your sword in mid-air randomly? Tough.

Realistically, this means that you would not be able to create area of effect abilities that allow you to target a random opening in between two enemies and hit both enemies. Of course, some games might not want players to do this, but the solution is not to simply remove this option altogether.

Moving Battlers

There is no concept of “moving” in battle. If someone shoots an arrow, you will always be hit no matter how much you try to avoid it. of course, there is a calculation that allows you to “evade” an attack with some percent of success, but that’s a pretty limited option if you wanted to provide a more interactive experience where you actually step aside.

You could possibly implement formation changing functionality that allows you to swap positions between members, and that’s about as close as you can get to avoiding a hit. But it just means someone else will take the hit.

Controlling Enemies

Suppose you have a skill that allows you to take control of an enemy and have it use its skills on their own allies. How dangerous. In fact, it’s so dangerous, RPG Maker doesn’t let you do it. You simply cannot control anyone that isn’t in the party.

Ok, so let’s put the enemy into the party. But the enemy is not an actor, so the party will reject it (by crashing the game).

Let’s just make it so that you can have an enemy attack it’s own allies! But you can’t either, because an enemy’s opponent is the party, and based on the scope rules, you simply cannot choose an enemy’s allies as a target for skills that target opponents.

On the upside, enemies cannot control you either, so you don’t have to worry about enemies mind controlling your party members.


Depending on how you see things, you may say that the target system is just fine, that it does what it was designed to do, and that anything else is outside the scope of the engine and is our own problem. However, there are plenty of ways to design a system that meets your own requirements and doesn’t limit flexibility. In that sense, it is not designed very well. Even something as simple as picking an actor or an enemy to attack is basically impossible because not enough data is provided to the relevant objects.

I would recommend building a more flexible targeting system and use it as a core script rather than trying to bend the default targeting system to fit your needs.

Spread the Word

If you liked the post and feel that others could benefit from it, consider tweeting it or sharing it on whichever social media channels that you use. You can also follow @HimeWorks on Twitter or like my Facebook page to get the latest updates or suggest topics that you would like to read about.

Help spread the word!Share on FacebookShare on TumblrTweet about this on TwitterShare on Google+Share on LinkedInShare on RedditFlattr the author

You may also like...

4 Responses

  1. Wavelength says:

    Hi Hime – didn’t realize you had replied to my comment, thanks!

    “Real” space and “real” time are very interesting elements to allow the player to manipulate in an RPG battle system, and the standard turn-based system doesn’t let you do either. I think it needs to be a very conscious design decision to open up either of these elements (and if you do both then you basically have a form of ABS) – these elements create more fun and strategic battles when designed well, but it also increases the complexity and length of combat turns.

    I’d be super-excited to see your positional combat system. Is it still in the works?

  2. Arsist says:

    Yeah, the fact that no matter what you do, you’re always going to hit or get hit the same is something I considered. For example, a shield-based front-oriented fighter and a mage in the back will get hit the same by dagger wielder. There are ways around this through scripts that add preparation, before, and after-use states and use of rows and modifications to the hit and eva formulas in the script editor. However, the default battle system doesn’t allow for visual representation of battle positions and sideview animated systems aren’t always versatile enough to show in-battle changes to position, and you’d have to create dynamic hit formulas based on how many “spaces” someone is away from you, for example, with two hand-to-hand combat users in the back row, with one using the Wait action and the other attacking, the one attacking will have a high chance to miss due to all the time the one that is waiting has to avoid the approach altogether.

  3. Wavelength says:

    Hey Hime – good write-up!


    I feel that the biggest issue in targetting is the concept you touched on that a character can’t “see what happens” before their action comes up (e.g. an allied character that they had chosen to heal is KO’ed, or an ally scores a Critical Hit that puts an enemy one shot away from defeat but they had chosen to attack someone else). In a few games I’ve created, such as How Badly Do You Want It?, I redid the “turns” system so that only one battler will take an action each turn. This lets you evaluate the current situation and choose an action directly before each character takes their action.


    The limitation of only being able to use a given skill on allies OR enemies and not being able to target either one can be sort of annoying as well. But I know that you yourself have the “Scope Change” script to get around that!


    When you start getting into things like Area of Effect attacks and movement around the battlefield, you’re talking something entirely different than a traditional turn-based system. As a fan of games like Skies of Arcadia I’d LOVE to see this kind of element in battle (and I do think a few scripters have partially done this with enemy positiions), but I see it more as a possible feature in future RPG Makers than an actual limitation of our current one.


    It would be insanely cool if you could, without using scripts, choose between different options for your battle system like Front/Side view, Unit/Area targetting, and Turn-Taking/Faux-ATB (RPG Maker 3, Grandia-style)/True-ATB (Final Fantasy 8-style) turns.

    • Hime says:

      I’m not a fan of separate command and execution phases, but I think it isn’t too bad. For example, if you think way back to Final Fantasy 1 (like, NES era), they had a command-input phase, and then an action execution phase. Now the thing with FF1 was that if the target died…well, that was it: your actors simply canceled their attack. I think in the re-make, they changed it so that actors would just hit the next available target. Fortunately when FF2 came around, actors wouldn’t just cancel their attacks completely when a target disappears.

      Scope Change was written fairly poorly. It overwrote a lot of things and doesn’t address the core issue: actions didn’t have information about scope. Instead, scope was pulled from the skill/item to use. I have a better targeting system in the works, which would address all of the examples I showed, and also implements what I think is a necessary feature: battle position.

      In Final fantasy, they use the concept of “rows”. In Grandia, you can walk around the battle field. Many games have the concept of position, and having a script that provides it should lead to a lot of new battle mechanics in RPG Maker. There are already scripts that implement it in various ways, so I’m more interested in a general implementation of a grid system rather than the actual consequence of standing on a certain square.

Leave a Reply

Your email address will not be published.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax