How would you implement an item system?
 

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.

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.

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.

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!

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.

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


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

By stealing someone elses!

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

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.