How would you implement an item system?

[cbk1994]

Some questions to keep in mind as you make an item system:

Originally Posted by cbk1994

Assuming you go with a MUDLIB a few things to keep in mind:

• Is it going to be a full MUDLIB? In other words, are you going to have it possible to dynamically create new instances of unique items, or are items static and created once, then players have a quantity of that item?
• How are you going to store the item data? If you go with a full MUDLIB, your best bet is probably text files, but there are also other options like SQL which may work for you. If you go with a non-MUDLIB and just use text files (or other storage) for items, you will need a way to store the amount of items players have (SQL, client flags both work well)
• Are you going to cache the item database in memory? This improves performance, but is only really possible when not using a full MUDLIB.
• If you go with a full MUDLIB, how will you handle stacking? For example, if you create 5 platinum coins, these should technically be 5 unique objects, so they can't stack in your inventory.
• How will you deal with getting item data clientside? Will you send it all on login or send it as needed and store it clientside then?

If you're not going the MUDLIB route and won't be creating objects on-the-fly, keep it simple. Store the item data in human-readable files, and have a script parse these files and store them as TStaticVar objects on serverside in a cache (in memory). Unless you have a ridiculous amount of items this won't use too much memory, and will limit the amount of disk IO you do.

[MrDunne]

Originally Posted by cbk1994

Some questions to keep in mind as you make an item system:



If you're not going the MUDLIB route and won't be creating objects on-the-fly, keep it simple. Store the item data in human-readable files, and have a script parse these files and store them as TStaticVar objects on serverside in a cache (in memory). Unless you have a ridiculous amount of items this won't use too much memory, and will limit the amount of disk IO you do.

Thanks for the response.

Yeah, I'm thinking of going with SQL for persistence since it offers a good structure for what I need. When ever an item is created, it will be cloned (conceptually anyway). This will allow users enhance and improve their items at free will.

I was thinking this:

Players have characters (max of 3, but potentially more).
Amongst other things characters can have many items.

Items have behaviour (probably set up some interface for behaviour)
Items have stats.

Now to get what I want with regards to unique stats, in the cross reference table when I do the many-many between the items and the players, there will be columns which are basically the stats of the item which can be modified from item to item.

Hopefully from the above, you can make out the relationships between the data because, if you're seeing what I'm seeing, you'll see that a trade could be as trivial as changing the appropriate ID in the many-many XR table.

I just don't think flat files will allow me to do this as effectively. The only thing I'm worried about is having a ridiculously rigid DB schema and aiming for supreme flexibility from the get go is a mistake.

In regards to item stacking, that is yet to be thought of but a simple boolean or some rules should do it. I think the boolean should do it but there's probably a better way. I need to do some more thinking on that.