Summary (TL;DR)
Implement a new build system with “build slots” where users can define all aspects of a build, equipment (armor, weapons, trinkets), traits and heal/utility skills. These “build slots” can be saved and activated whenever the character is out of combat. When a “build slot” is activated, the game client automatically changes the characters’ equipment, traits and heal/utility skills to those defined in the “build slot”. Equipment in inactive “build slots” don’t take up any inventory space, instead, it’s stored “invisibly” until it’s activated again. The user can move equipment between “build slots” and the inventory whenever he/she wishes as well as reuse the same equipment for different builds.
Introduction
Arenanet’s unique profession design allows most professions to take on different roles by changing equipment, traits and utility skills. The current system for changing builds is arguably better than most competing MMO’s and the changes to the traits system introduced shortly before the Heart of Thorns expansion was a big improvement. However, problems and frustrations still remain with the current system.
The process for changing a build, although easier than ever, still require a considerable amount of manual labour and double checking to make sure a build is configured correctly. To change a build, the user must open the build tab in the hero panel, change up to three trait lines and choose up to nine major traits. In addition, the user might have to switch out a considerable amount of equipment, which might involve a visit to the bank to withdraw the desired equipment, as well as deposit the previously worn equipment. It should be noted that it’s possible to carry equipment in the inventory, thus eliminating a trip to the bank, this however decrease the inventory space available, forcing the user to buy additional inventory space and/or buying larger inventory containers. But, even with an increase in inventory space, more trips to an NPC or bank for clearing the inventory is required when carrying equipment in the inventory. It’s also important to note that if equipment is stored in the inventory, special care must be taken when selling and/or salvaging equipment to avoid accidental selling or destroying of equipment used in other builds. Finally, the user must change the healing- and/or utility skills on the character. For users switching between different kinds of content often, these steps could easily become tedious as it might be required several times during a gaming session.
I propose a change where not only the outlined problems are solved but also where Arenanet’s desire for build diversity and experimentation are more easily accessible and feasible. Additionally, my suggestion opens up for a potential increase in monetary revenue for the company. Below, I begin by offering my suggestion in detail, after which I exemplify my idea with an example of implementation for completeness.
The Suggestion (Build slots)
I suggest a completely new system for “building” a character which allows the user to define All aspects of a desired build in one central place as well as the ability to name and save the complete build for later use. I suggest that, for each character, there exist several unique “build slots” which allows the user to create a complete build, containing trait configuration, equipment (armor, weapons, trinkets) and heal/utility skills. These builds can be saved and at a later time, activated as the “current build”. A user could, for example create three different builds named: “raid”, “wvw” and “fractals”. Depending on the type of content the user want’s to experience, the appropriate build is activated. When a build is activated, the game client automatically switch out the traits to those defined in the selected build, the game client also automatically unequips the current equipment, stores it in an invisible container and then equips the equipment associated with the selected build. Since new weapons (might) be equipped in the switch, the weapon bars change automatically. The healing/utility skills are also automatically changed to correspond to the healing/utility skills defined in the selected build.
As briefly mentioned in the previous paragraph, I strongly suggest that the game be expanded with “hidden” containers for any and all equipment (armor, weapons, trinkets) defined in each “build slot”. Once equipment is placed in a “build slot”, regardless whether it’s active or not, it will not take up any inventory space until it’s placed in the inventory again. Neither is equipment in “build slots” available to salvaging or selling. Understandably, the concept of allowing users to carry equipment without inventory penalty might sound provocative at first glance. I however think that “build slots” with hidden containers will greatly enhance the user experience, both in terms of using multiple builds (due to the problems with storing equipment), as well as an overall positive attitude towards the game and Arenanet as a whole. It’s also a fairly logical step and a large piece of the puzzle in creating an all-encompassing build system. There is also a potential for monetary gains which could help push this idea over top and lay any potential controversy to rest. In the following paragraph, I outline this in further detail.
Since these changes are fairly technical and will probably require a larger refactoring of the current system, it will come with a one-time development cost. It should be possible to finance the refactoring, as well as increase revenue, by introducing the ability to add additional “build slots” as a purchasable unlock in the gem store. The “build slots” unlocks could be character bound as well, meaning that each user must unlock “build slots” on a per character basis, much like how the current gem store “inventory unlock” works. The number of “build slots” a character starts with could also be fairly low. By adding additional “build slots” to the gem store, any potential penalty today’s user faces for unlocking inventory space will be transfered to “build slots”. Finally, I would argue that Arenanet is already an industry leader in MMO innovation, the time is right to take the last few steps in perfecting and hopefully standardizing the way character choice and diversity is presented to users in MMO’s. With this rationale, I submit that there are no non-technical reasons for not allowing invisible “build slot” containers.
Additional suggestions & notes
- When the user is in combat, the ability to switch build is disabled.
- It’s worth noting that individual pieces of equipment should be usable in multiple builds so a user can reuse equipment. In my “Example of implementation” section, I provide a solution for how this could be implemented from a UI perspective.
- This suggestion, in it’s entirety, doesn’t affect PVP.
- A “build slot” could be “tagged” as a WvW build, making it the default build that is automatically activated as soon as a character enters any WvW instance map. This “tagging” feature should however be made into an option available on all “build slots” but only usable on one at a time, i.e. there should not be a specific “wvw build slot”. See the “example of implementation” section for further details.
- If Arenanet feels that users should not be able to easily change build while in WvW, the ability to change build could be made to only work in the starting/safe zone. There should however Not be any restrictions to the functionality or limitation of build slots in WvW. The same argument of unlimited use of “build slots” also should be valid for all other content.
- It’s important not to set a potential Maximum number of possible “build slots” per character too low since a lot of variety might occur when this system is introduced. The system should be able to handle at least 10 build slots per character.
Example of implementation
- In the hero panel, in the equipment tab, add a submenu called “traits” which allows the user to choose traits (much like the current “build tab” but don’t include the weapon overview).
- Create a submenu for choosing healing and utility skills in the equipment tab.
- Remove the build tab in the hero panel.
- Add a static area at the top of the Equipment tab, which is visible regardless of what submenu (Equipment, Wardrobe, Dyes, Outfits, Miniatures, Finishers, Mail Carriers, traits, Skills) the user has chosen.
In the static area:
- Add a dropdown menu containing all “build slots”
- Add a button for saving the currently chosen build slot (the button is unfocused/“greyed out” and can’t be clicked if no changes has been made in any of the submenus)
- When the user clicks the save button, the current build including equipment, traits and skills are associated with the build.
- If a user has successfully bought a new “build slot” in the gem store, a new item in the dropdown box is added with a default name e.g “New slot”.
- Add a “rename” button which, if clicked opens a popup box which prompts the user for a new name for the selected “Build slot”. Upon clicking “Ok”, the name of the current “build slot” changes in the dropdown box
- Add a checkbox “Default WvW build”. If it is checked, the current build is “tagged” as the default WvW build and is thus automatically loaded when the user enters any WvW zone. Only one build can be “tagged” as the default WvW build and thus, if another build is already tagged when the user clicks the checkbox, the current build becomes the new “Default WvW build”.
- A “copy” button could be added which, if pressed, presents the user with a popup box with a list of all builds, when the user chooses a build from the list, that build is copied to the currently selected build. This allows easy access to tweaking and testing build variation.
- A “clear” button could be added which, if pressed, clears all selections of the current build. Note that all equipment that is cleared and not belonging to any other build might need to be returned to the user’s inventory.
- When a user is to define equipment used in a “build slot”, the user is presented with a UI much like the current “wardrobe” system. When the user clicks on, for example the head/helmet slot all the useable helmets in the user’s inventory, as well as helmets already in the invisible containers are displayed on the side (where “skins” are shown in the “wardrobe”). Note that this solves the problem of accessing equipment already defined in other build slots (unless access to the “invisible container” is added).
- Outfits should be included in build slots.
- Dye coloring should be included in build slots so the current dye patterns changes as builds are activated, this could be problematic depending on how dye’s are implemented and might be overlooked if it’s too demanding.
- Even though it’s not necessary, a build could contain: minis, finishers and mail carriers. These features could also be moved to a separate tab if it’s more convenient.
- Wardrobe could be placed in a separate tab or kept in the new build system but will function as it does today.
- When out of combat, if a user clicks on a build different from the one already active, the newly selected build becomes active and the game will satisfy all conditions in the builds, in other words, the equipment worn by the user will be changed and all the traits and skills will be changed. The weapon bar will reset to the new weapons equipped.
- When in combat, all functionality related to build slots is disabled.
- Since equipment can be reused in different builds, the problem of moving equipment from the a “build slot” to the inventory (while the same equipment is used in another “build slot” has to be solved.
Ideas for moving equipment used in multiple “build slots”
- The user could be prevented from moving equipment from a “build slot” to the inventory as long as it’s used in more than one “build slot”
- When equipment that is used in more than one “build slot” is moved to the inventory a warning message could be posed on screen and/or in the chat window notifying the users that some builds are now defunct.
- A defunct “build slot” could be made unequippable (a red exclamation mark could be added to the “build slot” to indicate that some action needs to be taken).