Table of Contents
Sheet Code Description
Names and Simple Lists
Here’s the code at the start of the sheet, for basic character description.
<h3>Castle Falkenstein Dramatic Character</h3>
<span>Name</span>
<input type="text" name="attr_character_name">
<span>Hero Type</span>
<select name="attr_hero_type">
<option selected>Heroic Hero</option>
<option>Tragic Hero</option>
<option>Flawed Hero</option>
<option>Innocent Heroine</option>
<option>Clever Heroine</option>
<option>Tragic Heroine</option>
<option>Fallen Heroine</option>
</select>
<span>Archetype</span>
<input type="text" name="attr_archetype" list="archetypes" placeholder="Choose Archetype">Code language: HTML, XML (xml)Notice that simple text is included in spans. You could skip those, but you’ll learn later that there are advantages to always putting your text in spans or some other element.
Inputs are used to let players enter text, and must have a type and name. The most common types are text and number – a number input can only be used for numbers, while text input can be used for anything even numbers.
The name must always start with “attr_” – if you omit that, Roll20 won’t know what to do and the value won’t be saved.
Whatever you name it, you can then access it in Macros and Abilities using the @{name} syntax. Ignore the attr_ part. So name=”attr_character_name” becomes @{character_name}
In fact, character_name is a special attribute: it is always equal to the name of the journal. If you change it, the journal name immediately updates.
Types of List: select and datalist
Then there is the hero_type select element. Use this whenever you want to present a dropdown list, and the player must choose one of the entries in the list. In Castle Falkenstein players must be one of these.
NPCs have a few types of their own, so you might want to expand this list.
Notice that a select has a name attribute, just like inputs, but doesn’t have any of the other attributes. It can have a selected attribute: use this when you want to set a default, initially chosen value. For reasons you’ll learn later, selects should always have one option selected.
And then there is this line:
<input type="text" name="attr_archetype" list="archetypes" placeholder="Choose Archetype">
Code language: HTML, XML (xml)Inputs with a list attribute are special. There must be a datalist with an id of the same name as the list. For instance, later in the code is this:
<datalist id="archetypes">
<option>Adventuress</option>
<option>Anarchist</option>
<option>Brownie</option>
<option>Calculation Engineer</option>
<!-- many archetypes deleted to save space -->
<option>Wizard</option>
<option>Writer</option>
</datalist>Code language: HTML, XML (xml)A list input shows a dropdown, a bit like a select, but it also allows you to write in anything you want. Use a select when players must choose from a restricted list of options, and a datalist when they can pick from a list or enter their own values.
In Castle Falkenstein, you can create your own Archetypes, so we use a datalist.
Abilities and Ranks
In Falkenstein, there are 20-30 Abilities, and each supplement introduces more, so it makes sense to define their names as Datalists. In a later chapter of the Guide, we’ll introduce a better way to do this.
Ranks are the equivalent of Scores – they have a specific, defined range of values, and each has a descriptive label and a numeric points value. So it makes sense to use a select for these. You can set a value=”whatever” when the actual option value is different from the displayed value.
<div>
<input type="text" name="attr_ability1" list="abilities">
<select name="attr_rank1">
<option value="2">Poor</option>
<option value="4" selected>Average</option>
<option value="6">Good</option>
<option value="8">Great</option>
<option value="10">Exceptional</option>
<option value="12">Extraordinary</option>
</select>
<button type="roll" name="roll_ability1" value="@{show_name}@{ability1}\nScore: [[@{rank1} + @{card_value}]]"></button>
</div>Code language: HTML, XML (xml)We’ll come back to the buttons later.
Note that the headings for the group are also inputs.
<div>
<input type="text" name="attr_ability_title" value="ABILITY" readonly>
<input type="text" name="attr_rank_title" value="RANK" readonly>
</div> Code language: HTML, XML (xml)This is just because they have a fixed width, and line up with the rows below them. Normally I’d set the headings using spans, but we can’t control the width of a span without CSS, so inputs it is, for now.
Notice they are set to readonly: this means players can’t modify their values so they function as fixed headings.
Checkboxes and Radio Buttons
At the bottom of the sheet we have Configuration settings. These are mainly an excuse to show how checkboxes and radio buttons work.
<div>
<h3>Configuration</h3>
<label>Ask For Card Value: <input type="checkbox" name="attr_card_value" value="?{Modifier?|0}"></label>
<h4>Show Name on Roll Output</h4>
<label>Show Name: <input type="radio" name="attr_show_name" value="**@{character_name}** rolls " checked></label>
<label>Hide Name: <input type="radio" name="attr_show_name" value=" "></label>
</div>Code language: HTML, XML (xml)There are a couple of things to notice here. The first is that the inputs are inside the labels. This is very a very simple reason you’ll see if you load the code into roll20, and click the label. You don’t have to click the checkbox or radio button precisely – if you click the label, those buttons get checked too.
In the next chapter, I’ll show another way to achieve this, but for now, this simple method works.
This checkbox and radio button change the output of a button roll.
Something to be aware of: never set a checkbox value to “0” or a radio button value to “” – they won’t work properly if you do (that’s why one of the radio button values is ” ” instead of “”).
Button Rolls
Here’s the code of a button, split across 3 lines to make it more readable. What we care most about is the value. That said, buttons must have a type=”roll” or “action”, and a name that starts with “roll_” or “act_” depending on the type of button. As with attributes, that prefix is dropped everywhere else.
<button type="roll" name="roll_ability1" value=
"@{show_name}@{ability1}\nScore: [[@{rank1} + @{card_value}]]">
</button>Code language: HTML, XML (xml)To keep with the theme of the sheet being ugly, we aren’t using a rolltemplate here. Besides, it’s handy to know the basics.
In the next post, we’ll use the default rolltemplate to show a prettier printout and later, in part 6, we’ll design our own rolltemplate.
A Roll button value works exactly like a macro with one major exception: if you want to use a line break, include \n where you need the linebreak.
The button value above starts with @{show_name} which is the radio button value. So the user can choose whether to include the name of the character or not, when clicking the button.
Likewise, the checkbox includes a query ?{Modifier}. This takes advantage of the fact that an unchecked checkbox always has a value of 0. So when the button is clicked, @{rank1} gets the point value of the Ability being used, and if the checkbox is checked, the user is asked if a bonus is added.
In the Castle Falkenstein default rules, you don’t make dice rolls – instead, play a card and get a value from that card. So this checkbox allows players to either add the card value or simply print out their Ability value.
Note that the printout is very ugly. A rolltemplate could be used to make this look a lot nice, but rolltemplates aren’t covered until chapter 6.
A Note On Containers
There are two types of containers used on the sheet. First, the sheet is divided into grouped sections using the div container. Then labels are used to enclose a checkbox or radio button.
It is a very good idea to separate groups of elements that belong together in divs. It’s very easy to overuse divs – don’t put single items inside a div, but do group elements that belong together.
It’s also common to put text inside spans – that will be very important when we start using CSS.
About Tables, Style, and Autocalcs
As noted earlier, we don’t use the table element because as you’ll find in the next part, there are much better and much easier alternatives.
If you look through the roll20 GitHub you’ll often find many sheets using style attributes to change the way elements look. Now that we have CSS, you should never use style. The next part will show how to use CSS to do everything style can do, in a much better, more reusable way.
There are also no autocalcs on this sheet. That’s mainly because they aren’t needed here – but in practice, you should avoid them and use sheet workers instead. They will be covered in Chapter 4.
So there we have it – an example of a sheet made entirely from HTML. It’s not pretty, but it works. In the next post, we’ll start using CSS, and will have all the techniques we need to make pretty and functional character sheets.
