WotC only acquired DDB in 2022. Even if they had clear plans, management support, and financial resources, it probably couldn't have happened, and doing it halfway is probably worse than not doing it.
This is key.
They acquired it in 2022, and then spent 2 years retrofitting the ability to have 90% of 2024's evolving rules to be applied, and then they could start looking at the existing code and fixing obvious bugs. Rewriting the whole thing now is actually a pretty aggressive update.
Agonizing Blast & other, similar Eldritch Invocations working with non-Eldritch Blast are EXPLICITLY named in the roadmap as top priorities in the site rework.
At this point, this thread should be redirected to the roadmap's page, in particular the relevant section to the above.
Rollback Post to RevisionRollBack
DM, player & homebrewer(Current homebrew project is an unofficial conversion of SBURB/SGRUB from Homestuck into DND 5e)
Once made Maxwell's Silver Hammer come down upon Strahd's head to make sure he was dead.
Always study & sharpen philosophical razors. They save a lot of trouble.
Stop defending incompetence. It should have been done completed for the 2024 product launch.
If the D&D Beyond character creator was a core part of the product, that might have some validity, but it's not. D&D Beyond itself is a secondary product, and it's not clear just how important tools such as the character creator are to D&D Beyond (its primary purpose appears to be digital storefront for E-books).
This is not to say there wasn't incompetence, but it's worth pointing in the correct direction:
The reason D&D Beyond's tools haven't been updated is because they're legacy code, probably built on rotten old software that they no longer have the in-house expertise to fix.
The reason D&D Beyond's tools haven't already been replaced is because they spent their development budget trying to build Project Sigil.
Stop defending incompetence. It should have been done completed for the 2024 product launch.
If the D&D Beyond character creator was a core part of the product, that might have some validity, but it's not. D&D Beyond itself is a secondary product, and it's not clear just how important tools such as the character creator are to D&D Beyond (its primary purpose appears to be digital storefront for E-books).
This is not to say there wasn't incompetence, but it's worth pointing in the correct direction:
The reason D&D Beyond's tools haven't been updated is because they're legacy code, probably built on rotten old software that they no longer have the in-house expertise to fix.
The reason D&D Beyond's tools haven't already been replaced is because they spent their development budget trying to build Project Sigil.
I am a 74 year old Fortran and COBOL programmer / analyst. I wrote a program using Fortran back in 1977 and this program, with minor modifications along the way, remained in service for 20 years. I know what "legacy code" is, because I was the hacker who wrote it. I retired from the university back in 2007, as the institution was installing a new comprehensive information system across the entire campus. It is the lot of software professionals to design, and re-design, and re-re-design information systems in accordance with the needs and occasional whims of administrators and end-users. It is frustrating, it is aggravating, it can lead to cardiac problems BUT in the end, when the end-users and the administrators are finally satisfied, that is when I and other hackers lift our tired legs and feet, plop them on our work tables and simply declare "piece of cake".
I am a 74 year old Fortran and COBOL programmer / analyst. I wrote a program using Fortran back in 1977
None of which is relevant to the problem at hand, which is that maintaining legacy code costs money and time, particularly if the people who wrote the software no longer work for you, and Wizards was simply not investing in the D&D Beyond tools because they assumed they had a replacement on the way. The development staff for D&D Beyond appears to be pretty small, which means you prioritize, and fixing a rarely encountered problem in an area of code that is apparently difficult to work with (based on the fact that they have never allowed homebrew invocations) isn't going to get all that high a priority.
I could be wrong here, but i dont think the dndbeyond website is written in fortran, stored on punch cards, and run on a mainframe with less than a megabyte of memory.
I am a 74 year old Fortran and COBOL programmer / analyst. I wrote a program using Fortran back in 1977
None of which is relevant to the problem at hand, which is that maintaining legacy code costs money and time, particularly if the people who wrote the software no longer work for you,
More importantly, "legacy code" covers a wide variety of code quality. Some is great, well-documented, chugs along happily for years, and is easy to modify when needed. Others are thrown together quickly, with a lot of hard-coded assumptions, and modifying it leads to a rickety structure of work-arounds on work-arounds, until trying to make changes is like playing drunk jenga during an earthquake.
It is my impression that the original DDB code was much more the latter. One can see it in the limitations.
I am a 74 year old Fortran and COBOL programmer / analyst. I wrote a program using Fortran back in 1977
None of which is relevant to the problem at hand, which is that maintaining legacy code costs money and time, particularly if the people who wrote the software no longer work for you,
More importantly, "legacy code" covers a wide variety of code quality. Some is great, well-documented, chugs along happily for years, and is easy to modify when needed. Others are thrown together quickly, with a lot of hard-coded assumptions, and modifying it leads to a rickety structure of work-arounds on work-arounds, until trying to make changes is like playing drunk jenga during an earthquake.
It is my impression that the original DDB code was much more the latter. One can see it in the limitations.
Yeah, the core problem, I think, is that its original purpose was as a tool for creating a character under the rules of 5e D&D that existed at the time the tool was created in 2017 (or whenever it was) and little or no thought was given to implementing any capacity for new capabilities and new concepts in the rules, even though a lot of those came along pretty quickly. That lack of foresight meant that every time a new concept was added to the rules — things like supernatural gifts, sidekicks, optional class features, bastions — they had to choose between implementing a half-assed janky workaround or just not doing it at all.
It's like we've got a road that keeps developing new potholes, and each one is either ignored or just fixed with a quick patch, so you end up with a mess of patches on patches on patches. The right thing to do is tear up the whole street and repave it from scratch, but that takes more time and money than a quick patch (and a lot more time and money than just ignoring the problem) and has to be approved by the people who control the money, who may still share that original lack of foresight.
Rollback Post to RevisionRollBack
pronouns: he/she/they
To post a comment, please login or register a new account.
This is key.
They acquired it in 2022, and then spent 2 years retrofitting the ability to have 90% of 2024's evolving rules to be applied, and then they could start looking at the existing code and fixing obvious bugs. Rewriting the whole thing now is actually a pretty aggressive update.
Agonizing Blast & other, similar Eldritch Invocations working with non-Eldritch Blast are EXPLICITLY named in the roadmap as top priorities in the site rework.
At this point, this thread should be redirected to the roadmap's page, in particular the relevant section to the above.
DM, player & homebrewer(Current homebrew project is an unofficial conversion of SBURB/SGRUB from Homestuck into DND 5e)
Once made Maxwell's Silver Hammer come down upon Strahd's head to make sure he was dead.
Always study & sharpen philosophical razors. They save a lot of trouble.
If the D&D Beyond character creator was a core part of the product, that might have some validity, but it's not. D&D Beyond itself is a secondary product, and it's not clear just how important tools such as the character creator are to D&D Beyond (its primary purpose appears to be digital storefront for E-books).
This is not to say there wasn't incompetence, but it's worth pointing in the correct direction:
I am a 74 year old Fortran and COBOL programmer / analyst. I wrote a program using Fortran back in 1977 and this program, with minor modifications along the way, remained in service for 20 years. I know what "legacy code" is, because I was the hacker who wrote it. I retired from the university back in 2007, as the institution was installing a new comprehensive information system across the entire campus. It is the lot of software professionals to design, and re-design, and re-re-design information systems in accordance with the needs and occasional whims of administrators and end-users. It is frustrating, it is aggravating, it can lead to cardiac problems BUT in the end, when the end-users and the administrators are finally satisfied, that is when I and other hackers lift our tired legs and feet, plop them on our work tables and simply declare "piece of cake".
None of which is relevant to the problem at hand, which is that maintaining legacy code costs money and time, particularly if the people who wrote the software no longer work for you, and Wizards was simply not investing in the D&D Beyond tools because they assumed they had a replacement on the way. The development staff for D&D Beyond appears to be pretty small, which means you prioritize, and fixing a rarely encountered problem in an area of code that is apparently difficult to work with (based on the fact that they have never allowed homebrew invocations) isn't going to get all that high a priority.
I could be wrong here, but i dont think the dndbeyond website is written in fortran, stored on punch cards, and run on a mainframe with less than a megabyte of memory.
More importantly, "legacy code" covers a wide variety of code quality. Some is great, well-documented, chugs along happily for years, and is easy to modify when needed. Others are thrown together quickly, with a lot of hard-coded assumptions, and modifying it leads to a rickety structure of work-arounds on work-arounds, until trying to make changes is like playing drunk jenga during an earthquake.
It is my impression that the original DDB code was much more the latter. One can see it in the limitations.
Yeah, the core problem, I think, is that its original purpose was as a tool for creating a character under the rules of 5e D&D that existed at the time the tool was created in 2017 (or whenever it was) and little or no thought was given to implementing any capacity for new capabilities and new concepts in the rules, even though a lot of those came along pretty quickly. That lack of foresight meant that every time a new concept was added to the rules — things like supernatural gifts, sidekicks, optional class features, bastions — they had to choose between implementing a half-assed janky workaround or just not doing it at all.
It's like we've got a road that keeps developing new potholes, and each one is either ignored or just fixed with a quick patch, so you end up with a mess of patches on patches on patches. The right thing to do is tear up the whole street and repave it from scratch, but that takes more time and money than a quick patch (and a lot more time and money than just ignoring the problem) and has to be approved by the people who control the money, who may still share that original lack of foresight.
pronouns: he/she/they