I have spent a lot of time brainstorming ideas for items in my rogue-like, then I remember, I've only played one rogue-like before. For all I know, I could be doing everything wrong! Currently in my game, you obtain items in a shop. I plan to add random NPC encounters, more shops, etc.

Right now, there are basic stat boosts like +max health items, or ones that you use on demand that have a cooldown, like, a Molotov, a knife, food.

I guess what I'm trying to ask is, are there any tips or changes that I can use to enhance my item system? should they function differently or add rules to the game? anything helps thanks!

pixelamped said:
rouge-like

I believe that's “rogue-like.” Rouge means red, so “rouge-like” would mean “reddish.”

@Tom Sloper Oops! Thanks for telling me!

How you do it will depend on the details of your game.

A common approach is that there is a struct/class which has information about each item. That info could be the base item plus any modifications. For example, it might look something like:

{
   Item: 43 (Lookup name: battle-axe)
   BCU status: Uncursed
   Rust level: 2
   Enchantment: +1
   Charges: 0
}
{
   Item: 19 (Lookup name: wand of magic missile)
   BCU status: Blessed
   Rust level: 0
   Enchantment: 0
   Charges: 9
}
{
   Item: 27 (Lookup name: quiver of arrows)
   BCU status: Uncursed
   Rust level: 0
   Enchantment: 0
   Charges: 20
}

You could add whatever attributes you need to track onto every item, such as a last used time if that's needed for your game. Subtract it from now to see how long ago it was used for any cooldown effect.

You'll have another table somewhere with each item type containing the base information that applies to all weapons of that type, such as if they're made from wood, iron, silver, leather, whatever matters in your game, base cost, base weight, base damage to small creatures, base damage to large creatures, attack range, (e.g. dagger and sword might be 1, polearms might be 2, slings might be 4, bows might be 7…) and whatever else needs to be known about all items generally.

@frob My game is in Godot 4.1 so I'm using resources each with their own metadata to be their information. Each resource has its own ID/int key in a BIG dictionary to be sourced and displayed in the shop and other places. When you collect one, it sources from a group with a dictionary. Each item has its ID the same as a key that calls a function with all the stat changes and stuff.

Now that I'm saying it out loud, it sounds like each item having its own resource (Basically a blank node) is a lot of unnecessary space being taken up.
Hmmmmm… :/

Usually they're just a bunch of massive tables.

You've got a huge table with all the items in it:

orcish dagger	4	10	12	IRON crude	2	d3	2	d3	2
dagger	4	10	30	IRON	-	2	d4	2.5	d3	2
silver dagger	40	12	3	SILV	-	2	d4	2.5	3	2
athame	4	10	0	IRON	-	2	0	d4	2.5	d3	2
elven dagger	4	10	10	WOOD	runed	2	d5	3	d3	2
worm tooth	2	20	0	NONE	-	0	d2	1.5	d2	1.5
knife (shito)	4	5	20	IRON	-	0	d3	2	1.5	d2	1.5
stiletto	4	5	5	IRON	-	0	d3	2	d2	1.5
scalpel	6	5	0	METL	-	2	d3	2	d3	2
axe	8	60	40	IRON	-	0	d6	3.5	d4	2.5
battle-axe	40	120	10	IRON	double headed axe	0	d8+d4	7.0	d6+2d4	8.5
...

You'll have similar tables with armor, shields, helmets, rings, wands, and whatever else you've got in your game.

Then you've got collections of things actually spawned into the world with the object instances and their modifiers in it. You only need to know the index to those earlier tables, like in my earlier post items 43, 19, and 27.

@frob Are you saying that I should not have a big table, but a class with the items in their own table/list or class?

A data table, an array of structures, a collection of classes, whatever format works for the game. It is typical to have a bunch of them.

In many roguelikes there are a variety of tables define the base rules for objects. There is a smaller set of modifiers for the actual objects in the game.

That is, item 43 in the weapon table might be a generic battle axe. It has all the statistics of a battle axe. Item 19 might be the generic data for a wand of magic missile. Item 27 might be the generic information for a quiver of attows. This way you don't have to duplicate it every time you create a new one, you can just reference item 27 and the code can look it up on the data to see 27 is the arrows.

A different array, structure, container, etc, contains details about the ones that are in the game universe. A general quiver of arrows might have a charge count of 20 arrows, use one and the charge count decreases. A magic wand might start with 10 use charges. A genie in a bottle might start with 3 use charges. The object might be enchanted to +5 damage, might be damaged with rust, might be blessed or cursed, whatever. That blob of data gets created when the object is spawned into the world, it gets moved around when an object is moved to inventories, moved elsewhere if the item is placed in a chest on the map, moved if it is dropped in a shop, etc.

It is this smaller blob of data that your post asked about, it says the details of the item use and upgrade status. Only store what is modified relative to the base object.

@frob So your saying that I'm not doing anything right or wrong necessarily? I'm just worried about, “what's the most streamlined I can make this?”. I want to have the cleanest code and the most storage space saved, ya know?

And to be honest, I should have worded my first question better. It was more of like, “What's the best way to create engaging upgrades that complement each other?” in a more of a game design/theory way.

Anyways, thanks for bringing this up too! It helps a lot!

Correct, not a right or wrong approach. Some are more easy to implement than others, some are a better fit for specific languages and tools.

You asked about typical, and typical is table-based configuration. Sometimes that is tables in source code, sometimes that is tables in data files, sometimes other variations, but lots of simple tables are the normal approach.

If your tool happens to show them in a graphical format where each table is called a collection and a row on the table is broken out as an array entry, it's still fundamentally the same approach.

With this approach adding an item in the world is easy. Find the table that describes it, add an entry, and it just works. If you want a new wand, maybe “wand of ice”, add a new entry in the wand table, it's a RAY type wand, it travels a distance of 15, it defaults to 8 charges, it does damage equal to [LVL]*D6, and has an effect COLD. Add another wand, maybe “wand of cold” that has a weaker than “wand of ice”, add another entry in the wand table, it's a RAY type wand, it travels a distance of 7, it defaults to 8 charges, it does damage of [LVL]*D3, and also has an effect COLD.

Rougelikes built this way tend to be quite extensible with relatively few building blocks. You'll have a few typical effects and their resistance (magic, fire, cold, shock/electric, acid, poison, …) a collection of effects (stun, confuse, blind, sleep, paralysis, sick, …), and similar broad attributes letting you mix and match as the game is built.

Often they multiply. You can create one new effect/resistance combination and it multiplies by everything else. One new effect means a new effect-related item in every type of weapon, every type of armor, and a new wand, ring, potion, and scroll related to the effect. That one new effect might result in 30+ new item variants in the game. Adding “COLD” might create 3 new potions (minor cold resistance, cold resistance, major cold resistance), a new ring of cold resistance, a cold resistance intrinsic for monsters, a few scrolls like “Blizzard”, “Arctic Chill”, “Freezing Orb”, a big collection weapons like ice knife, ice sword, ice grenades, ice-glyph arrows, some new spells like cone of cold, frost ray, armors that grant ice resistance like a fur cloak, a fur-lined helmet, fur boots, and fur undergarments, and so on.