Destiny 2: Forsaken

Major expansion to Destiny 2 containing a new storyline, new enemy faction, new activities, and new gameplay systems

Role:

Studio:
Team Size:
Tools Used:
Years:
Release Date:

Mechanics Designer responsible for enemy combatant design and implementation
High Moon Studios
~150
Bungie Proprietary Engine, Notepad++, Perforce, JIRA
2017 - 2018
September 4, 2018

Mechanics Designer responsible for enemy combatant design and implementation
High Moon Studios
~150
Bungie Proprietary Engine, Perforce, JIRA
2017 - 2018
September 4, 2018

Role:

Studio:
Team Size:
Tools Used:

Years:
Release Date:

Description

Destiny 2: Forsaken is the major Year 2 expansion to Destiny 2 that opens with a darker, revenge-focused story. After Cayde-6 is murdered by Uldren Sov and the Scorn, the Guardian partners with Petra Venj and heads into the chaotic, lawless Reef, exploring the Tangled Shore and the Dreaming City, to hunt Uldren down and stop his corrupted Fallen uprising. The expansion added a lot of new content: two new patrol zones, the hybrid PvE/PvP mode Gambit, the game’s first small-scale raid-style Dungeons, the massive Last Wish raid, random weapon perk rolls, higher level and power caps, and new subclass abilities and supers for every class.

Responsibilities

I worked with the lead combatant designer to design, implement, and polish all the combatants for a new enemy faction, The Scorn. The faction featured eleven unique combatants as well as eight custom bosses is still featured heavily throughout Destiny 2's content.

Notable Contributions

Authored numerous paper designs based on a wide array of different combatant archetypes to deliver a fun, balanced, and engaging enemy faction based on one of the game's pre-existing alien species.
Implemented dozens of rapid prototypes for promising paper designs so they could be evaluated early and iterated on quickly at minimal cost.
Experimented with existing assets and systems in game to give The Scorn a unique feel compared to other enemy factions.
Shepherded new combatants through iteration, testing, and polish delivering the high quality experience players expected from the franchise.

Key Takeaway

Get it in the game early.

Most developers, even veterans, struggle to "see" a design when it purely exists on paper. Imaging all the complex nuances and intersecting mechanics of even a single design can be quite difficult, and time spent debating its merits and potential issues is often time wasted. There are a few possible outcomes and none of them is really improved by having discussions prematurely:

The idea is inherently flawed or not as fun as initially thought. It can be safely abandoned in favor of other, more promising ideas.
The idea has merit but also problems that reveal themselves after experiencing the design in game. This is a good time to discuss and formulate solutions to any problems as well as the feasibility/cost of the solutions and design as a whole.
The fun of the design is immediately evident. The cost to get it across the finish line still needs to be considered, but the team can confidently move forward with the design and assume it will be part of the game after some iteration and polish.

By getting the idea in the game as quickly as possible, the idea can be more thoroughly evaluated by a wider audience. Usually a (very) brief design document is all it takes to build a crude prototype in game, and that prototype often answers, or even identifies, more questions than a long series of meetings or discussions ever could.

There IS a caveat to this, however, in that some developers will struggle to see past the crude prototype into what the final polished product will look like and thus feel that the prototype is "not fun." This is most common with designs that rely heavily on presentation elements like animation, visual effects, and audio in order to feel right, and can be difficult to overcome. The best thing you can do is help those developers "squint" to see what the design could be and get rough versions of those elements in place as soon as possible to help make the prototype more representative of the final experience.

Ultimately, it is often more cost-effective to build and iterate on a prototype in game than it is to linger in the paper design phase. Also, it is very easy to misinterpret a design on paper and much harder to do so with something in game. Once the prototype is "fun", more detailed documentation should be created to better communicate the design to the larger team, especially the ones in charge of building it.