Trainers

For how to create trainer data, see Defining a trainer.

A simple NPC trainer event created with comments.

This page describes how to set trainer events up in the game.

Setting up a trainer event

An NPC trainer is an event with certain event commands that cause a battle to occur against that trainer. While it is possible to construct a trainer event manually, Essentials is able to generate a basic trainer event from just a few comments written in that event, which are designed to be easier to create and edit.

Turning comments into a trainer event occurs when compiling the game, and this process erases anything else in the event at that time. Note that, after you compile your game, you will need to close and restart RPG Maker XP to see the changes in the events.

It is important to note that these comments are not erased by the Compiler, meaning that they remain in the event and will cause the Compiler to recreate that event again the next time you compile the game (and so on). If you want to edit a trainer event further, remove the comments or your edits will be undone.

The available comments are as follows:

Comment	What it means	Required?
Battle: Battle me now!	What the trainer says before starting the battle. This comment becomes a simple text event command which says "Battle me now!". Use "\m" to split the comment's message up into separate text messages. There can be more than one of these comments, and each one after the first is the introduction text for a different rematch battle (in order). Also, if there is more than one "Battle" comment, then the player will be asked to register the trainer in the phone after defeating them. You should have the same number of these comments as you do versions of the trainer (including the original), even if they are all the same phrase.	Yes
Type: CAMPER	The internal name of the trainer's type.	Yes
Name: Dave	The trainer's name.	Yes
EndSpeech: I enjoyed that.	What the trainer says when the player wins a battle. Specifically, this is the brief message they say while still in the battle screen, after the trainer has reappeared on the screen. There can be more than one of these comments, and each one after the first gives the end-of-battle text for a different rematch battle (in order). You should have as many of these comments as you do "Battle" comments; if there are more of these, the excess messages won't be used, and if there are fewer of these, the last one will be repeated for later rematches. If this doesn't exist, the message will be "..." instead.	No
EndBattle: I'll train even harder!	What the trainer says when you talk to them again after defeating them. Use "\m" to split the text into individual messages. There can be more than one of these comments, and each one after the first gives the after-battle text for a different rematch battle (in order). You should have as many of these comments as you do "Battle" comments; if there are more of these, the excess messages won't be used, and if there are fewer of these, the last one will be repeated for later rematches. If this doesn't exist, the message will be "..." instead.	No
RegSpeech: Here's my number.	What the trainer says when the player is asked to register the trainer's phone number.	Yes if there are multiple "Battle" comments
DoubleBattle: yes	Makes this battle a double battle.	No
BattleID: 1	If there are multiple versions of this trainer, then this number is the one used to distinguish one version from the others. This should only be used for isolated battles against the same trainer (e.g. the rival who shows up in different places) or a trainer with the same name as another (e.g. Team Rocket Grunts). For regular trainers that stay in the same place that you can rebattle, don't use this comment and instead just rely on using multiple "Battle" comments. If this doesn't exist, this value will be 0.	No
Continue: yes	Makes the player able to continue the game (with their party fully healed) if they lose the battle against this trainer, rather than blacking out and returning to a Poké Center. If this trainer has been set up with rematches by using multiple "Battle" comments, this continue effect will apply to all of those battles.	No
EndIfSwitch: 42	If the Game Switch with this number is ON, the battle is treated as already over. Typically used for trainers in a Pokémon Gym, which are deactivated after beating the Leader regardless of whether they have been battled themselves.	No
VanishIfSwitch: 42	If the Game Switch with this number is ON, the game won't show the event at all. This only updates during a map transfer; it will still be visible until then.	No
Backdrop: Mystic	Sets the battle background for this battle. For this example, the background images will have filenames of "battlebgMystic.png", "playerbaseMystic.png" and "enemybaseMystic.png".	No
Outcome: 42	The outcome of this battle will be stored in the Game Variable with this number.	No

Trainer behaviour

Since all NPC trainers are events, they can be manipulated in many of the ways that other events can be. They can be made to randomly turn on the spot, or roam around, or walk in a specific pattern. They can be made to only battle the player during a certain time of day (e.g. police officers at night), or after a certain point in the game, or to walk off after the battle is over. There are a wide range of possibilities, and all of them can be achieved through event manipulation (an RPG Maker skill, not Essentials-specific, so you won't find help on this here).

An NPC trainer is typically able to see a number of tiles in front of itself, and when the player enters that range, the NPC will stop them and approach and start a battle. To make an event do this, give it the name "Trainer(X)", where "X" is the number of tiles the trainer can "see" in front of it. You will also need to set the event to trigger on Event Touch.

Structure of trainer events

A basic trainer event has two pages to it, as described below. More complex trainer events can be created, by using more of the comments listed above or by editing the trainer event yourself (remember to delete the special comments described above if you want to edit the event manually).

Page 1

The first page contains something like the following:

@>Script: pbTrainerIntro(:CAMPER)
@>Script: Kernel.pbNoticePlayer(get_character(0))
@>Text: Battle me now!
@>Conditional Branch: Script: pbTrainerBattle(:CAMPER,"Dave",_I("I enjoyed it."),false,0,false)
  @>Control Self Switch: A =ON
  @>
 : Branch End
@>Script: pbTrainerEnd

pbTrainerIntro will play the ME specific to the trainer type mentioned in its argument (CAMPER in this case). If that trainer type doesn't have an ME specific to itself, it won't play anything. It also freezes all events on the map, so that nothing interrupts the battle (e.g. a free-roaming trainer happening to come across the player).

Kernel.pbNoticePlayer is the script used to have the trainer turn to face the player, exclaim and walk up to them. Noticing the player from a distance in the first place (and thus starting this event up) is due to the event being named "Trainer(X)" as described above. Note that this script can be used for non-trainer NPCs as well; it itself has nothing to do with battling (it is just commonly associated with them).

If you intend to use move routes after the battle concludes (e.g. to have a trainer who is blocking a doorway move aside after being beaten), you must refresh their position manually by using the script:

@>Script: $PokemonMap.addMovedEvent(get_character(0))

Otherwise if the game is saved and reloaded without first leaving the map, the NPC trainer will return to the position they were in after they moved towards the player because of Kernel.pbNoticePlayer, which could potentially lead to unintentional blocking paths.

The battle itself is caused by a line of code within a Conditional Branch. If the battle is won, then the contents of the Conditional Branch will be carried out (this could be a few more text messages, awarding a Gym Badge if the trainer was a Gym Leader, etc.). The Conditional Branch must contain a command to set the event's Self Switch A to ON, so that when the trainer is interacted with again after beating them, the battle will not occur again.

pbTrainerBattle itself has six arguments:

1. The trainer type. Note the colon in front of it.
2. The trainer's name.
3. A message that is shown at the end of the battle (before the battle screen is closed).
4. Optional. TRUE if it is a double battle, FALSE if it isn't. If this is TRUE, then you must also check before the battle whether the player has at least 2 able Pokémon, and forbid the battle if they don't. Default is FALSE.
5. Optional. A number used to distinguish between different versions of the same trainer (see above). Is 0 if there is only one version. Default is 0.
6. Optional. TRUE if the player can continue after losing the battle (with their party fully healed). You should also modify the Conditional Branch to include the "Set handling when conditions do not apply" option (i.e. an "else" part of that Branch), and insert something in there that says the player has lost the battle (you must also set a Self Switch to ON here, like if the battle was won, to prevent the trainer instantly re-challenging the player). Default is FALSE (i.e. the player blacks out and returns to the last Poké Center upon losing as normal).
7. Optional. The number of the Game Variable in which to store the outcome of the battle. By default, no outcome is stored.

Finally, pbTrainerEnd unfreezes all events on the map.

Page 2

The second page of the trainer event requires Self Switch A to be ON, and simply contains a text message, saying whatever the trainer will say when interacted with again after they have been defeated.

Double battles

You can have double battles against any of the following:

• One trainer.
• Two NPCs treated as a single trainer (which has a trainer type that depicts two people, e.g. "Sis and Bro").
• Two separate trainers who are partnered.
• Two unrelated trainers that just happen to spot you at the same time.

Note that the second and third types are different to each other: the second is set up as a single trainer, while the third is two separate trainers but who are always battled together.

The third and fourth types are also different to each other: the third is always a double battle regardless of which NPC is spoken to, but with the fourth you could potentially battle each of the two trainers separately.

Against one trainer, or two NPCs treated as a single trainer

These are both single trainers, except that the "two NPCs" version has a trainer type that depicts two NPCs.

Before starting the battle, you must check that the player has at least 2 Pokémon that are able to battle. This check is done in the trainer event before starting the battle, as a Conditional Branch which looks like:

@>Conditional Branch: Script: $Trainer.ablePokemonCount<=1
  @>Text: You don't have at least 2 usable Pokémon!
  @>Exit Event Processing
  @>
 : Branch End

Note that the event must exit event processing at the end of this Conditional Branch, which means that anything below that line will not be carried out.

To have a double battle against a single trainer or paired trainers, include the "DoubleBattle" comment in the trainer event. This sets the appropriate argument of pbTrainerBattle to "TRUE".

For the "two NPCs" version of this kind of double battle, there will be two NPC events standing next to each other, and you will have spoken to one of them to start the battle. It is possible to then talk to the other NPC, which could also start the same battle again; to prevent this, you will need to set the other event's Self Switch A to ON at the same time you set the interacted event's Self Switch A. To do this, include the code pbSetSelfSwitch(event,switch,state) in the event, where "event" is the ID number of the other NPC event, "switch" is the Self Switch's letter you wish to set (in quote marks, usually "A"), and "state" is TRUE or FALSE, e.g.

@Script: pbSetSelfSwitch(42,"A",true)

Each of the two NPC events should be identical, except for this additional line which will reference the other event's ID number.

Against two separate partnered trainers

These are two separate trainers who always battle together. Each of these two trainers should have three or fewer Pokémon, for fairness (this isn't mandatory).

Before starting the battle, you must check that the player has at least 2 Pokémon that are able to battle. This check is done in the trainer event before starting the battle, as a Conditional Branch which looks like:

@>Conditional Branch: Script: $Trainer.ablePokemonCount<=1
  @>Text: You don't have at least 2 usable Pokémon!
  @>Exit Event Processing
  @>
 : Branch End

Note that the event must exit event processing at the end of this Conditional Branch, which means that anything below that line will not be carried out.

You will also need to change the event's commands to replace pbTrainerBattle with pbDoubleTrainerBattle. This will start a double battle against two separate trainers. pbDoubleTrainerBattle has the following arguments:

1. Trainer 1's trainer type (e.g. :CAMPER). Note the colon in front of it.
2. Trainer 1's name.
3. A number used to distinguish between different versions of Trainer 1 (see above). Use 0 if there is only one version. This must be specified.
4. What Trainer 1 says when the player wins (before the battle screen is closed).
5. Trainer 2's trainer type.
6. Trainer 2's name.
7. A number used to distinguish between different versions of Trainer 2 (see above). Use 0 if there is only one version. This must be specified.
8. What Trainer 2 says when the player wins (before the battle screen is closed).
9. Optional. Whether the player can continue after losing the battle (like above). Default is FALSE (i.e. the player blacks out and returns to the last Poké Center upon losing).

For example:

@>Conditional Branch: Script: pbDoubleTrainerBattle(:CAMPER,"Dave",0,_I("I enjoyed it."),:HIKER,"Zaphod",0,_I("Where's my towel?"),false)
  @>Control Self Switch: A =ON
  @>
 : Branch End

There will be two NPC events standing next to each other, and you will have spoken to one of them to start the battle. It is possible to then talk to the other NPC, which could also start the same battle again; to prevent this, you will need to set the other event's Self Switch A to ON at the same time you set the interacted event's Self Switch A. To do this, include the code pbSetSelfSwitch(event,switch,state) in the event, where "event" is the ID number of the other NPC event, "switch" is the Self Switch's letter you wish to set (in quote marks, usually "A"), and "state" is TRUE or FALSE, e.g.

@Script: pbSetSelfSwitch(42,"A",true)

Each of the two NPC events should be identical, except for this additional line which will reference the other event's ID number.

Against two unrelated trainers

This is when two completely unrelated trainers just happen to spot the player walking in front of them at the same time. Each of these trainers can be battled separately, and will be regular single battles in that case. The total number of Pokémon between them should be 6 or fewer, for fairness.

In turn, each of the two trainers will approach the player and talk to them. The order they do this in depends on the IDs of those events (e.g. event 16 will move before event 17). Then a double battle against both separate trainers will occur (if the player has at least 2 usable Pokémon).

If the player only has 1 usable Pokémon, then the two trainers will be battled in turn, with the second not approaching the player until the first has been defeated.

In the unlikely event that three trainers happen to spot the player at the same time, the first will be a single battle, and then the other two will be a double battle (if possible). For example, if the events of these trainers are numbered 7, 8 and 9, then 7 will be a single battle, followed by 8 and 9 being a double battle.

Animation when entering battle

The Vs. animation.

A transition is a way of making the screen turn black, in order to start a battle. There are a number of transitions in Essentials, which are designed like the ones from Pokémon HGSS and used in the same way.

A trainer battle may instead display a Vs. animation, an example of which is on the right. This animation will play instead of a standard transition only if the appropriate graphics exist. The required graphics are:

• Graphics/Transitions/vsBarXXX.png
• Graphics/Transitions/vsTrainerXXX.png

The "XXX" is either the internal name or the ID number (not padded) of a trainer type, which means a Vs. animation will play for every trainer with the same trainer type (as long as the required graphics exist for that trainer type).

There should also be copies of the above graphics for the player's possible trainer types. There are also a couple of other graphics and sound effects used in this animation. However, none of these are checked for first - it is assumed that they all exist if the listed graphics above exist.