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

 

[Umbran]

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

No, you miss the point. There is no such thing as "generally expandable" software. Software expansion is always design specific - broadly speaking, every design choice you make will leave some future things easier, and others harder. If you know beforehand what the desired functionality will be, you can design to leave that future easy.

But if nobody can tell you what the future holds, then as a practical matter, expansion will always be middling-hard, as some of your past decisions, that you didn't know would matter, will make that expansion more difficult than it could have been.

 

[TwoSix]

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

Yea, but that's not really true that they have NO idea how it will expand. You know anything in a distinct list should be assumed to modifiable and extensible. Classes, subclasses, races, backgrounds, weapons, armor, equipment, magic items, spells, spells known, spells prepared, spell slots, tools, skills, languages, feats, class features, abilities.

Any calculations should be done from derived values instead of fixed values. That's a little more difficult, of course, as you might need to sweep in new values from new kinds of sources. But there are a finite amount of calculations that need to be made on the character sheet, so that's doable.

Almost certainly the hardest case to prepare for is if they added a new method of acquiring spells and spell progression, or just a new layer of effects in general (like if the added a new class of martial maneuvers to all martial classes). That's a whole extra layer, and would probably be a pain in the butt.

I mean, probably the biggest technical challenges they've had from new material is Tasha's class variants, since they had to turn those from a fixed value into a selection. But that goes back to designing those features to be toggleable to being with. Every class feature in a class should have been designed to be like an ASI, where you can select from an option menu.

Something like the Strixhaven subclasses I probably would have facepalmed at a little, since they break the general one-to-many assumption I would have had about the class-subclass relationship. But even that's not impossible to fix, since you can simply enter a new subclass for each class-subclass combination. (Lorehold-Bard and Lorehold-Wizard are different entries.) The tricky part would actually be coding that a Lorehold-Bard couldn't multiclass into a Lorehold-Wizard, so I don't think there's been any previous restrictions on subclass combinations while multiclassing. That would be a legitimate "come on, now" moment if I was developing that. That's new tables and a lot of new logic in the front end.

 

[kenmarable]

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

And as became pretty clear with UA releases, the DDB programmers were finding out the requirements the same time as the public. I can't imagine the stress of UA-Mondays at DDB waiting to find out what they would have 5 business days to deliver - on top of working on their actual core product. Had to suck going in on those Mondays and having no clue whether that week would be an easy one or overtime.

 

[Umbran]

Yea, but that's not really true that they have NO idea how it will expand. You know anything in a distinct list should be assumed to modifiable and extensible. Classes, subclasses, races, backgrounds, weapons, armor, equipment, magic items, spells, spells known, spells prepared, spell slots, tools, skills, languages, feats, class features, abilities.

Yes, but for example, "class feature" is not a single design object. As an example, some class features are a bonus on a specific die roll. Other class features are creatures with their own stat blocks and their own abilities, that are dynamically dependent on the character.

In terms of computer system design, those two features are nothing alike. And you can imagine game designs (like, psionics that work off a psionic "power points" system, that lots of people really wanted), that are not on your list at all. When classes can have features of arbitrary design, the software isn't going to be able to hendle them all with aplomb.

Any calculations should be done from derived values instead of fixed values That's a little more difficult, of course, as you might need to sweep in new values from new kinds of sources. But there are a finite amount of calculations that need to be made on the character sheet, so that's doable.

Oh, goodness gracious, "it is finite, so it is doable" is incredibly misleading. Yes, with sufficient code, any piece of data can be gotten to any other place in the system you need it. But that's not the whole story.

For example, you need to do that in a way that is secure, performant, and affordable at the scale of users you are working with today. When the number of users rises, the design you chose for the level of perfomance and economy of the past is apt to fail, but changing fundamental architecture to scale up is expensive and time consuming.

 

[TwoSix]

Yes, but for example, "class feature" is not a single design object. As an example, some class features are a bonus on a specific die roll. Other class features are creatures with their own stat blocks and their own abilities, that are dynamically dependent on the character.

Sure, but they're mostly blocks of text that are being returned to the character sheet. The character builder isn't doing calculations for the most part.

Absolutely, there are some that do require calculations, but they're relatively limited.

In terms of computer system design, those two features are nothing alike. And you can imagine game designs (like, psionics that work off a psionic "power points" system, that lots of people really wanted), that are not on your list at all. When classes can have features of arbitrary design, the software isn't going to be able to hendle them all with aplomb.

I know. Let's assume that we both work in similar types of jobs and are generally aware of how software works.

Oh, goodness gracious, "it is finite, so it is doable" is incredibly misleading. Yes, with sufficient code, any piece of data can be gotten to any other place in the system you need it. But that's not the whole story.

For example, you need to do that in a way that is secure, performant, and affordable at the scale of users you are working with today. When the number of users rises, the design you chose for the level of perfomance and economy of the past is apt to fail, but changing fundamental architecture to scale up is expensive and time consuming.

Yea, but this is 5e. There aren't many calculations being done on the character sheet. AC, weapon attacks, proficiencies.

I mean, I see two general arguments being raised here.

1) The scope of a 5e character builder is extremely difficult to implement, and the developers did the absolutely best job they could.
2) The scope of a 5e character builder isn't particularly demanding, and something got done half-assed in development (or resourcing) that makes them unable to keep up with a few new features every few months.

To my mind, the evidence points pretty strongly to 2, especially when I see something like Pathbuilder 2 being built by one hobbyist on a much more robust rule set.

 

[darjr]

I would have LOVED being on the UA development team, but still dreaded the delays and such.

This changing of how D&D works within an edition has been the problem for many a software project.

 

[Iry]

Two programmers can sit down and attempt to create the same thing. One of them makes something streamlined but utterly inflexible. Another makes something slower, but future-proof and modular. This is a thing that happens frequently. Different programmers at different skill levels can and do make things at different levels of quality, and place emphasis on different (sometimes the wrong) things.

"It's harder than you think" is true in many ways. But it's also true that the initial program can be a bad choice in retrospect.

 

[Oofta]

Sure, but they're mostly blocks of text that are being returned to the character sheet. The character builder isn't doing calculations for the most part.

Absolutely, there are some that do require calculations, but they're relatively limited.


I know. Let's assume that we both work in similar types of jobs and are generally aware of how software works.


Yea, but this is 5e. There aren't many calculations being done on the character sheet. AC, weapon attacks, proficiencies.

I mean, I see two general arguments being raised here.

1) The scope of a 5e character builder is extremely difficult to implement, and the developers did the absolutely best job they could.
2) The scope of a 5e character builder isn't particularly demanding, and something got done half-assed in development (or resourcing) that makes them unable to keep up with a few new features every few months.

To my mind, the evidence points pretty strongly to 2, especially when I see something like Pathbuilder 2 being built by one hobbyist on a much more robust rule set.

There's a huge difference between building for a known style and set of rules and having to implement something that follows a completely different pattern. I wrote an app for 3.5 back in the day just for giggles that worked reasonably well, but there's no way it would have been able to easily handle something on the scale of some of the UA articles.

Add in that, while I haven't seen or used Pathbuilder 2, I'm assuming they don't need to turn around these off the wall breaking changes overnight? That it takes a while to implement new features? For that matter, does PF even throw in the type of breaking changes that we've seen with some of the UA content?

You're comparing apples to oranges. Unless you're on the dev team for DndBeyond or know someone who is everything you're posting is simply unfounded and kind of insulting to the team that works on the application.

 

[lkj]

I am 'forgiving' of DDB because it has been an extremely useful product for myself and the numerous people in my gaming groups. We love the product, use it all the time, and most of the issues people cite have very mild impacts on our use. Now, that said, it's totally fine if you don't find the product useful or find the flaws more troublesome. We all have different needs. But, for me, DDB has been well worth the money I've spent on it. It's not even close.

I'll also note that I always find it amusing to go read on messageboards how everything should be so 'easy to implement'. I won't argue about it, because it's a fruitless exercise in speculation if we aren't actually working on the product together. But I don't buy it in the least. Almost anything can be made to sound easy when you have the luxury of ignoring everything but the particular wedge you're interested in.

In the end, either you find it a good product for you or not. The 'behind the scenes' mechanics of why it does this or doesn't do that aren't relevant beyond idle curiosity to me. (And yes, this post and my last are expressions of that curiosity)

AD

 

[Oofta]

Two programmers can sit down and attempt to create the same thing. One of them makes something streamlined but utterly inflexible. Another makes something slower, but future-proof and modular. This is a thing that happens frequently. Different programmers at different skill levels can and do make things at different levels of quality, and place emphasis on different (sometimes the wrong) things.

"It's harder than you think" is true in many ways. But it's also true that the initial program can be a bad choice in retrospect.

I have seen so many projects completely flounder because they tried to build an overly flexible system. We don't know anything concrete about the internals of the system and as a company they need to focus on providing the most benefit for the least investment.

Spending significant resources on a tool that the minority of people use, that only a minority of that minority will raise a stink about is probably simply not good business.