You might want to start reading a little bit about Object Oriented Programming (OOP) or a Component Entity System (CES). Like Hodgman said, all class objects are pointers.
Here's a rough first stab of an OOP approach. You might have an Item base class that would hold data and operations common to all Items. Things like its name, inventory icon, quantity, etc. Potion would inherit from Item so it includes all the Item data. and override the Item's Use() method. A Potion would have potion data like Heals 20 hp / sec for 40 seconds. Using a potion consumes it and applies the effect.
Your inventory system would have a list of Items. Since Potions, Swords, Scrolls, etc all inherit from Item, they ARE items. When your player right clicks on an item to "Use" it, the inventory system doesn't know if the clicked item is a Potion or Sword. It just calls the Item's Use() method. However, the clicked item knows which specific kind of item it is. "I'm a potion, so I'll reduce my quantity by one and apply my effect". If the Item was a sword, it might try to equip itself on the player.
And.... I should really stop answering questions when I first wake up in the morning. I see that's not the question you're asking, but I'm leaving this post up in case someone else finds it useful. So...Back to your original question. How do design your potion class...
I'm going to change the name of "Parameters" to CharacterStats for the rest of this discussion. (Option 1) If your Potion has a CharacterStats member variable named affectedStats, then you can have a potion that does anything. It's simple and powerful, but a little bit clunky. But if you have a simple healing potion that gives 20 health, you'll still have a copy of all the other stats Strength, Dexterity, Armor Class, etc. In all honesty, it's probably good enough for now.
Another option (option 2) is to code up a PotionEffect system. Create a StatAdjustmentEffect and an enum(eration) of your CharacterStats. The StatAdjustmentEffect has the AffectedStat and the Adjustment to make. When applying the potion's effect, you'd map the enumeration value over to the data of the CharacterStats class.
enum CharacterStatEnum
{
Strength,
Dexterity,
// more stats...
Health,
ArmorClass,
}
public abstract class PotionEffect
{
public float Duration {get;set;}
// Each potion effect child class implements ApplyEffect.
public abstract void ApplyEffect(GameCharacter potionDrinker);
}
public class StatAdjustmentEffect : PotionEffect // Base class for all potion effects
{
public CharacterStatEnum AffectedStat {get;set;}
public int Adjustment {get;set;}
public override void ApplyEffect(GameCharacter potionDrinker)
{
switch(AffectedStat)
{
case CharacterStatEnum.Health:
potionDrinker.Health += Adjustment;
break;
// More case mappings.
}
// Keep up with these effects somehow. could attach them to the potionDrinker or potionEffectManager class.
if(Duration > 0)
throw new NotImplementedException();
}
}
Then your Potion class can have a List<PotionEffect>. It's powerful, clean, but more complex. However, this system allows for an easier expansion into things like an Invisibility potion.
Another option (option 3) would be to include some sort of scripting library, and a potion can have the script that should run when the potion is drunk. This could be argued to be more or less complex than option 2, but you won't know until you get into it.
These are the types of design problems that make programing so fun ... and frustrating. There isn't just one correct answer and even Option 1 should be seriously considered. It might be simple enough to get the job done and you can move on to features that add more coolness than a robust potion featureset.
- Eck