Hi all. I just wanted to start a conversation about the limitations of the builder, including the homebrew mechanics.
First, there's the limitation for the classes. We all know you can only build standard subclasses- no new classes allowed. For instance, I bought into Ryoko's when it was a kickstarter, And Heliana's popped up. Heliana's and Ryoko's share a lot of their material and mechanics. Anyways, they have two classes, the bender class and the Tamer class, which are difficult to impossible to recreate here.
Next, there's the annoying limitations like the Dark Gifts from Van Richten's being unavailable. This seems like it should be a simple thing to add into the builder- and Lineages work pretty poorly, too.
Lastly, I also bought into the Grim Hollow kickstarter, and we just received an email that said some of the things that are central to the book and setting are unable to be initiated her due to constraints in the software. well, these aren't issues with R20, and we were offered an opportunity to change the digital offering.
Now don't get me wrong. I'm not a hater here, in fact I'm pretty dedicated to this site as my game resource. I tried roll20, and at the time my internet connection was too slow, and it was like trying to speak Chinese with the hiccups- and I don't know Chinese! (Actually, I do know some- that was a joke.) I see this site as a resource that keeps paying out to Wizards and Hasbro. Allow me to point out that as RPG publishers, Wizards has sold you the one product you need to play the game. Once we all buy the books, they have nothing else to sell us. What I'm getting at is that they need a source of monetary income or they need to create a second edition. I get that. This is a hard business to stay alive in!
What works on this site works very well, and it has 98% of what I need. I'm not bashing anything. Still, it has it's limits and they need to be addressed. I want to play my games on this site- it SHOULD be the premiere site, and every option should be available, right?
So, what limitations have you guys come up against that annoys you? Is it something we are all likely to come up against or something truly homebrewed that nobody else is likely to ever experience? What is the limitation you've come across?
Rollback Post to RevisionRollBack
“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.” John Stuart Mill, 1867
“The only thing necessary for the triumph of evil is for good men to do nothing.” Attributed to Edmund Burke, 1961 (It is conjectured that he never said it.)
Classes have been called out as requiring a lot of back-end support, which can't be exposed to Homebrew. Which is understandable for a startup (DnD Beyond) but not when the move to being part of a multi-billion dollar company. Hasbro/WotC need to invest a lot more into the product's backend and make it so that they make their own classes using the same Homebrew tools.
Hi all. I just wanted to start a conversation about the limitations of the builder, including the homebrew mechanics.
First, there's the limitation for the classes. We all know you can only build standard subclasses- no new classes allowed. For instance, I bought into Ryoko's when it was a kickstarter, And Heliana's popped up. Heliana's and Ryoko's share a lot of their material and mechanics. Anyways, they have two classes, the bender class and the Tamer class, which are difficult to impossible to recreate here.
Next, there's the annoying limitations like the Dark Gifts from Van Richten's being unavailable. This seems like it should be a simple thing to add into the builder- and Lineages work pretty poorly, too.
Lastly, I also bought into the Grim Hollow kickstarter, and we just received an email that said some of the things that are central to the book and setting are unable to be initiated her due to constraints in the software. well, these aren't issues with R20, and we were offered an opportunity to change the digital offering.
Now don't get me wrong. I'm not a hater here, in fact I'm pretty dedicated to this site as my game resource. I tried roll20, and at the time my internet connection was too slow, and it was like trying to speak Chinese with the hiccups- and I don't know Chinese! (Actually, I do know some- that was a joke.) I see this site as a resource that keeps paying out to Wizards and Hasbro. Allow me to point out that as RPG publishers, Wizards has sold you the one product you need to play the game. Once we all buy the books, they have nothing else to sell us. What I'm getting at is that they need a source of monetary income or they need to create a second edition. I get that. This is a hard business to stay alive in!
What works on this site works very well, and it has 98% of what I need. I'm not bashing anything. Still, it has it's limits and they need to be addressed. I want to play my games on this site- it SHOULD be the premiere site, and every option should be available, right?
So, what limitations have you guys come up against that annoys you? Is it something we are all likely to come up against or something truly homebrewed that nobody else is likely to ever experience? What is the limitation you've come across?
Hasbro not giving WotC their pre-2021 freedom back in the name of monetizing a brand into a lifestyle platform is the biggest limitation there is. It's why you don't hire Silicon Valley & Ivy League Business School types to run a TTRPG anything
Classes have been called out as requiring a lot of back-end support, which can't be exposed to Homebrew. Which is understandable for a startup (DnD Beyond) but not when the move to being part of a multi-billion dollar company. Hasbro/WotC need to invest a lot more into the product's backend and make it so that they make their own classes using the same Homebrew tools.
They need to hire more real people period, & offer them a humane benefits package while not dumping them after the job's done:A long-term team is needed. & allocate more of the budget to getting Beyond working via said hires, w/that money coming from nixing the lifestyle brand stuff. Lifestyle brandification is genuinely an attempt to make fetch happen. Hasbro ain't gonna make fetch happen.
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.
Classes have been called out as requiring a lot of back-end support, which can't be exposed to Homebrew. Which is understandable for a startup (DnD Beyond) but not when the move to being part of a multi-billion dollar company. Hasbro/WotC need to invest a lot more into the product's backend and make it so that they make their own classes using the same Homebrew tools.
While I agree that the backend needs a rebuild (which is a Hard problem to do in-place), even if we get one, we are very unlikely to get custom classes out of it. They're likely too complex to make it worth their while, and there are fundamental database issues once you have homebrew referencing other homebrew.
Classes have been called out as requiring a lot of back-end support, which can't be exposed to Homebrew. Which is understandable for a startup (DnD Beyond) but not when the move to being part of a multi-billion dollar company. Hasbro/WotC need to invest a lot more into the product's backend and make it so that they make their own classes using the same Homebrew tools.
While I agree that the backend needs a rebuild (which is a Hard problem to do in-place), even if we get one, we are very unlikely to get custom classes out of it. They're likely too complex to make it worth their while, and there are fundamental database issues once you have homebrew referencing other homebrew.
Honestly if they did it right, it definitely could be.
You build each element as a building block that adjusts a known thing. It would have to protect against circular references, but something that says "This feature adds +1 to Proficiency Bonus" would just change the proficiency bonus. Not something any normal class would do, but if you make every element as a simple "changes this" block, it will allow them to make all sorts of complex things.
They can already do a lot of it, but there are a handful of elements that you "can't change", which are where all the backend support is needed. I wrote a q&d version of it for the core elements and it worked fine for my own character building. I'm sure that an entire team could do it in a way that's more stable and doesn't take the same processing power.
Classes have been called out as requiring a lot of back-end support, which can't be exposed to Homebrew. Which is understandable for a startup (DnD Beyond) but not when the move to being part of a multi-billion dollar company. Hasbro/WotC need to invest a lot more into the product's backend and make it so that they make their own classes using the same Homebrew tools.
While I agree that the backend needs a rebuild (which is a Hard problem to do in-place), even if we get one, we are very unlikely to get custom classes out of it. They're likely too complex to make it worth their while, and there are fundamental database issues once you have homebrew referencing other homebrew.
Honestly if they did it right, it definitely could be.
You build each element as a building block that adjusts a known thing. It would have to protect against circular references, but something that says "This feature adds +1 to Proficiency Bonus" would just change the proficiency bonus. Not something any normal class would do, but if you make every element as a simple "changes this" block, it will allow them to make all sorts of complex things.
They can already do a lot of it, but there are a handful of elements that you "can't change", which are where all the backend support is needed.
I never said it couldn't be done (but see below), just that it is unlikely to be.
Consider how much there is to do to homebrew a subclass. Doing it for a class is probably an order of magnitude more. Imagine what the UI for that looks like. They have to maintain that, as well as the underlying backend.
Now you have to make subclasses for the hombrew class. And the system has to handle it cleanly when you modify the base class to invalidate the subclass. Or even delete the base class. You almost have to have versioning like we do now for published homebrew.
I wrote a q&d version of it for the core elements and it worked fine for my own character building. I'm sure that an entire team could do it in a way that's more stable and doesn't take the same processing power.
Not necessarily. You basically have to trade flexibility for speed. The current system is fast (and faster to implement), but inflexible. If you move down to much more basic primitives, you have more power, but loading a character sheet now involves many, many more database lookups and more calculation time.
Also, classes are where the unique abilities happen. Even with basic primitives, you still need to have the right primitives. If you don't have the necessary bits to do Eldritch Invocations, you can't do Warlock.
This is the sort of thing I have experience with, and I've idly thought about how I'd do it. And I have Thoughts. But I also have realism. If they put me in charge of designing DDBv2, even if I could implement my perfect flexible model without grinding the database into dust to load the character sheet, and somehow managed to do a clean conversion of all the existing material, I probably still would end up with classes needing to be hand-coded by the devs, instead of building them out of a thousand tiny parts.
loading a character sheet now involves many, many more database lookups and more calculation time.
It would still be a single JSON file, not database lookups. The way it works does most of this already, they just don't have targets for the rest of the elements.
D&D Beyond already passes most of the work off to the client to build the sheet.
loading a character sheet now involves many, many more database lookups and more calculation time.
It would still be a single JSON file, not database lookups. The way it works does most of this already, they just don't have targets for the rest of the elements.
How do you think that JSON file is constructed?
D&D Beyond already passes most of the work off to the client to build the sheet.
I admit that I've never dived into the code, but I would expect that the contents of the character sheet are calculated on the backend, and arranged by the front-end code.
loading a character sheet now involves many, many more database lookups and more calculation time.
It would still be a single JSON file, not database lookups. The way it works does most of this already, they just don't have targets for the rest of the elements.
How do you think that JSON file is constructed?
D&D Beyond already passes most of the work off to the client to build the sheet.
I admit that I've never dived into the code, but I would expect that the contents of the character sheet are calculated on the backend, and arranged by the front-end code.
From what I can see, it is not. The fast majority of it is instructional. A normal character.json is a 600kb+ file, with everything keyed to features listed in a separate collection call that do things like:
{
"id": 3035739,
"definitionKey": "class-feature:3035739",
"entityTypeId": 12168134,
"displayOrder": 2,
"name": "Favored Foe",
"description": "<p><em>1st-level ranger feature, which replaces the Favored Enemy feature and works with the Foe Slayer feature</em><br />When you hit a creature with an attack roll, you can call on your mystical bond with nature to mark the target as your favored enemy for 1 minute or until you lose your concentration (as if you were concentrating on a spell).</p>\r\n<p>The first time on each of your turns that you hit the favored enemy and deal damage to it, including when you mark it, you can increase that damage by 1d4.</p>\r\n<p>You can use this feature to mark a favored enemy a number of times equal to your proficiency bonus, and you regain all expended uses when you finish a long rest.</p>\r\n<p>This feature’s extra damage increases when you reach certain levels in this class: to 1d6 at 6th level and to 1d8 at 14th level.</p>",
"snippet": "When you hit a creature with an attack roll, you can mark the target as your favored enemy for 1 minute or until you lose your concentration (as if you were concentrating on a spell).\r\nThe first time on each of your turns that you hit the favored enemy and deal damage to it, including when you mark it, you can increase that damage by {{scalevalue}}.",
"activation": null,
"multiClassDescription": "",
"requiredLevel": 1,
"isSubClassFeature": false,
"limitedUse": [
{
"level": null,
"uses": 1
}
],
"hideInBuilder": false,
"hideInSheet": false,
"sourceId": 67,
"sourcePageNumber": 56,
"creatureRules": [],
"levelScales": [
{
"id": 390466,
"level": 1,
"description": "1d4 extra damage",
"dice": {
"diceCount": 1,
"diceValue": 4,
"diceMultiplier": null,
"fixedValue": null,
"diceString": "1d4"
},
"fixedValue": null
},
{
"id": 390467,
"level": 6,
"description": "1d6 extra damage",
"dice": {
"diceCount": 1,
"diceValue": 6,
"diceMultiplier": null,
"fixedValue": null,
"diceString": "1d6"
},
"fixedValue": null
},
{
"id": 390468,
"level": 14,
"description": "1d8 extra damage",
"dice": {
"diceCount": 1,
"diceValue": 8,
"diceMultiplier": null,
"fixedValue": null,
"diceString": "1d8"
},
"fixedValue": null
}
loading a character sheet now involves many, many more database lookups and more calculation time.
It would still be a single JSON file, not database lookups. The way it works does most of this already, they just don't have targets for the rest of the elements.
How do you think that JSON file is constructed?
D&D Beyond already passes most of the work off to the client to build the sheet.
I admit that I've never dived into the code, but I would expect that the contents of the character sheet are calculated on the backend, and arranged by the front-end code.
From what I can see, it is not. The fast majority of it is instructional. A normal character.json is a 600kb+ file, with everything keyed to features listed in a separate collection call that do things like:
So, either they just have that JSON file sitting around on a server, updating it with text-editing functions every time the character is edited, or it's being built from a bunch of database lookups, likely on the fly. (It's possible that they cache it, but given that IIRC I've never seen complaints about character edits in one place not being immediately reflected in another, I suspect not. (After all, cache invalidation is one of the hard problems of computer science, and we know they have (perfectly reasonable) issues with it elsewhere.)
"Build a json file out of a bunch of DB lookups and send it to the front-end to handle the display" is a pretty normal web application design. (To put it mildly.) So anything that makes the lookups more expensive is a potential problem, especially when it's for the core use of their web app.
How much more expensive it would be is entirely a matter of speculation, but it's not gonna be cheaper, and rebuilding their back end with enough granularity in abilities to enable the useful creation of custom classes would likely get shot down as potentially endangering the basic functionality of the site. (And it would also make the implementation of official and third-party classes a lot more work.)
And custom classes just aren't important to their business. If they naturally fell out of development they had to do anyway, they might do the extra work to make them a user-facing thing, but they aren't going to go out of their way to make them happen.
That's probably the bigger question. Given their desire to flood the market with options through third party offerings and their failures to update homebrew to work with 2024 in the parts that they *do* support, supporting custom classes is probably something they don't want to do from a business perspective.
Could they, definitely. Will they, probably not even with a rebuild, because you can't sell homebrew.
Unless they made it so you could sell homebrew and they'd get a cut, but that opens up a world of copyright issues.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Hi all. I just wanted to start a conversation about the limitations of the builder, including the homebrew mechanics.
First, there's the limitation for the classes. We all know you can only build standard subclasses- no new classes allowed. For instance, I bought into Ryoko's when it was a kickstarter, And Heliana's popped up. Heliana's and Ryoko's share a lot of their material and mechanics. Anyways, they have two classes, the bender class and the Tamer class, which are difficult to impossible to recreate here.
Next, there's the annoying limitations like the Dark Gifts from Van Richten's being unavailable. This seems like it should be a simple thing to add into the builder- and Lineages work pretty poorly, too.
Lastly, I also bought into the Grim Hollow kickstarter, and we just received an email that said some of the things that are central to the book and setting are unable to be initiated her due to constraints in the software. well, these aren't issues with R20, and we were offered an opportunity to change the digital offering.
Now don't get me wrong. I'm not a hater here, in fact I'm pretty dedicated to this site as my game resource. I tried roll20, and at the time my internet connection was too slow, and it was like trying to speak Chinese with the hiccups- and I don't know Chinese! (Actually, I do know some- that was a joke.) I see this site as a resource that keeps paying out to Wizards and Hasbro. Allow me to point out that as RPG publishers, Wizards has sold you the one product you need to play the game. Once we all buy the books, they have nothing else to sell us. What I'm getting at is that they need a source of monetary income or they need to create a second edition. I get that. This is a hard business to stay alive in!
What works on this site works very well, and it has 98% of what I need. I'm not bashing anything. Still, it has it's limits and they need to be addressed. I want to play my games on this site- it SHOULD be the premiere site, and every option should be available, right?
So, what limitations have you guys come up against that annoys you? Is it something we are all likely to come up against or something truly homebrewed that nobody else is likely to ever experience? What is the limitation you've come across?
“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.” John Stuart Mill, 1867
“The only thing necessary for the triumph of evil is for good men to do nothing.” Attributed to Edmund Burke, 1961 (It is conjectured that he never said it.)
Classes have been called out as requiring a lot of back-end support, which can't be exposed to Homebrew. Which is understandable for a startup (DnD Beyond) but not when the move to being part of a multi-billion dollar company. Hasbro/WotC need to invest a lot more into the product's backend and make it so that they make their own classes using the same Homebrew tools.
For example how Artificer is broken once you hit level 9 - with an impending book release, that was delayed, will that issue be addressed? Who knows.
Well, they've been given a 3 month reprieve to fix the problem for the new class, and hopefully that'll fix the old one too.
Hasbro not giving WotC their pre-2021 freedom back in the name of monetizing a brand into a lifestyle platform is the biggest limitation there is. It's why you don't hire Silicon Valley & Ivy League Business School types to run a TTRPG anything
They need to hire more real people period, & offer them a humane benefits package while not dumping them after the job's done:A long-term team is needed. & allocate more of the budget to getting Beyond working via said hires, w/that money coming from nixing the lifestyle brand stuff. Lifestyle brandification is genuinely an attempt to make fetch happen. Hasbro ain't gonna make fetch happen.
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.
While I agree that the backend needs a rebuild (which is a Hard problem to do in-place), even if we get one, we are very unlikely to get custom classes out of it. They're likely too complex to make it worth their while, and there are fundamental database issues once you have homebrew referencing other homebrew.
Honestly if they did it right, it definitely could be.
You build each element as a building block that adjusts a known thing. It would have to protect against circular references, but something that says "This feature adds +1 to Proficiency Bonus" would just change the proficiency bonus. Not something any normal class would do, but if you make every element as a simple "changes this" block, it will allow them to make all sorts of complex things.
They can already do a lot of it, but there are a handful of elements that you "can't change", which are where all the backend support is needed. I wrote a q&d version of it for the core elements and it worked fine for my own character building. I'm sure that an entire team could do it in a way that's more stable and doesn't take the same processing power.
I never said it couldn't be done (but see below), just that it is unlikely to be.
Consider how much there is to do to homebrew a subclass. Doing it for a class is probably an order of magnitude more. Imagine what the UI for that looks like. They have to maintain that, as well as the underlying backend.
Now you have to make subclasses for the hombrew class. And the system has to handle it cleanly when you modify the base class to invalidate the subclass. Or even delete the base class. You almost have to have versioning like we do now for published homebrew.
Not necessarily. You basically have to trade flexibility for speed. The current system is fast (and faster to implement), but inflexible. If you move down to much more basic primitives, you have more power, but loading a character sheet now involves many, many more database lookups and more calculation time.
Also, classes are where the unique abilities happen. Even with basic primitives, you still need to have the right primitives. If you don't have the necessary bits to do Eldritch Invocations, you can't do Warlock.
This is the sort of thing I have experience with, and I've idly thought about how I'd do it. And I have Thoughts. But I also have realism. If they put me in charge of designing DDBv2, even if I could implement my perfect flexible model without grinding the database into dust to load the character sheet, and somehow managed to do a clean conversion of all the existing material, I probably still would end up with classes needing to be hand-coded by the devs, instead of building them out of a thousand tiny parts.
It would still be a single JSON file, not database lookups. The way it works does most of this already, they just don't have targets for the rest of the elements.
D&D Beyond already passes most of the work off to the client to build the sheet.
How do you think that JSON file is constructed?
I admit that I've never dived into the code, but I would expect that the contents of the character sheet are calculated on the backend, and arranged by the front-end code.
From what I can see, it is not. The fast majority of it is instructional. A normal character.json is a 600kb+ file, with everything keyed to features listed in a separate collection call that do things like:
{ "id": 3035739, "definitionKey": "class-feature:3035739", "entityTypeId": 12168134, "displayOrder": 2, "name": "Favored Foe", "description": "<p><em>1st-level ranger feature, which replaces the Favored Enemy feature and works with the Foe Slayer feature</em><br />When you hit a creature with an attack roll, you can call on your mystical bond with nature to mark the target as your favored enemy for 1 minute or until you lose your concentration (as if you were concentrating on a spell).</p>\r\n<p>The first time on each of your turns that you hit the favored enemy and deal damage to it, including when you mark it, you can increase that damage by 1d4.</p>\r\n<p>You can use this feature to mark a favored enemy a number of times equal to your proficiency bonus, and you regain all expended uses when you finish a long rest.</p>\r\n<p>This feature’s extra damage increases when you reach certain levels in this class: to 1d6 at 6th level and to 1d8 at 14th level.</p>", "snippet": "When you hit a creature with an attack roll, you can mark the target as your favored enemy for 1 minute or until you lose your concentration (as if you were concentrating on a spell).\r\nThe first time on each of your turns that you hit the favored enemy and deal damage to it, including when you mark it, you can increase that damage by {{scalevalue}}.", "activation": null, "multiClassDescription": "", "requiredLevel": 1, "isSubClassFeature": false, "limitedUse": [ { "level": null, "uses": 1 } ], "hideInBuilder": false, "hideInSheet": false, "sourceId": 67, "sourcePageNumber": 56, "creatureRules": [], "levelScales": [ { "id": 390466, "level": 1, "description": "1d4 extra damage", "dice": { "diceCount": 1, "diceValue": 4, "diceMultiplier": null, "fixedValue": null, "diceString": "1d4" }, "fixedValue": null }, { "id": 390467, "level": 6, "description": "1d6 extra damage", "dice": { "diceCount": 1, "diceValue": 6, "diceMultiplier": null, "fixedValue": null, "diceString": "1d6" }, "fixedValue": null }, { "id": 390468, "level": 14, "description": "1d8 extra damage", "dice": { "diceCount": 1, "diceValue": 8, "diceMultiplier": null, "fixedValue": null, "diceString": "1d8" }, "fixedValue": null }So, either they just have that JSON file sitting around on a server, updating it with text-editing functions every time the character is edited, or it's being built from a bunch of database lookups, likely on the fly. (It's possible that they cache it, but given that IIRC I've never seen complaints about character edits in one place not being immediately reflected in another, I suspect not. (After all, cache invalidation is one of the hard problems of computer science, and we know they have (perfectly reasonable) issues with it elsewhere.)
"Build a json file out of a bunch of DB lookups and send it to the front-end to handle the display" is a pretty normal web application design. (To put it mildly.) So anything that makes the lookups more expensive is a potential problem, especially when it's for the core use of their web app.
How much more expensive it would be is entirely a matter of speculation, but it's not gonna be cheaper, and rebuilding their back end with enough granularity in abilities to enable the useful creation of custom classes would likely get shot down as potentially endangering the basic functionality of the site. (And it would also make the implementation of official and third-party classes a lot more work.)
And custom classes just aren't important to their business. If they naturally fell out of development they had to do anyway, they might do the extra work to make them a user-facing thing, but they aren't going to go out of their way to make them happen.
That's probably the bigger question. Given their desire to flood the market with options through third party offerings and their failures to update homebrew to work with 2024 in the parts that they *do* support, supporting custom classes is probably something they don't want to do from a business perspective.
Could they, definitely. Will they, probably not even with a rebuild, because you can't sell homebrew.
Unless they made it so you could sell homebrew and they'd get a cut, but that opens up a world of copyright issues.