I don't see why you would want to use a distinct class per Pokemon, especially not after what you've shown so far. It's probably much better to use the Prototype pattern (having a template instance and cloning it - e.g. you'd have one Pokemon instance for each Pokemon type, and if you want a Pikachu, you'd clone the Pikachu instance).

An alternative would be to use the Flyweight pattern (each Pokemon has a reference to a PokemonType instance - the Pokemon object would hold data such as position, XP and current HP while the PokemonType object would hold shared data such as type, name and max HP).


As for templates, when creating an instance of your templated struct, you do have to specify what type you're using it with. For example, take std::vector: you have to specify what it will hold beforehand (std::vector<std::string> names). Templates generate code at compile-time based on what types you've used them with. I'm don't think that's really what you need here though.

Having that said, what exactly are you trying to achieve here? Can you give a high-level explanation (i.e. what's the purpose of all this code)?

So, there's Pokemon types - Pikachu, whatever - and there's actual Pokemons (my Pikachu, your Pikachu). Pokemons of the same type may vary a bit in stats, but in the end you can treat all of them the same - that is, all Pokemon can be given, for example, move and attack orders, and all of them have the same kind of stats, right?

Prototype should work fine here - you'll want to customize it a bit to take the stat variations in mind (you may want to store specific variation information somewhere, and take it into account when copying a prototype instance).

If some Pokemon have radically different behavior, then (run-time) polymorphism may come in handy. Basically, you have a class (Pokemon) with virtual functions (applyDamage, move, attack). Pokemons (Pikachu) with different behavior can inherit from this base class, and provide their own implementations for these virtual functions (Pikachu could provide a custom applyDamage function). When you have a pointer-to-a-Pokemon and you call applyDamage on it, then if the actual object you're pointing to is a Pikachu, the Pikachu version of applyDamage will be called instead of the Pokemon version. So, regardless of the actual type of the object you're working with, you can still treat it as a generic Pokemon.

However, most differences can likely be modeled with some additional variables, so don't think you have to create a different class for each Pokemon type. It's an option, but not the only one. For example, in a strategy game an artillery unit can be implemented by adding a minimum and maximum range to the Unit class, instead of creating an ArtilleryUnit class.


I would not create a struct that holds pointers to member variables of another object. At most it should hold a pointer to that object. Giving away pointers to internal data is a bad idea. It'll make it very difficult to enforce constraints, such as limiting HP between 0 and the maximum HP for that Pokemon. If you have a pointer to that HP variable, you can set it to anything you want. If you only have a pointer or reference to the Pokemon object it belongs to, you can call an applyDamage() function and you can be certain the Pokemon is not left with an invalid HP value. Additionally, that function could inform the Pokemon's owner if the damage causes the Pokemon to die, or anything else that should happen. So, don't expose such variables directly. Work through an objects interface instead.


Oh, note that, in C++, classes and structs are pretty much the same (the differences have to do with default access and inheritance levels, private and public respectively). Also note that, when a class has a virtual function, it's destructor should also be marked as virtual. Finally, templates do provide some sort of polymorphism, but only at compile-time. Useful when you know what types you'll be working with but you don't want to write the same code for multiple types.