Home Creators Posts Import Register Favorites Logout

Content

In my previous post (https://www.patreon.com/posts/19069749) I proposed a JavaScript-based solution for declaring character sheets. Having thought about it a bit more, I've changed my mind.

JavaScript is still going to be the core language of the character sheet builder, because that gives me the flexibility to run it on server, client or wherever. It keeps my options open. But the way I was using JavaScript there had a leaning towards functional programming, with heavy use of anonymous elements (ie a complete object being passed straight into a function, without ever being declared in a namespace or saved to a variable). As such it suffered from one of the classic flaws of, at least, that form of functional programming, in that anonymous elements are denied entry hooks for modification.

If I know anything about Paizo after working on their stuff for years, it's that there will inevitably be *more*. Whether that's more classes, archetypes, feats, spells, ancestries, or whole new things I haven't anticipated, there are going to be more things coming out. So this system needs flexibility.

The now classic form of this is the Pathfinder 1 archetype: a variant of a class that replaces or modifies existing class features. For this to work in a component-based character sheet builder, each replacable element needs to be identifiable. They need an ID in a registry. That doesn't jibe with the functional JavaScript approach.

So instead I'm trying a declarative approach. This excerpt shows a sample using a YAML-based DSL, in which class features are broken out into features with IDs. Each contributes elements into zones. The sample includes the Cleric, Rogue and Wizard, along with a few feats and templates. Enough to get the flavour of it.

https://gist.github.com/marcus-downing/0981631652d677608c892d71d659b967

Comments

dyslexic_charactersheets

If you're a YAML reader, you may notice a few subtleties in that gist. The first is a form of duck typing: objects are identified by their elements, rather than by a preset field. Consider this element: - field: deity label: "Deity" type: text wide: true Nothing in there directly says "this is a field element"; instead that's inferred from the first element. This duck typing pattern was picked up from Ansible, which uses YAML like this a lot. The second is a common pattern for eliding nested elems that would contain a single item. In place of: - at: cleric:narrow elems: - section: "Spells" elems: - template: spellbox style: prepared max: 10 you can instead write: - at: cleric:narrow section: "Spells" template: spellbox style: prepared max: 10 The leading element would normally contain a list of elements, but since it only has a single element it can drop that. This example shows the pattern twice, first with 'at', then with 'section'.