# Syncing items between server and client

I'm doing this game of mine, and I want to add the items to it.
I'm already familiar with the basic concept of syncing data between server and client,
Usually using sync state, that's what i've done with my friends in our previous game.
This game is sort of a recreating of the previous one, but written better.

The problem we had with items is that every item we created in the server was basically a Subclass of a class that is a subclass of Item, for example:

EmeraldStaffOfTheExiledMonk : Weapon : Item

When we wanted to have the item in the client side, what we had to do is to create an item class, which would hold the necessary information we need to have of an item, and have some sort of an initialization of an ItemPool.
Now, to sync that, we obviously have to sync the IDs of each item, assuming we have them.
My question to you guys is, is there any good way to actually sync items across client and server, without having any hard-code of those items in the client side?

What I eventually want is to have an ItemPool that would be generated in the client when you connect to the server, and the only thing the client would really need to have is the assets of that item(textures, and so on)

• Data driven would be the way to go. – MichaelHouse Sep 22 '15 at 16:10
• Could you post an answer to what is Data Driven? – Giora Guttsait Sep 22 '15 at 16:27
• Since my answer would really just be about what data driven design is, it's probably not exactly relevant to this question, and best answered to a question specifically about data driven design. uliwitness has a good answer below that covers how to use data driven design for your situation. – MichaelHouse Sep 23 '15 at 15:47

Several approaches:

1. Serialize your objects, i.e. write out binary or XML data identifying the class (e.g. the class name, or a number representing the class) and all its interfaces. Then write some code that takes this data and de-serializes it again. Of course this means that you need to have all classes on both the client side and the server side.

But you don't need a class for each object, you just need classes for similar objects. So e.g. a class for a "staff" which then lists what amount of damage a staff does with its primary and secondary attack, and maybe what bonus it gives to certain kinds of magic or whatever. That part is the "data-driven" design that @Byte56 mentions in the comment.

2. Like 1, but just have one very complicated 'weapon' class instead of individual subclasses. This is a fully data-driven approach, and you'd need a way to tell the game that an item has or doesn't have a certain ability (e.g. set secondary attack damage to 0 to indicate there is no secondary attack). This makes it easier to update game state on the server without having to update the client, but also makes your code harder to maintain

3. Proxies. I.e. everything happens on the server, and your local object is just a cache/forwarder. It maybe has a name and an image, but whenever players perform an operation on it, you send a message to the server, which then replies with messages indicating what animations to play on your player/target, and how the actors' health numbers have changed. This is what many MMOs use (also as a way to prevent cheating, as all the logic happens on the server). Downside of this is that there is a lot more network traffic and a bad connection makes the game lag more.

4. Combinations of the above. E.g. basically 3, but with some of 2 or 1 for implementing caching, so you can start playing an animation because you know from your local data that the primary attack is 10 fire damage, and if the connection is slow, the game will mostly behave right by anticipating the info that comes in late. But it'll still be cheating protection because the canonical store of information is the server's, not the client's.

• Say, In the previous game we made, we followed method 3 strictly, with the exception of what the actual game map was, which was in a file. Had we had more time to work on the game, it'd have been transferred to server-side too. – Giora Guttsait Sep 22 '15 at 16:50
• We didn't care for something like, showing a damage stamp. We had Health bars for the health value which we thought was enough, but I want to make this one better than the previous one. So that does mean that I would have to have some logic in the client side, to make the damage-calculation and show it, while still separately calculating the damage in the server-side, using the same calculation function.\ – Giora Guttsait Sep 22 '15 at 16:53
• I think a good way to go at it would be to have that ItemPool, which would be generated on login to the server, and when I want to share for example that I equipped an item, I would send the equipped item's ID. Obviously all sent in binary data. – Giora Guttsait Sep 22 '15 at 16:55
• What do you think about it? Is it a good idea to do that? – Giora Guttsait Sep 22 '15 at 17:14
• It really all depends on what your game is. In some games, knowing the stats/images etc. of future items (or even an entire map) would let players cheat, so there you would download the map in chunks. You also wouldn't want the player to wait too long after starting a game while you're downloading all items and maps. If your items are few and download fairly quickly, this is a perfectly sensible approach. Just keep in mind to verify all data coming from the client (e.g. check whether the player HAS an item before you let them equip it). – uliwitness Sep 23 '15 at 15:16

The usual way to handle this is having just a base-class Item and optionally generic classes for item sub-categories like Weapon. But all specific weapons would each use an instance of the class Weapon and differ by the properties of that class.

When the number of items in your game is small and fixed, you could transfer a list of items and their properties on login or have such a list as a file and treat it like any other asset.

When the number of items is very large or not fixed (for example, because you have procedural generation of items), you should send item information on demand. Either send the information whenever the client encounters an item, or implement a request/response protocol which allows the client to request the details of a specific item-id from the server.