Good design for a recreation of pokemon

Question

I'm currently working on a group project to recreate the original Pokemon Yellow version in Java. We've only just started planning it out but they way we've drawn out the design right now is to have an abstract Pokemon class and have 151 (Count of the original Pokemon) classes that extend it, each one being a different Pokemon. Each class will be able to store data such as an ID, its name, the type of Pokemon it is (ie: rock/water/fire/etc), and the moves it can use and learn. It seems a little much to be creating 151 classes for the Pokemon but it also seems like a good way to limit coupling. As far as design goes is this a good way to go about doing it, if not what are some better methods to go about doing it?

Answer 1

You don't really explain why your group thought it would be a good idea to (hopefully) generate 151 classes, as "to reduce coupling" doesn't really make sense yet as you had no design or code and therefore no coupling.

Each class will be able to store data such as an ID, its name, the type of Pokemon it is (ie: rock/water/fire/etc), and the moves it can use and learn.

Change 'class' to 'instance' in that sentence and you get why you only need to create one Pokemon class: they all share the same properties. A derived class should add or implement properties (and / or methods) unique to that derivation.

If you define the properties of ElementType, Move and PokemonBase as such:

enum ElementType
{
    Fire = 1,
    Water = 2,
    Grass = 4,
    Rock = 8,
}

class Move
{
    int ID;
    string Name;
    ElementType ElementType;
    int BaseDamage;
}

class PokemonBase
{
    int ID;
    string Name;
    ElementType ElementTypes;
    List<Move> Moves;

    decimal HitPointsPerLevel;
    decimal AttackPointsPerLevel;
}

Then your various instances only differ in what is in those properties. Your class and code should not care about that. A Pokemon that has the type Fire can be stored in exactly the same class as a Pokemon of type Water: they only carry a different value of their ElementTypes property.

You can now fill a list of Pokemon instances with their properties and moves, for example by loading a text file or reading from a database, in a format you like.

You can solve all those problems when loading the Pokemon. In the data source you can store additional properties, which in the case of "the moves it can use and learn" can be a relational table (or flat text equivalent) where you join Pokemon.ID, Move.ID and Level to each other (if memory serves me right, they learn a new move on reaching preset levels), storing it in a list or dictionary property in your Pokemon class.

Or perhaps while designing you thought you needed a different class to implement the fighting system differently for each Pokémon. You don't have to, as by combining the various properties you can give each instance its unique properties.

---

The problem of course starts when you realize that you actually have two types of Pokemon: a 'blueprint' for all Pokemon that can possibly occur in the game, and an actual Pokemon that a player carries, which has a Level, HitPoints, and so on, all properties depending on or calculated through the Level or based on the fact that the isntance is "in the game". You can implement those properties in a derived class:

class Pokemon : PokemonBase
{
    int Level;
    int MaxHitPoints;
    int HitPoints;

    // Stats, for example
    int Attack { get { return Level * base.AttackPointsPerLevel } };
    int Defense;

    // This method directly applies the attack results to the incoming Pokemon, by reference.
    int Attack(Pokemon other, Move attack)
    {       
        int damageDone = (this.Attack * attack.BaseDamage) - defender.Defense;

        // TODO: http://bulbapedia.bulbagarden.net/wiki/Type_chart
        decimal modifier = CalculateEffectiveness(other, attack);
        damageDone *= modifier;

        other.HitPoints -= damageDone;      

        return damageDone;
    }
}

And all Pokemon instances can use it, without having to derive anything. The key is modeling your class and method so, that the actions you want to undertake on each of them can be applied to all combinations of types. You can also for exampla add a List<DamageOverTimeAttack> to a Pokemon to implement attacks that should stay active for a few turns, handling it in the Attack() method.

Now when a player encounters a new Pokemon, you might want create that from a Factory:

class PokemonFactory
{
    List<PokemonBase> _allPokemon;

    Pokemon GetPokemon(id, level)
    {
        blueprint = _allPokemon.Find(id);

        return new Pokemon
        {
            ID = blueprint.ID,
            Name = blueprint.Name,
            ...
            Level = level,
            ...
        };
    }       
}

Answer 2

do different pokemons should expose different APIs in your code? You should analyze this first.

Their ID, name & type can be stored in members. Now you could say that they have different abilities. So each ability should be a method. But you would be wrong. Doing so would prevent you from writing simple code when managing combat.

You should abstract an ability in a separate class. It may be defined by its cost & effect. Then each creature has a List of ability. Your 151 pokemons are defined in a service method or a config file. When writing features, the code should never care what type of pokemon is passed.

151 class for modeling something is a huge complexity cost. Most likely, you would have to use reflection to inspect data relevant to one particular class. This would be a misuse of the java class system.

Answer 3

I believe that if you have a base pokemon type, it may be easier to derive only the fire,water,electric types from the base class to limit the number of different classes needed. From that, you can set the relationships between the pokemon types without too much hassle, eg. Fire beats water and grass, weak to electric etc.

From there you can probably have a database or JSON/XML file that stores all of the stats of each pokemom, ID, name and which evolution it is from. This format could definitely help with grouping and classing the data without much overhead at all. The data can then be pulled by each pokemon type class once the program initializes by reading the JSON/XML file in sequence. A whole lot of that process can be automated once you've set up all of the stats in the file-store. From there, accessing each pokemon should be simples!

Answer 4

I'm not sure why you would need 151 separate classes to store the data for each Pokémon.

If I'm reading your intent correctly, you want to have 151 classes, one to store the base data for each species of Pokémon (ostensibly as static data for the class). But this is hopelessly inelegant. If you just need a structure to store the base data for each Pokémon, why not have something like a PokemonBaseData class?

You could structure it like this (forgive me if the syntax is incorrect, my Java is a little rusty):

public class PokemonBaseData {

    public int ID;
    public int type1, type2;
    public int height_cm, weight_hg;
    public int base_HP, base_AT, base_DF, base_SA, base_SD, base_SP;
    public Vector<Integer> usable_moves; // or move IDs
    // other properties as you desire them here

}

And have each Pokémon of a certain species ID refer to the PokemonBaseData class with a matching ID for the data inherent to that species.

Answer 5

Have you considered the flyweight pattern? That would allow you to avoid creating the 151 classes and still have the required functionality.