Jump to content
  • Sign Up

Can a programer help me understand how is GW2 able to manage so many dyes and gear customization? It doesn't make sense

Recommended Posts

So no mater how I think about this, it leads to GW2's data base being ginormous.
Scenario 1: Items that can be dyed retain the dye information edited by the player. So the item "remembers" how it was dyed, and displays that combination when equipped. Does that mean that the date base is holding a looong list of items that are the same ID, but need to be saved separately because they contain slightly different dye information? That would account of millions of instances of the same item taking up space in the data base.

Scenario 2: The dye information is stored in the player character's profile, not on items. Now the item IDs are fine, but we have a character profile that needs to remember every single item ID that's been equipped and what dyes were used or edited on each one of them. Again, data base nightmare. Now this Player character's profile has a looong list in it's data base of item and dye combinations to remember.

Anyone has any insight on this? Anyone from Anet :D?

Thank you~


  • Confused 1
Link to comment
Share on other sites

i'm not a games programmer but there are lots of aspects:

- database/disk space is cheap (and data can be compressed) , the art is efficiently retrieving and caching the data and minimising/optimising network traffic.

- you may persist only the delta/differential from the default rather than everything

-  you can use bitwise operations on binary values to retrieve many values

- you only need to retrieve data to support the current view.

- GW2 is running on my client just now with 2gb in memory, that's over 2 billion bytes of data for the local game +  player data, which is a lot.

Would be really interesting to hear from a game developers perspective.

Edited by vesica tempestas.1563
  • Confused 1
Link to comment
Share on other sites

  • 4 weeks later...

K so, they probably work with a high throughput, low-level language like C/C++, I assume it's just 1 16-bit integer to represent this information, with the max of 4 "dye" slots per item, this should amount to around 8 bytes of data per item.

Then they can retrieve the actual color and text from an array, using that int as an index, like 


int tableOfColors[65535] = { /* a long list of actual RGB-int colors */ } 
char* tableOfColorNames[65535] = { /* ... */, "Enameled Perseverance", /* etc */ } 

See http://www.shodor.org/~efarrow/trunk/html/rgbint.html for more information on how it's possible to encode RGB values into a 32-bit int.

This table of colors can easily fit into a "permanent memory allocation" for just 524kb tops on the client, the server probably doesn't even have to bother loading this array. And also this "table of colors" probably has way less than 65 thousand colors.

With this technique you get away with storing color with just 8 bytes, suppose you have 284 slots, it's 2272 bytes max per character, plus an account max of 4080 bytes from having 17 bank tabs of 30 slots; Material storage probably doesn't have an "item extra information" part, I assume it's just a long array of "amounts"
With this, each account should store about 4kb plus 2kb per character in dye information.
Suppose the average account has a lot of alts, even if you suppose at 32kb per account in dye information, that would be 312MB to store the entire dying system for 10 million accounts, it's not a lot really

Edited by figloalds.1274
  • Confused 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...