Looking for a little assistance with item class design...

I have been working on my rpg game for a long time, which started just as a test of my abilities, but now I am really trying to get it looking and working good.

I have the graphics engine down(pretty much bug-free), but the rest of the game code looks butchered.

I am working on random bits and pieces adding functionality,etc where I think it may be necessary.

Now onto my question. I have a very basic item design. Pretty much every item is the same as every other item, just the effect stack is different.

Code:

class Item
{
private:
  int iValue;
  int iModelID;//used for rendering
  boost::ptr_vector<bEffect*> vEffects;//Everything an item can or cant do is in this.
  
public:
  //all the other stuff
};

What i am wondering is how to design a item class/effect class/etc/etc to work similar to the Diablo 2 items. Any item can have any effect(I will modify this a bit), only difference that i will have really is each item regardless of type only takes up one inventory slot.

Any help or insight will be greatly appreciated.

So where are you having an issue? Just make bEffect an ABC.... What is the problem?

I would use an interface for Item and then derive your specific Item impl from the interface. This would allow you to plug in items that might have different impls easily.

I really cannot help you since I do not know much about your items or exactly what it is you wish to do. A little more information is needed.

I apologize for lack of information.

Okay, maybe this will provide a little more insight.

all items should be derived from a interface class(i think).

Yet I am unsure how to implement the various item types.
Question 1:
Do I derive just a very general weapon class from the item interface, and then derive
subclasses from that to represent 1-hand slash, 2-hand slash, 1-hand blunt, ranged, etc, etc,
or am i approaching this all wrong.

Question 2:
same as question one but with other items such as ( reagents, potions, trade items, etc, etc )

Question 3:
I am also unsure as to how to implement the effects. Seeing as how effects can range from HP bonus, HP recovery, detriment effects, timed effects(buffs, debuffs, etc ), to cast on strike stuff.
Edit: I am kinda thinking that effects should be hard-coded to do what they need to do, then possibly use scripting to implement more advanced effects?

For Q1 & 2, it's better if you derive it all from Item, and then probably Weapon, and if you can, make several more classes that can be used as base classes - for example, 1Hand, 2Hand, Slash, Blunt. I don't know what you can implement and what would be practical, but the more you have, the less code you need to write.
When you derive everything, you can specialize each class to fit their special needs.

And as for Q2, probably derive from Item and specialize classes from there with different properties. Perhaps more of them such as Healing, etc.

So basically you want to know how to structure your Item class/es for game development. Well now that you mention Diablo II, you might look further into how they did it. There's been a lot of progress into reverse engineering D2, and you can get an inside look into the memory, stack, hex, asm, packets, etc. If you load up a trainer you can get an idea of how they laid it out. I don't think they subclassed, but rather just had a property for the item type. They also had properties for the item requirement, item drop level, item quality (set, unique, etc), item durability, list of attributes,. The reason using a property over inheritance could be because it's an old game and OOP wasn't a major factor, or because when you store the list of items in a database you use a field, and that is easier to convert into a property than using a switch to determine the subclass.

It's easier to design the code after you setup a database. You want to be able to add/remove items, item types, item qualities, etc. on the fly. So lets say you have a SQL table for items, a table for effects, a table for item types, a table for item qualities (which in turn have fields for other attributes). The point here is just setup your code as a clone of how your database is setup. Hopefully in a generic, relational, way.

You can do this for everything, and it works out to perfectly map every different attribute about the game. To the point you can change the graphics and the database attributes so you have an entirely new game. Think of it like a tree of game settings, with branches of branches of different aspects about the game. All you do is parse the database, just as you would parse a graphics model (wrapper).

Code:

class Item
  id
  title
  quality
  type
  quantity
  requirement
  durability
  level
  required_level
  attributes[]
  effects[]

  const()
    quality = new ItemQuality(... sql here ...)
    type = new ItemType(... sql here ...)

class ItemQuality
  id
  title
  color

class ItemType
  id
  title

class ItemEffect
  id
  
  // callbacks whatever - can load and parse script files here, eg. /effects/9357334.ie
  function Hit
  function Move

class ItemAttribute
  id
  title
  value

Code:

table game_items
  field item_id
  field item_title
  field type_id // this links to the record down below
  field quality_id // so does this
  field item_level
  field item_required_level
  field item_quantity

table game_item_attributes
  field attribute_id
  field attribute_title
  field attribute_

table game_item_attribute_list //this is how you replace parsing a comma delimited string into an array
  field item_id
  field attribute_id

table game_item_types
  field type_id // right here
  field type_title
  field type_

table game_item_qualities
  field quality_id // and here
  field quality_title
  field quality_color

table game_item_type_icons
  field icon_id
  field icon_filename

---------------------------------------------------------------

insert into game_item_type_icons set icon_id = 3, icon_filename = "twohandedsword18943.jpg"

insert into game_item_types set type_id = 2, type_title = "Two-Handed Sword", type_icon = 3

insert into game_item_qualities set quality_id = 1, quality_title = "Unique", quality_color = "F0F0F0"

insert into game_items set item_id = 5, item_title = "Backlash Fist", type_id = 2, quality_id = 1, 
item_level = 51, item_required_level = 45, item_quantity = 1

// grab an item from the database
$item = select * from game_items where item_id = 5 
left join game_item_types on game_items.type_id = game_item_types.type_id 
left join game_item_qualities on game_items.quality_id = game_item_qualities.quality_id

// grab the item effects
$effects = select * from game_item_attribute_list where item_id = $item['item_id']

// should also find a way to grab the item icon

// these can all be merged into ONE database query

I use IDs, D2 uses "item codes" which are like EGB, JUV, BPO and such.

When it comes to relational databases you can parse a string into a list, or you can use an entirely new table which acts like a huge multidimensional array (just choose the element with the correct item id).

If you look into World of Warcraft or any other MMORPG private servers you will get a good idea for what I'm talking about, how to setup an item database, and how to parse the database into your game.

Note you don't have to use SQL, you could use a flat-file database (custom), or hardcoded arrays. It makes no difference.

If you were using a scripting language, or building objects generically, you wouldn't even have to design more than one class - Item.