Monstrous Compendium Vol. 1: Spelljammer Creatures
Frozen Sick
D&D Beyond Basic Rules
Basic Rules (2014)
Sign in to view your library & saved favorites.
Sign in- Marketplace
Monstrous Compendium Vol. 1: Spelljammer CreaturesFrozen SickD&D Beyond Basic RulesBasic Rules (2014)Sign in to view your library & saved favorites.
Sign in
I agree. I want to make a shaman class with custom points called spirit tokens but there is no way of doing that except making it a subclass and then making the tokens as magic items or something and who wants the specialness of their custom class reduced to a subclass wannabe?
Its almost as frustrating as not being able to make magic ammo which really should have been fixed by now.
NOTE: As a note it took me forever to figure out how to do this in Foundry and its sad that the player has to specifically use the Foundry char sheet to use it.
I feel like D&D beyond should foster enough to allow us to make homebrew classes, even if we aren't allowed to submit them, let us use something. And I can't even use it for my VTT campaign
What are the rules for making classes and sub classes.
In 5.5 not old stuff.
You can make any subclasses you like in either rule set but not classes. That’s a restriction of the way the site is built rather than rules
https://www.reddit.com/r/dndbeyond/comments/1tjsaq9/comment/on4wgp7/
https://www.reddit.com/r/dndbeyond/comments/1tjsaq9/comment/on9dzq7/
I understand that.
What I am asking is what are the specific rules in 5e and or 5.5e.
I cant find them in my books. Not on the website but written in the books.
The rules in 5.5e are missing, as are several other pretty important homebrew rules like creating monsters from scratch. The 2014 rules don't have class rules, but have some (very vague) subclass creation rules in chapter 9, creating new character options, creating new class options.
Without the rules being written in the books they will never be incorporated into the website.
They will add new classes and sub-classes piecemeal but they not write out the rules because those rules often break classes and sub-classes already in the game.
This is also why some classes, sub-classes, spells, races and equipment are not allowed in some games by the DMs.
That assumes rules that are highly specific. General rules such as "a subclass must have a subclass feature at each level where the class mentions a subclass feature" aren't going to break anything, and that's pretty much the only rule there ever was for subclasses.
That's not a D&D Beyond issue. That's a Dungeons And Dragons franchise issue.
It's also a great opportunity for them to create the "Homebrew Bible" to sell, which would explain how to do all these things.
I mean D&D beyond is owned by Wizards/Hasbro at this point so I feel like that is kind a both issue.
Sure, but the D&D Beyond team, of which this is the forums of, are not writing D&D. They're implementing what was written. They don't have (direct) creative input.
I do think that if the entire dnd beyond experience moves to a solution based on a database, it would be much simpler to add specific subclasses features et by the way, to permit creation of homebrewed classes... The tool will be much dynamic and able to add third party specifics...;p)... alas we must wait...
https://www.reddit.com/r/dndbeyond/comments/1toi4rf/comment/oo2f62m/
Don't get your hopes up. Homebrew classes introduce complications that no other type of homebrew does. (First and foremost, dependencies between homebrew items.) They may decide they're not worth solving.
Also, "based on a database"? I assure you that the DDB character builder is already based on a database. (I'd guess MySQL or a derivative.) Databases aren't magic; they're limited by how you design them and the software architecture around them.
It's a misunderstanding of this line:
https://www.dndbeyond.com/posts/2132-d-d-beyonds-2026-development-roadmap
Data-driven, not based on a database.
Eh, what this tells us is that old setup was a mixture of database and code. The new setup will almost certainly also be a mixture of database and code, they're just trying to move certain types of logic that was originally special-cased in code into more generic database logic.