It's so bizarre to me that people assume DDB either implements something from UA or such instantly, or has no plans to implement it at all. Bradford was on record in his update as saying this Class Features UA was "a hand grenade" that landed not even two months before their planned Big Holiday Break; even the most cursory examination of the facts and/or the most basic knowledge of programming says this one's gonna be a doozy.
It's so bizarre to me that people assume DDB either implements something from UA or such instantly, or has no plans to implement it at all. Bradford was on record in his update as saying this Class Features UA was "a hand grenade" that landed not even two months before their planned Big Holiday Break; even the most cursory examination of the facts and/or the most basic knowledge of programming says this one's gonna be a doozy.
Absolutely true. Speaking as someone with “the most basic knowledge of programming” (learned pascal and C++ in high school, cheated of my buddy to pass, and never looked back) I can 100% tell you that this one’s gonna be a doozy. I’m eager for it to happen! But I am well aware that the his one will be a while. The Ranger’s Deft Explorer alone would be... clunky at best with the current system. There are three “options,” and one of them has 10 “sub-options” nested within. That means they need to add nested options with that level of functionality to the builder. That is one feature, for one class, out of twelve classes, each with several features, covering more than 12 pages of text. For all I know Deft Explorer is one of the easy ones!!! I may wants it all now, but I’m realistic enough to know that we’ll have to be a liiiiiiittle patient this time.
Honestly, for those of us that are CS folks out there, I'd be curious to hear a technical discussion after it's done on how they pulled it off. This has to be an interesting technical change and I'm super curious about the development and final implementation.
It is a big change and they are working on other projects at the same time. This will be the first UA on DDB that isn't a race or subclass, so just be glad we get it at all.
Honestly, I'm not really upset. It's a lot of work just to create a character builder for content that may never be released or might be revised again the month after you put it on DDB.
And hopefully three months closer to much more robust, and much less nightmarish, homebrew class tools.
This, this, a thousand times this!
If a full on homebrew system that allows for Class creation comes out of this it is fully worth the wait.
If it takes this long just to implement the features into the existing system....that's a problem. That highlights a much larger issue underneath the whole thing I think.
If it takes this long just to implement the features into the existing system....that's a problem. That highlights a much larger issue underneath the whole thing I think.
These wasn't an existing system for doing this. That is the problem.
The underlying issue is that DDB was built up instead of built out, so if they want to add or change something that has been around longer, they have to recheck a large chunk of code for new bugs. It is part of the reason they plan to rebuild so many tools (character builder, character sheet, and homebrew for example).
If it takes this long just to implement the features into the existing system....that's a problem. That highlights a much larger issue underneath the whole thing I think.
These wasn't an existing system for doing this. That is the problem.
The underlying issue is that DDB was built up instead of built out, so if they want to add or change something that has been around longer, they have to recheck a large chunk of code for new bugs. It is part of the reason they plan to rebuild so many tools (character builder, character sheet, and homebrew for example).
Yeah I do not know a ton about development but I heard once that if they had built it one way (Database) vs. another (HTML Hard-Coded) then updates would have been much easier. However I am no expert and I am sure there are upsides to the way it was developed (easier access maybe?) but I am not familiar with them.
Ultimately the protection of existing structure makes it incredibly difficult to want to roll things over as well. Especially with new content, characters, and what have you coming in faster than they can implement.
I understand the rationale but I am pretty disappointed about having to homebrew in solutions to integrate in parts of products paid for. For me that is the main reason I use DDB is the fact they integrate so much stuff automatically and this is not serving their core purpose for the reasons I use the tool.
What the DDB team has to do here, at some point - and this Alternate Class Features content catalyzed the need - is essentially build the entire tool all over again a second time. Every single feature and function of DDB needs to be rebuilt.
They then also need to create a way for content to transfer seamlessly from the old shitty busted tool into the New Hotness tool, without breaking or losing anything.
They need to do this while also maintaining full support and compatibility for their existing Old Shitty Busted tool, including implementing new content and features into the OSB Tool whilst working on the NH Tool.
it's kinda like asking an auto mechanic to "fix" a car by replacing it with an entirely new car without the driver noticing any changes, all while the old car is being driven around, and then further asking said mechanic to ensure that any new problems with the old car are also fixed while he's busy replacing the entire car.
@Optimus: They got the tool up and running as quickly as they could when they were in early development, not realizing how extensively people would want to hack and homebrew their 5e, nor how much/often Wizards would throw out weird Unearthed Arcana. An AQAP implementation of any given chunk of code is basically never the most expandable implementation; doing the root code for something that expands easily is always time-consuming, especially when you have no idea how or in what ways the code will be expected to expand.
It's frustrating, but I can understand the hair-pulling on the DDB code end as well. Think about it this way - their programmers are beholden to a client who can change their expectations and demands at the drop of a hat, and they have no possible way to give any input back or say "that's three weeks outside our codebase, it'll take months to implement!" They just get to do whatever Wizards says they should, no matter if it's possible or not. Anyone who's ever dealt with a pushy, demanding customer/client knows that pain.
Notes: Please post constructively and respectfully.
@Optimus: They got the tool up and running as quickly as they could when they were in early development, not realizing how extensively people would want to hack and homebrew their 5e, nor how much/often Wizards would throw out weird Unearthed Arcana. An AQAP implementation of any given chunk of code is basically never the most expandable implementation; doing the root code for something that expands easily is always time-consuming, especially when you have no idea how or in what ways the code will be expected to expand.
It's frustrating, but I can understand the hair-pulling on the DDB code end as well. Think about it this way - their programmers are beholden to a client who can change their expectations and demands at the drop of a hat, and they have no possible way to give any input back or say "that's three weeks outside our codebase, it'll take months to implement!" They just get to do whatever Wizards says they should, no matter if it's possible or not. Anyone who's ever dealt with a pushy, demanding customer/client knows that pain.
Yeah I do not have the experience but the input I get from other more knowledgeable people is that they made an odd choice not using databases from the get go. Its likely, as you said, that the homebrew stuff was an afterthought and at the time it was easier to go with a more HMTL based approach.
Once they had a sizable amount of people on the service with millions of characters it was too late and now they are attempting to play catch up after the fact. Hopefully they can pull the resources together to get it done and be ready for the official release of class variants when it does drop for real.
The UA stuff I can understand them not really needing to implement quickly and honestly I care a lot less if it goes up ever before its official. The fact it prohibits what they can implement from official releases (Eberron) is the part that irks me a bit.
Overall if we end up with a massively easier process from this I will be fine. If its about the same but slightly different then I might question it.
I can assure you that the many millions of characters on the D&D Beyond website are indeed held in a rather complex database, along with all of the other data. 🙂
HTML is just the language that the data is presented in so that a browser application knows what to do with it.
I can assure you that the many millions of characters on the D&D Beyond website are indeed held in a rather complex database, along with all of the other data. 🙂
HTML is just the language that the data is presented in so that a browser application knows what to do with it.
It's so bizarre to me that people assume DDB either implements something from UA or such instantly, or has no plans to implement it at all. Bradford was on record in his update as saying this Class Features UA was "a hand grenade" that landed not even two months before their planned Big Holiday Break; even the most cursory examination of the facts and/or the most basic knowledge of programming says this one's gonna be a doozy.
Please do not contact or message me.
Absolutely true. Speaking as someone with “the most basic knowledge of programming” (learned pascal and C++ in high school, cheated of my buddy to pass, and never looked back) I can 100% tell you that this one’s gonna be a doozy. I’m eager for it to happen! But I am well aware that the his one will be a while. The Ranger’s Deft Explorer alone would be... clunky at best with the current system. There are three “options,” and one of them has 10 “sub-options” nested within. That means they need to add nested options with that level of functionality to the builder. That is one feature, for one class, out of twelve classes, each with several features, covering more than 12 pages of text. For all I know Deft Explorer is one of the easy ones!!! I may wants it all now, but I’m realistic enough to know that we’ll have to be a liiiiiiittle patient this time.
Creating Epic Boons on DDB
DDB Buyers' Guide
Hardcovers, DDB & You
Content Troubleshooting
Honestly, for those of us that are CS folks out there, I'd be curious to hear a technical discussion after it's done on how they pulled it off. This has to be an interesting technical change and I'm super curious about the development and final implementation.
Three months later...
It is a big change and they are working on other projects at the same time. This will be the first UA on DDB that isn't a race or subclass, so just be glad we get it at all.
Three months later, yes.
And hopefully three months closer to much more robust, and much less nightmarish, homebrew class tools.
Please do not contact or message me.
But when does it go live? 😜
Please do not contact or message me.
You, Snowraven, have been Outmuscled.
Partway through the quest for absolute truth.
🤣
Creating Epic Boons on DDB
DDB Buyers' Guide
Hardcovers, DDB & You
Content Troubleshooting
Honestly, I'm not really upset. It's a lot of work just to create a character builder for content that may never be released or might be revised again the month after you put it on DDB.
This, this, a thousand times this!
If a full on homebrew system that allows for Class creation comes out of this it is fully worth the wait.
If it takes this long just to implement the features into the existing system....that's a problem. That highlights a much larger issue underneath the whole thing I think.
These wasn't an existing system for doing this. That is the problem.
The underlying issue is that DDB was built up instead of built out, so if they want to add or change something that has been around longer, they have to recheck a large chunk of code for new bugs. It is part of the reason they plan to rebuild so many tools (character builder, character sheet, and homebrew for example).
Yeah I do not know a ton about development but I heard once that if they had built it one way (Database) vs. another (HTML Hard-Coded) then updates would have been much easier. However I am no expert and I am sure there are upsides to the way it was developed (easier access maybe?) but I am not familiar with them.
Ultimately the protection of existing structure makes it incredibly difficult to want to roll things over as well. Especially with new content, characters, and what have you coming in faster than they can implement.
I understand the rationale but I am pretty disappointed about having to homebrew in solutions to integrate in parts of products paid for. For me that is the main reason I use DDB is the fact they integrate so much stuff automatically and this is not serving their core purpose for the reasons I use the tool.
What the DDB team has to do here, at some point - and this Alternate Class Features content catalyzed the need - is essentially build the entire tool all over again a second time. Every single feature and function of DDB needs to be rebuilt.
They then also need to create a way for content to transfer seamlessly from the old shitty busted tool into the New Hotness tool, without breaking or losing anything.
They need to do this while also maintaining full support and compatibility for their existing Old Shitty Busted tool, including implementing new content and features into the OSB Tool whilst working on the NH Tool.
it's kinda like asking an auto mechanic to "fix" a car by replacing it with an entirely new car without the driver noticing any changes, all while the old car is being driven around, and then further asking said mechanic to ensure that any new problems with the old car are also fixed while he's busy replacing the entire car.
It. Will. Take. A. While.
Please do not contact or message me.
[REDACTED]
@Optimus: They got the tool up and running as quickly as they could when they were in early development, not realizing how extensively people would want to hack and homebrew their 5e, nor how much/often Wizards would throw out weird Unearthed Arcana. An AQAP implementation of any given chunk of code is basically never the most expandable implementation; doing the root code for something that expands easily is always time-consuming, especially when you have no idea how or in what ways the code will be expected to expand.
It's frustrating, but I can understand the hair-pulling on the DDB code end as well. Think about it this way - their programmers are beholden to a client who can change their expectations and demands at the drop of a hat, and they have no possible way to give any input back or say "that's three weeks outside our codebase, it'll take months to implement!" They just get to do whatever Wizards says they should, no matter if it's possible or not. Anyone who's ever dealt with a pushy, demanding customer/client knows that pain.
Please do not contact or message me.
Yeah I do not have the experience but the input I get from other more knowledgeable people is that they made an odd choice not using databases from the get go. Its likely, as you said, that the homebrew stuff was an afterthought and at the time it was easier to go with a more HMTL based approach.
Once they had a sizable amount of people on the service with millions of characters it was too late and now they are attempting to play catch up after the fact. Hopefully they can pull the resources together to get it done and be ready for the official release of class variants when it does drop for real.
The UA stuff I can understand them not really needing to implement quickly and honestly I care a lot less if it goes up ever before its official. The fact it prohibits what they can implement from official releases (Eberron) is the part that irks me a bit.
Overall if we end up with a massively easier process from this I will be fine. If its about the same but slightly different then I might question it.
I can assure you that the many millions of characters on the D&D Beyond website are indeed held in a rather complex database, along with all of the other data. 🙂
HTML is just the language that the data is presented in so that a browser application knows what to do with it.
Pun-loving nerd | Faith Elisabeth Lilley | She/Her/Hers | Profile art by Becca Golins
If you need help with homebrew, please post on the homebrew forums, where multiple staff and moderators can read your post and help you!
"We got this, no problem! I'll take the twenty on the left - you guys handle the one on the right!"🔊
Makes sense. As I stated I am no expert.
We shall see how it turns out!
After months of this thread, all I can say is
Can we (the users) buy you (the developers) a cup of Coffee? to says thanks