- Home /
Server controlled inventory
I'm beginning the process of networking and authoritative servers. I want my server to have a full list of every item found and crafted in my game. Naturally, I believe assigning an itemID would be the best thing for unique items.
I'm sure it's possible, but what would be best I think (correct me if I'm wrong) is almost a spreadsheet like format.
ItemID, name, condition, weight, type(armor, weapon, etc).
This will be for both the servers master list and the players' inventory(also stored on server).
I can make an inventory in a single player using a list, but for some reason, it boggles my mind in a multiplayer.
Can anyone give me ideas, suggestions, or examples? Thanks in advance.
Answer by Brahim113 · Jun 21, 2014 at 01:44 PM
I created a authorative server with Lidgrens network library not so long time ago. The server should obviously have data on what the client has. Then just send updates on the inventory when needed.
There is many ways to do this but the question is how much data you want to send to the client.
What i try to do is to send as small and few packages as possible. So i try to not send strings. But this is up to you.
Lets say the client has a sword. The server knows this sword as [ID = 10, damage = 100, missChance = 0.10, ownerOfItem = "Client1", currentDurability = 32, maxDurability = 100]
You dont need to send all this data to the client. It all depends on what you want to do. Lets say you want to update the client that he has this item when he connects to the server.
I try to send as little data as possible. So i did not want to serialize the item class. What i did was to fill a buffert with first a byte/number telling what kind of message this is. Example:
4 //Inventory Message
ID //When i know that nr 4 is read before. Then i can count on a ID is coming up next
currentDurability //Same goes for durability. I know the order the server put them in the buffert
4 //new inventory message in the same buffert
ID
currentDurability
3 //MovementUpdate message
float x
float y
float z
//No more messages in the buffert.
So the client will have an easy time reading the incoming messages. He will know the exact order of the data that is read. So when he gets the ID. Then he could go thru an itemList to get all the shared information that should be displayed. Like name of the item, Description and so forth. That is something the server dont need to send
Lets say you want to as a client drop the sword. Then you send a message to the server telling it 3 //Drop Item message ID //What item
When the server gets it. It could then check if the client has that item. If not. Then just skip that message.
I dont know if this helpes alot. But maybe it will give you an idea on how to go forward
Don't suppose you could explain the buffert you use a little more?