{"action":"created","issue":{"url":"https://api.github.com/repos/EmmittJ/PoESkillTree/issues/106","labels_url":"https://api.github.com/repos/EmmittJ/PoESkillTree/issues/106/labels{/name}","comments_url":"https://api.github.com/repos/EmmittJ/PoESkillTree/issues/106/comments","events_url":"https://api.github.com/repos/EmmittJ/PoESkillTree/issues/106/events","html_url":"https://github.com/EmmittJ/PoESkillTree/issues/106","id":67020722,"number":106,"title":"Full tree optimizer","user":{"login":"MLanghof","id":6524684,"avatar_url":"https://avatars.githubusercontent.com/u/6524684?v=3","gravatar_id":"","url":"https://api.github.com/users/MLanghof","html_url":"https://github.com/MLanghof","followers_url":"https://api.github.com/users/MLanghof/followers","following_url":"https://api.github.com/users/MLanghof/following{/other_user}","gists_url":"https://api.github.com/users/MLanghof/gists{/gist_id}","starred_url":"https://api.github.com/users/MLanghof/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MLanghof/subscriptions","organizations_url":"https://api.github.com/users/MLanghof/orgs","repos_url":"https://api.github.com/users/MLanghof/repos","events_url":"https://api.github.com/users/MLanghof/events{/privacy}","received_events_url":"https://api.github.com/users/MLanghof/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":10,"created_at":"2015-04-08T00:36:00Z","updated_at":"2015-07-02T21:02:44Z","closed_at":null,"body":"The original reason why I started looking into this project and worked on #98 was the vision of a tool that builds an entire tree based on specified user criteria.\r\n\r\nThere's so many tradeoffs (life, mana, damage, cast speed, mitigation etc.) that need to be made when devising a tree, and so many different nodes and node values (with widely varying point investments) that it's hard for a player to create something optimized. Only very few people actually do/check the math. For example, it's generally worth to take the melding cluster (25% ES) over spending those four points in the scion ES wheel (24% after you got Foresight), even if you only care about ES.\r\nOr another example, I often wonder whether I should get more cast speed or rather more spell damage in my tree at a particular point in order to optimize my dps. That obviously depends on my gear and my current tree, but that's data that can already be fed to the existing skill tree tool.\r\n\r\nIt's only a matter of letting the user communicate his desires and priorities about the tree. Well, \"only\" doesn't really nail it, the required UI work (and thought) is the entire challenge here.\r\nMy current idea is that users can select a node (control-click? Or go into a special mode and right click?) and then choose how much he values certain attributes that node has (which will \"apply\" to all nodes with those attributes).\r\nGoing one step further, either the user should be able to combine attributes (dpsMulti = (1+spelldmg)*(1+castspeed)) or there should premade functions that compute things of interest (total life, armor...). In particular, Compute.cs (I was really impressed somebody sat down and basically recreated the engine!) will provide accurate calculations for whatever setups and gem links people want.\r\nThen there needs to be a way for the user to weight those aspects in a certain way. Here my idea is that the user selects a desired target value and how important it is to reach that value. A Mjölner char has pretty set requirements for str and int (so that would have full priority), but maybe setting desired life to 160% increased and giving it lower priority could give you 150% life with much better dps. You get the point.\r\n\r\nInterestingly enough, all the \"hard\" algorithmic work is already completed with #98: Instead of searching for the set of steiner points with the lowest point investment, all nodes possibly affecting the user defined tree value will be part of the searched node combinations. The genetic algorithm doesn't really care, it only needs a fitness function (providing which will be the challenge). It's obviously going to take longer to find the optimum, but that's a given.\r\n\r\nI still don't really know how to represent \"value\" for this, and how the individual aspects should be combined (multiplied? added?). And especially how to make this somewhat transparent for a user.\r\n\r\nSo these are the questions I'm asking myself at the moment:\r\n-In what way should the scores for e.g. life and dps be defined, and how should those be combined into a final score/(fitness) value?\r\n-How fast is Compute.cs? Is it modifiable in a way that permits faster calculations when only some/a few of the input things change?\r\n-Most of all: How should the UI for this be built so that it is both powerful but also accessible to an unfamiliar user (who has no idea of math)?\r\n\r\nI'm keen to hear your thoughts on this!"},"comment":{"url":"https://api.github.com/repos/EmmittJ/PoESkillTree/issues/comments/118167347","html_url":"https://github.com/EmmittJ/PoESkillTree/issues/106#issuecomment-118167347","issue_url":"https://api.github.com/repos/EmmittJ/PoESkillTree/issues/106","id":118167347,"user":{"login":"brather1ng","id":7596346,"avatar_url":"https://avatars.githubusercontent.com/u/7596346?v=3","gravatar_id":"","url":"https://api.github.com/users/brather1ng","html_url":"https://github.com/brather1ng","followers_url":"https://api.github.com/users/brather1ng/followers","following_url":"https://api.github.com/users/brather1ng/following{/other_user}","gists_url":"https://api.github.com/users/brather1ng/gists{/gist_id}","starred_url":"https://api.github.com/users/brather1ng/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/brather1ng/subscriptions","organizations_url":"https://api.github.com/users/brather1ng/orgs","repos_url":"https://api.github.com/users/brather1ng/repos","events_url":"https://api.github.com/users/brather1ng/events{/privacy}","received_events_url":"https://api.github.com/users/brather1ng/received_events","type":"User","site_admin":false},"created_at":"2015-07-02T21:02:44Z","updated_at":"2015-07-02T21:02:44Z","body":"Yeah, using the hard constraints as a factor is probably better.\r\n\r\n>And yeah, I edit my stuff a lot after posting.\r\n\r\nLol, good that I randomly stumbled upon this sentence and read the comment again. :D\r\n\r\n>Keep in mind that using this tool for lower levels also makes sense (think LLD or leveling), and it gets really hard if you want to work without user-supplied constraint target values.\r\n\r\nHm, why would it be harder to work without target values on lower levels?\r\n\r\nJust an idea to throw in here: A useful feature for leveling trees would be something like only searching in a given subtree (which would be the endgame tree).\r\n\r\n>I suppose you could do an \"autopilot\" mode [...], while also having an \"advanced\" mode\r\n\r\nYeah, that sounds awesome :)\r\n\r\nBut idk, specifiying target values for everything that is taken into consideration sounds pretty hard on the user part, at least for specific values like % increased damage and things like that. This would probably only have a use on a more abstract level with things like total health, total evasion, dps on the main skill, etc. (which should be possible to calculate with Compute.cs). And also as you said it would be more useful as an advanced mode, since a relatively inexperienced user would not know what dps to shoot for, for example.\r\n\r\nI guess the best thing to do is to start with different fitness function approaches and throw out the ones that prove to not be very useful. In the end the remaining ones could then be used for the user to select between (named like \"autopilot\", \"advanced\", ...)."}}