So I'm working on a roguelike and I've run into a bit of a wall. I need to get the item system implemented but I'm running into a situation that I cant seem to come up with a solution for.
So using a library I have OOP in lua. It's not the strictest OOP but its definately workable.
However I seem to not be experienced enough or simply not familiar how to handle a situation where I need to initialize many new objects at runtime.
Each item can be of three variety: consumable, weapon, armor. Right now I have an object class which contains functions that interface with the inventory system and the tile map allowing them to be placed. And then armor, weapon, and consumable inherit from the item class.
Ive done some research and it seems that other roguelikes use a data file and using a standardized format parse the data file at launch.
I guess I'm just looking for an explanation of how this would be implemented architecturally in code.
Roguelike Item code architecture
I would advice against modelling the difference between items with inheritance.
Try to break down the items into what they "do", instead of thinking of them in terms of what they "are"
You might find you need only one class "Item", which has different properties.
One property defines how you "use" it, it would in your case be "consumable", and "equipable".
Another property defines what happens when you use it.
consumable could give the buff "reduce hunger" (if food) or "grant invisibility" (if potion), etc.
equipabe with the buffs "increase attack dmg" , or "increase defence".
A third property defines what graphics to use, and what animations or effects happens when it is activated.
Then a forth property contains a string with item description, this is where the item gets its "flavor", and what really definies what it "is" in the virtual world.
That part happens mostly in the head of the player (This is Amazing Fire Sword that smithes all my foes with the Fires of Hell when I use it), and does not have to be modelled in code.
(meaning, you don't need an AmazingFireSword class)
Etc.
This way, you can create a data format with lots of item descriptions, which set the different properties, and then just load it in.
From the games perspective it is all just "items"
Yep, OO inheritance is boxing yourself into a corner for a roguelike, games normally built on vast complexity of mechanics instead of graphics.
In the past I have used arrays of attributes to define everything. So my armor might have stats like:
Defence, Slash, 5
Defence, Stab, 3,
Defence, Shock, 2
Defence, Fire, 3
Wearable, Torso, nan (Or similar)
Backpack, Weight, 15
and in similar way a weapon might have stats like
Attack, Range, 1
Attack, Slash, 10
Attack, Shock, 3
Equipable, OneHanded, nan
Backpack, Weight, 5
Means everything lives in similar "shape" and you query the attributes to see what capabilities etc that an item has. The nature of how you store stuff depends on how complex your rules engines are in your roguelike.
I would agree with the answers above as well, the OPs way of (as I understood it) having the item-object actually having functions which directly interfaces with the map/inventory etc sound very backwards.
An item object should be the item and only that, what I mean is that you should be able to use/transfer the item to any other higher order class etc which might want to use it (i.e. the item-object should be the same object regardsless if its contained in a character, a map list of dropped loot, a highscore table of best item etc..) Let the class/func whatever that actually handles the object take care of the rest, sort-of..
Also, if you plan to have a large amount of very different items I would suggest (and I think this is just what WosNZ meant) that instead of having fixed item variables like Damage, Crit. Chance etc just have an array of floats, (or int or whatever suit you game design the best) and define which array location would correspond to what stats
Example: For a sword item.data[0] would be damage (defined as a const somewhere for example (item_itemdata_sword_damage = 0) ) but if the item-type is an armour, then item.data[0] could correspond to armour-value instead (item_itemdata_armour_armourvalue = 0). This way you don't need multiple variables in the item which are never used.
BG109 - Yes I was hinting at using a set of attributes in each thing to describe.
So in the armor example it would have all the attributes
Defence, Slash, 5
Defence, Stab, 3,
Defence, Shock, 2
Defence, Fire, 3
Wearable, Torso, nan (Or similar)
Backpack, Weight, 15
And hence would provide "5" protection against slash, 3 against stab etc. This way it is easy to add a new damage type and add it to items as it is just another attribute
Instead of array index for specific things I tend to query the collection for all applicable properties and make them all apply, this allows you to stack a number of effects. So a sword might do slash damage and also fire and shock damage on top.
As always, there is no correct way as everything is a trade off of speed/flexibility etc :) My lists I query adds overheads in walking the attribute bags but the flexibility pays off later when changes are made etc.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
