You’re kinda missing the point, which is what the rest of the sentence goes into. They are >not< “clearly designed” to be “optional” just because there is no (for example) barrier.
Maybe it’s better if I describe some of the things that I’ve encountered in development. Occasionally, there’ll be a ticket that comes across to us, the idea behind “X should do Y”. There are many responses that can happen, some of which signal intent or a specific design idea, some of which do not, and some of which are based on concerns that have nothing to do with design intent. For example, here is a nowhere-near-exhaustive list of potential calls, and every company takes different stances at different points, and some of these involve decisions not by developers, but by product owner/project manager type people. That’s a lot of disclaimers, but hopefully it’s clear why:
- sometimes we disagree.
- sometimes we disagree, and signal back that it’s working as intended (in issue tracking software, this might be a resolution of “Won’t Do” as opposed to “Won’t Fix”).
- sometimes we might agree on that, and do it.
- sometimes we’ve already internally discussed that it should not behave that way for whatever reason (and that reason may not be available to whoever made the ticket)
- sometimes we might agree that it’s a good idea in principle but decide it doesn’t need changing. There’s variations on this like “It’s annoying, but not yet a problem”, or “It’s a problem, but it’s not worth the fix at this point in time”.
- sometimes we might agree that we should but there’s X Y and Z tasks that are higher priority first (and since there’s always new tasks, a specific ticket might always get bumped down in priority and not handled for years).
- sometimes we agree but will only get around to it if we’re doing a change in a related area (what with every change needing a certain amount of testing, QA, and what not).
- sometimes we’ll think about it, but we’ll get back to the customer that we’re only prepared to do it if they pay us $$ to do it, since we can argue no one else wants that functionality/behaviour (ofc, nothing stops us from then marketing that to someone else later)
How come the same wasn’t done for the bridge after Skycaptain in Freehold or the first two bosses in Plaguefall? Or an invisible wall blocking the bridge to Harlen until you kill the council and the arena boss?
I can’t answer that for you, since I wasn’t part of their internal discussions. I can speculate on a few possibilities, but it could get really long.
My guess is people skipping Augh because he does take a while to become attackable after you kill lockmaw on heroic. See it sometimes in timewalking too. According to Wowpedia …
No, I’m talking Lockmaw specifically. Unfortunately, neither wowpedia nor wowhead are great at capturing that kind of information, especially since we’re going back a full decade. And also like I said, it might have been on a PTR build before even going to Live, in which case it wouldn’t really be “patch documentation”.
Sidenote, what is with your quotes lol. Are you like getting rid of the person you are quoting so they won’t get a ping that you replied to them?
It’s just the > shorthand. I’ve had plenty of practice using that so it’s easy for me to type that on the fly, and coincidentally in Blizz’s editor that doesn’t attach post history metadata the way [quote] does. But I don’t care about that last part.
Maybe there’s an analogy to be made there about intent vs consequence.
