0
\$\begingroup\$

I'm building a tooltip item like that

enter image description here

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?

\$\endgroup\$
4
  • 1
    \$\begingroup\$ They say there are only two hard problems in computer science: cache invalidation and naming things. ;) What events would cause an item's attributes to be modified? Does the system performing the modification have the ability to send a message that causes the cached info to be updated or cleared? If not, what specific obstacles do we need to overcome between these two pieces of your game? \$\endgroup\$
    – DMGregory
    Nov 10, 2018 at 5:28
  • \$\begingroup\$ @DMGregory yes, its possible to send a message to the client when something is changed in item \$\endgroup\$
    – Leohige
    Nov 10, 2018 at 20:17
  • \$\begingroup\$ Cool. So, what have you tried so far when implementing this? Is part of it not working, or are you stuck on a particular piece of the implementation? \$\endgroup\$
    – DMGregory
    Nov 10, 2018 at 20:18
  • \$\begingroup\$ Send the information to the client will be easy using a new opcode, but I have a new doubt now. The inventory can be closed/opeded, so should I clean the cache always the inventory is closed? or keep it? The item can be dropped on the ground or been traded with another player, the cache could be a problem in that case? \$\endgroup\$
    – Leohige
    Nov 10, 2018 at 23:07

2 Answers 2

1
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$
2
  • \$\begingroup\$ I should send all the info about the item or specific info? \$\endgroup\$
    – Leohige
    Nov 10, 2018 at 20:17
  • \$\begingroup\$ That depends entirely on how you normally deal with updates. If your code is made to handle partial updates then specific info would work, if however your code simply replaces it with the network version then the whole item would be required \$\endgroup\$ Nov 11, 2018 at 4:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .