System & Sandbox Design

The System & Sandbox design page lists notable examples of my work building non-bespoke content: systems, balance, or gameplay elements that were used across different contexts or in different situations.

Destiny 2: “Infinite Forest” Procedural Map Generator

Release: The Curse of Osiris, 2017
My Role: Feature Lead and System Designer
Key Creative Goals:

  • Lean on Destiny’s deep sandbox to create enormous variety

  • Provide interstitial gameplay that activity designers could use for the middle beats of their activities

  • Embrace the inscrutability of Vex architecture and characters goals to cloak the rough edges

The “Infinite Forest” was a system that could generate maps and combat encounters, that activity designers could deploy inside of their activities to get ready-made content.

It was built out of a large set of “rooms” that were pieced together by the system. Each room was a set of baked environmental geo, lighting, etc.; content that would usually be loaded as a single asset for an entire environment all at once.

I was the feature lead, which meant that I was responsible for ensuring that every aspect of the feature was on track to ship successfully. This meant that I had to stay abreast of every contributing discipline’s work, ensure alignment on creative and milestone goals, and stay in constant communication with the creative director.

I was also the only designer working on the team for the feature. I was responsible for the modal rules of the environments, things like:

  • Defining how do players progress

  • Deciding how the generation algorithm determined which rooms to place and where

  • Ensuring that players understand what their objectives were and how to navigate

  • Designing the combat encounters and working with environment artists to design the combat spaces.

The lion’s share of my day-to-day work was on defining the combat encounters: figuring out how to organize the “encounter atoms” that were randomly placed together to create wide variety in encounter experiences. The solution we shipped involved defining sets of combatants that served certain tactical roles in combat, for example: mid-range fodder, snipers, “anchors” that had a lot of health and drew player attention, and more. We would then randomly combine 2-3 of these atoms together to create a full squad of enemies. I had to implement a number of special rules about how these were combined: certain atoms were mutually exclusive, and others, like anchors, were 3-4x more likely to appear.

One major problem that we struggled with was that too much randomization being available all at once meant that individual runs didn’t feel distinct. It all became undifferentiated experiences in player’s mind. Towards the latter half of production a lot of my effort was spent on adding in rules and settings that would allow us to “theme” runs through the system in certain ways. A simple example is that in Activity A, only the “Fallen” combatant faction appears, but in Activity B, the Fallen or “Vex” combatant can appear together. A more nuanced example was that I added in special “hero” encounters that were more hand-crafted, and made it very likely that one, and only one, would appear in each run.

I also worked closely with the activity designers that were utilizing the system to help them set it up in their activities, and to help match the theme to their activities’ themes.

View Gallery

Infinite Crisis:
Champion Designs

Release: Infinite Crisis, 2015
Role: Sandbox/Gameplay Designer

Over two years of production, I designed, wrote, and implemented twenty different champions for Infinite Crisis, a DC Superhero MOBA.

This role required careful consideration of the way MOBA characters are balanced and the different functions they fulfill in a MOBA match. It also required careful attention to moment-to-moment gameplay feel.

The champion designers owned the animation trees for our characters: timing, blending, and other elements were under our control. We were ultimately responsible for making sure that abilities and movement felt responsive, clear, and intuitive, to both user and target alike.

This role required close collaboration with gameplay engineers, map designers, animators, VFX artists, our in-house competitive QA team, and more.

The pipeline for our characters was 4-6 months, with multiple characters in flight at different stages of the pipeline at any given time. The typical pipeline was:

  • Pre-production:

    • Kickoff: Brainstorm major themes or fantasies for the design, pick 1-2 to pursue.

    • Kit Iteration:

      • Design: Design a potential “kit”—a set of skills and abilities—for the character. A character always went through at least 3 major design revisions before entering production.

      • Feedback: The design team had formal review meetings for each iteration.

  • Production:

    • Formal Spec: A formal spec that we’d use to help guide production—asset creation, engineering requests, etc—was written.

    • Implement kit: A gameplay engineer would do the first pass on creating the abilities of the character. Afterwards the designer would take over iteration.

    • Playtests: We did playtests 2-3 times per week and generated tweaks and changes for the character, that we’d try to turn around within a week.

  • Post-Production:

    • Redesign: Some characters, after hitting alpha or beta stages, would go back to the drawing board for major iteration outside the scope of balance tweaks.

I have some case studies and example documentation from this project on my design blog:

View Gallery

Destiny 2:
Activity Modifiers

Release: Seasons 13-17 (2021-2022)
My Role: System Designer

During this time I was a member of the Destiny “Activity Frameworks” team, a system-focused team that handled a lot of the systems surrounding re-using, scaling, and difficulty of activities, as well as setting conventions and requirements for activity types and presentation.

One of my responsibilities on that team was to handle work involving “Activity Modifiers”, also called “Skulls”: additive rules or mechanics that could be layered on top of activities to create gameplay variety at different difficulties or upon replay.

In my time in this role, I:

  • Built a total of 18 new modifiers

  • Removed many low-impact modifiers

  • Updated which modifiers could appear where, to ensure that we were stressing the right combinations of player skill axes

  • Introduced “informational” modifiers that told players what kind of challenges to expect, so that they could craft their loadouts

  • Pitched and built the concept of “Seasonal Modifiers”: unique modifiers that would be used for just one season and then retired

Dungeons & Dragons Online: Druid Class

Release: Menace of the Underdark, 2012
My Role: System Designer

Early in my career I was entrusted with the work of designing and implementing Dungeon & Dragons Online’s version of the Druid class from D&D 3.5 edition.

Players had been clamoring for this class—one of the base classes from the tabletop game—for years. Another more senior designer was responsible for building animal transformation skills for the class, and I was responsible for everything else. This included:

  • Designing feats, talents, and “enhancement” trees

  • Designing and implementing the Druid spells

  • Designing preset builds

  • Working with our various resource teams—art, UI, test—on all matters related to the class.

  • Extensive playtesting for balance and quality

Galleries

Gallery: Infinite Forest

Gallery: Infinite Crisis Champions