Some dev commentary can be found here. Work in progress.

"Personally, I think forever 29 wasn't ideal because there was no protection against bad luck. There is a non zero percentage of players that tried every week to get capped but just couldn't get what they needed. That sucks, and I think makes for a pretty crappy experience. I think having some element of guaranteed progression helps mitigate that; the tricky problem is balancing that guaranteed progression with the feeling of excitement of getting what you need. Always room to do better!"

  • They had to turn off item comparison in the vault to make an expansion work on legacy consoles for D1. (Cozmo, Reddit)
  • Originally they wanted the raid armor to have 2 mod slots (one normal, one raid) but they ran in to some technical hurdles that they didn't have time to solve. (Daniel, Reddit)
  • Player top speeds affect world loading, hence why they have to be careful with increasing it and why there are no sparrows in certain places. (Josh H, Twitter)
  • The root cause of raid spawning issue was the cinematic and the start of the raid pushing some of their memory budgets over the edge as players swapped around gear later on. (Cozmo/Lemming, Forums)
  • Tower Blackscreen saga:
    • The Tower blackscreen issue was a very difficult issue to identify and fix. a Lore Scannable was duplicating in the Tower when transitioning between the Courtyard and the Hangar, eating up memory. (DMG, Reddit)
    • The Lore scannable was Ana Bray’s log. (Lemming, Reddit)
    • The Speaker’s quarters book was moved for good measure as well due to concerns that it could lead to similar bad behaviours. (Lemming, Reddit)
  • Oryx Basketball Court, and why it was useless:
    • It came in super late as a challenging to reach secret and we hoped it would have a reward but it was too late for ship. Options were ship it as a hidden spot to go dunk on friends w/o reward or cut it. But the excitement around it led to early planning of future meta puzzles.” (Andrew H, Twitter)
  • Joe Blackburn provides some insight on the old raid token system.

Brendan talks about Crota's End structure:

During dev on Crota, we would frantically move from one side of the arena to the other when Crota moved. It never occurred to us that people would stand on the center windowsill, negating the purpose of his movement. We learned a lot from that raid.

Player containment is not a thing. If players can get somewhere, they will, even if it doesn’t seem advantageous at the time. Everywhere in your encounter space needs to have a purpose. If it doesn’t, try to cut it.

Players like to contain risk and variables to as few points of failure as possible. If they can pile all the responsibility onto a single person, they will. Usually, this is only fun for that one person. “Ok, you guys stand here and shoot when I yell. I’ll do the rest.”

Don’t expect players to do the mechanic unless it’s absolutely compulsory. “No one will solo the Abyss. They have to stick together or they’ll get...oh, look, they’re skipping whole sections... oops.”

I thought I was super clever designing the bridge encounter. “No one will cross the bridge without someone holding the plate.... oh. Look at that. They’re crossing the bridge without anyone holding the plate.” Again, see point about player containment and compulsory mechanics.

“They have to kill all the adds even after Deathsinger is dead.” Why on earth did I think this would be fun? There’s no sense in drawing out an experience. Identify the core experience, fill it out, then stop. If it feels like unnecessary steps, cut it.

Don’t add mechanics that players only experience if they make a mistake. Crota 1.0 summoned the oversoul only when people died. If you never die, you never have to respond. The reprisal patch changed it so he summoned it after every DPS cycle. Much better implementation.

Anyway, I’m rambling. Hopefully, some of this is interesting or useful and not completely obvious for anyone interested in encounter design.

Oh, one more important thing. We were basically done with Crota before destiny 1 even shipped. There was a lot of guesswork as to how people would actually play the raids.

To clarify, “done” usually means content complete. That is, stop adding stuff, fix the bugs, finalize text and localization, etc. You can’t keep making changes after a certain point because then the game will never ship. (Twitter)

Soloing Crota's End (albeit without exploits) was a big inspiration for the Shattered Throne. (Twitter)

Generally, we’ve gotten better at predicting player behavior based on experience and having our internal “Team Velveeta” playtest it. They’re a group experts who find the most efficient way of doing the fights. (Twitter)

We play the raids in retail just like everybody else. Part of our job is understanding player psychology. We also have a l33t in-house group that helps us with tuning and exploits, not to mention the embedded raid test group, who are goddamn ninjas. (Twitter)

Brendan on why bosses are just scaled up versions of existing enemies

This is a tale about that's pretty common among most studios. Stay a while and listen...

You're a designer and just started early design work on the next project. You're in a meeting talking about what the next boss will/should be. The lead says, "We have 6 months from start to launch, which means in reality, we have a lot less time."

You cheerfully suggest that the boss be a brand new, giant squirrel-eagle cyborg that flies around the raid breathing fire. Immediately, the entire staff of animators, tech artists, FX artists all look at each other and cringe. "What?" you ask.

Not being an artist, you don't understand their looks of horror. The character artist who will be responsible making the boss gently explains to you that it will require a new rig (the skeleton that actually lets the thing move) which will take 2 months alone...

... all new animations, concept art exploration time, all new FX, audio, and we still have deliverables for the other teams working on this release. Then the tech designer says, "We also don't have flying tech in this engine. That's months of engineer time."

"Plus," she adds, "We have no idea what space we're building it for. Is it bespoke where it flies around a spline, or can it just path anywhere? How will it..." The lead steps in. "Okay, no flying boss. We don't have time."

"So," you ask, "what can we do?" The rigging artist says, "Well, we could add a couple bones to the rig. Maybe add a couple attack animations. Maybe play with the walk cycle a bit."

"Remember, we only have about 3 months." I thought we had 6? "No, *we* have 3 months. We have to finish it and move on to the other features for this release." Ok, scaled up squirrel it is. How big can we go? "Well, anything bigger than x3 is going to look bad because it'll mess with the animations and FX, so we'll have to redo those as well." Great, so much for my squirrel boss idea. What can we use to make a really big boss? "The elephant combatant is already pretty big. We can scale that up."

But we already used that one last...

"We can add some spikes to it." Spikes are cool. What about a jump attack? "Are you using a perfectly flat space with no geo that it can get stuck on or otherwise mess with the physics?" Well, no, but...

TLDR: making a new character model is time consuming and expensive because you have to make all the stuff that supports it. Devs can make a lot more stuff by reusing existing assets and customizing it.

To be clear, this is basically an abridged version of my 12 yrs as a game designer across multiple studios. (Twitter)

Edgar talks about ghost stories:

I think the funniest story was that, when we were first experimenting with the API, there was a bug that allowed us in our internal environments to strip off all weapons and armor. When you did this, anyone looking at your character would only see hands and a little bit of your neck! #ghostmode (Reddit)

When you're running around in the world and the game thinks it's an area where you should have your helmet on, it doesn't even attempt to render your face or any facial customizations - because it assumes that you won't be able to see them! But with this bug, the unequipping of your helmet is something the engine isn't expecting to happen and so it continues not attempting to render your head. And you'll notice that you never really see any other parts of your body: your neck, hands, and sometimes head are the only three unarmored parts of your body that you can ever see. Thus is how we ended up with nothing but floating hands and neck with that bug! (Reddit)

On not wearing helmets on "combat" areas of the world: I asked around and it sounds like it's for several reasons: technical (the rendering budget while in activities that have a lot of action going on don't include being able to render the higher-cost facial features) as well as some potential design/ratings concerns. (Reddit)

On Areas being too dark:

Ideally all artists, designers, and players would have identical vision and calibrated displays. But players reported some areas were too dark and it was hard to play. I spent today implementing a debug mode for us to identify these areas before they get out in the wild. Based on an "out of the box" LG OLED to establish worst case black levels, with default game brightness.

It raised questions about what features to exclude from measurement, and the nature of whether or not a render feature will generate player-decision-affecting information; information is a key term. If a cave is black and a feature remaps it to grey, it isn't adding information.

Some pixels seemed valid, actually above black from volumetrics being rendered in front. Theoretically they could be used to 'shape' the geometry, but the artist fix of slightly boosting the light isn't that damaging to the final image to exclude this case. Disabling these.

Others were valid due to colour grading boosting black levels up. Our grading takes place after tonemapping (I know), so grading was not creating information that was being lost in the shadows, only remapping it to a different colour. Disabling this.

Often a frame is made too dark due to tonemapping or a wide dynamic range autoexposure, so leaving both active. Then highlight areas in red that fall below this empirical black point and kindly ask fellow devs to trust it, regardless of their monitor looks like. (Twittter)