D&D 5E D&D Beyond No Longer Supporting Unearthed Arcana

Announced on their livestream Dev Update, D&D Beyond will be refocusing development on new features and content, citing an inability to keep up with Unearned Arcana in a timely fashion.

We at D&D Beyond regret to inform you that we will no longer be supporting Unearthed Arcana content on our platform.

While we have loved giving users the opportunity to use new Unearthed Arcana playtest material offered by Wizards of the Coast on D&D Beyond, there are a multitude of factors that have made it difficult for us to do so in a way that presents the content the way it was intended, and in a timely way that does not divert our development resources.

[News] The Future of Unearthed Arcana & DDB - News & Announcements - D&D Beyond General - D&D Beyond Forums - D&D Beyond

We at D&D Beyond regret to inform you that we will no longer be supporting Unearthed Arcana content on our platform. While we have loved giving use...

www.dndbeyond.com

 

[Bolares]

This is a pretty big misunderstanding of how products like DDB should work.

If you're sane, you essentially (and yes, I am dumbing this down a bit) build the building blocks you need, then you arrange them in the ways you need. And you have a team who can quickly add features, and those are unlikely to be wasted, because they tend to be possible to reuse later.

I work with three products somewhat similar to DDB and they all have a very different attitude and approach. All of them are aimed a professionals who are obviously less tolerant of bad implementations than gamers, but that's not really an excuse at all, if anything it's the opposite.

You say "Just spells and Feats would be fine", but no, actually you're demonstrably wrong. DDB have shown that they can't handle that. They still haven't implemented incredibly basic/trivial stuff (from a technical perspective) like the Supernatural Gifts from Theros, which are, to all intents and purposes, Feats (indeed, you can drop yours and get a Feat). Why haven't they done this? Because as they've actually admitted before (some of it in since-deleted threads IIRC), they mishandled their design of the backend, didn't allow for anything new, conceptually, to be added to D&D, and then have not had the resources to actually implement this stuff.

What's particularly striking is that they've also avoided cheap "brute force" approaches (i.e. putting stuff in, in a format that isn't final but will work for now). That can indicate one of three things - firstly, completely incompetent management - you can't rule it out! Secondly, it can mean that the actual proper solution is just around the corner - i.e. 3-6 months away or less. That's demonstrably not the case. So we can rule that out (though again, we can't rule out delusional managers believing it was). Thirdly, extreme under-resourcing, which means even the minimal budget to basically data-entry this stuff (which they can do, hence them telling us to do it) isn't available.

And why haven't they had the resources? Not because it's hard - it isn't. It's because they've taken their developers (and no, this is not like gaming where devs are ultra-specialized) and put them on projects like making glowing dice to sell to people, or working on a VTT that's seen apparently zero progress but they've constantly claimed to have a bunch of devs on, and so on.

One thing I'll say... the DDB dev team seems to have not "future proofed" their programming. They made a system that worked for the products they had at the time, and scramble to catch up ever since. I remmember that the big variant options UA (that later was used in tasha's) was BIG hurdle for them....

 

[Oofta]

It never ceases to amaze me how simple people who never do software development think software development is. We used to joke about the (literal) napkin spec we got from the program director that wanted a "simple" feature. He thought it should take 15 minutes, half an hour tops to implement. It took a competent and dedicated resource 3 weeks.

The rules are difficult to implement when you have to take into consideration every single permutation that might happen. Then you need to give practically instantaneous access to hundreds of thousands of characters while doing so seamlessly. Oh, and it all has to be reasonably idiot proof.

In addition, development is only part of the issue. Before it's released you have to do quality testing which ... I can't even imagine. Every line of code you change, every database entry that gets tweaked has to be validated to ensure that it doesn't unexpectedly affect something else.

So no, I'm not going to judge them. People greatly underestimate how complex their systems must be and I don't blame them for not wanting to support UA stuff any more.

 

[Ruin Explorer]

Agreed. Making a customer-friendly front-end facing character builder isn't trivial, but neither is it extraordinarily complex. I mean, look at something like Pathbuilder 2e, which is a very robust character builder for a system that has a much increased amount of complexity compared to 5e. And that's just one main guy running a Patreon!

Yup. I've worked with companies who are starting up things, which, frankly could be used for this, and they often have small numbers of people with tiny budgets - and yet achieve more in a year than DDB has in it's entire dev time.

One thing I'll say... the DDB dev team seems to have not "future proofed" their programming. They made a system that worked for the products they had at the time, and scramble to catch up ever since. I remmember that the big variant options UA (that later was used in tasha's) was BIG hurdle for them....

Definitely correct. They basically admitted as much at one point (possibly more than once). It was bizarre, they just hadn't allowed for essentially anything to go beyond the core three books, instead of designing an extensible system, and it's like, what? Why? If it was 2004 I'd sympathize. If it was like 1998, I'd completely understand. But they got started in what, 2014? 2015? Jeez. That approach was old-hat by then.

It never ceases to amaze me how simple people who never do software development think software development is. We used to joke about the (literal) napkin spec we got from the program director that wanted a "simple" feature. He thought it should take 15 minutes, half an hour tops to implement. It took a competent and dedicated resource 3 weeks.

The rules are difficult to implement when you have to take into consideration every single permutation that might happen. Then you need to give practically instantaneous access to hundreds of thousands of characters while doing so seamlessly. Oh, and it all has to be reasonably idiot proof.

In addition, development is only part of the issue. Before it's released you have to do quality testing which ... I can't even imagine. Every line of code you change, every database entry that gets tweaked has to be validated to ensure that it doesn't unexpectedly affect something else.

So no, I'm not going to judge them. People greatly underestimate how complex their systems must be and I don't blame them for not wanting to support UA stuff any more.

Yeah and people who are involved in software development do have different opinions to that. I'm very well aware (from experience) that trivial features sometimes aren't - but that's either because they're novel in some really wild way that isn't obvious from the outside (not the case here with Supernatural Gifts, as again, the actual devs admitted at one point), or because we screwed up. And this is definitely the latter. Again the devs basically admitted it - they admitted they hadn't planned to allow anything new, just class features, subclasses, spells, feats, items, which given the history of D&D was a spectacular oversight. People were asking for a "generic feature" from literally day on of the DDB. The devs have been discussing it since, what, late 2018? They still haven't actually implemented it, whilst they have implemented glowing dice and various other features, and allegedly have a lot of people on the VTT.

That's a resourcing choice, a very clear one.

Half the issues you're describing shouldn't really be occurring if they'd approached in a sensible way in the first place. It's not something novel or wild. It's a database with a front-end. That's all it is. The character sheet is probably the actual most complicated bit, and making it work with thousands to millions of people accessing it could be potentially be demanding (depending, again, on how they initially approached it), but they've never indicated or shown any problem with the latter so I suspect it isn't vexing them.

 

[dave2008]

This will heavily impact future campaigns, but very little on my current one. I certainly can understand why though.

Are they dropping UA content that has already been implemented, or just future content?

 

[Oofta]

The other aspect of this is simple cost benefit analysis. How many people are using the options? I have no clue, but I assume only a small percentage of their user base cares enough about UA to actually use the options. There comes a point of diminishing returns, especially for "what-if" development that inevitably will be thrown away.

As far as "they should have just made a perfect system", well obviously. Unfortunately it's software that was developed by humans who aren't perfect and software development is not simple. It's not "just a database" with a front end. You could describe some of the most complex systems out there that way, it's meaningless.

All I know is that it works infinitely better than the first attempt that completely crashed and burned before it ever got out of beta stage. I'm not part of the dev team. I have no idea how well the back end is written. But I also don't know how many people took advantage of the UA material and, unless you actually work on the application neither do you. Nor does anyone know the amount of work that goes into maintaining or adding new features.

It doesn't affect me because, like the majority of people, I don't care that much about UA stuff. For a one-off test I can just write something up with pencil and paper. Whether or not they "should" continue to support it, it's a business decision and we don't know all the factors that led to this decision.

But I'm sure that won't stop the people that think software development is "simple".

 

[TwoSix]

But I'm sure that won't stop the people that think software development is "simple".

Shrug. I'm not saying I think software development is "simple" (it really isn't), I'm saying I do it as my day job and it's fairly obvious that the overall development has some faults if it isn't fairly easily expandable, for a product that's designed to be continually expanding.

Granted, that could just as easily be the fault of the project manager and whoever scoped the project, not the actual people that wrote the code, but still. Somewhere a ball got dropped.

 

[Umbran]

This is a pretty big misunderstanding of how products like DDB should work.

How a system "should work" is based on the patterns present in the game. The problem with UA is that it frequently breaks patterns, without warning, and that's a big software system design problem.

D&D Beyond is in an unenviable position, as software providers, in having NO SAY in what gets developed. In well-functioning software shops, when the product people come up with an idea, they allow the software engineers to review and assess it, and give some indication of how easy or difficult it is to do, and have some negotiation with the product people over exactly what will happen, and when.

D&D Beyond doesn't get to do that with D&D content. The game is designed by someone else, and as far as we are aware, the publication timeline is set by someone else.

At least with the major publications, each user pays for the content (and thus the development around it). UA was a series of freebie, short-notice design/implementation challenges from the D&DB perspective. So, yes, I can see the decision to stop supporting them.

Especially when WotC has said they are increasing their rate of publication. There's more official, paid work to be done, so yes, resources will get moved to that.

What's particularly striking is that they've also avoided cheap "brute force" approaches (i.e. putting stuff in, in a format that isn't final but will work for now). That can indicate one of three things - firstly, completely incompetent management - you can't rule it out!

No, we can't rule it out. But on the other hand, if your opening gambit is insulting, well, we shouldn't hope for much out of this, should we?

And why haven't they had the resources? Not because it's hard - it isn't.

At this moment, getting resources is hard. Hiring and keeping software engineering talent has been a challenge for the past six months and more.

It's because they've taken their developers (and no, this is not like gaming where devs are ultra-specialized) and put them on projects like making glowing dice to sell to people, or working on a VTT that's seen apparently zero progress but they've constantly claimed to have a bunch of devs on, and so on.

Yes, so, what you are telling us is that they've put developers on projects that might get paid for, rather than those that don't. And you want to position this as something they shouldn't do?

 

[Umbran]

Shrug. I'm not saying I think software development is "simple" (it really isn't), I'm saying I do it as my day job and it's fairly obvious that the overall development has some faults if it isn't fairly easily expandable, for a product that's designed to be continually expanding.

Your challenge - design a system that's easily expandable... but you are not told HOW it will expand.

 

[Bolares]

Your challenge - design a system that's easily expandable... but you are not told HOW it will expand.

well... making it not easily expandable is hardly the answer. I bet it's super hard to do, but it's still a problem with the platform

 

[Oofta]

well... making it not easily expandable is hardly the answer. I bet it's super hard to do, but it's still a problem with the platform

The more flexible you make any system the more difficult it is to maintain and verify. Not to mention performance headaches.

Imagine designing a car and someone comes along and says "it would be really awesome if instead of burning gas we could burn coal instead". Followed by "Oh, and it will only be used by a maximum of 20% of the users and we're probably going to change it completely in a month or two. Can you get that done by a week from Tuesday? QA will need it for that Friday's release."