Spreadsheets: The Next Generation - Page 6

Athyiken · 10/11/10, 9:45 AM

Just some ideas:

I think the UI should be as disconnected from what serves up either the calculations and/or data. For example, UI -> Calculations -> Data. You can set up the interface to Calculations and data as a static API. This would allow development of each tier independently in terms of progress, but not so much in terms of adding functionality. You'd want to define what each tier would do and how it would be accessed.

Within the Calculations part, as Aldriana suggested, you can stack the calculations to get the complete set returned. For example, get_full_dps() -> get_cycle() -> get_dps(). This would simply pass along the Item IDs used in the Data section in an object for each reference and processing. The result of the get_full_dps() would be a JSON object to be easily interpreted by any front end, but with an expected structure that would give the necessary details to accurately represent the data that would be typically desired.

If for some reason, the type or amount of data would need to be altered, having the the accessor functions be configurable with parameters would aid this.

AJAX Data vs Front Loaded Data

AJAX Data would require an online request to some script serving up the gear. The gear data could be stored as one massive static variable (to remove the dependency on yet another technology) or stored in a DB (which now requires maintenance).

Front Loaded Data could be hosted and/or stored with the client as a JS file of just JSON. The Calculations portion could be configured to support both local and remote access to allow offline usage. The maintenance of this file could either be stored entirely in a repository and pulled strictly for offline usage or hosted on some server somewhere where it can be downloaded or requested by the application.

So, in a sense, it comes down to what features you want for maintaining your data sources and storage and how much maintenance you want to come with it. The greatest value of the spreadsheet is being able to easily use it as a stand-alone "app" without having to monkey with a bunch of technologies. While the Next Big Thing in technology sounds nice, finding people to maintain it when some lose interest is going to be difficult.

As for MongoDB: High Scalability - High Scalability - Hilarious Video: Relational Database vs NoSQL*Fanbois

Murath · 10/11/10, 5:21 PM

One of the best things about spreadsheets, and the main reason I have used Aldriana's is the ability to look into (and play around with) the guts of the calculations. Personally I value this a lot, as I want to understand the reasoning behind gemming and gearing a certain way and not just do it because the calculator said so. That said, if something can be put together that includes that capability with a spiffy UI and features such as armory import, then that would definitely be a huge benefit to ease of use.

Reeshet · 10/11/10, 5:40 PM

I've generally used Aldriana's spreadsheet on my rogue and Simulationcraft on my warlock. While there were times I didn't feel Simulationcraft was as accurate, what I *really* liked was getting individual skill numbers that I could compare to a WoL parse.

Say I simulated a 300 second fight and it gave me some expected values (making up numbers for the example)
melee 57 hit 462 crit Hit Avg dmg 3000 Crit Avg Dmg 6000
Killing Spree 5 hit 8 crit hit Avg dmg 7000 Crit Avg Dmg 11000
etc.

Then I have "some" basis of comparison for how I did vs. theoretical. I know theory is going to generally be unobtainable but it's a starting point. Like if the average damage of my hits is way lower I can go back and look to see if I was missing Attack Power buffs and if my total number of melee attacks is way low I can try to identify if I was spending that much time off target.

cjo20 · 10/12/10, 9:46 AM

IMHO, the best way to implement this is as two separate modules, the UI and the calculation engine. You define an API for accessing the calculations from the interface. That way the people that do calculations best can just concentrate on that; I'm not sure they particularly care whether the information is from a website, database or text file.

The API would be designed around what information is needed by the people doing the calculations, and what output they are able to provide.

A possible third module would be a "data source" module, which would output a data set in the same form as the calculation module requires. This way, someone could write an Armory->tool converter, someone else might write something to access a custom database etc. to prevent replication of common code. This means that the people writing the interface would only have to worry about writing a way of displaying/editing the data.

Doing this in something like Java seems the obvious method, being cross platform, portable. The code could also be used in web applets for those that want a web based system.

Shaithis · 10/12/10, 2:58 PM

a) Which aspect(s) of these sheets do you particularly like?

I'm a big fan of convenience so I love the functionality of Armory imports and optimization scripts (Rawr).

b) Which aspect(s) of these sheets do you particularly dislike?

On the converse, sheets that are built with a limited list of items (generally only high-tier); thus hard to use for anyone who is not on the cutting edge of gear, particularly when you need to, for instance, add multiple chest items to encompass (1) what you're wearing and (2-x) possible upgrades.

c) Are there any features you've seen in tools from other classes that you'd like to see included in rogue sheets?

I am not familiar with tools for other classes, but what I would love to see on the optimization end is a way to plug in justice / valor points to encompass possible purchases, and let the script decide what the optimum purchases are.

Also, it would be nice to be able to quickly switch between solo, and adjustible 5-man, 10-man and 25-man buff templates with the click of a button, or be able to run an optimization script that calculates separate DPS totals for each category.

This is targeted specifically towards Rawr: it would be nice to have a clean way of bringing up a screen listing all variables (items, gems, etc) of an optimization script and be able to quickly check off just a few for the script to focus on.

Dorsivad · 10/12/10, 7:46 PM

I agree with Mornguruth. Any web-based application should allow the user to add an item that is essentially just attached to his/her id in the database. Seems to me that with runeforging this type of ability will be necessary on any spreadsheet/application that is developed anyway. Especially if it is going to simulate the potential dps that you will do with a particular gear setup.

I personally would prefer to see something web-based but that is because I am a web application developer by trade. I am more of a .NET programmer than PHP or Python, but I have actually worked with both of those languages as well as HTML, Javascript and Flash/Actionscript. If it is decided that a web-based solution is the way to go I would be happy to work on a few parts of the project. I could probably provide the hosting for the test environment also.

Liquoid · 10/13/10, 4:46 AM

I feel that Armory import was pretty much one of the very few features that Aldriana's spreadsheet lacked, considering that people went as far as to add that feature by themselves in the past. Other than that, it was great to use.

Celfydd · 10/13/10, 5:51 AM

a) Which aspect(s) of these sheets do you particularly like?

I like the Armory import feature of iDPS.

b) Which aspect(s) of these sheets do you particularly dislike?

I really dislike the fact that nearly all the sheets require proprietary software that must be bought in order to run, which don't even work properly on non-Windows systems (I use a Mac, which is fine enough for WoW so why not the sheets?)

c) Are there any features you've seen in tools from other classes that you'd like to see included in rogue sheets?

I am a huge fan of Zeherah's hunter DPS analyzer (Zeherah's Hunter DPS Analyzer). This embodies everything I'd like to see in one of these tools:

Totally platform neutral, can be used on any computer and even mobile phones that have a browser with JavaScript support.
Armory import
Ability to save configurations for later retrieval
No need to worry about updating to the latest version as it is all on centrally maintained website

VonGarona · 10/13/10, 7:02 AM

Spreadsheets:
- Spreadsheets are cumbersome to work with. They always have been. They just aren't good for UI.
- They present a problem with respect to "configurations". You're not just saving the configuration, you're saving the configuration and the modeling in its current state. The data is tied to the metadata is tied to the logic is tied to the user interface. Not good.
- They do allow for users to tweak modeling, if so inclined. Though I suspect this is somewhat of a double-edged sword.

iDPS:
- A step up from spreadsheets in the UI perspective, thought definitely room for improvement.
- Has significant problems with configurations, to the point that I frequently had to redo my configurations. Frustrating.
- I do like many things about this, and would be ok with moving forward with.

Rawr:
- I use this for every other class I play, except the rogue, because the rogue module isn't ready for use.
- This is built on .Net, so I'm not sure of how well it can be expected to perform on non-Microsoft platforms. I do know that Mono is coming along quite well, Novell is working hard. It has been (last I looked, partially) converted to Silverlight, so should work across multiple platforms, at least in the browser.
- It is quite complicated from a code perspective. I am a .Net developer, and I have glanced at the code on a few occassions. Getting ramped up to work in this codebase could take some time. If the Rawr devs that really know what's going on in this codebase could help the folks with the modeling expertise get off the ground, it would be quite valuable.
- Configurations are handled well. Have had no problems with loading configurations from previous versions into newer versions.
- Browser and standalone versions, as mentioned.
- Charts and Graphs capabilities, which I have used on the Mage module, for instance, to see the scaling of Haste to find plateaus. Very handy from a visualization standpoint.
- Time willing, I would be able to help out here. I wouldn't be able to help out with Java or Spreadsheets.
- [Edit] Also, many devs working on this. Ideally the rogue module devs get to concentrate on the rogue stuff and not worry about the infrastructure.

Reforging is going to throw an interesting curve-ball into the mix. Optimizing could be tough. A set of common patterns/rules would probably have to be defined. Maybe multi-step optimization, once stat values are determined? dunno.

So, my vote is Rawr, for what it's worth.

cjo20 · 10/13/10, 8:28 AM

Originally Posted by VonGarona

Reforging is going to throw an interesting curve-ball into the mix. Optimizing could be tough. A set of common patterns/rules would probably have to be defined. Maybe multi-step optimization, once stat values are determined? dunno.

So, my vote is Rawr, for what it's worth.

Surely you can just look at EP values to work out reforging? Find any items with the lowest EP value stats and convert them to the highest possible EP stat. If the EP values of a stat swap after a reforging, undo it as you probably just crossed a threshold.

*The below pseudo code is off the top of my head, during a lunch break. It may be totally and utterly wrong.*

SortedArray EPVals[n]; //Contains stats sorted by EP: Highest EP stat in EPVals[0], lowest EP in EPVals[n]
ArmorArray  Armor[m]; //An array of equipped armor

main() {

  while(Reforge())
  {

  } 
}


int Reforge() {
    for(i = n; i >= 0; i--)
    {
        for(j = 0; j < i; j++)
        {
            for(k = 0; k < m; k++)
            {
                /* Can reforge checks that EPVals[i] is present on the item and that EPVals[j] isn't, and that it is possible to change i to j. */
                if(CanReforge(Armor[k], EPVals[i], EPVals[j]))
               {
                   FromStat = EPVals[i];
                   ToStat = EPVals[j];
                   Reforge(Armor[k], FromStat, ToStat);
                   RecalculateEP(EPVals);
                   
                    if(getEPValue(FromStat) > getEPValue(ToStat))
                    {
                       UndoReforging(Armor[k], FromStat, ToStat);
                       RecalculateEP(EPVals);
                       continue;
                    }
                    return 1;
                }
            }
        }
    }

    return 0;
}

Changing stats from the lowest EP value to the highest EP value feels like the right thing to do. The ordering of the Armor items would have an effect, as the amount of reforged stat would be higher on, say, chests than daggers, so putting the higher value items first and lowest value items last (weighting per slot, and then base on ilvl maybe) would mean you get as close to any caps as you can without going over/under.

Barac · 10/13/10, 8:53 AM

Aldriana will you be releasing your normal spreadsheet whatever happens with this monster project?

VonGarona · 10/13/10, 9:45 AM

Originally Posted by cjo20

Surely you can just look at EP values to work out reforging? Find any items with the lowest EP value stats and convert them to the highest possible EP stat. If the EP values of a stat swap after a reforging, undo it as you probably just crossed a threshold.

Not to go too far into a tangent, but an interesting question is whether the Rawr system supports this kind of thing. I know that an item with different gem combination's are treated as separate items, and selecting too many gem/enchant/item combination's can hurt the solver performance. So with something with a big window of variability like reforging, treating each increment of change as a different item could be bad. That's why I suggested maybe it would need to be a pattern/rule; some kind of heuristic system. I don't know enough about the codebase to determine, so enough talking out of my arse.

[Edited]

Shaithis · 10/13/10, 11:11 AM

Originally Posted by VonGarona

Rawr:
- I use this for every other class I play, except the rogue, because the rogue module isn't ready for use.

Er, Rawr is definitely working for Rogues, and has been for some time. Perhaps I did not understand you correctly?

Link: Rawr.Rogue

• Aldriana · 10/13/10, 11:51 AM

Originally Posted by Barac

Aldriana will you be releasing your normal spreadsheet whatever happens with this monster project?

I don't know. I have a lot less free time to work on this sort of project than I once did, so I'm not sure I have the time or inclination to rebuild another sheet (or set of sheets) from scratch. That was part of the motivation for this thread - to see if I could outsource some of the front-end work to other interested parties so that I only had to worry about the back end computations. Which is not to say I definitely will if I get some help or definitely won't if I don't; but it certainly makes it more likely that I will have time if I can limit the scope of my involvement.

winkiller · 10/13/10, 12:00 PM

Most of you raised very valid points, for me as well the worst part of the spreadsheets was: download update, redo every slot, (notice Aldriana kicked out some old stuff I'm still wearing), enjoy. I still loved the results - so I lived with the downsides.

I think there's not much hope in trying to specify an API (and even cross-language), that won't happen soon and probably not very clean.

I think it would be much easier to specify a common interchange format. Every solution (apart from Excel, but the more knowledgeable people might join here) could easily parse, for example, JSON (much easier to parse than anything with XML or plain text) - so that could at least reduce the "update stat weightings/new items/changes" hassle.
If there was a consensus about a defined message format at least input and output would be tool-agnostic.

This can only help with some problems, not the "library" part doing the calculations.

Oh, and one more thing, you might have a look at tiddlywiki - it's purely in HTML/JS and you could easily download it and use it locally, this would also solve the "must be online" problem.