Trainers

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

See also

Defining a trainer

• For how trainers and trainer types are defined.

Time-sensitive events

• This article describes how to make events "active" only during certain periods of time. Usually used for police officers, who battle only at night, and NPCs who only appear on certain days.

Battles

• Enemy trainers will challenge the player to battles.

Setting up a trainer event

To do this, create an event with the name "Trainer(X)", where "X" is the number of tiles the trainer can "see" in front of it (i.e. if the player steps within that range, the trainer will automatically notice them, move towards them and talk to them). If you don't want the trainer to be able to "see" in front of it (e.g. for Gym Leaders, Elite Four members), then don't name the event this.

Then, add some comments in that event. When the game is compiled, these comments are transformed into the proper event commands required for a trainer event; the comments are just easier to work with than creating a trainer event from scratch.

The possible comments are:

Comment	What it means
Battle: Battle me now!	What the trainer says before starting the battle. This comment becomes a simple text message 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 gives the introduction text for a different rematch battle (in order). Also, if there is more than one "Battle" comment, then the player will 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.
EndSpeech: I enjoyed that.	What the trainer says (still in the battle screen, after the trainer has reappeared on the screen) when the player wins a battle. There can be more than one of these comments, and each one after the first gives the post-battle text for a different rematch battle (in order). Ideally you should have as many of these comments as you do "Battle" comments.
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). Ideally you should have as many of these comments as you do "Battle" comments.
RegSpeech: Here's my number.	What the trainer says when the player registers their phone number.
Type: CAMPER	The internal name of the trainer's type.
Name: Dave	The trainer's name.
BattleID: 1	If there are multiple versions of this trainer, then this number is the one used to distinguish one version from the others (see above). 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.
DoubleBattle: true	This battle is a double battle. Typically used for when you have a single trainer type (i.e. sprite) that depicts two trainers (e.g. "Sis and Bro" depicts a female "Swimmer" and a male "Tuber"), or when you just want a double battle against one opponent.
Continue: true	Makes the player able to continue the game (with their party fully healed) if they lost a 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.
EndIfSwitch: 42	If the Global 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.
VanishIfSwitch: 42	If the Global 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.
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".
Outcome: 42	The outcome of this battle will be stored in the Global Variable with this number.

After these comments have been converted into the proper event commands, you can then edit those event commands however you want (e.g. to insert a long speech before the battle, or to insert a Conditional Branch for something).

NOTE: Each time the game is compiled, events called "Trainer" or "Trainer(X)" will be reset to a basic form using the above comments (if they exist), which will erase any changes you might have made. To prevent this from happening, you should remove the comments after initially compiling the trainer event, so that you can then edit the event further as you want.

Trainer behaviour

Since all trainers, as seen in-game, are events, they can be manipulated in many of the ways any 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).

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.

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(PBTrainers::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).

pbNoticePlayer is the script used to have the trainer notice the player from a distance and walk up to them. The distance (in tiles) is the number that is part of the event's name (e.g. "Trainer(3)" will see 3 tiles in front of it). 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 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 event NPC will return to the position they were in after moved towards the player, which could potentially lead to unintentional blocking paths.

The battle itself is put as the clause of 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.
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. Double battle. 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. Whether the player can continue after losing the battle. If TRUE, the player's party is fully healed upon losing the battle. 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 returns to the last Poké Center upon losing).
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: 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: the third is always a double battle regardless of which NPC is spoken to, but with the fourth you could 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 and have the same battle again, so 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.

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. PBTrainers::CAMPER).
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 returns to the last Poké Center upon losing).

For example:

@>Conditional Branch: Script: pbDoubleTrainerBattle(PBTrainers::CAMPER,"Dave",0,_I("I enjoyed it."),PBTrainers::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 and have the same battle again, so 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.

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

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, and one is randomly chosen each time a battle occurs. The same transitions are available for trainer battles as wild battles.

However, trainer battles may instead display a VS. animation, an example of which is on the right. This animation will play instead of a random 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.