Open World/Editors Notes
- 1 Overview
- 2 About
- 3 Do You Make All These Builds?
- 4 Build Philosophy
- 5 Build Submission
- 6 Build Edits
- 7 Voting Rules
- 8 Build Deletion / Archival
This is a simple page of notes from the Editor of the Open World Section. This page will work to answer many common questions and explain a bit about how the Open World section functions from the point of view of its Editor.
I'm Jupiter. I also go by Star or Clover fairly frequently, and I manage the Open World section here on Metabattle. I've been playing Guild Wars 2 since a few months after launch, with around 8k hours in the game, most of which are on Guardian. I was briefly involved in some of the higher-end NA speedrun guilds during the Dungeon and T50 fractal meta, and lead a raid-focused, blind-progression guild for a few years after Heart of Thorns was released. By the time Wing 5 was released, I had stopped raiding and instead focused on Open World and more general play due to a number of factors. I run a youtube channel dedicated to Guild Wars 2 builds in addition to this section.
Do You Make All These Builds?
I've written most of the open world builds on this site, though I can't take credit for all of them. There have been a number of users that submitted builds either anonymously or through Metabattle's proper channels. In these cases I'm very grateful, as I'm just one person so maintaining such a large repository can be stressful at times.
I always welcome help, so if you want to contribute I highly encourage you to do so.
A large number of questions come in regarding build philosophy, so I hope this section will help address some of those. There are a number of aspects we base build design on, as follows:
Open World builds are designed with consistency in mind. This does sometimes mean sacrificing some damage, or losing some of the strength the build's raid counterpart might have. To me, this is a more-than-acceptable tradeoff, as players in open world are generally looking to farm gold and relax rather than push themselves hard for hours at a time. This doesn't mean that DPS isn't important, just that sometimes tradeoffs are made to ensure success.
Builds should be comfortable to play. The reason for this is that in open world, most players are not looking to deal top damage, and DPS breakpoints in open world are quite low - many of them are so low you can pass them with an entire squad of naked players. With that said, DPS is still important so finding a balance between comfort and damage is always the goal.
When we evaluate a build for comfort, we look at how taxing the build is to play for long periods (30 minutes+) of time and the builds Skill Floor and Ceiling. Builds with a lower Floor are generally more popular and more comfortable to play, though this is not a hard rule.
There are two kinds of damage metrics to consider in most PVE - Burst and DPS. Burst damage represents damage output over a very short window of time, typically 5-20 seconds. DPS considers the damage dealt on average, usually over 45+ seconds. When we evaluate a build for damage, we consider both of these in relation to the build purpose. Builds dedicated to solo bossing will have longer fights, so DPS is more relevant. Builds for general farming prefer burst since trash mobs have low HP.
Damage is an important factor in our builds, though it is not the only one we consider. When examining a build, remember that its damage output may not be the most important thing it offers.
Defense is an umbrella term that encompasses two things: Buffer and Sustain. Buffer is roughly analogous to effective hitpoints (EHP), while Sustain represents self-healing. These two aspects are very important to builds that are meant to be played with no allies; Sustain is especially a critical component of builds, as regaining hit points is usually more efficient than trying to stack more EHP.
When we evaluate a build's Defense, we look at how well it performs with defensive gear or defensive traits. If its Damage and Comfort are not drastically affected by utilizing some defense, it passes the test. If you have to sacrifice a lot of Comfort and Damage to get extra Defense, it fails the test and must be re-evaluated.
Mobility is icing on the cake, typically, especially with the introduction of Mounts in Path of Fire. Generally speaking, Mobility becomes important on builds that are designed to be used without mounts for a time, such as in chain-farming scenarios (i.e Kourna Inquest Farming) or rapid zergs, such as the Mad King's Labyrinth or Overflow's LS4 Train. These events seldom have a lot of time for mounting due to being in-combat for long stretches of time, and as-such in-combat mobility becomes important.
When we evaluate a build for Mobility, we examine what it has to sacrifice to gain that mobility and how important extra mobility is to the build as a whole.
For builds designed to assist allies, Support becomes a key factor. This is a broad aspect that encompasses factors such as healing output, boon support to allies (i.e. Quickness or Stability), and unique buffs such as warrior's banners. Support builds can be especially useful in a zerg to allow DPS players to focus on high damage output, though a zerg should not run many of these as they typically lack damage themselves.
Due to the need for tagging, Support builds typically focus on Power, Concentration, and Healing power gear. This makes Harrier's a key component to most support builds, though some may make use of Condition sets like Plaguedoctor's or Celestial . The important thing is that these builds have enough damage to get tag-credit while in the zerg while at the same time granting allies critical support.
Support builds are generally evaluated for the factors above rather than their damage or defense.
If you want to submit a build, there are a number of things you'll need to do.
1. Review Submission Guides
We have a number of guides on the site that will show you how to submit a build. Metabattle uses mediawiki markup, so you will need to learn a bit of that to submit builds. The best place to start is usually by copying a build and editing non-relevant parts of it out, while keeping the general format.
You can find our submission guides here:
2. Make the Build
Have the build ready before submission so it can be referenced while creating the page.
3. Review Open World Build Rules
There are only a few. These are in addition to the wider site rules.
- Avoid meme- or joke-names.
- Avoid duplicate builds
- Avoid trash talk of any kind
- Always follow the standard template listed in the Style Manual, or copy the template used in Tempest - Condi Tempest (This is used as an example, any updated build should work)
- Do not post a build without a comprehensive usage section. Failure to provide an adquate usage section will result in Archival within 2 weeks of build posting. See Firebrand - Cele Firebrand or Tempest - Fresh Air for examples of adequate usage sections.
From here, create the build by following the Style Manual and Tutorial listed above.
If you believe you have a reason to edit an existing build, feel free to do so. Afterwards, please post a comment on the Disqus page of the build (found at the bottom) detailing changes so they may be more easily reviewed.
Anyone can post a vote on any build they like, and you are heavily encouraged to do so. However, do not include rude or crude language in your vote, and do not use the vote to provide feedback. Instead, place your vote and explain the reason for your voting. If you have some specific feedback, please leave it as a comment on the page, as this will appear in our Recent Comments feed, which I review daily. You should try a build before voting on it, as specific synergies of a build may not be apparent until you play it.
We never delete votes unless the site's or section's rules are violated in them.
Originally, I would never vote on any builds I created and asked other authors to do the same. Recently, this rule as been removed due to a lack of votes on Open World builds. Even if you created the build, please vote on it.
Build Deletion / Archival
In general, we avoid outright deleting builds unless they are direct duplicates of an existing build. Instead, we archive builds due to a small number of factors.
- Is the bulid especially similar to an existing build? If so, we may merge two builds.
- Is the build heavily outdated with an absent author? It may be archived if it is an especially niche build.
- Is the build's usage section inadequate? It will be archived.
Builds that have meme names may be forcefully renamed rather than archived. Builds that break several rules may be deleted outright.
Anyone can mark a build for Archival by following the directions in the Tutorial. When you do so, leave a comment on the build page stating that you've marked the build for archival. I will personally review requests to archive and either manually archive the build or contact the author for updates.