Patron-only: stage 4 prototype (Patreon)

Here's the stage 4 prototype: Barbarian!

As before, remember that this is only a prototype. It's not perfect, and it's not supposed to be perfect. This is just a step on the road.

For reasons explained below, there won't be prototypes for stages 5 or 6.

Colour!

I wasn't planning to do colour till later, but I was bored and it was surprisingly easy. I particularly like the way vector images like icons get the colour effect while the logo and character portrait don't.

Pages

I'm trying another shift of pages. Ancestry, Background and Class have been moved onto the cover page along with the character's portrait and details. Meanwhile the skill feats are on the skills page. Let me know if that balance feels good to you - feedback welcome!

I added an example "permission to print" page, which some people find helpful when taking these to a print shop. As in PF1, that page will be optional.

Barbarian

There's nothing particularly revolutionary about the Barbarian here. I'm expecting some important details to change in the final game. This is mostly about me nailing down the ingredients of a class: the level markers, the action icons, the calculations etc.

Data driven

Stage 3 was built by calling lots of render functions directly in a big ball of code. Stage 4 is built from a big JSON data file that describes what elements should go where. The rendering code walks down that file, saying, "This says it's an icon, so I'll call the icon render function."

As well as being a necessary step for the final product, this makes some things a lot easier. Each of the render functions has a set of defaults, which the renderer applies automatically, which means the data driving it can miss out any details that match the default. Without that, the data file driving it would be several times as big. For example, every element has a default that says "Do I actually exist? Yes." A few elements override this, saying instead, "Do I exist? Let me check...". You can see this in the Armour Check Penalty column on the skills table, where most of the rows don't have that box, even though the table is defined with the same code for each row.

The render functions now return more complex results, most notably for fields. A single field object can result in a dozen HTML elements - the surrounding frame, the box, the icon, the label, the overlay, the underlay, etc - which makes it easier to apply complex styles to all those pieces.

An important, and easily overlooked, aspect of all this is the thorny question of what to call things. Is that an icon or an image? Is this a box or a frame? Is that a unit, an element, a node or an object? Sorting

Stylesheets

Stage 3 converted the stylesheets from raw CSS into SASS, a structured language that compiles into CSS. The result was a bit of a mess, so in this stage I continued the work of tidying up the stylesheets and dividing them into modules. As well as being easier to find my way around, this is important for the future when the stylesheets get interchangeable parts, like an alternative visual style, a large print option, or a dyslexic-friendly font.

Next steps

Stage 5 is about the the zone composer. This prototype was fed from a single big JSON file describing what goes where, but a real character sheet is a combination of options from different places.

This is where the code becomes much more flexible, allowing a set of selected units - typically an ancestry, a background, a class, various feats etc - to each contribute visual elements to the character sheet.

For an example of why this matters, look at the combat page of the Barbarian or Monk on PF1, or the skills list of the Barbarian or Ranger. Those classes make alterations to the core pages, but in my PF1 character sheets the only way they can do that is to replace the whole page. There's a Monk version of the combat page. That means you can't play a Barbarian/Ranger without it having to choose one or the other. A zone composer allows you to intervene.

Stage 6 is then about writing a couple of fully-fleshed-out example units that can contribute to this, such as an example class, an example ancestry, an example feat etc. Then Stage 7 will be about settling on the right format in which to write all the units, so that it can once again be data-driven.

That means there won't be prototypes for stages 5 and 6, since they're both internal steps. The next time you see a prototype, it'll be for stage 7 - presumably some time in the spring.

And that's definitely not because I'm spending the winter huddled under a blanket with a hot mug of tea, a tub of peanut butter and a bad book.