FANDOM


Blue check

This page is a style and formatting guideline on PvXwiki.

It has general acceptance among editors and is considered a standard to which articles should adhere. However, it is not set in stone and should be treated with common sense and the occasional exception.

Shortcut:
PvX:WGB
PW:WGB

When writing a build article, it is important to keep in mind many different things. This article lists some basic steps to help you submit good builds to the wiki.

Quality of writing

  • The build should be written precisely, to specific detail, without sounding redundant or stupid.
Review your use of grammar in the build.
A good rule of thumb is to try and avoid compound sentences whenever possible.
  • Build should not contain any first-person point-of-view.
Convert all POV's into second-person (i.e., I would take a break here -> you should stop here).
  • Build should consist mostly of fact, rather than opinion.
Do not use a lot of "I think" or "It is believed that".
  • There should not be any spelling or grammar mistakes.
Use a spell checker and make sure there are no red links because you've spelled something incorrectly.
  • Avoid the use of words or terms that apply time or temporary effectiveness in a build.
For example, the terms "the recently buffed", "the imbalanced skill", or "despite the nerf" should not be used in build articles.

Build Performance

  • Builds should have been tested prior to posting it on PvXwiki.
Do not submit "ideas" for builds.
  • The build should be able to achieve its goal, and do so with minimal difficulty.
There should not be other builds out there that do the same job with less effort.
  • The build should be able to deal with the range of situations it is designed for, and survive through minor disruption.
The build should include ways to deal with the most common counters to the build
  • The build should be able to last for thever or regain spent energy. (see energy management)


PvP Builds

  • Should take into account the different level of intelligence of the opponents.
Many tactics that work against the AI will easily be countered by real humans. Do not rely on these for PvP.
  • The build should take common other PvP builds into account.
Try to exploit tactics that are common in PvP, while using ones which are not usually countered themselves.
  • Should include what area of PvP they are intended for.
Specify which part of PvP the build is intended for (GvG, Random Arenas, etc) and add the category.

Random Arena Builds

  • The build should adapt to the fast pace of fighting.
For example: There should be a really good excuse, if the build includes no Resurrection Signet.
  • Since teams are randomly formed, the build should not overly depend on other characters.
In particular: It should not be totally dependent on having a monk for healing.

Alliance Battles

  • The build should be able to deal with the NPCs present in the alliance battles.
It is easy to exploit the static character of the NPCs present, the build should aim to do so.
  • The build should specify which tactics it uses in Alliance Battles.
Is the build used for capping, mobbing or something else?
  • There is an automatic resurrection function in alliance battles so there is usually not a need for a resurrect skill.
This seems to be the general opinion of the community, so if you do include one in your build make sure it works well and for a purpose, with clear instructions of when and how to use it.

Competitive Missions

  • The build should be able to deal with the NPCs present in the missions.
It is easy to exploit the static character of the NPCs present, the build should aim to do so.
  • Since teams are randomly formed, the build should not overly depend on other characters.
In particular: It should not be totally dependent on having a monk for healing.

Special Cases

Similar Builds

  • In several cases (Minion Master builds, Assassin Combo builds, 55 monk builds) of builds which are very popular in the game, a huge number of builds have been submitted to the wiki, which only differ in minor aspects. Always search for similar builds before submitting; the site does not, in many cases, need multiple articles of very similar builds.

Existing Builds

  • If your build already exists, there are two options available to you.
    • If the existing version of the build is unfavored, the unfavored build should be modified to your liking, rather than creating a new build page.
    • If the existing version of the build is in any other category, the build should simply not be made. Instead, suggest changes in the existing version's talk page as to why your version may be better than the current revision of the article.

Keeping an open mind

Don't be discouraged

Community content is available under CC-BY-NC-SA 2.5 unless otherwise noted.