Register
View RSS Feed

WoW-GPS Dev Blog

WoW-GPS 2.0 - How to Build a Better Shuffler

Rate this Entry
So, I started a bit of a conversation the other day about the new WoWGPS shufflers via twitter: https://twitter.com/wowgps/status/489390770671988737

I stopped after a realized I could probably go on forever about it, and decided to flesh things out a bit more in a blog post.

A Brief History of WoWGPS Shufflers
So far, I've built the equivalent of 5 shufflers for WoWGPS:
1) Saronite shuffle
2) Ironpaw Tokens
3) Overhaul of the Saronite shuffle to streamline many redundancies
4) Crafted DE
5) GiO shuffle (ended up being about 95% complete, but hasn't ever been publicly released)

With each one, I've learned a little bit more about what goes into the process and I think it's been a faster and easier process each time around. That said, there's still quite a bit of manual data entry and configuration that's gone into each one, and while part of that may have been necessitated by the data source I was using and its own limitations, but still I ended up having to configure all the output paths, yields, procs, etc. This is fine when I'm building 1 shuffler every few months, but in order to get WoWGPS 2.0 to where I'd like it to be, we're probably talking about anywhere from 10-20 shufflers that will need to be built.

A Look into the Future
Now that I'm housing and using my own data, I have a LOT more flexibility on how to interact with it. This time around, I needed something more versatile and scalable if I were to have any hope of ever getting this thing completed. One of the things that I noticed about each of the previous shufflers was that although I was using similar settings/parameters, there wasn't really much that was transferable between them. Each time, I found myself configuring a list of item IDs and looking up and configuring misc. yield %s (prospecting, DE, token exchange rate, etc.). I then would have to go and manually configure all the routes (ie. Saronite Ore -> Uncommon gems -> jewelry -> enchanting mats, Cobalt Ore->..., etc.)

With 2.0, I've been doing mostly data-modelling so far, so it's all structure and I'm trying to think of every possible scenario so that things can all be setup as efficiently as possible. In the twitter conversation there, I had mentioned how the WoD Ore and WoD Herb shufflers were currently sitting at the top of the features list, and as such, I've been thinking a lot about how to implement them. My original plan for item data was going to be to include a prospecting yield, milling yield, DE yield, column in the Item table, but it becomes sufficiently problematic when you aren't working with a 1:1 relationship. I thought at first that I might be able to create some sort of custom string, with key/value pairs (ie. "id1:qty1,id2:qty2...") and then parse through a pre-defined format, but that could get really messy and quickly out of hand, so I really wanted to move away from that.

As I briefly mention in the tweets, I think the best solution will be to completely separate the data from the Item table. I'll create a Conversion model, with some sort of structure similar to the following: (source_itemID, target_itemID, quantity, conversion_type, conversion_medium) and every single item conversion will have it's own row within that table. So, if a stack of GIO can be prospected into 1 of each uncommon gem, then there will be 6 rows (one for each type of gem) that all reference GIO as the source with a 0.05 qty and a "type" of prospecting. The same table would also hold milling, de, and any currency conversions or straight item exchanges (ie. Frozen Orbs, or SoH) would also be there. I might have to restructure the table in order to cut down redundancies (ie. add some sort iLvl column for DE, or something to represent various non-item currencies - like Ironpaw tokens) but I think it provides a very flexible structure in order to build more scalable shufflers, and faster, too.

Instead of having to predetermine every possible route of a given shuffle, I'd just need to feed in the top-level items (ie. each itemID for all the xpac ores) and then walk through the various conversions. So, walking through GIO would return all the uncommon, rare gems, etc. because there would be a row for each of them with the GIO source_id, and then I could look for conversions for various sources (crafts, AH - via BoE property, vendors, conversions, etc.) and either return cost, value, etc. - cycling through each result until I reach the end. This essentially means WoWGPS 2.0 will likely end up with 1 recursive Shuffler function that serves EVERY SINGLE ITEM in the game. I don't know about you, but I find that extremely exiting. To perhaps make it more tangible for people, imagine a breakaway from traditional, profession or market based shuffler definitions and imagine throwing a random set of item IDs together (perhaps the contents of a guild bank you've just acquired, or some leftover mats from profession leveling) and getting a full-fledged, customized shuffler on the other end.

I'm personally pretty excited about how this will change the process moving forward, what do you think?
Categories
Uncategorized

Comments

  1. Lionsword's Avatar
    Kath,

    If you were able to create a "build your own shuffle" shuffler, 100% independent where users could input contents (I like your guild bank example, how many guild banks in WoW do you think are filled with limitless potential?) and get the most useful...use of those items, that would be quite the tool. It's fantastic and quite a venture, if you decided to go down that road. I, for one, would be very excited to see it.
    Updated July 22nd, 2014 at 11:58 AM by Lionsword (My sentence structure sucks sometimes.)
  2. Kathroman's Avatar
    Quote Originally Posted by Lionsword
    Kath,

    If you were able to create a "build your own shuffle" shuffler, 100% independent where users could input contents (I like your guild bank example, how many guild banks in WoW do you think are filled with limitless potential?) and get the most useful...use of those items, that would be quite the tool. It's fantastic and quite a venture, if you decided to go down that road. I, for one, would be very excited to see it.
    Oh, I definitely intend on going for it. Not only for the potentially HUGE value for users - but it will save countless hours of future development time, so it's quickly becoming a top priority, moving forward