Hello, I'm new to this forum and really like elements. I also happen to really like programming, and I couldn't help but notice that a little optimization could be made. You know how the deck builder thing gives deck codes like this?
4t5 5f0 5f0 5f0 5f0 5f0 5f2 5f2 5f6 5f6 5f6 5f6 5f9 5f9 5f9 5f9 5f9 5f9 5fa 5fa 5fa 5fa 5fa 5fb 5l9 5l9 5l9 5l9 5l9 5l9
Well, I have a way to shorten that a bit. It's a little mathy, but can reduce the file size of deck codes a a little bit. It's kinda annoying that the deck codes have numbers in them, and an array lookup would be kinda slow, so I'll have to think on how the game is going to do letters. Don't have flash, but I think it has an inbuilt for numbers of a base higher than 10. anyways, on the meat of what I was saying.
Suppose you took a 30-card deck code like this:
4t5 5f0 5f0 5f0 5f0 5f0 5f2 5f2 5f6 5f6 5f6 5f6 5f9 5f9 5f9 5f9 5f9 5f9 5fa 5fa 5fa 5fa 5fa 5fb 5l9 5l9 5l9 5l9 5l9 5l9
That, in programming, would be a string of 120 characters, or 120 bytes. If the player-owned cards database is also managed in the same way, that's 1500 cards times 4, which comes to 6000 bytes. That's 6 kb. 1,000 players means 6mb. 1,000,000 players means 6gb. Doesn't seem like much, but scale up the numbers and the cards and things are going to start adding up. My proposal is a client- side compression, where the codes have the spaces removed and are treated like base-36 integers. They are then converted to base 10 using an inbuilt function in flash, or high-school maths if no inbuilt exists. Those base 10 integers are then stored instead of the long string-based card lists. Thus, a deck code like this:
4t5 5f0 5f0 5f0 5f0 5f0 5f2 5f2 5f6 5f6 5f6 5f6 5f9 5f9 5f9 5f9 5f9 5f9 5fa 5fa 5fa 5fa 5fa 5fb 5l9 5l9 5l9 5l9 5l9 5l9
becomes:
4t55f05f05f05f05f05f25f25f65f65f65f65f95f95f95f95f95f95fa5fa5fa5fa5fa5fb5l95l95l95l95l95l9
Which becomes a really big number that I can't be bothered to work out, but definitly takes up less than 120 bytes of space. Or you could just go halfway and convert each individual card to a number value, to get:
6269 [some long line of four-digit numbers]
While this seems like it would take up even more space, to the computer, it's just a long line of shortints, or whatever you call 16-bit numbers in flash. Decoding is similarly easy, just convert each number back to base 36 to get your original card values. Because flash stores characters as 16-bit characters, you immediately cut out 2/3 of the filesize. If you went all the way and did the conversion of the whole deck code, you may have to store it in multiple longints, butit would take up a small fraction of the space that it would take up now.
What does it mean to players?
Your decks codes will stay the same, but a conversion would be preformed when sending your card info to the server. People with fast internet connections but slow computers will suffer. People with fast computers but slow internet connections will benefit. People who have slow computers and internet connections will see a small performance hike. People with fast computers and fast internet connections should wait for elements 3D.
What does does it mean for Zanzarino?
You can put off upgrading your servers for a little longer by offloading the conversion work to the game clients. Your hard drive gets freed up a little, your bandwidth takes a bit less strain and the CPU has less data to process. Which means you can cut AC costs too and help save the environment.
What can be added because of this?
The max card limit can be ramped up massively, or Zanzarino can implement a “save decks” feature to fill in the space he saved. This will still mean that he has to code the feature, so I wouldn't nag him.
Any thoughts? Is it already done? Any flaws I missed?
