You want to be data-driven, rather than creating concrete sub-classes for every item. Maintaining that many classes is headache enough, but inevitably you'll fall into the "solution" of creating deep class hierarchies to re-use code, and this is an abuse of object oriented design.

What you probably want is a very tight, shallow group of classes that represent different objects by constructing them with different attributes or scripts. For example, most any kind of consumable item that has an effect can be represented by one class that calls into a different script. A loaf of bread that restores 10HP? A Tincture that refills mana? A cure-all that removes any negative status effect? Check, check, and check again -- 3 instances of the same class calling into a different "script".

Here, a script could mean a "proper" scripting language like Lua or Python, but it could also mean function pointer, functor object, an "Action" class, or lambda (anonymous function), depending on the language you're using.

If you do use a full scripting language, be aware that any scripts that are user-accessible and stored in plain text can be modified to give an enterprising user a means to cheat, say by making the cheap health potion fully restore health, so you should take countermeasures for the final release if you care.

You want to be data-driven, rather than creating concrete sub-classes for every item. Maintaining that many classes is headache enough, but inevitably you'll fall into the "solution" of creating deep class hierarchies to re-use code, and this is an abuse of object oriented design.

What you probably want is a very tight, shallow group of classes that represent different objects by constructing them with different attributes or scripts. For example, most any kind of consumable item that has an effect can be represented by one class that calls into a different script. A loaf of bread that restores 10HP? A Tincture that refills mana? A cure-all that removes any negative status effect? Check, check, and check again -- 3 instances of the same class calling into a different "script".

Here, a script could mean a "proper" scripting language like Lua or Python, but it could also mean function pointer, functor object, an "Action" class, or lambda (anonymous function), depending on the language you're using.

If you do use a full scripting language, be aware that any scripts that are user-accessible and stored in plain text can be modified to give an enterprising user a means to cheat, say by making the cheap health potion fully restore health, so you should take countermeasures for the final release if you care.

You want to be data-driven, rather than creating concrete sub-classes for every item. Maintaining that many classes is headache enough, but inevitably you'll fall into the "solution" of creating deep class hierarchies to re-use code.

What you probably want is a very tight, shallow group of classes that represent different objects by constructing them with different attributes or scripts. For example, most any kind of consumable item that has an effect can be represented by one class that calls into a different script. A loaf of bread that restores 10HP? A Tincture that refills mana? A cure-all that removes any negative status effect? Check, check, and check again -- 3 instances of the same class calling into a different "script".

Here, a script could mean a "proper" scripting language like Lua or Python, but it could also mean function pointer, functor object, an "Action" class, or lambda (anonymous function), depending on the language you're using.

If you do use a full scripting language, be aware that any scripts that are user-accessible and stored in plain text can be modified to give an enterprising user a means to cheat, say by making the cheap health potion fully restore health, so you should take countermeasures for the final release if you care.