This article describes how to set up a rival trainer. It focuses on how to name the rival, and explains how to choose which version of a rival to battle with.
- This article describes how to create a trainer.
- Many games have a rival who uses a different set of Pokémon depending on which starter the player chose. This article sets the foundation for allowing these differences.
A rival is no different to any other trainer, and is defined in exactly the same way. See the article Defining a trainer for how to do this.
Typically, the player will encounter the rival at several fixed points during a game, and each time the rival will have a different team of Pokémon. Each instance of the rival appearing is completely separate to the others.
Since the rival will be battled multiple times during a game, as they will (likely) always have the same trainer type and name, each instance of the rival trainer will need to be set up as multiple versions of the same trainer, much like other trainers you can have rematches with. The difference here is that each battle with a rival version is in a different event in a different part of the game, rather than all in the same event. The article Trainers describes how to arrange a battle against a given version of a trainer.
Naming the rival
You may wish to allow the player to give a name to the rival. To do so, use one of the following scripts:
pbSet(12,pbEnterNPCName("Rival's name?",1,7,"","trchar004")) pbSet(12,pbEnterNPCName("Rival's name?",1,7,"Blue","trchar004"))
This will open the naming screen, which may already have a default name displayed. The "1" and "7" are the minimum and maximum name lengths allowed, and having "1" as the minimum means the player must input a name; 7 is the maximum name length only because of tradition. The last parameter is the name of a charset in the folder "Graphics/Characters" which depicts the NPC you are naming.
When the player has input a name, that name is saved to the given Global Variable (12 in these examples) - make sure that whichever Global Variable you use is not used for anything else, because the name needs to be saved in that Global Variable for the rest of the game.
You can display the name by putting
\v within a text message. However, this only works in regular text messages in events, not in the various messages used in battles (e.g. "Rival Blue would like to battle!"). To make the game use the correct name for the rival, you will need to edit the following array in the script section Settings:
RIVALNAMES = [ [:RIVAL1,12], [:RIVAL2,43] ]
Each line of this array contains a trainer type and a number. This means that if the player battles with a trainer with one of the trainer types listed (e.g. "RIVAL1"), and the Global Variable of the corresponding number contains anything (i.e. the player has named the rival), then that name will be used (e.g. "Rival Blue"). If the rival hasn't been given a name yet (i.e. the Global Variable is blank), then the name as written in the PBS file "trainers.txt" will be used instead as it normally would - this should be "???" or something similarly ambiguous, and will typically be done for rival versions which can be battled before they are named.
Since you have allowed the player to name the rival, that means their name will be replaced regardless of what it is (so long as they have the appropriate trainer type). As a result, you can use the names as written in the PBS file "trainers.txt" for other things instead, since they'll never be shown to the player. That is, you can create a trainer of type "Rival" and name "battle2grass", which is much easier to read when looking at/managing the rival versions. This only applies to rival versions who are battled after the rival has been named, of course.
Remember that this only affects the text displayed during the game. The scripts that start battles with the rival should still use the names from the PBS file "trainers.txt" (e.g. "???", "battle2grass") in order to start the correct battles.
This feature isn't exclusive to rival trainers. Any NPC can be named with this script, and any NPC trainer with a unique trainer type can use the custom name appropriately.
The rival appears at various points throughout the game, with an ever-changing party of Pokémon. For each appearance, their party will typically depend upon which of the starter Pokémon the player has chosen (with the rival using the starter that is strong against the player's). The article Choosing a starter describes how to create a variable that records which starter the player chose, which will later be used to determine which party the rival uses.
Each appearance of the rival should have three versions, one for each starter Pokémon choice, i.e.
|1||Professor's lab after choosing a starter||Grass starter|
|2||Route 22||Grass starter, Pidgey|
|Fire starter, Pidgey|
|Water starter, Pidgey|
You can quickly end up with a large number of rival versions, so be sure to keep track of them all so that you don't accidentally arrange battles with the wrong version at some point. One way to help keep track, as mentioned above, is to give the rival versions distinctive names (this only works if the player can name the rival, thus meaning those distinctive names will never be seen by the player).
Once the rival versions have been defined, you will then need to trigger a battle with the appropriate version. This will use the Global Variable that records which starter the player chose. After creating a basic trainer event for the rival, you should modify it to include Conditional Branches that determine which version of the rival should be used, and then trigger a battle against that version. Here is a simplified example of how to lay this out:
@>Conditional Branch: Variable [0007: Starter choice] == 1 --- 1 means the player chose the Grass starter @> Battle with the Fire version of the rival : Else @>Conditional Branch: Variable [0007: Starter choice] == 2 --- 2 means the player chose the Fire starter @> Battle with the Water version of the rival : Else --- The only other option is if the player chose the Water starter @> Battle with the Grass version of the rival : Branch End @> : Branch End @>
Note that each part highlighted on the left should be a set of event commands that run the battle script for the appropriate version of the rival. See the article Trainers for what this set of commands is.
- No one said you could only have one rival in your game...
- Have the rival change their battle sprite between different encounters. To do this, you will need to create a different trainer type for each sprite. If you let the player name the rival, be sure to include the extra trainer types in the array mentioned above, so that the rival's name is displayed for all of them. Multiple trainer types can refer to the same Global Variable for the name.
- You could follow Pokémon Yellow's example, and have the rival's Pokémon team depend not on which starter the player chose, but on the number of times the player defeats them first time around. To do this, use another Self Switch in the rival's event to help distinguish between the first battle and retry battles, and alter a Global Variable (that keeps track of first time wins) only if it is one. Later encounters will use this number to decide which rival version to use.
- Alternatively, have the rival's team depend on other things, such as the number of Pokémon the player currently has, the player's Pokédex counts, etc. Don't go overboard! Remember that you'll need a rival version for each possibility, and you could end up with hundreds of them if you're not careful (which is possible, but hard to keep track of).
- The rival's starter doesn't need to be stronger than yours. You can make his starter weaker or the same type as your starter.
- No one said your rival had to have a starter pokemon...