Jump to content
  • Advertisement
Sign in to follow this  
Shabla0

RPG Item System Structure

This topic is 2587 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I'm currently trying to make an item system for an hypothetical RPG. This "project" is educational, I'm not making a game, I just want to work out the different systems of a game separately before going for the big thing. The language to be used is C++.

What I have in mind is pretty much like the Diablo 2 item system. Same kind of inventory, but the inventory have "infinite" space (scrollbar) and the items have a weight to limit the number of items on the player. Every item have a base, those bases obtained via data from outside files. Then to those base items can be applied a quality as follow :
Magic items are composed of a base + a prefix and/or a suffix, each giving the item special properties (ex. Base: Axe + Prefix: 3 attack + Suffix: 5 health = Axe that gives 3 attack and 5 health).
Rare items are composed of up to 3 prefix and 3 suffix.
Unique and Set items are composed of an arbitrary number of prefix/suffix (those items are also obtained via data from outside files).
That's for weapons and armors. Then there's usable items like potions and quest items.

I usually tend to jump right into code, but I decided to try and think it through before starting coding, so that I won't have to modify the whole architecture when I want to add a functionnality. Here's what I have so far :
itemsstruct.jpg
But I already see that it's not quite there yet, principally for the properties usable, destroyable, droppable, sellable, and equipable in Item.
Weapon and Armor: CAN BE: destroyable, droppable, equipable, sellable. CANNOT BE: usable (as in activated).
Misc (potions, keys, stuff that's only purpose is to be sold, items that don't do anything): CAN BE droppable, destroyable, usable, sellable CANNOT BE: equipable.
Quest items: CAN BE: usable. CANNOT BE: droppable, destroyable, equipable, sellable.

So I'd like to have some opinions on how to proceed, here the Misc class is obviously odd. If you have any example of class structure from existing games or any personal experience with such a system, I'd be glad to read about it !

Share this post


Link to post
Share on other sites
Advertisement
Very broadly --

Distinguish between static descriptions of items (Pristine items as they exist in the game "database") and instances of items (actual items as they exist in the game "world" or in the player's inventory). All the player's inventory needs to be is a reference to an item ID, perhaps quantity, and any instance-specific information (if you support that -- for instance, one sword might be blessed (or cursed), but that doesn't apply to all similar swords in the world.)

Prefer a shallow, data-driven hierarchy -- For example, don't further derive classes from Weapon for Knife, ShortSword, LongSword, Pike, Club -- They're all essentially the same, they have different ranges and power, but in the end its something you swing around. Nearly all types of weapons can be described as Melee weapons, Ranged weapons, or "Smart" weapons -- that's swingin' weapons, throwin' weapons, and triggered weapons, respectively. Nearly every other distinguishing feature can be easily described by data alone in most cases.

For behaviors (eg, a cursed blade that inflicts normal damage, + poison or mana damage) consider composite patterns -- In other words, very specialized or temporary effects are composed into a list of additional effects, probably in the form of function objects or anonymous functions, that are executed when an attack or other use is initiated. This is also known as a component model. Your MagicEffects member looks to be something similar, however that would also lead me to believe that you currently have no distinction between item descriptions and item instances currently.

Share this post


Link to post
Share on other sites
Thanks for your reply !
Like you said, my goal is to have the base items be data-driven. An item in data form would look like that (that's just an example):

<items quality="normal">
<weapon name="Sword" weight="10" equipable="1" destroyable="0" droppable="1">
<attackspeed>1.4</attackspeed>
<maxdamage>10</maxdamage>
<mindamage>4</mindamage>
<range>3</range>
</weapon>
<weapon name="Axe" weight="13" equipable="1" destroyable="0" droppable="1">
<attackspeed>1.1</attackspeed>
<maxdamage>13</maxdamage>
<mindamage>6</mindamage>
<range>3</range>
</weapon>
</items>
<items quality="unique">
<weapon name="Greatsword of Death" weight="18" equipable="1" destroyable="0" droppable="1">
<attackspeed>0.8</attackspeed>
<maxdamage>32</maxdamage>
<mindamage>23</mindamage>
<range>5</range>
<effect type="lifedrain" condition="onattack" chance="0.10" value="5"/>
<effect type="health" value="100"/>
</weapon>
</items>

Then for the magic and rare quality ones, prefixes and suffixes are generated randomly when the item is created with a "normal" quality item.
I've modified a few things in my diagram:
itemsstruct2.jpg
Sellable is determined by the value of the value member in item (the value is determined by the base type and the different effects on the particular instance), value can be set to -1 if the item is not sellable.
Equippable doesn't need a flag, since only the Weapons and the Armors are equipable, it can easily be checked when trying to equip something (in-game).
Misc doesn't need its own class, an item with no magic effect can be a BaseItem.
The InventoryItem itemRef member would actually be a reference to the instance of an item (my diagram soft didn't want me to add a & in the type).
In the current form, melee weapon are represented by Weapon (a dagger have a smaller range than a spear for example) and ranged by RangedWeapon.

Then again, should I store the in-game sprite/model for an item in the data from the BaseItems ? Or have a separate file associating a sprite/model with each item ?
For a ranged weapon, I have to keep track of the max ammo and the current ammo, should I add a field currentAmmo to RangedWeapon too, or is even the RangedWeapon not a good way to go ?

Any ideas would be appreciated :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!