| abstract
| - Everyone seems to be having difficulty with yes/no concept of build vetting. Some people claim that build voting is pure abstract opinion, yet people can look at a build and instantly tell if is good or bad. Builds are not works of art, they are mechanical systems designed to do specific things, and as such can be rated in accordance with what it's designed to do. This could be best done by giving the build attributes using a numerical value, from 1-10, that are voted on by the community. There would be single core attributes category along with subtype categories that would be augmented by additional sub attributes to meet the builds capability. This would garnish a true evaluation of the build and its abilities, and help mitigate the 'glance and favor/unfavor' people as they would be forced to think about the build. Non-testers could be more easily screened out at that point.
* Each build would recieve the standard "Favored" or "Un-Favored" vote.
* In addition Each build would be rated with the selected region or arena in mind. An idea for the core attributes to a build would be:
* Overall
* Energy/Adrenal Management,
* Survivability
* Micromanagement (Ease of use)
* Vulnerability
* Adaptability
* Sustainment Each subtype is based on the general concept of what the build is supposed to do. For example: Healer/Prot Monk
* Hex Removal
* Condition Removal
* Damage Prevention
* Spike Counter
* Healing
* Utility Additional sub attributes could be added to showcase any 'oddball' aspects the build was designed to accomplish. Such as a SoMW spike monk would also receive:
* Damage Output
* Spike Ability Rating descriptions would need to be created for each attribute, and the number of attributes and template types kept to as few as possible, with oddball builds simply given an additional attribute field to match it's ability. The most important attribute to look, other than the 'Favored/Un-Favored' vote: would be the "Overall" attribute. This denotes the builds usefulness in the designed area in which it is to work. So a build could potential have a high Overall score but low sub attribute scores if it worked very well in the designed circumstance or is part of a team concept. An example of the numerical values of the Overall Category would look something like this:
* 1 - The build is completely ridiculous and does not work at all (such as a build that tries to utilize skills from seven different attributes).
* 2 - The build is simply broken or lacks an elite (most noob or beginner 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 (such as a Pacifism monk).
* 5 - The build works, but there are much better examples of its type already out there (such as the default Zealous Benediction monk suggested by the primer articles).
* 6 - The build works well, but is hurting in a minor area such as condition removal or e-management (such as a Fast Casting monk).
* 7 - This build is solid and would be a good example of it's type (such as the RC/Prot monk for Hero's Ascent).
* 8 - This build works very well and can even accomplish a few things that aren't in its design scope (such as the A/Me Solo Sin).
* 9 - A prime example of what a build of this type should be (such as a stanced LoD Infuser).
* 10 - The Uber l33t version of the build. Will incite a massive nerfing backlash by Anet! (Such as boon prot, back in the day when it worked.) Anything a that an admin sees as receiving a 5 or less is immediately available to be Deleted as in accordance with PX:Well. -The community could figure out what kind of attributes need to be related to each kind of build and then each person, when they vote, put the rating of the build further down on the page. A script would then tally the marks in a table at the top of the page (near the votes) to allow for better understanding of the strength's and weaknesses of the build. I know this would be a lot of crazy work, but it might be a really cool feature to have and fix a lot of problems we experience with the vetting system.
|
![[RDF Data]](/fct/images/sw-rdf-blue.png)