Practical Example: Building the 5th Edition SRD

By this point, you might have a general idea of what Hedron is trying to do — but you don't know how to get started yourself.

In this guide, we're going to walk through a practical example of building a Rule System, starting with the Dungeons & Dragons 5th Edition SRD. The hope is that as you go through this, you might get a better grasp of how to make Hedron work for your vision!

NOTE: If you just want to play 5th Edition, you DO NOT NEED to do this. Or if you're just expanding/modifying 5th Edition, you ALSO DO NOT NEED to do this.

This guide is strictly for the purposes of illustrating how the Rules Editor works so that you can better create your vision of your personalized system!

For the best experience, try to use a desktop or laptop, rather than mobile for following along with this guide.

Create a Rule System

Start by creating a fresh Rule System from which you will build off of. Normally, you could use any of the Hedron-Official Systems as a starting point, but for this guide, let's start blank.

Go to the Mechanics and Rule Systems Page and click the "Create Ruleset" button in the top right to get started. In the dialog that follows, name your system and click submit!

Once you've done that, you have your basic structure ready and your Rule System will be valid for the purposes of Contexts (see the Quick Start for more details on that) — though only you can see it (it's private initially).

But, it's empty right now. Let's start editing it.

Go into edit mode with the pencil icon in the top right.

From the new menu, you'll see options lots of tabs and options to update your Rule System. In future updates, the tabs might be re-ordered, but their names should stay the same.

Otherwise, know that auto-save is enabled by default on the Rule System, so as you work, much of your work will get saved automatically. You can disable it using the icons in the top right, as well as trigger a manual save if necessary. Or even delete your Rule System.

The General Tab

From the first tab, the "General" Tab, you can set the Rule System's description. This is really free-form, but for our purposes we'll set it to a fairly standard statement.

Next, you'll also see an area to specify your system's cover art, if any. We'll leave this blank.

And now, we come to the first major setting provided by Hedron: "Enabled Functionalities". Hedron is all about customization for every kind of system out there. And not every system needs to use all of Hedron. So here, you can control what aspects of Hedron Rule Systems are and aren't in use.

For D&D 5th Edition, we need all of them except "Feats", "Item Properties", and "Casting Modifications" (none of these exist in 5E). So, so far, we have:

Next, you can set the Default Dice. This setting doesn't affect a whole lot, but setting it makes it easier to configure dice rolls in your system later.

For D&D 5th Edition, the Default Dice would be 1d20. Other things you could put here include "3d6", "2d10", etc.

Next you see some settings for Bonuses. These determine how bonuses interact. For 5th Edition, we can leave "Identical Bonus Type Stacking" off, and set rounding strategy to "Down (Strict)". This makes it so that when you get a fraction as a result of a calculation, such as Character Level / 4 (used for Ability Score Increases), you will have it rounded down before anything else can affect it.

For most cases, in 5th Edition, you can probably just use "Down" instead of strict down, and it would be identical. However, by official technical definition, 5E uses Down Strict.

So overall, your general tab looks something like:

The Time Keeping Tab

Next up, the "Timekeeping and Turns" tab, which we use to set up a round of Initiative and combat.

NOTE: This is not the same as the "Calendars Page" in Hedron.

First, we have time units. Note: the time units you define here are used for mechanical purposes only. For example, spell durations, ability effect durations, etc.

For each Time Unit, we will need to give it a name, abbreviation, and duration.

We could define its duration any way we want, as long as the relative duration of each unit to other units is consistent. For example, as long as our definition of a "Hour" is 60 times longer than our definition of "Minute", that's okay. Just make sure you pick a duration so that no unit has a decimal.

To keep things simple, we'll define all of our Time Unit durations in terms of seconds.

For 5E, we can define "Second", "Round", "Minute", "Hour", "Day", and "Week". We also want to add one more unit: "Forever" and mark it as Infinite using the button. When we're done, it should look like this:

Next up on the same tab, you'll see an area to set up the Action Economy. This basically defines "what does a turn look like for a character in this system?"

In 5th Edition, declaring the usage of your Action Economy System is called "Initiative", so we set that as the System Label. And 1 cycle of all characters in the Action Economy is called a "Turn", so that's the Cycle Label. And in terms of "real time units", 1 cycle is 1 Round, so we set that as the "Cycle True Duration".

Next, we specify the structure of a turn in 5E: 1 action, 1 bonus action, and 1 reaction. Start by clicking "New Action" and adding each of these. For all 3 of these, we will have the "Quantity Per Cycle" set to 1 and the "Refresh Rate" set to 1. And because you can't exchange any of these actions for other actions, you don't need any conversions.

The result should look like so:

All in all, this tells the Hedron VTT that each character gets 1 action, 1 bonus action, and 1 reaction for every Turn they take during Initiative. When every character has taken a turn, 1 Round (a true time unit) has passed.

And that's it for time-keeping! Hedron will handle the rest.

The Character Derivations Tab

Jumping to the Character Derivations tab, let's set up the concept of a Character in your system.

First, what is a "Character Derivation"?

A Character Derivation is a single number that is calculated on your characters. For example, in 5E, it can refer to an Ability Score, or a Skill, or your AC. And when you have lots of Derivations that are related to each other (maybe they share a pool of investable points — like Skills), they are Derivation Group.

Note: Derivations are always numbers. For non-number fields, see Derivation Properties or Character Fields (more on this later).

This will make more sense as we go, but understand that when 2 or more things share a pool of points or have parallels, they might just be in the same Derivation Group.

Let's define 5 Derivation Groups for 5th Edition:

• Ability Scores
• Ability Score Modifiers
• Saving Throws
• Skills
• Other

Notice: We separate Ability Scores and their modifiers. Why? It's because you can put points into an Ability Score but not into it's modifier (modifiers are just a calculation based on the overall score).

If you're ever not sure if something should be two Derivation Groups or one, it most likely should be two. But things can be tricky. Let's move on so you can see how 5th Edition uses Derivation Groups and maybe that will help clarify your understanding.

Once you've created the 5 groups, hit save and you should see this:

And below it, tabs for each group:

Ability Scores

Let's start with the Ability Scores as they sort of determine many other facets of the system. For now, ignore any Ability Score changes as a result of Character Race (we will handle that later).

For this guide, let's assume we want "Point Buy" to be the default method of setting Ability Scores. For those unfamiliar, "Point Buy" works by setting all of your scores to 8, then you have 27 points to allocate that can raise or lower each of these scores (to a maximum of 15 each) — noting that some changes, like raising a score from 14 to 15 is more than 1 point. Here's the total cost to achieve each possible final Ability Score value:

While we're mentioning it, there's also the concept of Ability Score Increases; at 4th level and every 4 levels after, Player Characters may raise any one of the Ability Scores by exactly 1.

Returning to Hedron, to implement this, we're going to start by setting up the points section of Ability Scores. Players start with 27 points to set Ability Scores, so "Initial Points" is set to 27.

There's no "Minimum Points per Derivation" nor Maximum, so leave those fields as is.

Next, we have "Points". As we have "Ability Score Increases" to handle, we want characters to gain 1 investable point to raise their Ability Scores every 4 levels. Click edit on the field to open The Bonus Editor and configure it to Character Level / 4 as so:

Thus, your points section for Ability Scores, once you save, should look like this:

Skip "Checks" for now, and take a look at "Point Mappings". By default, when a Character puts a point into a Derivation, it goes up by 1.

For most cases, this is what you'd want — including for our ASI. However, we don't want Point Buy to work this way. Luckily it's easy to fix.

Start defining some Point Mappings by defining what each Point Value is converted into for the purposes of increasing the Derivation. We'd want 0 becomes 0, 1 becomes 1, 2 becomes 2, and so on. But, as per the table above, we also want "Input 7 Becomes 5" and "Input 9 Becomes 6" and no defined mappings for 6 or 8. And as we only want to apply this at Character Start, we set this to "Apply Only at Start". The result is:

What this will do is that because all of our Point Mappings apply at the start only, Point Investments will be 1:1 for Level-Ups and past Character Creation, but at Character Creation, we've constructed our Point Buy Table. Note: By skipping Input 6 and 8, we disallow Point Investments of 6 and 8 — Players will either have to invest 5, 7, or 9.

Also, by defining at least 1 Point Mapping, we restrict what Point Investments players can have to the options we specified. That means at the start, Players must invest a number we listed here — but because none of these apply at Level Ups, they can invest any number of points (more on this in "Skills" below).

Next, we have Properties. Properties are basically some sort of field or value that are Derivation-specific and might be affected by class choices, feats, etc. 5E doesn't have Properties for Ability Scores, but it does have Properties for Skills — so skip this section for now. We'll revisit it below!

A future guide will take advantage of these options and go into more detail, but for now, skip it.

And now, to set up our Derivations!

Create a Derivation and name it Strength.

Enable Character Input on it. This will give you options to set the "Input Points Scalar" and "Input Base Value". We will leave these values at 1 and 0, respectively.

"Input Points Scalar", as it might sound, makes it so a Point Investment can actually be something besides 1:1. For example, if you wanted each invested point to increase Strength by 2, you'd set the Scalar to 2. Decimals do work here — just keep in mind that your Strict Down rounding Strategy means after the multiplication, the result will get rounded down immediately. If you had non-strict Down rounding, then it would be rounded after all bonuses are applied and a final number is produced.

Meanwhile, "Input Base Value" specifies what's the default point investment when a character is first created. It's just a default and players can override it, so it's just for convenience.

Next, the "Additional Bonus Calculation". Set that to 8 as Ability Scores start at 8 (before Player Input). This is basically what gets added to Player Input to compute a final value for the Derivation.

Rounding Override determines if this Derivation should use some special rounding approaches. In 5E, nothing, by default, breaks the Strict Down rounding strategy, so we can leave it as "No Override" for this Derivation and all others.

"Conditional" specifies a way to have certain Derivations hide under some conditions. For example, maybe you don't want an item's damage dice to be displayed if it's not a weapon, etc. For the Derivations of 5E, we don't really need these for now, so leave it unchecked.

Next, 5E typically imposes a hard limit of lower and upper values for Ability Scores, so to better introduce guard rails, we can set a "Derivation Minimum Value" and "Derivation Maximum Value" to 8 and 20, respectively — which are the said limits of Ability Scores.

Lastly, we have a section for "Checks" a.k.a "Rolls"; in short, defining a roll here gives the VTT a hotkey to roll a specific computation alongside a die. In 5E, there is such a thing as rolling a "Strength Check", which is basically a test of your character's Strength — such as lifting a heavy object. However, in 5E, such rolls are typically adding one's Strength Modifier, rather than their full Strength Score. So for now, we can skip this.

The result looks like this and indicates a fully set up Strength derivation!

In short, this captures all of the necessary functionalities for the Strength Ability Score in 5E. You may be wondering: "What about Skills that scale with Strength?" or "What about Carrying Capacity?" or "What about Strength Checks?"

Don't worry, we'll handle that later on. For now, use this as a basis and set up all of your Ability Scores; there's 5 more Ability Scores: "Dexterity", "Constitution", "Intelligence", "Wisdom", and "Charisma". All of these should be mostly the same as Strength, just with different names. Use the copy symbol in the top right of the editing box for Strength to make things easy!

Once you've done that, hit save. If you have Autosave enabled, then saving one of these boxes will close and save all of them. If you don't, then you'll need to scroll up to the save button for the entire Rule System. Remember, you need to save the Rule System before you can use this Ability Scores in other calculations. So, make sure you do that before moving on!

General FAQs From This Section

Q: How does Hedron know that Point Buy is shared across the 6 Ability Scores?

A: They're all part of the same Derivation Group — so they share this pool of points that we defined above.

Q: What about stuff that scales with Strength or Constitution?

A: Don't worry, we'll handle that when we get to it. For now, we just need to tell Hedron these stats exist!

Ability Modifiers

Now that you have a feel for creating Ability Scores, we can move on to something that is dependent on them and thus, a bit more complex: Ability Modifiers.

Ability Modifiers are direct calculations based on Ability Scores. Specifically, an Ability Modifier is equal to 0 at an Ability Score of 10. Then for every 2 above 10, it goes up by +1. Meanwhile, going down to 9 makes the Ability Modifier -1. Then, every 2 lower it goes, the modifier decreases by -1.

Here's a quick chart to summarize:

So why did we talk about the every 2 levels thing above if this nice chart explains it all? On Hedron, you can manually make charts and things like this for bonus calculations, BUT it's a lot easier when you can express it as a formula. For the chart above, you can see the formula is:

Modifier = (Ability Score - 10) / 2

To check the formula is right, try running through the numbers in the chart above. And remember, because we use Strict Down rounding, fractions/decimals round down! I.e. 3.5 becomes 3, -1.5 becomes -2, etc.

Knowing this, we can set up our Modifiers fairly easily. Just keep that formula in mind for now and let's go through each section and set up the Modifiers.

Go to the "Ability Score Modifiers" Tab under Derivations.

First, the "Points" section. In 5E, players can't directly invest into Modifiers, so leave everything as is.

Likewise, skip the "Checks" section for now, as well as "Point Mappings" and "Properties". The latter 2 here don't apply to Modifiers as Players can't directly influence Modifiers with points so Point Mappings don't affect them, and as mentioned above, "Properties" don't really exist in 5E.

That brings us to the important part for Ability Score Modifiers: "Derivations".

Like we did with Ability Scores, we're going to create a Modifier for Strength. And we're going to use that formula we came up with before.

Start by creating the Derivation using "New Derivation", just like before.

Then give it a name, and optionally an abbreviation. But skip the "Character Input" (as Player Characters cannot add points to modifiers directly.

Next, in the "Additional Bonus Calculation", we set-up the whole formula we came up with above. Click the edit icon to open up the Bonus Editor (see the full guide on the Bonus Editor if you're curious). Then, set up your formula just as we did before! It'll look like this when you're done:

Click save here and you should see the calculation appear as the "Additional Bonus Calculation".

Now, we can skip the "Rounding Override", "Conditional", and the "Maximum/Minimum Values" options. Why? We can use "Rounding Override" to set-up special rounding rules for Modifiers, but we're happy with the default we set for our system: "Strict Down". We can use "Conditional" to make the field only appear sometimes, but all Creatures/Characters/NPCs in 5E have Strength, so we can skip that, too. Lastly, while Modifiers technically have a Minimum or Maximum Value as a result of them depending on their Ability Score having a min/max value, we don't have to re-specify the limits here. The limits set on the Strength already will impose a minimum or maximum value.

Lastly, we have "Checks" also known as Rolls. In short, this is a way to specify the commonly rolls of your system so that the VTT can provide a hot key to roll it easily and so that bonuses can target/affect the roll when they are applied.

Before we can set up Checks, we need to hit Save. This save makes it so that we can use the Modifier for setting up our Check (making sure to hit save for the whole Rule System if you don't have auto-save enabled).

Once saved, simply "Add Related Check" and rename the Check Name to "Strength Check", rather than the default name.

And that's it. It'll look like this when you're done:

And that's all we need to do for Ability Score Modifiers. In session, characters will have a Strength Modifier that's calculated based on the formula we provided. And when they hover over the number on their sheets, they'll see an exact breakdown of how it came to be. Like so (example from my own system which renamed Dexterity to Agility, but otherwise works the same):

Now that we've seen how to set up Strength Modifiers, you can probably infer that we need to do the exact same thing for all 6 of our Attributes.

As with Ability Scores, they will work very much the same way as our Strength Modifier set-up, but we will rename them and use different Ability Scores in their calculations.

PRO TIP: I suggest creating all of your Ability Scores, then saving, then adding Checks. Also consider using the "Copy function" to be more efficient.

As an example, here's what my Constitution Modifier set-up looks like when I'm done:

Once you've set that up, we're ready to move on. It gets a bit more free-form from here, but you probably want to finish up your derivations before you move on to other tabs of your Rule System.

Saving Throws

Based on the previous two sections, you should be getting a feel for how you set up these calculations based on one another.

Saving Throws in 5E are just a specific Ability Score Modifier + d20. Really, they're more a Check than a stat. But that's okay. We can set them up as a Derivation anyway.

Why would we want to do that? Here's a few reasons:

• When something is its own Derivation, you can make a Prerequisite for Abilities or Feats based on it.
• Making it its own Derivation lets you set bonuses that affect the Saving Throw directly (rather than the attached Check)
• Hedron, as of writing this, only allows 1 check to be associated with a single derivation. This could be changed, but for the reasons above, we are so far keeping this 1:1 association.

Anyway to set them up, they're going to be a lot like Ability Score Modifiers — no point investments, no Max/Min Values, a singular check for each of them, and their Bonus Calculation is just equal to their associated Ability Score Modifier.

So reference the previous section, just replacing the Bonus Calculation with simply the Modifier of interest. This should be your result when you're done (note: I'm only showing 2 Saving Throws, but I set up 6 total — one for each Ability Score):

Skills

Skills have an interesting additional detail: Proficiency.

In short, your bonus for a particular Skill Check is equal to the Skill's associated Ability Score Modifier PLUS an additional Proficiency Bonus IF a character is proficient in that skill.

For now, we can ignore how proficiency is determined, and just set up the framework to support it.

First, go to your "Skills" tab, you can once again ignore the sections for "Points", "Checks", and "Point Mappings". However, we cannot skip the "Properties" section this time entirely.

First, let's create a Derivation. Create one Derivation and just name it "Acrobatics" (the first Skill in 5E). No need to do anything else yet. Then hit save and let's go back to Properties.

Why did we do this? The way Hedron stores data behind the scenes means only Properties that have been added to one or more Derivation are saved. So we need to create a Derivation before we can make a Property and save it.

So what is a Property?

As mentioned earlier, Properties are basically a field that is Derivation-Specific, but present on all Derivations within a group. Technically, they are a form of Entity Field (more on this later).

Let's set up one to help us handle Proficiency Bonuses. Start by clicking "New Property". The result probably looks somewhat familiar:

Properties (and all other Entity Fields) basically look like this. In short, Entity Fields are fields that can either be alphanumerical (letters & numbers), purely numerical, or true/false (checkboxes). Stepping back, you can even think of Derivations, themselves, as Numerical Entity Fields.

TIP: We use "Entity Field" to refer to Properties, Item Fields, Spell Fields, Feat Fields, Ability Fields, and all other fields of the naming convention "<SOMETHING> Fields". It's just a terminology and doesn't actually matter — nor will you see this phrasing on Hedron anywhere! It's just to make guides easier to talk about.

Anyway, to actually set up our Property to handle Proficiency, all we really need to track is "whether or not the Character is in Proficient in a Particular Skill".

So, let's name this Property "Is Proficient". And we'll change its Field Type to "True/False".

Next, we can skip giving it a Field Grouping (which is used purely for organizational purposes and has no mechanical effect) and leave the "Conditional" checkbox unchecked. Finally, set its default value to False (the default anyway) and you're done!

What this does is basically tell Hedron that all Derivations in this Derivation Group ("Skills") has an additional property regarding whether or not the Skill "Is Proficient".

Once you're done, hit Save and go back into editing your Acrobatics Derivation.

You'll notice a new section for "Default Property Values" and it contains your Property, "Is Proficient":

Because you've created a Property for the Derivation Group, all of the Derivations you create in this group will also have this Property. If we had set the Default Value to true, the checkbox would be checked by default.

Considering that most Characters are not Proficient in any given Skill (they specifically need a Class or Race to grant proficiency), it's better we leave the Default Value for the Property as False.

Now, we have to actually accommodate the idea of being Proficient (which results in a bonus being granted).

So, open up the "Additional Bonus Calculation" and go straight to the "Advanced" tab.

The way Proficiency is applied is that IF a character is proficient in a particular Skill, they add +2 plus an additional +1 for every 4 Character Levels PAST 1st level. For example, a Level 2 Character has a +2 Proficiency bonus; a Level 13 Character has a +5 Proficiency bonus, etc.

So, we can express this idea as: 2 + (Character Level - 1) / 4.

How did we figure that out? It's a bit of math but the intuition is "What is the rate at which the bonus goes up?" and "What level does the bonus start increasing at?" The answers to that are every 4 levels and level 5 respectively. Then, we subtract the second number from the first one and that becomes the "-1", while the second number becomes the denominator. Lastly, because we start at +2, we add that +2 as well. With practice, this reasoning will become easier.

Feel free to try this formula yourself to check our math (remembering that things round down).

Anyway, let's set up this formula first. On the Advanced Tab, you do this by:

1. Click "Add Component"
2. Under "Operands", click "Add Operand"
3. In the operand that appears, set up your formula.

If you follow these steps, you'll end up with this:

As we've learned from previous sections, this creates a bonus calculation that is equal to 2 + (Character Level - 1) / 4. But, this bonus will always be applied — whereas we only want it to apply when a Character has the relevant skill proficiency. This is why we are on the Advanced Tab.

Let's add the condition to make this bonus only apply if the Character has Skill Proficiency:

1. Click "Add Condition Set"
2. Click "Add Condition"
3. In the resulting condition, search for "Acrobatics Is Proficient", leave the dropdown on "Equal (=)", and check the resulting checkbox.

The result should look like this:

Let's take a step back and look at what we did.

Basically, we created a "Condition Set". What that means is that it's a set/collection of conditions. For the bonus to be applied, the "Condition Set" has to be overall true. How do we know if it's true? Well, we check if each of the "Conditions" we made are true and then use the "Conditional Set Operation" to combine the results. Here, we have the operation set to "And".

So, in English, this condition set says "IF Acrobatics Is Proficient = Checked/True". If we added another condition (like if Acrobatics > 0), then the "And" operation would make the result read as "If Acrobatics Is Proficient = Checked/True AND Acrobatics > 0".

For more details on how Condition Sets work, check out the Guide on Bonuses and The Bonus Editor.

Anyway, with that, we've completed this set-up. This bonus, holistically, can be read as ""IF Acrobatics Is Proficient = Checked/True, then the bonus is equal to 2 + (Character Level - 1) / 4", which is exactly how Proficiency Bonuses work for a Skill.

Now, one last detail to finish setting up The Acrobatics Bonus calculation: adding the related Ability Score. You might think to use "Add Operand" to add a second formula for the Ability Score; HOWEVER, doing that would also make it conditional on the conditions we set.

So instead, click "Add Component". In the new component created (the one without Condition Sets), add an operand to add your Dexterity Modifier. Note: Operands within the same component are combined using the Component's Operation (MAX by default), but different components are always added together.

When you're done, the completed Bonus should have two components, one with conditions for Proficiency and one without conditions for Dexterity:

Now that you've set this up, hit save!

You'll see the Additional Bonus Calculation as such:

Note: When this summary view is read out, it assumes all conditions are true. This doesn't mean that the Proficiency Bonus is always applied. It's just a summary.

Now, you might be wondering, "But Is Proficient is False, so won't this always just be equal to your Dexterity Modifier"?

Not quite. Remember, we're defining the Rule System. The actual final value for Derivations will be based on the specific character builds. So while we have the "Default Property Value" unchecked, Character Builds might have it checked as a result of their Class, Race, etc. Because we set the Default Value as False, characters will not be Proficient in Acrobatics unless something like a class, ability, or other thing changes that.

Thus, your Derivation for Acrobatics is correct if it looks like this:

Notice how we can, once again, ignore most of the options available to us. As a reminder, this is part of the core philosophy of Hedron — we give you options to do a variety of things, but you never have to use all of them. Use only what you need.

Moving on, you can now repeat this process for all of the remaining Skills in 5E. To make things easier, as the only thing that varies from Skill to Skill is the name and potentially the associated Ability Score Modifier, use the "Copy Button" to quickly replicate the logic without having to repeat the process.

Other Derivations

We created one final category for Derivations: "Other". Let's go to that tab to set-up one last Derivation: Armor Class.

Now, remember that one of the main benefits of Derivation Groups is the ability to have several derivations share a pool of points that are distributed between them. As "Armor Class", much like "Saving Throws", is purely a calculation, and has no way for players to directly increase it without the gaining of abilities, items, etc, we could have just made a Derivation Group for "Calculations" or something like that and had "Ability Modifiers", "Saving Throws", and "Armor Class" all under that "Calculations" Derivation Group.

However, by creating logical separations by creating separate Derivation Groups, Hedron will make sure that the related calculations are positioned next to each other in their own categories. In other words, separate Derivation Groups never hurts and it helps organize content.

Anyway, let's make our Armor Class computation. Start by going to the tab corresponding to your "Other" Derivation Group. As before, we can skip all of the settings at the top:

Now, let's create our Derivation and name it "Armor Class".

In 5E, your Armor Class is equal to 10 + Dexterity Modifier. Optionally, you may also add some Ability Score Modifiers and/or some bonus from your armor. Let's start by setting up the 10 + Dexterity Modifier, then return to these other cases.

Similar to before, create this calculation by:

1. Click "New Derivation"
2. Name the Derivation "Armor Class" or "AC" for short.
3. Click on the "Additional Bonus Calculation" to set-up your calculation to simply be 10 + Dexterity.
4. Click save and leave all else unaffected.

The result, when done, should look like so:

And that's it! Armor Class is fully set-up!

What about Barbarians and Monks who add Ability Scores? Or Armor?

Great question. Let's talk about this by taking a step back and discussing Entity Fields in more detail:

Entity Fields

We touched on the concept of Entity Fields above in the form of Properties. Derivation Properties are a type of Entity Field specific to each Derivation. In other words, they are a "Derivation Field".

Entity Fields, on Hedron, are values that vary between entities of a particular type.

• Derivation Properties (i.e. Derivation Fields) can vary from Derivation to Derivation
• Item Fields vary from item to item
• Ability Fields vary from ability to ability
• etc.

Whenever your system has a value that varies from a specific kind of entity to other entities of the same type, that's probably an Entity Field.

REMEMBER: "Entities" are just a general word for things on Hedron. Items, Abilities, Feats, Classes, etc. are all types of Entities.

Why is this important? This is the foundation of how Hedron works for every system out there.

Let's go into more detail by returning to the question: "What about Armor adding to Armor Class?"

Armors & Armor Class

In 5E, there's several kinds of Armor, each granting a different bonus to AC.

For example, characters can wear "Leather Armor", which grants +1 to AC. Or they can wear "Chain Shirt", which adds +3. And so on.

Notice, the bonus granted by each Armor varies from Armor to Armor. This makes it a great candidate for an Item Field, the Entity Fields associated with Items!

An Aside: Hedron Versatility

At this point in the guide, there's actually multiple ways to set things up for the next few steps. We're going to do it in a way that teaches you the most about the set-up of systems, but definitely there are different and better ways to do the next few things.

Ultimately, when/if you design your own system, you'll have to make your own decisions about how to set things up, each with pros/cons. Consider joining the Hedron Discord if you want to discuss some options with the developers!

Anyway, let's push on knowing that the way we're about to set this up is just one of at least 3 reasonable approaches.

Items

Leave the "Derivations Tab" and head over to the "Items Tab", skipping a few tabs for now.

Here, you'll see all the options to configure how items work in your system.

Let's start with the first option under "Basic Options": "Allow Slotless Items". In some systems, like 5E, characters can benefit from or otherwise use items without actually equipping them — think of floating stones that grant some benefit to the character. For 5E, let's enable this.

Next, we have the label overrides. Setting a value here will rename how Hedron refers to this kind of Entity within the context of this system. For 5E, the terms "Item" and "Items" are reasonable, so we'll skip these.

For "Max Capacity Calculation" under "Carrying Capacity", we specify the computation used to determine the maximum carrying capacity for characters. If your system doesn't use Carrying Capacity, you would leave it blank. For us, let's set it to 5E's Carrying Capacity Calculation: 15 times your Strength.

Finally, we have "Measurement Units". Here, we can specify how the value of items and the weight of items is expressed from a units perspective. In 5E, items are valued in "Gold (GP)" and weighed in "Pounds (lbs)", so go ahead and specify it as such.

The final result for this initial set-up is:

Next, we see areas for "Previews" and "Overviews". These are purely for customizing the display of your system. So, for now, let's skip them. We'll discuss these in a separate guide.

After that, we see an area to define "Item Slots". 5E uses a very loose definition of items by default. That is, there's only 1 rule officially stated and the rest is up to GMs: Player Characters can only attune to 3 items at a time. There's no real concept of "Slots" in 5E, but your system may vary.

For 5E, we'll just add this limit by creating a slot called "Attunement" and indicate that there are 3 such Slots:

Item Fields

At last, the Entity Field of Items: Item Fields.

As we mentioned earlier, a singular Item Field indicates a specific value that varies from Item to Item.

You have a lot of options here as a creator regarding what to make an Item Field and what to not make an Item Field. For example, you could make "Color" or "Weight" or "Cost" or whatever else an Item Field. However, there's a full things to keep in mind as you decide what to make an "Item Field":

• Is this Item Field mechanically relevant? "Color" is a legitimate Item Field, but does Hedron's VTT really care about the color of the item? If not, there's no real benefit to making it an Item Field unless you specifically demand all creators in your system designate the color of the item.
• Is this Field already provided by Hedron? Hedron generally avoids assumptions, but we do provide some useful and highly common fields to all systems. This includes both "Cost" and "Weight" (using the cost and weight units we defined above).
• Would this field be useful for "Advanced Searching Purposes"? More on this later, but any Entity Field you create is 100% searchable on Hedron (which makes sorting your content VERY easy.

So given that, let's think about the Entity Fields in 5E.

5E has different kinds of items: Armors, Weapons, Consumables (Scrolls/Potions/etc), and Wondrous Items. Each of these work a little differently, but the fact that they can be categorized conceptually means players/GMs might want to search by category and/or only see data based on the type of item it is — i.e. players/GMs probably don't care about a weapon's Armor Bonus, etc. So, the "Item Category" itself is a good candidate for an Item Field.

Moving past that, Items often have an "Enhancement", which is a numerical value indicating the item's power but also sometimes increasing the efficacy of the item itself. For example, a +1 Leather Armor grants a +1 + 1 , for a total of +2 to AC; the +1 before the name and added to the total bonus is the "Item Enhancement", another good Item Field.

While we're at it, let's also return to our prior question regarding Armor Bonuses to AC and set up an Entity Field for the Armor Bonus that a particular Item grants.

Lastly, users might find benefit from quickly knowing if an item is a ranged weapon or not — as mentioned above, this would make users able to search for Ranged Items specifically. So let's also make "Is Ranged Weapon" an Item Field.

Again, these are just examples of Entity Fields we can create (and they might not be all we create), but they will illustrate how to use Item Fields well, so we will start with these. To summarize, we have 4 entity fields:

• Item Category: What kind of item is this?
• Enhancement: How well made is this item?
• Armor Bonus: What bonus does this item provide to AC?
• Is Ranged Weapon: Is this item a ranged weapon?

Let's create each of these to learn more about Item Fields (and more broadly, Entity Fields).

Item Category

To summarize, the Item Category should be a field that determines the category of items that a particular item belongs to. It could be "Armor", "Weapon", "Consumable", or "Wondrous Item" (we could make more categories, but let's start with this).

Let's start by clicking "New Item Field".

Then, name the new field "Item Category". We could also give it an abbreviation and/or description, but it's not necessary, so for this guide, we'll skip it.

Next up, "Field Type". Item Categories are a mixture of letters and numbers, so we should select "Alphanumeric" from the drop down.

"Field Grouping" is how we organize our Item Fields. In short, from an Item's edit page, you'll see Item Fields grouped by this "Field Grouping", then ordered by the order they appear in our Rule System. Since "Item Category" is pretty general, let's leave it blank (this puts it in a Field Group called "Other Fields" by default).

Next, "Conditional". We can skip this as well (don't worry, we'll use this below so you can see how it works).

Following up, we see "Default Value". This field, like its name might sound, sets the value of the "Item Category" Item Field when items are first created; creators of Items can always change this value. So, let's just say new items belong to a category called "Uncategorized".

Almost done; we have the "Possible Values" section. If we don't add any Possible Values, creators will be able to put anything in this field. But, we want to keep things organized, so let's restrict it. Click "Add Possible Value" and add the 4 groups we mentioned previously: "Armor", "Weapon", "Consumable", and "Wondrous Item".

What about "Uncategorized"?

This is a special trick on Hedron. Because we set a default value, this Item field will ALWAYS be "Uncategorized" (our default value) when an item is created. But in the dropdown, you'll never see "Uncategorized" as an option — which means any time a creator actually changes this value, they will have to categorize the Item. You'll see what this looks like once we're done setting up Items.

You, of course, don't have to do this; you could add "Uncategorized" as an option to allow creators to leave their Items Uncategorized.

When you're done, you should see something like this:

And that's it for this field. We'll come back to how this looks for creators and players.

But let's move on to our next Item Field.

Enhancement

Enhancement, itself, is a pretty simple field. It's just a number that creators set on their items (though it does get used in other calculations).

So create a "New Item Field". Name it appropriately, and change the Field Type to "Numerical". And that's it, really:

That being said, let's go over some of the details in this example.

Numerical Fields, notably, have a field called "Value Tracking", unlike Alphanumeric or True/False fields. If you set this to something besides "None", it signifies to Hedron that this field is actually a "Tracker". Meaning, there's a counter associated with it and it either counts up or down. We'll come back to this idea when we set up "Death Saving Throws" and "XP-based leveling" below.

Next, we have the fields we discussed before: "Field Grouping", "Conditional", "Rounding Override", "Default Calculation", and "Calculation Minimum/Maximum Value".

And lastly, as this is a numerical field, we also have an area to specify a "Check". You might be wondering why this option exists for Item Fields. Some systems have checks that are based on some value provided by Items — including 5E. We'll revisit this later, but let's leave it for now.

Armor Bonus

Moving on, let's finally address the question of how to apply Armor to our AC.

Reminder, there's multiple ways to do this. We're just doing this one particular way.

All we have to do is create a "New Item Field", name it "Armor Bonus", and set it to a "Numerical" field, just like we did for Enhancement. So far, the result is exactly the same.

So make those changes and then go down to "Conditional". Check the box to activate this functionality.

So what does "Conditional" do? Conditional indicates to Hedron that this field should only be displayed to creators if some condition is met. In this case, we only want to show the Armor Bonus IF the item belongs to the "Item Category": "Armor".

Set that up as so by clicking on the edit icon next to the checkbox for Conditional:

Save that condition, and go down to "Default Calculation". If you haven't saved since you made "Enhancement", now would be a good time to do so (or it won't be available for our calculation)!

Edit the Default Calculation and set it to equal "Enhancement", no multiplication or addition necessary.

And that's actually it! You should see this:

You might still be asking "How does AC play into this? Where do we add Armor Bonus to AC?"

Don't worry. I know we didn't connect the two of them yet, but this is really all that creators need to set-up Armors. We'll look at the Item Creation process in a moment here. For now, trust that we have done it correctly.

Is Ranged Weapon?

Lastly, we have one more simple Entity Field to set up: "Is Ranged Weapon?".

This one is also fairly simple, create a "New Item Field", name it "Is Ranged Weapon?", change the Field Type to "True", and skip the Field Grouping again.

Add a Conditional, just like we did for "Armor Bonus", except this time, make the condition: "Item Category = Weapon". Save that condition, and leave the "Default Value" as False (most items are not Ranged Weapons).

And that's it for this field:

And with that, we've actually fully set up the basic framework of Items in 5E.

That being said, we can make some improvements to include some of the other characteristics of items. Specifically, let's flesh out ranged weapons by adding 2 more Item Fields: "Weapon Range (Normal)" and "Weapon Range (Long)". These are just numerical fields that look exactly like "Enhancement", except in name and "Conditional". Specifically, we want these fields to also only appear if the Item Category is "Weapon". We'll skip the step by step this time and show you the final result (for one of these fields — the other is very similar):

NOTE: We added a Field Grouping to these new fields called "Ranged Details". This is purely for convenience and organizing. Feel free to ignore that part, but we'll show you what it does in the area below.

Why did we make the "Field Grouping" be "Ranged Details"? Field Grouping is purely a mechanism for you, as the writer of a Rule System, to create logical connections between different fields. No matter how you set them up, the game mechanics won't be affected by them. BUT, by setting them, you can make it easier for someone using your system to find related things.

For example, if you had 3 fields labeled "Durability", "Toughness", and "Strength", there's a few ways you could set their Field Groupings, depending on your system design. You could put "Durability" and "Toughness" together under a Field Grouping named "Health" — leaving Strength out. Or you could put "Toughness" and "Strength" together under "Physical Power" — leaving Durability out.

It's really entirely up to you. As a System Designer, when setting Field Groupings, try to think about "If I was a player, looking for this information, what kind of category would I group it as?"

While we're completing the full support for items in 5E (including Roll Automation), let's add a field for "Attack Bonus". And like "Armor Bonus" includes "Enhancement" in its calculation, so will "Attack Bonus". Further, let's add "Strength Modifier" to our Attack Bonus. By doing this, we're setting up the idea of an "Attack Roll" in 5E, where a character adds their weapon's enhancement plus the relevant Ability Score Modifier in order to determine how effective their attack is. Here's what the calculation looks like:

Save this, and add a check to this Item Field, naming it "Attack Roll" to complete this Item Field:

Now, you might be wondering here, "What about weapons that add Agility?" As we mentioned above, we're only setting the Default Calculation. When a creator is making an Item, they can change this value and replace Strength with something else.

Notice, we also re-used "Enhancement". We could have broken it out into "Weapon Enhancement" (used strictly for "Attack Bonus") and "Armor Enhancement" (used strictly for "Armor Bonus"), but that would create more buttons for creators to deal with, so we opted to just re-use "Enhancement" for both.

Now, we've mentioned a few times that "trust us, this works". And we've talked about the experience of creating items. But, let's illustrate that experience more concretely.

To better give you a sense of what we've done, let's take a step back from our Rule System and look at what it looks like from an item creator's perspective.

Don't worry, after you've saved, you can always come back to your Rule System later to continue working on it — the changes you make will automatically be synced across all the content in your system. I.e. you can always switch back and forth between creating content in the system and modifying the framework itself.

Creating Items

So save your Rule System, and go to the Items page by going to the "Content" tab from the top navigation and click on "Items".

The top of the Items page should look somewhat like this:

The main difference could be that your "Current Ruleset" might be set to something else. Before you continue, make sure that you click "Change Ruleset" and select the Ruleset that you have been working on for the rest of this guide.

From the Items page, click "Create Item" in the top right. As an example, let's make a simple "Leather Armor"; name it as such and click "Create". That'll take you to your new, empty item page:

As you look at this page, you'll notice some of our Item Fields that we created, as well as the Field Groupings. Let's go into Edit Mode by clicking the pencil icon in the top right.

First, you'll see the general, basic information for all items, regardless of System:

These fields are available to all items of all systems, but also aren't relevant to illustrate our point from a Rule Systems perspective. Below this section, you can see an area for Item Fields:

As you can see, Hedron provides a few basic fields for items in all systems: Is Currency, Price, Weight, and Equipment Slot. However, you will also see a section for "Other Fields", the fields we defined without a Field Grouping.

Clicking on "Item Category", you will see it's a drop down with the values we listed as possible values: Armor, Weapon, Consumable, etc.

Before we select the value, notice also how there's an indicator showing that there are 3 Hidden Keys in the Other Fields category, as well as 2 Hidden Keys in our Ranged Details. If you recall, these fields are hidden because we created a "Conditional" for them.

Let's set the "Item Category" to "Armor". You'll notice some of those hidden fields are no longer hidden:

Similarly, if we set the Category to "Weapon", we'd see other fields appear:

This is Conditionals in action. It makes our fields hide/unhide automatically based on the conditions we set earlier.

Of course, if the item creator wanted to, they could just click on the "X Hidden Key(s)" and it would reveal all the Hidden Keys until the Item is saved.

Anyway, let's set it back to Armor and actually set our values — as if we were making the item.

Really, the only thing we need to change is the "Armor Bonus Field". Specifically, it's currently set to "Enhancement", by default. We just need to add +1 to that formula (the effect of Leather Armor in 5E), as so:

Now, moving on to the section titled "Granted Bonuses", we make the actual connection to our AC. Click "Add Bonus" and you'll see a section for "Bonuses and Penalties" appear, with 1 bonus:

As it says, "No Bonus Configured". That means, "this bonus does nothing", as of now. Let's fix that.

Click the pencil icon to open the Targeted Bonus Editor dialog. At first, you will see something like this:

What this dialog is asking you is "What Field do you want to affect with your Bonus?"

Let's type "Armor Class" into the target field (selecting it from the suggestions when it appears). When you do so, you'll see a more familiar sight:

The only difference is the header area, where we see the "Target Field", the "Application Operation" (SUM in the example above), and the Priority. For more details on these options, check out the guide on Bonus Editors.

But for us, we're going to add the item's Armor Bonus to our Armor Class. So set the calculation to be equal to "Armor Bonus", as so:

Save this bonus, and you'll see something like this under "Bonuses and Penalties":

Great. That sounds like what we want our Armor to do.

Note: Items only grant bonuses when they are equipped. If systems allow Slotless items, then being equipped as "Slotless" counts.

And with a Save, we've successfully set up our Leather Armor.

A Note About Entity Fields

Hopefully from this section, you've gained an idea of how Entity Fields, at least in the context of Items. Generally, this is the way you will set up all the other kinds of Entity Fields (for both 5E and also for other systems).

Entity Fields can do a LOT of different things. But rarely do they need to do everything. Many options for many Entity Fields will remain untouched. And that's okay!

Skippable Tabs

With Items now set-up, we can turn our attention to other Entity types.

But, given how we are going to be using some of these other Entity Types, we can actually leave some of them unaffected.

That is, for 5E, we don't have to do anything special for Hedron to understand Abilities, Campaigns, or any of the other disabled features.

So for now, we can ignore these Tabs, leaving us with only a few others:

Heritages

There are a few small changes we need to make for the Hedron Heritages mechanics make sense to someone looking to play 5E.

Let's go back to our Rule System editor.

Then, go to the "Heritages" Tab. For the first time, we're going to use the label overrides. Specifically, in 5E, "Heritages" are referred to as "Races". So add a label and plural label override of "Race" and "Races", respectively.

Other than that, we don't need to make any other changes to Heritages.

But what did this do? When someone has selected your 5E Rule System, their navigation at the top of the page under "Content" will use your new labels:

Magic

Another major section for us to update is the "Magic" Tab of our Rule System.

As before, let's leave everything as-is for the labels, previews, and overviews:

Spells, like Items, have a lot of Spell Fields, another type of Entity Field, this time unique to Spells.

For succinctness, we'll only go over one of them — just to show you how similar it is to setting up Item Fields. Specifically, let's set up a field called "Attack Type", which just determined if a Spell's attack is "Ranged" or "Melee". It's an Alphanumeric field with 2 possible values:

Similarly, you'll set up several other Entity Fields, based on the needs of your system.

For 5E, we'll be setting up:

• Damage Type: To denote the main type of damage dealt by the spell. Actually, when you create a damaging effect, you can also set the damage type (provided by Hedron), BUT, having it as an Entity Field makes it easier to search.
• Has Concentration: A True/False field to denote if the spell requires Concentration to maintain
• Has Ritual Casting: A True/False to denote if the spell can be cast via Ritual
• Material Components: The Material Components to cast the spell, if any.
• Range: The numerical range of the spell in feet.
• Somatic Components: A True/False field denoting if the spell requires Somatic Components to cast.
• Special Duration Description: Any special notes regarding the duration of the spell.
• Variable Duration: A True/False to denote if the spell's duration is variable
• Verbal Components: A True/False to denote if the spell requires Verbal Components to cast.

All in all, the completed Spell Fields will look like this:

Magic Schools

Now, time for something we haven't seen before: Magic Schools.

This is a totally optional thing to do for your system, but setting up Magical Schools can help you and your players organize spells, as well as make bonuses that vary from Spell School to Spell School.

Click "New Spell School" to create an empty Magic School:

It's a pretty simple thing compared to Entity Fields. It just contains a place for the name, abbreviation, description, and also a break-down into Sub-Schools (if relevant). When people create spells for your system, they will see options to attach one (or several) Magic Schools.

Classifying a spell under a specific sub-school doesn't do anything mechanically, but bonuses and other effects can apply to spells differently by Spell School, just like any other Entity Field.

For 5E, we don't need Sub-Schools. We just need several Magic Schools. So go ahead and create each of the relevant schools:

And lastly on the magic page, we have a more interesting and unique functionality for Spells. The key defining feature of the Spells/Magic System on Hedron is that they draw from some form of reservoir, which is granted by classes, abilities, etc.

Depending on the system, that reservoir might be Mana, Sanity, or (in 5E's case) "Spell Slots". In other words, for 5E, "Spellcasting Sources" refers to "Spell Slots" — which each source representing one level of spell that can be cast.

Start by creating a "Spellcasting Source".

You'll see a blank "Spellcasting Source" like so:

Let's start by naming the source. It'll be called "Cantrips".

Next, is the "Default Size Calculation". In short, when creators create a "Spellcasting Source" or "Spell Slot" (for our purposes), they will be able to specify how the overall size of the source is determined. BUT, it will default to the value we specify here.

The big question that you might be wondering here is: "But Cantrips don't really run out?"

And you'd be right! But the important thing to know here is that you configure that when you make a spell. The "Size" of the source is really just the maximum number of such spells you can prepare (if you're a prepared caster like Wizard) and it's meaningless for classes like Sorcerer, who "just know" some number of spells.

For 5E, the number of each "Spell Slot" is determined entirely by one's class. So, we can leave it at 0 — for the creators to configure when they make their classes.

Lastly, we have "Source Fields", which, like other Entity Fields (or perhaps more similar to Derivation Properties), can vary from one Class' "Cantrips Source" to another's. We don't need these for 5E, but you could, if desired, include a Source Field designating if it's an Arcane or Divine Source — just to fit with the "feeling" of the system.

So our completed "Cantrips" source will look like so:

For 5E, the magic system is relatively simple. We're just going to need 9 more copies of this exact Spellcasting Source (with different names and no other changes).

When it's done, it'll look like this:

And that's it for setting up magic! Everything else is taken care of when creators make spells or when they create classes.

Character Fields

Let's jump back a few tabs to "Character Fields".

Like the other major entity types, "Character Fields" are the Entity Fields for Characters.

"But what about Character Derivations?"

Great question! Here's the simple explanation:

• Character Derivations are heavy-duty. They support player input, properties, and more. They are complicated to set-up, but very powerful for NUMERICAL calculations only.
• Character Fields are just Entity Fields. So they're much simpler, but if you have a simple thing to track, they're easier than using Derivations.

Let's give an example of something from 5E that is a good candidate for a Character Field over Derivations: Alignment.

In 5E, "Alignment" refers to a character's disposition towards good/evil, law/chaos. It's a highly distilled TLDR of your character's personality. And generally, there's only 9 options, which you decide when you create a character and doesn't really change (usually). There's no progression, leveling systems, or other fancy functionalities involved — you pick an Alignment and you're done.

This is a great candidate for a Character Field. Specifically, it's an Alphanumeric Character Field with 9 options:

Simple enough!

If we had tried to do this with a Character Derivation, it probably would have worked, but it would have been a mess. This was a much easier way to do the same thing.

Death Saving Throws

Now, thinking ahead, there's one more thing we will want to track on a per-character basis: Death Saving Throws. That is, when a character hits 0 Hit Points (which we will set up shortly), they will have to roll "Death Saving Throws".

In 5E, Death Saving Throws are a simple roll of a d20, where numbers at or above 10 are a success and numbers below 10 are a failure. When you fail 3 such Death Saving Throws, you perish.

So, we'll make a simple Death Saving Throws field with a default calculation of 3. Then once we've done that, set "Value Tracking" to "Countdown":

We mentioned Value Tracking before, but let's go into what this means now. By specifying that this Character Field is a "Countdown", it means that Hedron will use the calculation (in our case, 3) as the "maximum value". I.e. this will be the number that the Countdown starts at. Then, effects from abilities, items, your GM can add or subtract from this number — for example, reducing it by 1 when you fail your Death Saving Throw.

Then, when your GM sees that your "Death Saving Throws Current Value" is 0, they know your character has perished (in addition to the "Dead Condition" which we'll set up below).

Experience Points (XP)

To further illustrate the idea of trackers, let's also set-up XP tracking.

In short, for 5E, character level-up and progress based on their accumulated Experience Points (XP).

XP is given out by the GM for a variety of things, and when the total accumulated points reaches various points, the character levels up.

To set up a system like this, we'll use another Character Field.

Create a new Character Field called "Experience Points", and set the "Value Tracking" to use the other kind of Tracker: "Counter / Increasing Value".

Now, for setting the default calculation, we're going to need to do something a bit more interesting. Open the bonus editor for the calculation and go to the "Scaling Tab". Add a component and set it to infinite using the Infinite Button:

Note: Even though we're multiplying by zero, the result is still infinity. Actually, the only thing that matters about the number you multiply by infinity is whether it is positive or negative. Negative numbers will result in "Negative Infinity".

Now when you save this bonus, you'll see that the calculation is set to "Infinity":

Why did we do this? Because XP continues to accumulate without limit. At some point, players will level-up, but we don't necessarily want to automate that — it's a GM's decision after all. But even after they level-up, their XP continues to increase. By setting this "Counter" to have a Default Calculation of Infinity, that means the value will start at 0 and keep counting up to Infinity.

If we wanted to, we could have also approached this by creating a complex advanced calculation that determined an XP cap based on the character's level, which would prevent XP from "overflowing" into the next level. But, this is likely not necessary for us.

Using the Modules System, a GM could also override this behavior for XP to do their own approach (a future guide will cover this).

But otherwise, that covers Character Fields for 5E! We could also create fields for "height", "weight", or other "flavor" fields, but for succinctness, we'll stick with the basics for now.

Health

Next, let's go to the "Health Tab".

The Health tab is where you specify how life and death work in your system. Starting with "Health Bars".

Health Bars

Create a "New Health Bar". You'll see another very simple prompt:

So what's all this? First, there's the usual name and abbreviation.

Next, you see a button for "Primary Health Bar?" In short, Hedron has two kinds of Health. Total Health and Primary Health. And each one comes with a bunch of referenceable calculations for "Remaining Health", "Max Health", etc.

For example, you could create a penalty that reduces one's Dexterity when their "Total Health %" is under 50. Or you could make a penalty that does the same thing when "Primary Health %" is under 50. And of course, you can specifically do the same thing for particular Health Bars — "Health Bar 1 %" is under 50.

In 5E, it's easier to explain by demonstration.

Let's make one Health bar titled "Hit Points". And it will be a "Primary Health Bar".

Next, let's see "Health Bar Grouping". When Health Bars are grouped, they will be drained in the order they appear on this page from top to bottom. As 5E has fairly simple Health systems, we can leave this empty.

Finally, we have the "Default Size Calculation". Again, this is a "Default Calculation", so when players are building their Characters, they can change this calculation. But, in general, for 5E, your character's Hit Points is based on their level in a particular class. Which means we need to set-up a quick Class Field for that.

Health Detour: Class-Based Health

Head over to the "Classes" tab.

We're going to create a simple numerical Class Field called "Class Hit Points", to represent the amount of Hit Points you get from your Class.

The only things we will need to set is the name of this Class Field, as well as a "Default Calculation". The Default Calculation for Class Hit Points will be a bit tricky. First, let's reiterate how Hit Points work.

Each class has an associated Hit Dice (d4, d6, d8, etc.). At first level, a character in that class has a number of Hit Points equal to the maximum number on their Hit Dice plus their Constitution Modifier. At every level after first, the Character must roll their Hit Dice and add it to their Constitution Modifier in order to determine how many more Hit Points they gain at that level.

So, let's set that up in calculation form. As this is just setting the default calculation (and each class can override this), let's assume the Hit Dice is d6. Let's also ignore the Constitution modifier for just one moment.

Thus, the calculation can be thought of as "6 (Hit Dice max) + (Class Level - 1) * 1d6":

Notice we used "Class Level" here, but we never defined it! Hedron provides this specific field for all systems. In short, it represents the "Level of the Class that is doing the calculation". That means if this calculation happens for a Wizard ability, the Class Level will be the Wizard Level, for example. By using "Class Level" over "Character Level", we ensure we correctly capture the 5E rules.

And that means our Class Field so far looks like:

Now, let's revisit Constitution. As mentioned above, a character's Total Hit Points is increased by their Constitution Modifier at each level.

There is a way for us to squeeze this all into one calculation, but this is a good time to mention a reason to consider another entity field for "Constitution Hit Points":

When you create an extra Entity Field, players can see the calculation of each part individually.

If we jam it all into one calculation, a player of a level 8 Wizard with 12 Con would see something like:

"Class Hit Points (56) = 6 + 1d6 * [Class Level (8) - 1] + [Class Level (8) * Con Mod(1)]"

Looks messy right?

But, if we create a separate Entity Field, it would look like:

"Constitution Hit Points (8) = [Class Level (8) * Con Mod (1)]"

"Class Hit Points (56) = 6 + 1d6 * [Class Level (8) - 1] + Constitution Hit Points (8)"

Of course, this is just one example. We could also separate out the rolled Hit Points to create an even simpler break down, but we'll leave it at this for now.

So, let's create another Class Field for "Constitution Hit Points". Note that because this is a multiplication of two different calculations, we need the advanced tab. The calculation should look like this:

Notice we set the "Operation" to "Product".

And the overall Class Field for the "Constitution Hit Points" will look like this:

Now that we've set this up, let's go back to our "Class Hit Points" and add that "Constitution Hit Points" Calculation:

Which gives us a completed "Class Hit Points" of:

This is actually all we need to finish the support for Classes as well, so we can return to our Health Bars. But first, let's answer some questions about this section:

When will the 1d6 be rolled?

Because this is a part of the character's calculations themselves (as opposed to a spell effect or something transient like that), they will be rolled when the character joins a campaign.

Could we separate the dice rolling part to another Class Field like "Hit Dice"?

Yes. And honestly, I would do that. It would do the same result (they would be rolled when the character joins a campaign), but the calculation breakdowns will be simpler.

I just didn't do it here for succincity (it's already a very long guide!).

Why did we make Constitution Hit Points a Class Field and not a Derivation?

Great question! Notice how our "Constitution Hit Points" relied on "Class Level". If you made it a Derivation, the Class Level would not be your level in a specific class. You should never reference "Class Level" outside of a "Class" or an ability/spell/entity granted by a Class.

Plus, Derivations are more complex than Class Fields (as we mentioned before), so we should prefer Class Fields.

IF we wanted to set it up as a Derivation, we could do it by using "Constitution Modifier * Character Level". After all, mathematically, it will be equivalent. But, the rules of 5E also talk about it as "Constitution Modifier * Class Level", so we should stick to their conventions.

A side effect of also doing it this way is that a player could see how much they get from each class, not just a total number.

Returning to Health Bars

Returning to the "Health" tab, we are reminded we started setting up "Hit Points":

In fact, we've fully set it up, except for the Default Size Calculation. Well, this part is really easy — it's just going to be equal to our "Class Hit Points". That's it! That calculation, as we just set up, handles the Constitution, the rolling for HP, and more.

We just need to reference it to create our completed Hit Points calculation:

"How will Hedron handle multiple classes, each with their own value for "Class Hit Points?"

It's additive. The combination of Class Fields like this are always additive. At this time, there's no way to change this, but we're always open to feature requests as necessary!

Damage Types

Next on the Health tab is "Damage Types".

In short, Damage Types specify the suggested Damage Types for creators to use when they specify effects that deal damage. Note: it's purely a recommendation for creators. Creators in your system will always be able to specify "Other" for alternative damage types.

Let's just go ahead and simply specify the standard 5E damage types:

And that's it for Health! All of the tracking of Character Hitpoints, damage, and all that stuff will be handled behind the scenes by Hedron!

Conditions & Status Effects

Click on the "Conditions & Status Effects" tab.

Here, we can create re-usable blocks of Effects. In a way, it's like grouping together several effects so that other spells, abilities, items, etc can easily replicate the effect.

Let's create a few of the basic 5E Status Conditions to show how one can set them up.

Deafened

First, we're going to make the "Deafened" condition.

Click "New Status Effect" to create a blank Status Effect:

Start by naming it appropriately.

Next, we have a section for "Condition Fields". Condition Fields are basically super simple fields that don't really serve a mechanical purpose. They aren't really relevant to 5E, so go ahead and skip them. (In the future, we might upgrade these to proper Entity Fields, if there's a request for it)

Next, the interesting portion: Effects. Effects are all the things that happen or are applied when this status condition is applied. It's really the section that differentiates between different Status Effects.

Let's "Add Bonus". According to the 5E SRD, Deafened Characters automatically fail any check that requires hearing. To support this, we'll create a bonus of -Infinity applied to Perception Checks:

The resulting completed Deafened Status Condition will look like:

You might be thinking "But only hearing checks automatically fail", and you'd be right. However, at this time, there's no way to explicitly specify which checks will and won't be hearing checks in advance. Instead, the player will simply toggle this status effect for hearing and non-hearing checks.

Dead

Another simple condition we can set up is the "Dead" condition, which won't have any effects, but will be a good marker for the GM to know which characters are dead.

And we'll have it automatically apply itself using Thresholds (see below).

So, for now, just create a simple Condition titled "Dead" and that's it:

Now, let's see how we can automate the application of "Dead".

Note: using the above strategies, you can set-up all of the other 5E conditions, but we'll leave it here for now.

Thresholds

Thresholds are a way to automatically apply some Status Effect based on some conditions.

For 5E, there's only 1 threshold we really need: the one to determine when a character has died.

Create a "New Threshold".

Name it "Character Death" as this Threshold will be used to track when a Character should be given the "Dead Status Effect".

When you click to edit the condition, set it to "Death Saving Throws Current Value is Less than or equal to 0". In other words, when our "Death Saving Throws Countdown" hits 0, we'll trigger this threshold.

Then, all we have to do is "Add Status Effect" and choose our "Dead" condition, which will denote to the GM that this character is dead.

Of course, if the character undoes their Death saves somehow, this Threshold will become deactivated and the character will lose the Dead Status (as long as they don't have it for some other reason).

The end result should look like this:

And for 5E, that's the only Threshold we need!

Generally, we can use Thresholds to do a variety of things from encumbrance rules to critical injuries. But 5E doesn't have many of those kinds of automated effects, so we're done here.

Sharing & Licensing

Last, but not least, we have the "Sharing & Licensing Tab".

From here, we have the standard Hedron controls as well as some controls to manage the Licensing information for our Rule System.

Note: the following is not legal advice. Hedron is not responsible for the legal consequences of publishing content you do not own and we take DMCA requests very seriously.

When you create a Rule System on Hedron, you can (optionally) including a License with it. To create one, you go to the Licenses Page and create a new one to reflect the content of your License.

What Are Licenses?

Licenses are a legal document that describe the rights of your content. That is, what people can and can't do with the content you created.

In general, you can't write anything you want and expect it to be enforceable. You also can't publish someone else's content verbatim and say its yours.

That being said, we're not lawyers. If you plan to publish your content publicly, and you want to make sure your paperwork is in order, then speak to a legal expert.

D&D 5E's SRD

If you noticed, we kept referring to this guide as building the "SRD" or "Source Reference Document". As per Wizards of the Coast's official statement, the content of the SRD is considered to be published under the "Creative Commons" — one of the most permissive licenses there is.

The exact legality of the document is not relevant to this guide.

So we'll simply create a License titled "Dungeons and Dragons: 5th Edition Source Reference Document 5.1" and include the necessary links and information for the "Creative Commons".

Then, from our "Sharing & Liscensing Tab", we'll simply set our License to our created License.

Next, we have an area to control who can and can't see this Rule System, as well as who can and can't edit or delete the system. Of course, this part is up to you, but as we're publishing a system for all of Hedron, we'll make it Publicly Viewable, but there's no need to add any other editors or deletors.

Closing Thoughts

And with that, we're done!

This was quite a lengthy walk-through, but then again D&D 5E is considered one of the "heavier" systems.

Before we close out this guide, I just want to congratulate you for sticking through it! Hedron is a powerful engine, but it requires a bit of learning to get right. So thanks for your patience.

And also, hopefully, after this guide, you feel more comfortable working with the Rule System editor. This is, by far, the hardest page to "get right". But once you do, you never have to look at it again. And hopefully you can also see, there's a lot of different ways to "get it right".

Otherwise, I hope this guide was generally helpful to you and if not, feel free to reach out to us over any of our platforms and/or leave a reaction below!

And of course, feel free to check out some of our other guides!