How to implement an tooltip item cache?

Question

I'm building a tooltip item like that

I would like to keep this information cached on the client side, avoiding that whenever the information is displayed it's necessary to make a request to the server, but make the cache is not the problem, the problem is that an item can have its attributes modified and the cache on the client side will show wrong information.

My question is, cache is a good idea? if yes what is the best solution?

Answer 1

I wouldn't worry about caching in this situation.

When the player is looking at an item they don't own, then it is not very likely that they will look at it again in a couple minutes. So caching it longer than a couple seconds is unnecessary.

When the item is in the player's inventory, then I would just provide them with full information on every item as soon as it gets changed. We are not dealing with a lot of information here. Let's take a look at the screenshot, and see how much information we actually got there:

• The icon. The image asset is likely on the client, so you just need to send an ID of the icon to use. Let's assume that your asset IDs are integers (4 byte).
• The item name. When this is a completely server-sided string, that would be 23 byte (22 plus null-terminator). It might be smarter to have a string table of item names on the client-side. That doesn't just make item names localizable, it also means you just need an index to that table (4 byte). But let's assume the worst case that the name is indeed a literal string coming from the server.
• Rarity level. 1 byte.
• "Mythic 15 Titanforged", which is I assume two enumerations which fit into a single byte and an integer (6 byte)
• Item level, another integer (4 byte)
• "Binds when picked up" and "Unique-Equipped". I don't know how many such mechanics you have in your game, but you can likely represent them with a bit-field. Let's be generous and say you got 32 of such flags an item can have. (4 byte)
• "Finger" - an enumeration representing the equipment slot. Likely fits into 1 byte.
• 3 different Integer-bonuses to different stats. 4 byte for the number and 1 byte for the enumeration of the stat, so 12 byte in total. Plus an additional byte for the number of bonuses we got. Whenever you allow n of something in your netcode, you need either a number or a stop-byte so the parser knows when the list stops.
• "Required level". 1 byte when your levels go to 256, 2 byte when they go to 65536. Let's be pessimistic and assume 2 byte.
• Vendor-price. Integer (4 byte). Yes, that fancy representation of gold, silver and copper coins is likely handled as a single integer internally.
• "Auction: BOP", not sure what that is, but I assume it's another price (4 byte)
• Disenchant-price. Integer (4 byte)

That leaves us with a total amount of data of a measly 71 byte. You will likely need some more data which isn't visible here as well as some padding and bookkeeping data, so let's be generous and round that to 100 byte. Do you think that sending an additional 100 byte whenever an item in the player's inventory changes will be too much for your network stack to handle? I doubt it. You could even reduce that by implementing incremental updates to item properties (only change new data for the properties which actually changed), but I doubt that this is worth the effort.

Answer 2

The short answer is exactly the same way you would update any other information inside your game. You will generate an update to the item tool-tip anytime that it changes and the cache will display that instead.