| rdfs:comment
| - I like the idea, really not a bad way to go. Needs some cleaning and additional small things but it sure a nice start :) GCardinal 19:08, 6 May 2007 (CEST) A system like this would be completely subjective. The effectiveness of any build anywhere would depend primarily upon your opponent. Not only are the criteria totally subjective, but the ratings would be uninformative as well. Firstly, the numbers themselves could be confusing, i.e. what distinguishes a 4 from a 5 in ability to resist counters? (Btw, a counter to a build what will neutralize it. If any build can resist or circumvent that factor, it is not a counter) Secondly, it will distort the effectiveness of builds that are known to be good or bad. Take just about any GvG warrior build. It's only heal would likely be Healsig (poor
|
| abstract
| - I like the idea, really not a bad way to go. Needs some cleaning and additional small things but it sure a nice start :) GCardinal 19:08, 6 May 2007 (CEST) A system like this would be completely subjective. The effectiveness of any build anywhere would depend primarily upon your opponent. Not only are the criteria totally subjective, but the ratings would be uninformative as well. Firstly, the numbers themselves could be confusing, i.e. what distinguishes a 4 from a 5 in ability to resist counters? (Btw, a counter to a build what will neutralize it. If any build can resist or circumvent that factor, it is not a counter) Secondly, it will distort the effectiveness of builds that are known to be good or bad. Take just about any GvG warrior build. It's only heal would likely be Healsig (poor self-survivability). It would likely have no Hex removal, and likely no condition removal (high team dependence). No hex or condition removal = difficulty "resisting counters." E-mgmt could arguably be inapplicable, because of a warrior's adrenaline. Taking these factors into consideration, the build might be judged unuseful to the team. As easily as that, you can portray a great and well-known build to be a disaster under this system. Lastly, having to rely on that "Test 1st Plz" policy pretty much puts the icing on the cake. That requirement is not only impossible to enforce, but it will also create an enormous backup of horrible builds that people will have to test to unfavor. I would never waste my time doing that. I can telly you right now that an all-Signet gimmick build will be ineffective, I shouldn't have to test it first. Over at GWiki, that "Testing Optional" policy wasn't enacted by a cabal of evil admins up to no good. It was put in place to maintain efficiency and a higher standard of quality than otherwise would have applied. - Image:Kowal.jpg Krowman (talk • contribs) 19:28, 6 May 2007 (CEST) Too many factors to judge fairly... and in pve, what if a build has a lot of enchants, and some area's have no enchant removal but other's do. Just my thought's. --Image:Ranger-icon-small.pngfrvwfr2 (talk)(contributions) 20:20, 6 May 2007 (CEST) The concept of whether a build is generally "good" or not is inheirantly abstract, we don't need to hold a ruler up to it. --Image:Rollerzerris.jpg 23:28, 6 May 2007 (CEST) Re: My attempt to bring a Gate of Madness team into Foundry. Again re: My latest attempt at DNKP... using a team based off of our Hell's Precipice experience. -- Armond WarbladeImage:Armond sig image.png{{sysop}} 22:52, 7 May 2007 (CEST) But a measuring stick would greately help with the allready existing problems of how we fairly judge existing builds. I just realized where I got the idea for this and it may help if we take a look at their system to get some ideas. The following is one of those anime-music video sites run by a guy named Phade. Their community is completely opinion based and they rate each others videos and their system seems to work pretty well for them. Perhaps we could take the concept (not necessarily the exact procedure) and adapt it to out needs. The pre-set categories and numerical values are whats gonna make or break this policy (IMOP). We just need to discuss and figure out what's reasonable. And we can put together a guide to the voting section to better understand what it means to put a '10' or a '6' or a '3' into a particular voting field. For example. If we were to put an 'Overall' or build quality category, the range would be from 1-10, 1 being lowest 10 being highest and we could do a quick chart like:
* 1 - The build is completely rediculous, Example: 6 Skills - 2 Assassin, 2 Monk, AND 2 Warrior??? FTW! (Delete Candidates)
* 2 - The build is simply broken or lacks an elite (Most noob or beginer builds people try to make)
* 3 - The Build is functional but makes poor skill selections and is very difficult to use (Like an Ether Lord e-denial build)
* 4 - The Build is functional, but only in very specific situations and is not reliable. (Pacifism Monk)
* 5 - The Build Works, but there are much better examples of its type allready out there. (Like the default ZB sujested by the primer articles)
* 6 - The Build works well, but is hurting in a minor area such as condition removal or e-management (Faster Caster Monk)
* 7 - This build is solid and would be a good example of it's type. (RC Prot for HA)
* 8 - This build works very well and can even accomplish a few things that isnt in it's designed scope.
* 9 - A prime example of what a build of this type should be. (Stanced LoD Infuser)
* 10 - The Uber 3llt version of the build. Will incite a massive nerfing backlash by Anet! (Like boon prot, back int he day when it worked) Thats an idea, and we could do a chart for each category type we create. Just an idea to perhaps put some of this in perspective. Shireen 14:39, 7 May 2007 (CEST) Then, a person can glance at a build to find if it does what he/she needs the build to do. Also a person can look in the unfavored section and see what needs to be fixed on a build. Although i could see people abusing it and using it to decide how to make their own votes. Eronth 21:10, 7 May 2007 (CEST) I like this option, it's simple, it provides room for discussion, and though people might not like being a '4', there are many useful builds that are specific for a reason. I do think this system is best for PvP builds and perhaps another categorical system is better for PvE. --208.5.44.21 22:27, 7 May 2007 (CEST) For the record, Mo/E SoA Sliver was the most awesome solo bosskiller ever and got nerfed by ANet - and it had no elite. Elites are handy, but in many cases aren't as useful as one might think. Solo builds and (let's be honest now...) many casual assassins play without elite. And it's spelled l33t. -- Armond WarbladeImage:Armond sig image.png{{sysop}} 22:52, 7 May 2007 (CEST) This is just too slow. nice idea but to much work to vote.--Coloneh 23:03, 8 May 2007 (CEST) Yeah I agree. The concept is good but it would only work if we had some way of restricting the amount of builds submitted. The submissions will come in faster than they can be voted on. Its also makes voting a bit overwhelming and might discourage people from voting, which would compound the problem of too many builds not enough votes even further. -- BrianG 01:04, 9 May 2007 (CEST) Also, a problem i run into often is i find (lets just say) a good assassin build. but all the votes on it are "bad". then u read teh reasoning and find out that its bad because theres another warrior build that does better... i dont play a warrior so i dont use warrior builds, so we deffinently need to be able to say "if you have a warrior, try running this!". I understand different classes are different skills, but sometimes an assassin would like a good raw power build that doesnt get put down for being inferior to a warriors. dunno, maybe this would be the job of the "buildmasters" or whatever they were called in earlier pages. Eronth 01:11, 9 May 2007 (CEST) Let me kick this around in the old brain housing group to see if I can streamline the process into something a bit more managable... I guess I am a bit to detail orented. Shireen 02:29, 9 May 2007 (CEST) Added a more detailed description of how the voting process would function mechanically in the scripting section at the bottom. Shireen 19:42, 11 May 2007 (CEST)
|
![[RDF Data]](/fct/images/sw-rdf-blue.png)