I have written before that I consider myself to not have a strong imagination. This is why I’ve spent so long on finding imagination helpers, and designing my own.
One of the reasons for this is that I think in abstract terms, and I gravitate to patterns. That is, I habitually see patterns and build around them. When it comes to developing imagination, this is something of a problem.
When it comes to designing frameworks and things that are supposed to do stuff consistently, it’s wonderful.
Comparing Headings
Years ago, I starting building my taxonomy around a simple realization. Game objects have pretty consistent content, and often about the same formatting rules. All I needed was a way to assign things things in a consistent manner.
I touched on this in a couple recent posts, but with different emphasis.
What I hadn’t done, though, is take the next step.
Game Entity Structure
Fully articulated, in my workflow today a game entity is formatted with these elements:
- Mandatory
- Name
- Content (text and other document elements describing the thing, sub elements); can be empty
- Optional
- ‘Brief’ (one-liner describing the entity, found in feats and spells mostly)
- Level marker
- Types marker
- Stat block (spells have these)
- Prerequisites (commonly rendered in stat block)
- Source name (often not published, but is in my working copy because I need to track them down when editing)
- TLDR block (summary of the effects of the entity, a value-add in the WIP and Full versions)
- Subelements (class features, domain powers, etc.)
Entity child elements can be rendered several ways. The spells granted by a domain are normally presented in a list, with their ‘briefs’… but I don’t have to do it that way.
Document Structure
In my workflow today, my document structure is at the same time simpler and more complex.
Simpler, in that each document section (nested/hierarchical) has these elements:
- Mandatory
- Name/Title
- Content (text and other document elements, game entities); can be empty
- Optional
- Metadata (author name, publication date, etc.)
- Source name (where this content originated, often not published but is in my working copy because I need to track them down when editing)
Abstraction
The game entity structure is almost a proper superset of the document structure. If I squint a little and ignore the names of the elements, I can treat them basically the same.
This suddenly opens up a huge taxonomy/workflow opportunity for me.
Structurally, from a coding perspective, a document entity like a chapter or section is just a really simple game entity.
- Document element has a name/title, can have a ‘stat block’ (metadata), can have a source, and has content.
- Game element has a name, can have a stat block, can have a source, and has content… and a bunch of other stuff.
What does this mean?
Application of Abstraction
When I started using my taxonomy, I made a distinction between game entities and document entities. This isn’t actually needed, I just realized.
I don’t need to have different rules for rendering the entities in different styles. Instead, I can define some relatively generic transformation rules that use mapped styles. That is, I can define several types of heading styles and shapes, then assign those to the entity types. When it comes time to transform, the engine doesn’t need to know about ‘feats’ or ‘classes’ or ‘chapters’, and how to decide how to render. Instead, it uses the mapping file to decide the rendering style
This makes it easy for me to have multiple mapping files, and decide at render time how to render. This solves a whole stack of problems for me.
Closing Comments
The last bit might not totally make sense to the reader. It’s late and I’m tired, and I’m not writing well. I’m not even typing well, my fingers are getting confused.
No matter! I’ll come back in my next post with an example, and hopefully it’ll all make more sense! To you, and to me!