The purpose of this page is to offer guidance to bring alignment. They are not hard and fast rules, and there may be times where they can be ignored in favour of an improved reader experience. If you're unsure whether your work aligns to the principles on this page, shoot Harry (or any editors) a message and they'll be happy to review the piece and come back to you.
Creating the Build
Naming a Build
Once you have created a build, the first thing you will need to do is name it. Our naming scheme is very simple.
[Damage Type][Boon][Specialization]
Example: Condition Quickness Herald or Condition Herald.
If the build is not a support class, then [Boon] can be skipped. In the majority of cases, there are only two options for boons - Quickness or Alacrity. If you feel that the build you are working on does not fit into this naming scheme, please send us a message.
Localization and Build Categories
If you are reading this guide in English, then the chances are that you should be setting the build under the "en" Locale.
The category that the build is assigned to is more of a complicated feat.
Recommended is for builds that are performing well during the current meta, excluding the use in high end only gameplay.
Viable is for builds that are updated and maintained, but aren't going to be a solid choice to competently compete in the current meta. We are fully aware that there is the arguement that every build can perform well so please use your own judgement.
Beginner is for builds that have been broken down into smaller steps to help first time raiders get into the gamemode. Typically, builds that go into this section have already been discussed before with either Harry or Hodge. If you have suggestions or ideas for builds in this category, please contact us.
Legacy is for builds that are no longer maintained and can be seen as an archive section.
Assuming you can defend yourself when questioned as to why your build is in X category, then your judgement is fine.
Introduction Date and Tags
Although not technically the introduction date of the build, this should reflect the most recent balance patch that affected this particular build. Please keep an eye on this to ensure that you update it to the current balance patch if required.
Tags are used when filtering builds via the build page. Multiple can be selected and attributed to a build.
Build Overview
This section should be short and sweet.
- What is the build?
- What does it provide?
- What special features does it have? If it doesn't have any special features, is it a hard build to play?
Overviews should be a maximum of four to five lines of text. They should not include any information about skill options, trait options or any type of variations. It is just a brief description of the build at hand.
Variants
Rotation
Rotations can be created in one of two ways. The first, and more common approach, is to have an Opening and a Loop section. Ordered lists should be used in both sections.
Opening
- Weapon Swap
Loop
- x 5
- x 2
Auto attack chains should be written out using between each attack. Mutiple skill uses can be noted with x 2 or x Y at the end of each line.
If the rotation does not have counted auto attack chains, then you should not list them. Instead, make a note in the Rotation Notes section.
Rotation, Skill and Trait Notes
Rotation Notes should be populated with the most vital information when it comes to completing the rotation. This section should be a maximum of four to five points of concise information with no fluff or long strings of text. It is used as a reference to the reader to quickly glance at.
Advanced tips and more detailed information should not be listed here. This information should be included in the gameplay guide.
Skill Notes is used to display the possibly variations of utility skills. This information should be minimal with no advanced reasoning. Simply the most common skill to replace, followed by the options in bullet point form.
should be swapped out first:
- for Breakbar Phases.
- for Aegis to block attacks.
- for Stability
- can be taken if you need to reflect any projectiles.
If you feel that this is not possible for your build, then it should be reflected in the gameplay guide.
Trait Notes should be treated in exactly the same was as Skill Notes.
Closing Remarks
Build pages should be short, concise and to the point. Additional and advanced information should be listed in the gameplay guide. If you are unsure about where to place your information, then please contact Harry or Hodge.