How would you implement an item system?

[MrDunne]

Not asking for code here nor am I asking to be spoon fed. I'm just wondering what the general consensus would be on implementing an item system in GScript?

For example, how would you implement persistence and how would you implement it so that you're not performing disk reads all the time?

I have a fairly good idea in which to do this, using the SQL capabilities and maybe writing some kind of simplistic object-relational mapping for this (if GScript is powerful/fast enough). For behaviour, I'd probably have some common interface which weapons would need to implement. Either that or a way to define callbacks with arbitrary names.

Again, just wondering what you guys would do. I don't even think it matters to much, I'm itching to build something.

[Tigairius]

You can set player strings equal to objects. So if you make a TStaticVar with the stats of your item and then set a player string to that TStaticVar, you can access it constantly without performing any disk read/writes. Then if you want to change values on the object that's in the player's inventory, you can just access the object directly in memory and change it. When the player logs out, save the TStaticVar object to some file or database on the server probably using TGraalVar.savevarstoarray(bool). On login, you can load the object back up using loadvarsfromarray. That way it's only reading/writing on login/logout.

[MrDunne]

Originally Posted by Tigairius

You can set player strings equal to objects. So if you make a TStaticVar with the stats of your item and then set a player string to that TStaticVar, you can access it constantly without performing any disk read/writes. Then if you want to change values on the object that's in the player's inventory, you can just access the object directly in memory and change it. When the player logs out, save the TStaticVar object to some file or database on the server probably using TGraalVar.savevarstoarray(bool). On login, you can load the object back up using loadvarsfromarray. That way it's only reading/writing on login/logout.

Have you had much success with SQL on here? I know it's using SQLite, which isn't the greatest, but yeah.

[Tigairius]

SQLite is one of the most powerful technologies we have at our disposal with GScript2, and almost anything that can be done with SQL can also be done with SQLite when also mixed with a little GScript2. Sure, there is no automated cleanup or date typedefs, but SQLite serves its intended purpose as a quick retrieval database system. I use it extensively in our development on Kingdoms iPhone and it works well.

[MrDunne]

Originally Posted by Tigairius

SQLite is one of the most powerful technologies we have at our disposal with GScript2, and almost anything that can be done with SQL can also be done with SQLite when also mixed with a little GScript2. Sure, there is no automated cleanup or date typedefs, but SQLite serves its intended purpose as a quick retrieval database system. I use it extensively in our development on Kingdoms iPhone and it works well.

Well that's good to know. I've heard a lot of other developers outside of this game complain about SQLite for a few reasons. Mainly one being it's inefficiency when with larger amounts of data (due to the whole database being stored in one file, I believe).

But since you speak of success in production, I'll take your word for it.

[fowlplay4]

You can easily get away with storing quantities, and item data in clientr flags.

Just cache your base items in a DB/SQL instead of loading a text file with them every time.

I wrote a simple 'Active Record' implementation for GS2:
http://forums.graalonline.com/forums...hp?t=134262561

GS2 is probably fast enough for what you're planning to do anyway.

[MrDunne]

Originally Posted by fowlplay4

You can easily get away with storing quantities, and item data in clientr flags.

Just cache your base items in a DB/SQL instead of loading a text file with them every time.

I wrote a simple 'Active Record' implementation for GS2:
http://forums.graalonline.com/forums...hp?t=134262561

GS2 is probably fast enough for what you're planning to do anyway.

Thanks for the tip.

Migrations. Nice!

[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.

[Chompy]

http://forums.graalonline.com/forums...hp?t=134261963
Might be a good read

And what the hell is a MUDlib here on Graal?
For future reference, FOR ALL YOU SCRIPTERS OUT THERE; DO NOT USE THE TERM MUDLIB FOR ITEM SYSTEMS

Originally Posted by Skyld

It seems that the average forum user/scripter on Graal has no real concept as to what a "mudlib" really is.

So, please can we stop using the term "mudlib" to describe your scripts?

Basically the trend to use the term MUDlib back in the days was all about File I/O to store information..

Originally Posted by Skyld

Can someone please explain to me what advantages a system that reads and writes from text files for all player or item data really has? I find it difficult to believe that, whatever it is, it justifies the:

• More CPU cycles going to loss to read and write text files when the gserver is already doing this for Database NPC flags or player attributes;
• Greater memory usage in caching both player flags and even more text data;
• Files filling up file manager which are just going to turn into a disorganised mess;
• More layers of scripting that could potentially go wrong and may need debugging, or more things to confuse someone else who has to work with your systems.

This GST doesn't approve.

[DustyPorViva]

By stealing someone elses!

[cbk1994]

To clarify, when I use the term MUDLIB as I did above, I use it loosely to mean an item system capable of generating new items dynamically (Kingdoms) rather than one with a fixed set of items that can only be added to by staff (Era).

[MrDunne]

I don't really care for terminology. When I hear MUDlib, I think of telnet but it's not important.The DBNPC approach seems fine for basic uses but there's not much you can do in the way of:

• Querying the data
• Organising the data

With SQL, you can express a lot more about what kind of data you want. It's much suited for this sort of thing than GScript, hence why it was invented.

Anyway, thanks for the information Chompy. The enchanting stuff was golden and I feel inspired.