Pokemon Essentials - Advanced Topics

Peter O. (http://upokecenter.com/projects/pokestarter/)

This section contains advanced topics for Pokemon Essentials, that normally require a knowledge in Ruby and scripting.

Contents

Scripts

Here are details on some of the scripts found in Pokemon Essentials. (Some of this documentation is currently out of date.)

PBAbilities

Constants for each ability in the game. To get the name of an ability, call PBAbilities.getName(item). This script section is automatically generated.

PBMoves

Constants for each move in the game. To get the name of a move, call PBMoves.getName(item). This script section is automatically generated.

PBItems

Constants for each item in the game. To get the name of an item, call PBItems.getName(item). This script section is automatically generated.

PBSpecies

Constants for each Pokemon species in the game. To get the name of a species, call PBSpecies.getName(item). This script section is automatically generated.

PBMove

A lightweight class for storing information on a move. Call PBMove.new to create the object. After creating the object the following methods are available:

This class shouldn't be edited.

PokeBattle_AI

Mechanism for intelligently choosing a Pokemon's moves. This is done by assigning a score to each move based on whether it can or should be used and depending on the situation.

PokeBattle_ActiveSide

Structure for effects specific to only one side of a battle. Not meant to be edited.

PokeBattle_DamageState

Structure for holding the results of damage calculation. Not meant to be edited.

PokeBattle_Move

Structure for holding information about moves. This script also contains damage calculation and accuracy-checking routines.

PokeBattle_Battle

Class for Pokemon battles. This is the heart of the battle system. Battles are implemented by dividing each round of a battle into a command phase, attack phase, and end-of-round phase. Also contains methods for using items and throwing Balls.

PokeBattle_Confusion

Implements a pseudomove for confusion damage.

PokeBattle_Effects

Contains methods for inflicting common in-battle effects such as stat reduction, confusion, and status problems. It is part of the PokeBattle_Battler class.

PokeBattle_MoveEffects

Contains classes that derive from PokeBattle_Move. These classes implement effects specific to certain kinds of moves.

PokeBattle_Scene

A simple implementation of a battle scene. It is mainly now used for debugging purposes.

PokemonItems

Contains functions that implement the use of items out of battle.

Utility functions:

PokemonField

Contains various functions called in the field.

Constants:

Functions:

PokemonLoad

This script loads games and starts new ones. There are two parts to this script: a class called PokemonLoad, which is the backend, and PokemonLoadScene, which is the frontend. This latter class implements the user interface of the load screen. PokemonLoadScene must implement these methods:

PokemonLoad, as the low-level backend, is generally not interesting to edit.

PokemonMenu

This script displays the menu. The class PokemonMenu_Scene is the frontend, and the class PokemonMenu is the frontend. PokemonMenu_Scene must implement these methods:

PokeBattle_Pokemon

This class stores data on each Pokemon. Refer to $Trainer.party for an array of each Pokemon in the Trainer's current party. These methods are defined on the PokeBattle_Pokemon class.

PokeBattle_Trainer

This class stores data on a Pokemon Trainer, such as the Trainer's party, money, badges, and Pokedex status. The global variable $Trainer stores the player's Trainer object.

PokemonStorage

Implements the Pokemon Storage System.

PokemonTrainers

Implements support for Trainer battles.

PokemonWeather

Overrides the built-in RPG::Weather class. Here are the defined weather types:

Compiler

Converts setting files to an internal format used by the game. Should not be edited.

PokemonUtilities

Contains various utility functions.

Advanced Configuration Files

These configuration files are to be edited only by advanced users. The Poemon Essentials editor contains features that make editing these files largely unnecessary. This section is only meant to give further detail on the format of these files.

PBS/metadata.txt

The file is divided into sections, and each section's title is the ID of the map whose metadata the section describes (check the middle of the status bar to find a map's ID.) The section title is enclosed by two square brackets like this: [011]

Each section can have any number of entries. The entry's name and the entry's value are separated by an equal sign (=).

The map ID 000 is reserved for global metadata not specific to any map. For the section titled [000], possible entry types are:

Other map IDs are specific to a map. For sections with titles other than [000], the possible entry types are:

PBS/encounters.txt

This text file is for placing encounter data for each map.

For each section of the file:

Depending on the encounter type, the number of entries required varies:

PBS/connections.txt

Pokemon Essentials supports maps that connect to each other seamlessly. This file defines connection points of maps with others in the game. This is done by associating a point on one map's edge with points on another map's edge. Due to the nature of connected maps, maps cannot overlap. Each line of this file contains six fields, separated by commas, as defined below:

The restriction here is that the east edge of a map can connect only to another map's west edge, and vice versa. The same applies to south and north edges.

More formally, each line defines a point on one map relative to another point on another map. Each line is in the format A,B,C,D,E,F where:

In the example "4,0,0,5,-26,0", the first two zeros represent the point (0,0) within map 4, and the -26 means that the point is located 26 spaces west of map 5's top left corner.

PBS/trainernames.txt

This file stores data on each trainer type. This file is divided into lines, and each line is divided by fields separated by commas. These fields are defined below.

PBS/trainers.txt

This text file stores data on each Trainer in the game. This file consists of one or more trainer sections. Here is the format of each trainer section.

Internal Structure of Item Events

Items have two event pages. The first event page has an Action Button trigger and the following structure:

@>Conditional Branch: Script: Kernel.pbItemBall(::PBItems::POTION)
  @>Control Self Switch: A =ON
  @>
 : Else
  @>
 : Branch End
@>

The second event page has a condition of "Self Switch A is ON", has no graphic, and is blank.

Putting a Pokemon instead of an item in the event is easy. Just use something like: "Kernel.pbAddPokemon(PBSpecies::MEW,20)" in the conditional branch.

You can also make the item event hidden. In the first event page, select "Through" under Options, and set the Graphic to "(None)". However, it should be named HiddenItem so that detectors and other mechanisms can look for it.

Scenes in Pokemon Essentials

The various screens used in the game system follow a different pattern than RPGXP's scripts. Each screen is separated into two different classes--one to handle the logic, and another to handle the appearance. The advantage of this separation is that the screen's appearance can change without impacting its logic, and vice versa. For instance, the basic tasks of switching and giving items to Pokemon will be same regardless of the scene's appearance.

The code below is a skeleton of a scene in Pokemon Essentials. You should read the comments carefully.

#
# Scene class for handling appearance of the screen
#
class MyScene
  #
  # Processes the scene
  #
  def pbScene
   loop do
    Graphics.update
    Input.update
    pbUpdate
    if Input.trigger?(Input::B)
     # Process the B button here
     break
    end
    if Input.trigger?(Input::C)
     # Process the B button here
     break
    end
   end
  end
  #
  # Update the scene here, this is called once each frame
  #
  def pbUpdate

  end
  #
  # End the scene here
  #
  def pbEndScene
   # Fade out all sprites
   pbFadeOutAndHide(@sprites) { pbUpdate }
   # Dispose all sprites
   pbDisposeSpriteHash(@sprites)
   # Dispose the viewport
   @viewport.dispose
  end
  def pbStartScene
    # Create sprite hash
    @sprites={}
    # Allocate viewport
    @viewport=Viewport.new(0,0,Graphics.width,Graphics.height)
    @viewport.z=99999
    # Create sprites, planes, and windows using the 
    # pattern below.  Refer to sprites using
    # '@sprites["sprite1"]', etc.  Be sure to use
    # '@viewport' when creating the sprite
=begin
    @sprites["sprite1"]=Sprite.new(@viewport)
    @sprites["sprite2"]=Plane.new(@viewport)
=end
    # Fade in all sprites
    pbFadeInAndShow(@sprites) { pbUpdate }
  end
end
#
# Screen class for handling game logic
#
class MyScreen
 def initialize(scene)
  @scene = scene
 end
 # If pbStartScreen includes parameters, it should
 # pass the parameters to pbStartScene.
 def pbStartScreen # (param1, param2)
  @scene.pbStartScene # (param1, param2)
  # Calls pbScene currently, but can instead be made
  # to call multiple functions instead, such as pbDisplay
  # for displaying a message, pbCommand for confirming
  # a choice, pbRefresh for updating the screen, etc.
  # The important thing is that this screen
  # should not be responsible for controlling the look of
  # the scene, that's the scene's responsibility.  Generic
  # methods such as display, command, and refresh are good
  # choices for methods.  To call a method on the scene,
  # like pbDisplay, use "@scene.pbDisplay", just as it's
  # done here.
  @scene.pbScene
  @scene.pbEndScene
 end
end
#
#
#  Here is how a script would initialize MyScene:
#  
#  pbFadeOutIn(99999){           # Optional
#    scene=MyScene.new           # Create the scene
#    screen=MyScreen.new(scene)  # Create the screen
#    screen.pbStartScreen        # Initialize the scene
#  }                             # Optional
#