[Please read my first reply before commenting. I forgot something really important]
From my knowledge, it’s really common practice nowadays to store all your items in a ModuleScript in some form of table, with sub tables storing the properties. I’ll warn you in advance, In the examples I’m using, primary keys are stored as numbers in a dictionary. A fairly simple example of the “GameItems” table could be:
local gameItems =
{
[1] = {“Wooden Sword”, 3, 5, 10} – Let’s say 3 = Rarity, 5 = Damage, 10 = Price}
}
But I imagine a lot of programmers are internally (or perhaps externally) screaming at this malpractice.
I can think of another way:
local gameItems =
{
[1] = {[“Name”] = “Wooden Sword”,[“Rarity”] = 3, [“Damage”] = 5, [“Price”] = 10}
}
Which has the added advantage of being able to access psuedo properties of the “object”. For instance, gameItems[1][“Name”] returns “Wooden Sword” and so they start to feel more like objects. Ultimately, this system feels like one that lends itself to OOP and I’m wondering if any advanced programmers are out there using abstract / virtual classes out there to implement their items. I imagine this to be a serious step up from the predescribed dictionary format.
I’m a fan of inheritance and I’m curious if other scripters would have input on this topic. I’m more than happy to be told I’m wrong, so long as some insight as to why is provided!
Thanks for reading,
Zarkonan_Zenheart / Luke