Destiny: Rise of Iron
Destiny: Rise of Iron was my second project at Bungie after the Destiny: Taken King. I wore two hats over the course of its development: senior designer of open world content in our new zone, the Plaguelands, and point person for memory management on the design team.
Plaguelands Open World
The Plaguelands was our new explorable zone for Rise of Iron. It presented a wintry vision of what the Cosmodrome destination transformed by SIVA, rogue nanites from the Golden Age. As the senior designer on the team, I mentored other designers, filled the play space with open world content (including the new Quarantine patrol archetype), and worked with artists to determine the destination’s geometry and player flow.
Design Mentorship
I mentored junior and mid-level designers on the project with technical and qualitative content reviews. This included reviewing spec plans with other designers, setting the right goals, and guidance on Bungie design values through frequent desk-side playtests. On the technical side, I gave frequent code reviews as well as advice on how to build content efficiently so as to put less strain on our servers and end-user CPUs.
The Quarantine Patrol
Content & Technical Limitations of Patrols
The Plaguelands ended up being quite large in comparison to our other destinations, and as such we had a lot of ground to cover on open world content. I reprised a number of patrols and public events with new combatants (such as the SIVA Spider Tank), new narrative and voice-overs.
Patrol states in Destiny were tracked strictly per-fireteam. That means you (and your friends) might have a “Collect” patrol, for example, instructing you to collect McGuffins from enemy Fallen, and you might’ve made a certain amount of progress (say 3 out of 10). Another group in the same area could have 8/10. You have no way of knowing, and no method of social cooperation, because there was no way for one fireteam’s patrol script to talk directly to another fireteam’s. The data simply didn’t exist.
So while multiple fireteams could have unique patrol experiences in the same place at the same time, this also prevented designers from allowing players to collectively impact their the shared world. If a fireteam-scoped patrol script attempted to spawn creatures for your team to fight, nobody outside the team would be able to see them or understand what you’re shooting at.
My goal with the Quarantine Patrol was to buck these limitations and create a social patrol that brought players together through cooperative gameplay, on-demand. While patrol scripts could not directly communicate with each other or shared, global scripts, they could raise named “flags” (fancy global booleans) that world scripts could read.
Player Flow
Player activates the patrol via a blinking beacon, receives narrative instruction that a Fallen Splicer Priest is conducting SIVA rituals in the area and needs to be stopped as soon as possible.
The player follows a waypoint to the Splicer Priest’s location, where the Priest is planting destructible SIVA nodes. Other players may also be nearby fighting the same Priest.
If the Priest plants 5 SIVA nodes and completes the ritual before the player defeats them, the patrol ends and players collect their reward.
If the player quickly defeats the Priest before it plants 5 SIVA nodes (or takes their time but destroys the nodes as the Priest plants them), Fallen forces in the area take notice and launch a large-scale counteroffensive via Skiff dropships. In this case, Saladin supports players by sending them a Relic Axe to use against the Fallen. All players in the area can take part in the battle and its rewards, even if they didn’t activate the patrol beacon.
Technical Flow
Player activates patrol beacon, instantiates fireteam-scope script
Fireteam patrol script queries for flags on the global host which could signify that a Fallen Splicer Priest has already been spawned in this area. If no Priest currently exists, the patrol script raises a request flag and waits
The global script, which is constantly watching for raised flag requests, sees this new flag and spawns a Fallen Priest. It raises its own flag to let the patrol know this has happened. This flag includes metadata on where to place the player’s navpoint.
Whether the player is being sent to an existing enemy combatant or a new one has been spawned for them, they follow the waypoint.
As soon as that enemy is killed, the global host raises a flag alerting all active fireteam patrols. This includes information about the type of kill (was it fast enough to interrupt the SIVA ritual and trigger the final battle?), so that the fireteam patrol can update UI appropriately.
Memory Management
While Rise of Iron was the first Destiny project to ship exclusively on the “next generation” of consoles at the time (PS4, Xbox One), we were still saddled with some limitations of the previous generation, particularly when it came to memory management. It’s fair to say that we were completely unprepared for a few megabytes of memory to pose an existential threat in the year of our lord, 2015. Between the new Devil Splicer faction of Fallen enemies and the Plaguelands being our most ambitious new region to date, the project had ballooned to an unshippable footprint. There was simply too much new stuff, and it took an enormous, concerted effort between engineering, design and art to right the ship.
I became the point person for memory on the design team, which entailed daily meetings with most discipline leads. Engineers shared data showing progress made through cuts in certain areas while highlighting which zone/activity combinations remained the worst offenders. I would bring this information back to the team and sit down with individual designers and artists to determine which cuts made the most sense. Some of the calls were easy, some of them were painful to the point of reworking content goals. We all understood that failure was not an option and that an overage of even 10kb could prevent us from shipping, so there was plenty of motivation to drive us across the finish line!