Inventory client and server proper way to set up?

#1 When I coded our inventory I simply sent messages between the server and the client, and short ones at that.

The client stores all values of the item in a database. When the user clicks on an item to inspect it, the client looks in this database and fills the dialog with the text. The server never has anything to do with that.

OR you could do it this way instead:

You inspect the item. The client tells the server:
"Hey, I clicked on item "Yabbas Mask", show me some love!"

The server tells the client what the item's ID (let's say #24) was, and the client looks in it's database (like before) for ID #24, and then it's description, damage, value, etc is printed to the screen.

If a hacker wants to change this information for some reason then it won't even matter as that's only what gets printed to the screen.

#2 Do you keep a copy of the players current inventory on the client also? So that you don't have to talk to the server when you view your inventory, but only when you do game important items, like equipping something?

I like the database idea, makes complete sense adding a database # to the datablock instead of a bunch of text strings for images, descriptions etc.

any reccommended database? mysql?

#3 When the player is initiated or created, I send the inventory info to the client.. just the ID's and on what slot it is. That's pretty cheap, the client can figure out the rest with it's database.

This information is kept until you quit. I've had problems though with moving stuff around.

I tried this first: When the client moves an item, it is positioned on the new spot immediatly (on the client) and the client sends a command to the server that tells the server to move item to that slot. (The server then checks if this is possible, of course). Then it does. If you do alot of moving this way and move the items fast and if you have higher ping, you will get alot of jumping and you "could" ask the server to move an item to a slot that's already occupied, or a spot that the client thinks is free but in fact ain't because it haven't got it's update sent back yet.

The other way I tried was to send a command to the server to move the item, and when it was moved the server sent a command back to the client to tell it to update the GUI to reflect the change.

I stayed with the latter one.

Equipping was made the same way.

I did it pure text files :S Was thinking of adopting John Vanderbecks SQLLite resource and using that, so you might be interested in checking it out. I'll certainly do when I get more time.

Edit: Grammar and spelling.

#4 Thanks for the explanation.
I was half way under the impression that tagged strings could maybe be used for all this shared data, then anytime I pass a string, like a long text description of an item, I'm really only passing a small number. That would definitely help some, but I think keeping a local version of inventory for things like this makes sense.

"I did it pure text files :S "
nothing wrong with that :)

#5 Pure text files will be terribly slow on larger amounts of data, as far as I know.

#6 Another idea is when you send the move command to the server, immediately call a lock inventory, so nothing can be moved, then when you recieve information back from the server, it first unlocks then moves the item or not depending on the servers response. You may need to have a cancel move button if there is extremely high latency. You wouldn't want a locked inventory. I don't know just an idea though.

#7 @Clint
Did you find a solution for this.
I have a problem.
I need somekind of server inventory that all clients can pick from.
And when 1 client take a item from that inventory it disapears from the server
inventory.
Any clues how i shall approach this without using a db ?

#8 Hey Billy,

I haven't done any more work with this, I'm still just passing messages back and forth like crazy between client and server.

I'm doing a single player / no coop game right now, so I haven't had to deal with the same problem.

sounds like your problem shouldn't be too hard though? is this an in game store/merchant or something?

#9 Something like that :)
With the simgroup save function i got new ideas (like always) .
So i need to figure out some kind of big coop backpack for the clients.
To store the beer in :-)

#10 This may be going a whole different direction and definately don't mean it as a plug for what I've worked on... but I built up basically a script based Torque Database... have all helped functions (searches, adding, deleting, writing, dumping, load, encrypting, etc...) except sort functions.

The way I've been thinking is the server and client has a version of this torquescript database, for now think if it as TorqueDB I guess lol... that way no heavy file data needs to be transfered, just TorqueDB with identical item database (or any other info) on it... so you just need to pass reference numbers or simple names

so the client has an inventory set and the server has an inventory set as well... so descriptions and other linking info are handled both on seperate ends (most of it on client due to the need for it to effect the clients interaction)

here is a couple image of the ways I have my system set up...

#11 @Matthew
This is your resource you working on right ?

#12 Yes, didn't mean this as a plug for the resource I'm working on, just the way I've been thinking of doing inventory...

The data back end of the resource works well... the part I'm still working on is the journal front end, I decided to modify it a bit and that modification is taking more work than I've had time lately... dont know if this is the most efficient way to do this or not, just the way I've been imagining it