Off the Path: Words of Power, Part 1

The first Off the Path series will take the Words of Power system from Pathfinder Roleplaying Game: Ultimate Magic and make it more to my taste. The general approach is good, and I see room to add a lot more to it.

Words of Power Overview

Runecaster by Gary Dupuis

Runecaster by Gary Dupuis

Words of Power in the Pathfinder Roleplaying Game are pretty straightforward. There are many ‘effect words’, and a smaller number of ‘target words’ and ‘meta words’. Effect words ‘do something’ (burn targets, heal subjects, teleport the caster), target words determine what is affected by the effect words, and meta words change what or how this happens.

A wordspell consists of one target word, one to three effect words, and any number of meta words, within the limits of the caster’s ability. A fireball analogue wordspell might be ‘burst fire blast distant’

  • burst: 10-foot radius within close range, or boosted to 20-foot radius within medium range (level 1, or 3 if boosted);
  • fire blast: 1d6 points of fire damage per caster level (level 3, max 10d6);
  • distant: range extended from medium to long (level 0).

This wordspell has a single effect word with a minimum level of 3, the burst target word has a minimum level of 1 (or 3 if boosted, and why not do that?), and the distant meta word does not modify the level. This is a third-level spell doing 1d6/level damage (max 10d6) in a 20-foot radius at long range.

There are more targets, more meta words, and many more effects described in Pathfinder Roleplaying Game: Ultimate Magic… and yet I see some things that could be added, and while it’s pretty close to what I want, I see a few things I’d like to do differently.

Changes Under Consideration

There are several things I’d like to try to incorporate.

Casting Cost Based on Caster Level

The psionics rules in D&D 3.x (and later in Dreamscarred Press’ Ultimate Psionics) base casting cost not on ‘spell level’, but on the ‘caster level’ of the effect. I find I very much like that, and want to incorporate it here. Higher-level abilities might be more efficient (more benefit for cost — cure light wounds doing 1d8+1/level, and cure serious wounds doing 3d8+1/level, both could be cast at a cost of 5 points, but one would do 1d8+5 points of healing and the other 3d8+5). I like the idea of unskilled but powerful casters throwing heaps of power at a spell in order to achieve what a more skilled caster could do more easily.

Reorganize Effects

There are many (137 effect words across 35 effect types, 10 meta words, and 6 target words)… but I they can be better organized and expanded. In fact…

Unified Power Framework

think I see the outline of a unified power framework that can be used to develop a variety of different power types. Spells, psionics, and martial disciplines (as from Dreamscarred Press’ Path of War) might all be possible here.

Closing Comments

This is a pretty ambitious change, to be sure… but it relates to several things I’ve considered over the years, and I think it can be done.

Off the Path: Exploring Different Ground

Blank Arrow Sign -- William McAusland

Blank Arrow Sign — William McAusland

I’m starting a new series, “Off the Path”.

Off the Path takes an idea currently implemented in the Pathfinder Roleplaying Game and changes it — much like the old ‘KJD-ALT‘ posts I used to make to

Much of my design is influenced by my work on Echelon. I mostly talk about Echelon at my other site, but since this series is actually about Pathfinder I’m keeping it here.

Echelon Influence

The mechanics of Echelon are in flux, I’ve identified several ways they can be implemented. The only important bits about Echelon to remember in this series are:

  • Many Games In One: D&D 3.x, and by extension the Pathfinder Roleplaying Game, has several modes of play hidden within it. At low levels it’s relatively gritty and realistic, in the middle levels the PCs are superhuman, and at the upper levels they are functionally superheroes and demigods (even if they don’t have divine traits — look at human mythology, and what the PCs can do).
  • Power Curve Is In Spells: The true power curve in D&D 3.x is not at all based on fighters and the like, but on dedicated spell casters. The most powerful classes are cleric, druid, and wizard. Tiers in Echelon are mapped to iconic spell levels (the iconic spells are usually at levels 1, 3, 5, 7, and 9, and are gained at caster level 1, 5, 9, 13, and 17 respectively). I’ll be remapping back to D&D-esque levels (i.e. PCs start at first level, not ninth), but I’ll still keep “levels 1-4, 5-8, 9-12, 13-16, 17-20” in mind.
  • Awesome Comes From Level, Not Class: Everybody should become increasingly more awesome as they reach higher levels. Spells are fantastic, but fantastic doesn’t need to mean spells. Even the non-casters should not be limited to strictly mundane, can-happen-in-reality options.

These will often have application in the Off the Path series.

I Blame GreyKnight

Today GreyKnight tagged me in a G+ post regarding some machine-assisted mapping software by Martin O’Leary (Uncharted Atlas on Twitter).

Well, I say ‘machine-assisted’, but it looks like the software does most of the work.

It’s also frighteningly close to some ideas I explored about fifteen years ago, but Martin made it work much better than I did… and this gives me ideas for how to improve what I’d done, and make it a little more interactive.

Fantasy Map Generator (Terrain 2.0)

Some notes off the top of my head, so I don’t forget.

Original Version

My original attempt was a command line program. Given an an arbitrary height map (TIFF file with elevation ranging from black to white — which mapped to values ranging from 0..1) it would apply many iterations of ‘precipitation’ to discover rivers (and thus watersheds) and lakes/oceans (depressions that filled with water). I was good at finding waterways, I never did find a satisfactory method of finding bodies of water.

There was also an erosion element, where moving water would reduce the elevation along its path. This included a ‘sediment’ component where the eroded material could be dropped if the speed of the water became too low. This would happen mostly when the slope became to shallow or when the ‘water unit’ hit standing water. It didn’t work as well as I’d hoped but I think this was mostly because of my problem finding bodies of water.

The program would periodically render the image in several modes, so I could see what was going on.

  • Bump mapped height map, just the terrain itself. Over time I could see the effects of erosion.
  • Bump mapped colored height map, the terrain with pseudocolored elevation so I could more readily make out the differences in elevation.
  • ‘Water map’ showing the aggregated water flows, optionally with the ‘ocean’ (everything with an elevation under a specified value) filled in blue. This gave me a very good idea of how the water flows were working out. It was very satisfying seeing how, over time, I could pick out where the mountains were by the water flowing away from them.
  • Combined, the colored height map with the waterflows and ocean shown. Because I like the pretty pictures.

New Version

First thoughts on what will be in the new version.

  • GUI (C#/WPF, because that’s what I work with in my day job) allowing adjustments as it goes.
  • Multiple phases in map development:
    • Initial height map. The first iteration will load a greyscale raster image (black = low, white = high) to use as its height map. I might later add a height map generation tool, but that’s lower priority for me.
    • Adjustment layer, so the user can adjust the heights of the original height map nondestructively. I will probably add this after height map generation, since loading the height map from a raster image means the height map can be modified outside this program if needed.
    • Set sea level (which might be below the lowest elevation, if the entire map is above sea level). This should be readily adjustable, but will affect later steps.
    • Find lakes (apply the Planchon-Darboux algorithm), so I know where all the standing water is.
    • Erosion, per my original algorithm. Drop units of water on the terrain, see where it goes. If it hits a lake, go to the exit point of the lake and carry on until it hits the ocean (or the edge of the map). This will find my rivers and watersheds, and will affect the final height map.
      • I might need to find lakes a few times, depending how much effect erosion has. The water leaving the lake should probably erode the terrain as well, and would thus reduce the maximum elevation of the surface of the water. Ultimately it might even wash the lake out!
      • I might go with with a more approximate, but much faster, erosion mechanism. I might even make it configurable which gets used… but I will still need to do the water flow analysis.

That gets me more or less as far as I’d gotten before. Get height map, pour water on it. Now for the next steps.

  • New phases in map development:
    • Settlement. User identifies how many cities (major settlements) and towns (minor settlements) to add. There might be the option of manual insertion (put them exactly where the user says), but for the first pass I’m going to apply them based on rules — mostly around where the water is. Each city or town added will grab the most attractive location available.
      • Initial version will follow Martin’s algorithm, taking into account how attractive the location is (how much water) and how unattractive (how close to another city or town).
      • Later versions might allow weighting these. Perhaps cities want to be far from each other, but towns like to be close to cities.
    • Nations. Assign control (or at least influence) over the territory based on proximity to settlements.
      • It appears Martin assigns control of the territories based on relative proximity to the cities, splitting things as evenly as possible between them. This seems to take the terrain into account, with mountains, and rivers and other waterways, penalizing distance.
      • Martin’s process appears to assign all territory on the map. I am greatly tempted to restrict the reach of each settlement.
      • I might instead give each settlement a certain amount of ‘regional reach’ (first pass, each city is worth this much, each town is worth less) that governs how far their influence can reach. (City, city) regions overlapping are probably either contended or split based on proximity (each point goes to the closer city), (city, town) regions overlapping probably see the town allying with the closest overlapping city, (town, town) probably either stand alone or ally. Allied town regions are counted as part of their ally’s region, extending the reach of a city (or set of towns).
    • National option: iterative assignment.
      • Rather than working on ‘distance to settlement’, each settlement might have a certain amount or number of points of influence. Assign each in turn (proportional to number available, I suspect — if a city has twice as much influence as a town, the city should assign/grab two units of territory for each the town grabs… of course, there are more towns than cities).
      • Each time a settlement grabs territory, it looks for the most attractive location to grab. This is probably a function of:
        • Distance from settlement;
        • Ease of travel (proximity to water is probably a good measure here, easier to follow a river up-valley or follow a shoreline than to cross the mountains);
        • Distance to or amount of neighboring territory of the same settlement (while it is easier to go up-river for a while, eventually the proximity to other controlled terrain makes it cheaper to climb the hill than to follow the river).

I don’t anticipate worrying about names.

Further Adjustments

I expected to have more places for the user to intervene in the map development. Adjusting the height map is the biggest one, but by dropping the need (and ability) to do that there isn’t much left to change. There are some controls involved (how much erosion, etc.) but most of the work after that is done by the computer.

… I started to list other things that could be added, but I think I’ve got enough to start. It would be very easy to get bogged down in additional detail, and I don’t want that to happen. At least, not until I’ve got this part working.

Taxonomy and the Echelon Reference Series

In the last couple of posts it’s pretty clear I was wearing my geek hat. Time to lower the flaps and tie the strings under my chin, because this is going to get busy.


Echelon Game Design Logo

Echelon Game Design Logo

Straight from

taxonomy [tak-sonuh-mee]

noun, plural taxonomies

  1. the science or technique of classification
  2. a classification into ordered categories:
    a proposed taxonomy of educational objectives
  3. Biology. the science dealing with the description, identification, naming, and classification of organisms.

Moving to a more abstract representation of the game data means I need some way of identifying what a particular object is. At one point this was done using styles, but now ‘object’ is the only style left related to game objects. I have others for document structure and for certain types of information belonging to objects (the ‘abstract’ styles described in my last post, ‘attribute’ style from the last post, a ‘brief’ style for things like one-line spell descriptions), but these are not game objects.

I have styles in place for type declaration (d20-1-Decl, d20-2-Decl, d20-3-Decl), but what do I put in them? Well, I’m working a hierarchical taxonomy.

Hierarchical Taxonomy

Almost all taxonomies are hierarchical. Biological taxonomy has seven levels (kingdom, phylum, class, order, family, genus, and species), with each becoming more specialized and specific. At any given level, a member of a group is a member of that group’s parent group. For instance, a dog is canis lupus (or canis lupus familiaris, for domesticated dogs)… which means that it is of the canidae family, carnivora order, mammalia class, chordata phylum, and animalia kingdom. It shares characteristics with all canidae, all carnivora, all mammalia, all chordata, and all animalia. These characteristics become a smaller and smaller set the higher you get the taxonomy, but ultimately there are identifiable characteristics shared between dogs and cats (same order, carnivora), and dogs and humans (same class, mammalia), and dogs and sea slugs (same kingdom, animalia).

Game object taxonomy can be similar. I don’t plan to be nearly so rigorous or have so many levels, but having a hierarchy makes many things easier for me down the road.

Hierarchical Parsing

I can take advantage of this when parsing content. Because an object has all types at its level and above in the hierarchy, I can resolve many references I can’t now. Consider the partial hierarchy below:

  • Ability Something a creature can do
    • Feat Learned ability gained using a feat slot
    • Class Feature Ability granted by a class or archetype
      • Class Subfeature An element of a class feature, often chooseable (rage powers) but sometimes not (bardic performance)
        • Class Subsubfeature An element of a class subfeature, sometimes choosable (revelation) but often not (bloodline power, granted power)
          • Bloodline Power Ability granted by a bloodline
          • Granted Power Ability granted by a domain
          • Revelation Ability granted by a mystery
        • Bardic Performance Ability granted by the bardic performance class feature, not choosable but determined by class or archetype
        • Domain Ability granted by the domains class feature (or domain class feature for classes and archetypes that just get one), usually choosable
        • Mystery Ability granted by the mystery class feature, choosable
        • Oracle’s Curse Ability granted by the curse class feature, choosable
        • Rage Power Ability granted by the rage powers class feature, choosable
        • Rogue Talent Ability granted by the rogue talents class feature, choosable
    • Sense Sensory ability; included here as a universal monster rule but I’m not sure that’s appropriate for the taxonomy.
    • Skill Learned ability with variable degrees of expertise (skill ranks)
    • Trait Ability inherent to a creature
      • Character Trait Trait of characters, choosable
        • Class Trait Trait available to characters of a specific class
        • Race Trait Trait available to characters of a specific race [note collision with ‘racial trait’, below; personal peeve]
        • Regional Trait Trait available to characters from a particular region
      • Racial Trait Trait inherent to a race, common to all members of that race
      • Monster Trait Trait inherent to a species of monster, common to all members of that species
  • Magic Non-abilities that do fantastic things
    • Spell Castable magic
    • Magic Item Magic in physical form
      • Magic Armor Physical protection, magically enhanced
      • Magic Quality Magic that can be added to an item
        • Armor Quality Magic that can be added to magic armor
        • Weapon Quality Magic that can be added to a magic weapon
      • Wondrous Item Miscellaneous magic item
  • Affliction Persistent (usually bad) thing that happens to a creature or object
    • Curse Supernatural stuff that happens to a creature or object
    • Disease Illness that happens to a creature or object [O.o for consitent definition… –kjd]
    • Poison Venom or toxin that happens to a creature or object [well, applied to an object, so it affects a creature –kjd]

“Darkvision” is both a racial trait (dwarves have it) and a monster trait (dragons have it). There is also a sense (universal rules) called ‘darkvision’.

In the second and third versions of the Echelon Reference Series, ‘darkvision trait’ could not be readily resolved. I could find ‘darkvision racial trait’ or ‘darkvision monster trait’, but ‘darkvision trait’ did not exist. I also couldn’t find ‘darkvision’ because there were multiple objects with that name.

Under this taxonomy, I am in a much better position.

  • I can now resolve ‘darkvision trait’ because racial traits and monster traits also are traits (specializations of ‘trait’). If I search for ‘darkvision trait’ I find an implied ‘darkvision trait’. That there are two variations (racial and monster) doesn’t matter to me because I specified the ‘trait’ level. If I wanted the racial trait specifically, I would have said.
  • Similarly, ‘darkvision ability’ will resolve at the ‘ability’ level: I just care that you have the darkvision ability, and not whether it is a sense or a trait.
  • ‘Darkvision’ alone won’t resolve. There are traits (abilities) and a darkvision spell (magic). Without something to further identify the target, I can’t tell which is the correct link. ‘Heal’ is another challenging one (skill and spell).
    • I do get some benefit out of implied rules. If I see heal (that is, ‘heal’ in italics), by convention that is the magic heal, the spell, rather than the skill.

This can still lead to ambiguity, and I need to decide what to do. The ghost touch quality resolves to two different concrete items (armor quality and weapon quality) with different characteristics, and I do care about the distinction. Similarly, bane (weapon quality and spell) and spell resistance (armor quality and spell) conflict. I suspect marking certain elements of the hierarchy ‘abstract’ or ‘not implied’ could handle it. That is, while both are under ‘Magic’ for classification reasons, spells and magic items are to be considered sufficiently separate from each other and cannot be equated. For ‘bane‘ to resolve, it must be specifically the spell or the weapon quality (or technically it could be the quality, or the magic item).

Obviously the exact hierarchy will be in flux for a while. I’m still not satisfied with the class feature/subfeature bit.

On further consideration, I think I like the “blocker” possibility. While in many ways the taxonomy holds for many purposes, for some there might be a restriction on climbing the hierarchy for reference purposes. That there is both a “bane spell” and a “bane weapon quality” doesn’t mean there is a meaningful “bane magic”… but they are both still magic for other purposes. Must consider further, this seems very strange in a hierarchy, like it can be a thing without being a thing.

Hierarchical Rendering Rules

The Echelon Reference Series is quite consistent in how it renders game objects. Most often, each game object has a heading (rounded rectangle containing the name) that may have additional elements.

  • A stat block (spells, feats with prerequisites, archetype class features that replace or alter features of the associated class);
    • Because the stat blocks are so long, monsters and characters have a ‘relaxed stat block’: the stat lines are still grouped together, but are not contained inside the heading because it looks really, really bad when it doesn’t fit in the column. Though I think I haven’t had any single stat block fail to fit on a page; I could go full page width and two column within that. Hmm…)
  • a level marker (feats and other character options that have a minimum level derived from level, skill rank, or base attack bonus prerequisites);
  • a type marker (abilities can be (Ex), (Sp), or (Su); abilities might have other types such as (Combat) or (Item Creation) feats; some abilities have special rules, such as rogue talents that modify the sneak attack ability and only one can be applied at once).

Often the only visible difference between objects is color (class features are dark brown, class subfeatures are a medium brown, feats are pale brown). The rendering in documents is otherwise identical. When rendering an object I can take the type and work up the taxonomy hierarchy until I find rules for how to render the object: ‘rogue talent’ and ‘rage power’ are both ‘class subfeatures’ and have no special formatting, so I can fall back on the inherited rendering rules for ‘class subfeature’ when I want to render one of these objects. I might want to render bloodlines differently, so I override the rendering rules for bloodlines and they will look different… and when I add ‘draconic bloodline’ to the taxonomy, it gets rendered the same was as normal bloodlines.

The head of this taxonomy, ‘ability’ (which is ‘something a creature can inherently do’ — includes skills and feats, does not include spells) would thus provide a default rendering mechanism that will let me see the content. It might be very generic, it might be very ugly (I like to make undefined things red so they jump out when I’m reviewing documents — which is why some ‘links’ are red in my PDFs, it means I had identified some text as a link but no target was found, while green means a target was found but is not in this document), but it is presented in the document.

Closing Comments

Building a hierarchy gives me a lot of functionality by letting me ‘inherit’ parsing and rendering behavior, without really adding or changing code. For instance, I can add ‘draconic bloodline’ (child of ‘bloodline’ class subfeature, in the taxonomy) and objects marked as draconic bloodlines will be correctly identified as this kind of bloodline, but still parse and render as normal bloodlines.

I can also use the more more specific taxonomy to change behavior correctly. When I added ‘bloodline’ to the taxonomy it was rendered the same as any other class subfeature, and while that works, I’d like to do something a bit different. I can add code to change how bloodlines are rendered, without affecting other types… except draconic bloodlines, because they inherit this code.

Between the increased abstraction and the use of hierarchical taxonomy, I can get rid of a great deal of complex and redundant code, while making the processing more powerful and specific.

Next Generation of the Echelon Reference Series

Echelon Game Design Logo

Echelon Game Design Logo

In my previous post I wrote about the evolution of the Echelon Reference Series. So far there have been four stages:

  1. Raw copy and paste aggregation. Ultimately not useful to me because it threw away so much information without gaining me much.
  2. Aggregating by source document, marking up in Word using styles specific to the problem domain. Ultimately too specific, not abstract enough, and my workflow was prone to error… as illustrated very clearly when a moment’s inattention blew away almost everything. Oops… but it cleared the deck for the next version.
  3. As second iteration, but slightly more abstract, making it easier to handle in code. More importantly, started using source control (as I should have been from the start). Also started to parse and gain information from the text itself, allowing automating linking and cross-referencing of content. Ultimately insufficient because it lacked fine control over layout, and the automated data extraction similarly lacked fine control. Released: ERS: Barbarians, ERS: Clerics, and ERS: Sorcerers.
  4. Revised document construction mechanisms. Made workflow more efficient by building a common index file, then linking and cross-referencing information as new content was added. While it is getting closer, I realized there is opportunity for another level of abstraction in content (which I’ll talk about below) and combining the document files (as opposed to data files) so I need only maintain one set for all six versions (see below) of each. Released: ERS: Rogues, ERS: Fighters, ERS: Monks, and ERS: Rangers in RAF (except Monks, which is WIP — Work In Progress, the next stage), and will release the other ERS class books and the ERS spell books (sample ERS: Elemental Wizard Spells, PWYW).

Now to describe the next generation of the Echelon Reference Series.

Next Generation Data Geekery

Grab your pocket protectors, this is going to be a ride.

The biggest limitation I’ve had with the Echelon Reference Series lately is around data selection, and redundancy in document scaffolding. What does that mean? Well…

  • Almost every title of the Echelon Reference Series has two main flavors: PRD-Only, and 3pp+PRD. The first has material only from the PRD (well, mostly… I don’t count my augmentations), the second includes select third-party material.
  • Each book in the Echelon Reference Series has three versions, at different stages of development. I started releasing the early-stage versions (at a discount, see below) so they at least exist, and I can then improve on them.
    • The RAF (‘Rough And Fast’, politely) version has the basic text content, but not much more. No diagrams, no additional useful redundancy (such as applying the archetypes to the associated class to build a ‘new class’ and see what it looks like when the archetype is used. While I do look for places where items are referenced (such as feats and skills) I might not have yet done it exhaustively. This version of the product sells at 50% off (75% off in bundles) because they’re not complete, and buyers will also get the WIP and Final versions at no extra charge when they come available.
    • The WIP (‘Work in Progress’) is more developed. The text has been gone over more thoroughly, and I’ve added many diagrams (but possibly not all). I probably don’t have the archetype classes in place, but I might have started organizing things better. This version of the product sells at 25% off (50% in bundles) because while they’re getting closer, they’re not actually done yet. Again, buyers will also get the Final versions at no extra charge when they are available.
    • The Final version has the diagrams and the archetype classes, and so on. I’m done with this, until I add more content. This version no longer has a discount on its own, but does have a 25% discount in bundles.

The releases that don’t have both PRD-Only and 3pp+PRD versions, and don’t have RAF/WIP/Final versions, are typically sample documents (such as ERS: Elemental Wizard Spells and ERS: Teamwork Feats).

I have found while working on them, though, that even though the earlier versions aren’t as complete as I’m aiming for, they’re still pretty good. The RAF version is, after I finish cleaning the text up, a pretty close copy of the source material, but organized and consistently formatted. I can see many people preferring this version, in fact. Similarly, the WIP has that and the diagrams, without some of the redundant text that provides context: I can see people preferring this version because it doesn’t have excess material, but presents the rest of the content in a more approachable manner.

As a result I’ve pretty much decided to release each document with RAF, WIP, and Final included, when and as available, with discounts for ‘buying early’ (before Final version). This means I’ll be maintaining six versions of each title, and the current framework… does not do that well. What was more or less manageable with two versions (PRD-Only and 3pp+PRD) becomes difficult with six versions of each document.

Document Workflow

A couple years ago I described workflows for extracting data from Word files, so I won’t describe it here again… except as ‘painfully complicated and prone to error’. I’ve largely worked around the problems, but even now I run into problems when a line ends (or starts? I forget) on an HTML element, in which case the space that should follow it gets removed. This leads to cases where I get text like

Bloodline Spells magic missile(3rd)

If you look closely, there is no space character between ‘magic missile‘ and ‘(3rd)’. I have not found an acceptable workaround for this that is easy and consistently effective.

Moving ahead, I will instead convert the Word files to ‘WordprocessingML’, an XML representation of the Word internal structure of the file. This starts in a useful character encoding (UTF-8) rather than the less than useful windows-1232, and more importantly does not need HTML Tidy (which appears to have a lot of influence on the problem). This means that once the content leaves Word it will be in happy XML, where it is easy for me to get at.

Document Creation, Single Sourcing

I realized that with some changes to how I capture the information I can probably get each title down to a single source document (plus my data store, of course). Major sections simply copy content from my data store into the output document. For instance, a chapter containing all the rogue talents contains the chapter title and introductory text, then a long list of object IDs of content to copy from source into this document. Right now the PRD-Only and 3pp+PRD rogue talent chapters are different files, but I realized that if the IDs are properly unique I can get away with a single list and plug into different data stores depending on version. If I plug into the 3pp+PRD data file all the identified objects will be copied, if I plug into the PRD-Only data file then many of the identified objects (the 3pp ones) won’t be copied. I achieve my PRD-Only/3pp+PRD split with no further effort… at least as far as data objects are concerned.

Text selection and formatting is a little more effort:

  • All PRD content ends up in the 3pp+PRD version, but there are sometimes entire chapters that exist only for the 3pp+PRD version (exalted domains are in ERS: Clerics (3pp+PRD), but not in ERS: Clerics (PRD-Only), so an ‘Exalted Domains’ chapter in the PRD-Only version would be empty and out of place). There needs to be a way to turn off certain content based on PRD-Only/3pp+PRD distinctions.
  • Final includes content not present in WIP and RAF (archetype classes, for example) and WIP includes content not present in RAF (diagrams, some expanded text). It’s easy to exclude the diagrams in the RAF version by simply ignoring the diagram instructions, but there needs to be a way to exclude text.
  • Because the content differs from version to version (that is, I might need six different sets of tweaks), there needs to be a way to include or exclude tweaks based on (PRD-Only, 3pp+PRD) and (RAF, WIP, Final) distinctions.

This actually should be easier than it sounds.

Word is very flat (except for tables): a chapter heading, a section heading, and a list nested within two other lists are all at the same level according to Word. The first two steps when processing the XML files created from these Word files are:

  1. Remove stuff I don’t care about. Word has a lot of overhead in the file, defining styles and whatnot. I don’t care about it, I get rid of it. This step includes mapping the content elements to other elements with attributes to be used later. For instance, a paragraph with ‘doc 4 Chapter’ (document level 4, chapter — ‘doc 4 indicating depth and so they’re ordered properly in the style manager, ‘chapter’ to remind me of the semantic intent) gets turned into <section outline-level=”4″ />. This happens with many elements.
  2. Build the document hierarchy, so each outline-level=’1′ element contains all following objects of lower (or with no) outline level, repeating until there are no more outline-levels… then do the same for list-level. (Incidentally the game objects live somewhere around outline-level=10… and For Reasons, stat blocks are considered lists)
    • Instructions to import files or copy game objects are also given outline-levels, which 1. keeps them from being nested incorrectly in other content, and 2. allows me to append content to them after importing.

This gives me a very easy way to solve my problem. I can assign attributes (exact mechanism not yet determined, I have many options) to the various objects so they are relevant only for certain builds.

  • prd means ‘include only in a PRD-Only build’.
  • 3pp means ‘include only in a 3pp+PRD build’.
  • raf means ‘include only in an RAF build’
  • wip means ‘include only in a WIP build’
  • fin means ‘include only in a final build’
  • !prd means ‘do not include in a PRD-Only build’
  • !3pp means ‘do not include in a 3pp+PRD build’
  • !raf means ‘do not include in an RAF build’
  • !wip means ‘do not include in a WIP build’
  • !fin means ‘do not include in a final build’

When processing, it is very easy for me to know which version I’m working on. The “Exalted Domains” chapter I mentioned earlier would be marked (either on the chapter itself or in the include instruction) as “3pp”, meaning it is only to be included in the 3pp+PRD version, while the “Cleric Archetype Classes” would be marked “fin”. The layout tweaks can also be marked with these values, so “3pp wip” means “do this tweak only if it’s the 3pp+PRD WIP version” (because all the PRD-Only and the RAF and FIN versions don’t need this tweak).

This largely solves my ‘scaffolding’ problem. A single set of input documents should now be transformable into six output documents, depending on flags set. I’ll need to make some changes in the make-the-final-document scripts, but by and large this should greatly reduce the file handling I need to do.

Data Hierarchy

The earliest versions of the Echelon Reference Series data store, at least after I started parsing the data, had very specific styles, from ‘class’ down to individual class subfeature types such as rage powers and bardic performances. The middling versions used some better abstractions and let me get away from being quite so specific, but when rendering the documents I had to examine the context of the object to see what it was. For instance, I would deduce that a particular class-subfeature is a rage power because it’s parent was a class-feature called ‘rage power’. This worked, as far as it went, but led to my ‘inserting’ parent data objects so the abstractions would work.

This had two unfortunate side effects, one minor and one more significant. The minor was that if I were to render the source document in PDF (as I often do as a data check, to verify the structure is correct) I would have extraneous objects in the document. This is ultimately not a big deal, but I found it jarring. The more significant effect was that it caused me to have many objects in the system with exactly the same ID. This was more troublesome.

It looks like the easiest solution consists of embracing abstraction. Much of the time I need only know that I have an object and what type it is (i.e. a label). It is still necessary to be able to nest the items, but the following seems to work well:

  • Replace all data-specific stat-block styles (spells and monsters are the most-used, but there are others) with ‘d20 Abstract’, ‘d20 Abstract Group’, and ‘d20 Abstract Sub’. These can be applied to all object types. ‘d20 Abstract’ is the most commonly used, ‘d20 Abstract Group’ provides a heading in the stat block (often seen in monster stat blocks), and ‘d20 Abstract Sub’ is a child object of a ‘d20 Abstract’, most commonly used so there can be more than one paragraph in a stat block field (such as a monster special ability that needs more than one paragraph to describe). These are actually identified internally as list items so they can interact and include lists.
  • Replace all game object styles with a combination of nine styles (three sets of three):
    • d20-1-Decl, d20-1-Object, d20-1-Section (Heading levels 1-3)
    • d20-2-Decl, d20-2-Object, d20-2-Section (Heading levels 4-6)
    • d20-3-Decl, d20-3-Object, d20-3-Section (Heading levels 7-9)
  • Add ‘d20 Attribute’, which adds or overrides meta information about the object, that isn’t game information. This is used mostly to provide processing hints, and doesn’t get used much.

The naming scheme seems odd, but is set up that way so they appear in my style manager in a useful order.

Functionally there is no difference between a d20-2-Object and a d20-1-Object, except that the d20-2-Object can be nested within a d20-1-Object… and because I declare the types explicitly now, this mostly does not come up often.

When I encode a character class, I can do something like

[d20-1-Decl] Class

[d20-1-Object] Rogue

(description goes here)

[d20-1-Section] Class Features

Rogues have the following class features

[d20-2-Decl] Class Feature

[d20-2-Object] Weapon and Armor Proficiency


[d20-2-Object] Sneak Attack


[d20-2-Object] Trapfinding


[d20-2-Object] Evasion


[d20-2-Object] Rogue Talents

(description… not including actual rogue talents)

The headings — all the styled paragraphs in the block quote above — are actually increasingly indented in Word, to make the hierarchy easier to see. They also show up in the navigation pane in tree format, making it easy to navigate.

While processing, I end up with an object (of type ‘class’) called ‘rogue’, with the ID ‘class.rogue’. This has descriptive text and a section containing five objects (second-tier, but still ‘objects’) of type ‘class feature’. These objects each have a description and are called respectively ‘Weapon and Armor Proficiency’, ‘Sneak Attack’, ‘Trapfinding’, ‘Evasion’, and ‘Rogue Talents’. Because they are inside another object, though, their IDs are slightly different: class-feature.weapon-and-armor-proficiency.rogue, class-feature.sneak-attack.rogue, class-feature.trapfinding.rogue, class-feature.evasion.rogue, and class-feature.rogue-talents.rogue. Each also has a ‘group ID’ (gid) that has the ‘.rogue’ suffix removed.

That each instance of the object now has a unique ID is incredibly valuable. It lets me to identify and refer to (or copy) a specific data object. In many ways they are equivalent (they do the same thing, and satisfy the same prerequisites… usually), but in some ways they are different (class-feature.evasion.rogue is gained at rogue second level, but class-feature.evasion.ranger is gained at ninth level).

This also makes it feasible for me to define ‘universal class features’ (provide a single standard definition for a class feature such as evasion). I can then change the class-specific definitions to the class-specific application (‘Rogues gain evasion at 2nd level’, ‘Monks gain evasion at 2nd level’, ‘Rangers gain evasion at 9th level’). It will no longer be necessary to define the class feature each time a class gains it, and more importantly it becomes reasonable to get rid of ‘gains evasion, as a 2nd-level rogue’.

Regarding the rogue talents above, the class feature describes the rules for rogues taking rogue talents (gained at 2nd level and every even level after that). The actual rogue talent definitions happen outside the class, mostly because most rogue talents are not defined in the class (in other supplements). Also, rogues aren’t the only class to gain rogue talents, so defining them outside the class makes it easier to ‘share’ them. I might put the following in another chapter (using d20-2-Decl

[d20-2-Decl] Rogue Talent

[d20-2-Object] Bleeding Attack (Ex, Sneak Attack Exclusive)

(description goes here)

[d20-2-Object] Combat Trick

(description goes here)

[d20-2-Object] Fast Stealth (Ex)

(description goes here)

[d20-2-Object] Finess Rogue

(description goes here)

This gives me four new objects, named ‘Bleeding Attack’, ‘Combat Trick’, ‘Fast Stealth’, and ‘Finesse Rogue’ (with IDs rogue-talent.bleeding-attack, rogue-talent.combat-trick,, rogue-talent.finesse-rogue). I used d20-2 styles to show that it isn’t necessary to start at d20-1.

In case you’re curious, Bleeding Attack is given the ‘sneak attack exclusive’ type for clarity. “Talents marked with an asterisk add effects to a rogue’s sneak attack. Only one of these talents can be applied to an individual attack and the decision must be made before the attack roll is made.” is not terribly useful when asterisks are used in many places for different things, I prefer to be explicit.

And with a little bit of forethought, I can even prepare for the type tags to be objects themselves, so if I want I can define them in data and provide textual descriptions for them that I can present when needed.


I had originally planned to write about object type taxonomy, but this article is already almost 2,900 words long! Next post!

Evolution of the Echelon Reference Series

After I finish releasing the RAF versions of the Echelon Reference Series, I’ll be rebuilding my workflow for data capture. It will be simpler and more abstract, and more powerful. I thought it might be interesting to show how this has evolved.

Origin of the ERS

Echelon Game Design Logo

Echelon Game Design Logo

The ERS started as a set of research documents for Echelon. There have been several iterations.

First Cut

Originally I just created a file for each topic — feats, spells, rage powers, etc. — and dumped all the relevant bits into the file. This worked for a while, but I started running into places I wanted to split the data up or organize it in different ways. The feat document could be split into item creation feats, metamagic feats, combat feats, style feats, and… the last two could be applied to the same feat.

And the prerequisites. The complexity of the prerequisites started to overwhelm me, and there wasn’t a lot I could do about it. First design scrapped, thankfully before I invested too much in it.

Second Cut

I started to use styles to mark data types, with a style for each data type of interest. I didn’t limit it to ‘feats’ and ‘spells’, either: rogue talents, advanced rogue talents, domains, all had their own styles (that mostly looked like Heading 3… I didn’t start changing the style presentation until later). Using heading styles for game elements made it easy to navigate my Word file because they’d show up in the navigation pane, but making them look the same meant it was easy to assign the wrong one.

I was manually saving the files as Word and ‘filtered HTML’ formats so I could do a series of transformations to parse and extract information. Everything was done in a single directory… don’t do that. Hundreds of source files, each combined with about eight intermediate files before hitting the final form made for a huge directory full of stuff I don’t care about, with important stuff inside it.

More intermediate files than that, even. After parsing the information I would spray out the individual items into their own files — each feat, each spell, each rage power, etc. — that would be picked up by a script for inclusion in output. I started building PDFs via LaTeX, but it wasn’t very manageable. It was also very easy to accidentally delete something.

… as I actually did. Got a new computer, was working on it and decided to blow away the ‘copy I’d made’, forgetting I hadn’t actually copied the files but created a shortcut to the folder to ensure I kept both versions in step.

Much to my surprise, after a moment of shock I wasn’t even particularly upset. No swearing or tears involved, even, just a deep breath. I was running into severe limitations and was ready to move on already.

Third Cut

This version saw the release of ERS: Barbarians, ERS: Clerics, and ERS: Sorcerers. This is where I started to abstract the data types. ‘Class feature’ had been around for a while, but I replaced all the individual feature types (rogue talent, etc.) with a more abstract ‘class subfeature’ type. This reduced the mental space needed to keep track of things, and simplified parsing later quite a bit.

Rogue talents and rage powers really parse about the same way, so why differentiate in code? I know from the parent class-feature what this is (class-subfeature with class-feature of ‘Rage Power’ means I’m looking at a rage power, right?) so I could mark it and move on. Lots of heavy encoding in the object markers, mostly for automation reasons.

Runeforger (Su) [1 Forgemaster’s Blessing; 2; 4; 6; 8; 10; 12; 14; 16; 18; 20] <channel energy>

A forgemaster may inscribe mystical runes upon a suit of armor, shield, or weapon as full-round action, using this ability a number of times per day equal to 3 + her Intelligence modifier. These runes last 1 round per cleric level, but inscribing the same rune twice on an item increases this duration to 1 minute per level, three times to 10 minutes per level, and four times to 1 hour per level. Erase affects runes as magical writing. A forgemaster learns forgemaster’s blessing at 1st level and may learn one additional rune at 2nd level and every 2 levels thereafter. Only one type of rune marked with an asterisk (*) may be placed on an item at any given time.

Using the runeforger class feature of the forgemaster cleric archetype as an example, The heading line has:

  • class feature name,
  • class feature type (Su, supernatural ability),
  • [1…20] showing the levels it is applied (first level gives ‘Runeforger (Forgemaster’s Blessing)’, then every even level up to 20th you get another runeforger choice), included mostly so I could automatically create the level table correctly (or at least automatically),
  • <replaces class feature> indicating that runeforger gets this instead of the ability to channel energy. <<double angle brackets>> indicates that this new feature only modifies an existing feature.

This actually worked, more or less. I could parse and render the items, and even eventually combine them (applying archetype to base class) to get the archetype class, complete with level table. I had almost no control over it, though.

Parsing, Prerequisites, and Pictures

Animal Companion Diagram

Animal Companion Diagram

This was also the version where I finally had the ability to extract and automate prerequisite links. This gave me the ability to draw pictures showing me the prerequisite relationships between game elements. The first pass would be machine drawn using GraphViz (software that takes a list of nodes and edges and draws the diagram — linked page includes sample diagram for the Improved Sunder feat), which was helpful for understanding but not very pretty when I tried to include them in the PDF.

I would then redraw the diagrams using PGF/TikZ, a LaTeX package that, well, draws diagrams. I’d write down where to put each node and how to draw the edges, then the image would be rendered and added to the output PDF. This let me put diagrams with hyperlinks in the documents.

For example, the diagram to the right shows the relationship between Animal Companion (top, second column over) and a bunch of feats (pale brown). In many cases Animal Companion is not sufficient, and the feat has other prerequisites (class features or subfeatures, mostly), and in others Animal Companion is one of several options to meet a prerequisite (one of animal companion or familiar or mount or divine bond… or some subset of these).

The other thing the prerequisite parsing and linking allowed was the automated discovery of ‘class-relevant’ feats. I could take the list of class features for the base class and archetypes, and look for feats that had those class features (or subfeatures) as prerequisites. I could then pull a copy of those feats into the PDF. Some of the choices ended up looking nonsensical because they required features from other classes as well, but since the barbarian’s uncanny dodge did meet the prerequisite I kept it.

Subversion Repository

This also is where I started working with an offsite Subversion repository. I had my formatting software on a server offsite and SVN allowed me to send minimal file changes from my workstation to the server, while making it almost impossible for me to accidentally blow the whole thing away again. I’m now creeping up on revision 2000.

Automated Conversion

In Second Cut I was manually saving the files as DOCX and Filtered HTML as I went. This was troublesome and annoying, and made it frightfully easy to get out of step — a couple times I ended up making the same change more than once because I’d saved as Filtered HTML and forgot to save it again as DOCX.

I wrote a program that would go through the ‘docx directory’ and convert all the files to Filtered HTML. Every time it was run. Very time-consuming and wasteful, but after learning of the ‘%’ file designator I switched to making the program a filter (single-input, single-output) and adding a make rule so only the files that were out of date needed to be replaced.


The third cut did a lot, but it didn’t give very good control over the output. There was no facility for being selective: the druid got access to some cleric domains, so if I included domains in the druid book I had to include all the domains. I could add a note to the front of the chapter that said “druids get only these ones, ignore the rest”, but after including subdomains that amounted to about a hundred pages when I needed only a couple dozen (which is why I didn’t release the druids book under the ‘third cut’). It also gave very little control over spacing the like, the small tweaks that let me fix unfortunate object placement. That’s why this version sees some places where a feat name appears at the bottom of a page and the description on the next.

Fourth Cut

The lack of control over layout was getting to me, so I took steps to clean the data up some more and regain more control over the layout. This led to the release of the ‘RAF’ (‘Rough And Fast’) releases that grabbed all the information, but didn’t add the diagrams or useful redundancy (and have a ticket price of 50% less than the final version will). I no longer capture certain information (such as the detailed level progression of the class feature within the class) and reworked the entire linking process so it could work on individual files as it parsed them, and was more accurate.

This cost me some of my automated data discovery, though. I no longer have the tools in place (with the current data set) to generate the initial version of each of the books. It also does not handle duplicate items well, something that really showed up (to me) with Draconic Bloodlines, when it could not differentiate between the ‘Claws’ bloodline powers. It seems a minor thing, but it bothered me.

So, while I did release ERS: Rogues, ERS: Fighters, ERS: Monks, and ERS: Rangers in RAF (except Monks, which is WIP — Work In Progress, the next stage), and will release the other ERS class books and the ERS spell books (sample ERS: Elemental Wizard Spells, PWYW), I will be revising the entire workflow and data capture process to make it easier to move to the next step.

And I’ll describe that in my next post.

Ornamentation: Polishing Gems… and Cutting Them

Hope Diamond, By David Bjorgen

Hope Diamond, By David Bjorgen (Own work) [GFDL, CC-BY-SA-3.0 or CC BY-SA 2.5-2.0-1.0], via Wikimedia Commons

My last post refined the generation of random gems, introducing variance to the size and quality of the stones. One of the first comments I got regarding the post suggested ‘uncut’ as one of the low-quality entries. I hadn’t previously considered gem cutting because I was focusing on the end result, but I do have some ideas on it.

In the Pathfinder Roleplaying Game, when randomly generating gems they suggest having odd-numbered rolls indicate a raw or uncut stone that is half the value of the final cut version. With a successful Craft check, DC increasing with base stone value from 10 to 25, the stone takes on its full finished value. As shown in yesterday’s post, a -5 quality modifier to the base value halves the value of the stone (ignoring size considerations).

Here are some things I want to consider:

  • A rough, uncut stone has a quality modifier of -5. This halves the value of a medium stone.
  • Cutting something makes it smaller (or rather makes more pieces of it; I’m going to say the other bits are valueless for my purpose). Cutting a stone can make it smaller, but this makes it easier to improve the quality of what remains.
  • A rough stone will be easier to improve than a well-cut stone.

As a first pass, perhaps something like the following:

  • Craft DC to improve a stone is 10 + 2 per target grade up to average, +4 per grade above average. This means taking a normal uncut stone to average quality is a DC 20 check, but taking it to flawless (quality +4) is DC 36.
  • When cutting the stone, each step you reduce the size gives a +2 bonus to the check. Given the abstract nature of the system, I’m willing to say you don’t have to reduce the size.
  • Failure by 5 or more damages the stone, reducing its quality by 1d4. However, you normally can Take 10.
  • Probably needs to be done trained.

Taking a normal uncut medium opal (100 base value, -5 quality modifier = 50 gp current value) and cutting it (they’re usually polished, actually, but faceted opals do exist… don’t look as nice, IMO) to bring it to average quality has a DC of 20 (10 + 5 steps improvement). DC 20 checks can be made by first-level characters Taking 10 if they are focused on it (good ability score, Skill Focus, and masterwork tools — and a gemcutter should be able to afford masterwork tools). Someone a little bit better (+12 total modifier) and willing to reduce the stone’s size a bit (one step) could reliably take it to good (+1) quality but a small size (-1) — same net value, but a nicer gem. This person could try to do the same without reducing the size but would need to make a check (+12 modifier but DC 24; must roll in order to succeed) and can increase the value of the gem… but runs a chance of damaging it.

If the stone starts at average quality and the gemcutter aims to improve it, the DC… is the same, actually. A more skilled crafter might take a gem that has already been cut and improve it, but under normal circumstances a single gemcutter probably wants to take only a single run at it. I’m okay with that.

Improving a Gem

A trained gemcutter can improve a gem’s quality by making a success Craft check (DC = 10 + 2 per target grade up to average, +4 per grade above average). The gemcutter gets a +2 bonus to this roll for each step the gem’s size is reduced. A failure by 5 or more reduces the gem’s quality by 1d4 grades. The gemcutter can Take 10, but cannot Take 20 (unless there are many gems available to work with and the goal is to get one of the target quality).

Ornamentation: Polishing Gems

Hope Diamond, By David Bjorgen

Hope Diamond, By David Bjorgen (Own work) [GFDL, CC-BY-SA-3.0 or CC BY-SA 2.5-2.0-1.0], via Wikimedia Commons

Creighton Broadhurst of Raging Swan Press (I like Raging Swan products) wrote a post last week about Gygax On… Treasure, speaking mostly of how most treasures are likely to consist of a collection of varied but valuable items, rather than a simple chest full of coin or pouch of gems. Coins and gems will probably be involved, as might jewelry and objets d’art, but there might be trade goods (barrels of wine, furs) or luxury items (such as spices).

One of the items listed was “a two-handed sword (with silver wire wrapped about its hilt and lapis lazuli pommel to make it worth three times its normal value)“, and it occurred to me that I haven’t seen guidelines to help make items like this. I’ve seen guidelines for randomly generating weapons (possibly masterwork), and for jewelry (though often that just identifies the gold piece value range and suggests items that might be worth that value), but never really any tables for generating ‘decorated items’.

I started to write a post about this, then realized it’s likely to run pretty long. Thankfully the topic almost naturally splits itself up, at each stage I can add another piece. In good programmer fashion, I’ve got the high-level design done, but will implement from the bottom, most-detailed part up.


Gems are divided into two general classes, semi-precious stones and precious stones. Precious stones are ideally clear, even-colored (with some exceptions; some particular irregularities are very appealing), and often cut so they are faceted. Semi-precious stones are more common and are often opaque and/or have patterns or irregularities in their coloration that give them their appeal.

Some earlier editions of D&D had fairly complex rules for determining gem value, but this article is based more closely on the Pathfinder Roleplaying Game. This model identifies six grades of gems. Each grade has a different standard value, and it can be easiest to simply use the base values. There can also be some variation in the values, but not nearly as much as the earlier editions.

Grade Name Standard Value Random Value Random Range
1 Least Semi-Precious 10 gp 5 gp + 2d4 gp 7-13 gp
2 Lesser Semi-Precious 50 gp 25 gp + 2d4 × 5 gp 35-65 gp
3 Semi-Precious 100 gp 50 gp + 2d4 × 10 gp 70-130 gp
4 Greater Semi-Precious 500 gp 250 gp + 2d4 × 50 gp 350-650 gp
5 Lesser Precious 1,000 gp 500 gp + 2d4 × 100 gp 700-1,300 gp
6 Greater Precious 5,000 gp 2,500 gp + 2d4 × 500 gp 3,500-6,500 gp

Both the standard value and the random value are workable. The standard value feels a little like funny-shaped coins (especially considering the recommendation to assume 50 gems weighs a pound) but it really is straightforward and easy to apply. The random value amounts to the same thing in the long run but has a little more texture, at the expense of a bit more work.

I’m going to take it a step further. Older editions actually described why the gem was worth more or less. I’d like to retain that.

A simple way is to use the dice of the random range to assign size and quality. This almost works, but I don’t see in the table how to have an “average medium-sized” gem. With four values per die you don’t have ‘average’ values on the individual dice, even though the two dice together have an integral average (mean) value.

However, it is easy to fake it using a pair of d10s. I initially considered applying these as “d5s” but ended up weighting the ranges differently. They still get added together to get the modifying value.

d10 Value Size Quality Alternate Value
<1 -3 Diminutive ? not yet named -3 + roll
1 -2 Tiny Flawed -2
2-3 -1 Small Poor -1
4-7 +0 Medium Average +0
8-9 +1 Large Good +1
10 +2 Huge Excellent +2
>10 +3 Gargantuan Flawless +2 + roll – 10

2016-10-26 I realized there’s really no reason these have to be capped at -3..+3 when the size or quality roll would be very far out of bounds. The difference in value is 10% per point (see below), so if you manage to get a size 10 quality 10 stone it’s still only worth three times normal. I provide an alternate value for those cases that gives an addition +-1 for each point the roll is outside the normal 1..10 range.

This gives a slightly wider range (from -2 to +2 on each die, assuming no modifiers, giving -4 to +4 in the final result instead of -3 to +3) but keeps pretty close to the same percentages for the same values. I show values outside the normal d10 die range because later articles will include modifiers to the rolls.

Value 2d4 Indexed 2d10
-4 1
-3 6.25 4
-2 12.50 12
-1 18.75 20
0 25.00 26
+1 18.75 20
+2 12.50 12
+3 6.25 4
+4 1

The values shown above adjust the market price of the gem by 10%. That is, a large (+1) excellent (+2) opal (greater semi-precious gem, base value 500 gp) would have a market price of 650 gp, while a small (-1) excellent (+2) opal would have a market price of 550 gp, and a tiny (-2) flawed (-2) opal would have a market price of 300 gp.

Despite using the normal size descriptors, I’m going to consider gems to be 100 per pound. I had originally thought to use 50 per pound, then I read that the Hope Diamond — which would likely count as a ‘huge gem’ under this scheme — is a touch over 9 grams in mass: 1/50 of a pound. As almost all gems are probably less than half this, I figured 1/100 pound each should be fine. (And if this causes problems with the encumbrance rules, the encumbrance rules aren’t where the problem is…)

I considered varying by size descriptor, but decided that if we don’t bother doing that for coins I’m certainly not going to bother for gems.

Now, just to see what it looks like in practice…

  • a medium [0] average [0] jade [100]: [100 gp]
  • a medium [0] good [+1] turquoise [10]: [11 gp]
  • a tiny [-2] poor [-1] moonstone [50]: [35 gp]
  • a large [+1] poor [-1] obsidian [10]: [10 gp]
  • a large [+1] average [0] aquamarine [500]: [550 gp]
  • a large [+1] poor [-1] topaz [500]: [500 gp]
  • a large [+1] average [0] carnelian [50]: [55 gp]
  • a medium [0] good [+1] jasper [50]: [55 gp]
  • a large [+1] average [0] ruby (blood red) [5000]: [5500 gp]
  • a tiny [-2] average [0] citrine [50]: [40 gp]
  • a huge [+2] average [0] aquamarine [500]: [600 gp]
  • a large [+1] excellent [+2] sapphire [1000]: [1300 gp]
  • a huge [+2] good [+1] spinel (red or green) [50]: [65 gp]
  • a small [-1] flawed [-2] quartz (milky, rose, or smoky) [50]: [35 gp]
  • a medium [0] good [+1] spinel (red or green) [50]: [55 gp]
  • a large [+1] excellent [+2] pearl (black) [500]: [650 gp]
  • a medium [0] excellent [+2] diamond (fancy) [5000]: [6000 gp]
  • a huge [+2] average [0] amber [100]: [120 gp]
  • a small [-1] average [0] pearl (saltwater) [100]: [90 gp]
  • a medium [0] average [0] topaz [500]: [500 gp]
  • a small [-1] poor [-1] coral [100]: [80 gp]
  • a tiny [-2] excellent [+2] sapphire [1000]: [1000 gp]
  • a small [-1] excellent [+2] ruby [1000]: [1100 gp]
  • a small [-1] average [0] topaz [500]: [450 gp]
  • a medium [0] average [0] topaz [500]: [500 gp]
  • a medium [0] flawed [-2] jet [100]: [80 gp]
  • a small [-1] flawed [-2] turquoise [10]: [7 gp]
  • a tiny [-2] average [0] jet [100]: [80 gp]
  • a medium [0] good [+1] ruby [1000]: [1100 gp]
  • a large [+1] good [+1] pearl (black) [500]: [600 gp]
  • a medium [0] good [+1] malachite [10]: [11 gp]
  • a medium [0] average [0] amethyst [100]: [100 gp]
  • a medium [0] poor [-1] jet [100]: [90 gp]
  • a small [-1] average [0] pyrite [10]: [9 gp]
  • a large [+1] flawed [-2] jasper [50]: [45 gp]
  • a medium [0] good [+1] onyx [50]: [55 gp]
  • a large [+1] average [0] jade [100]: [110 gp]
  • a large [+1] good [+1] obsidian [10]: [12 gp]
  • a medium [0] flawed [-2] peridot [50]: [40 gp]
  • a large [+1] average [0] tigereye [10]: [11 gp]
  • a large [+1] average [0] pearl (black) [500]: [550 gp]
  • a tiny [-2] good [+1] onyx [50]: [45 gp]
  • a huge [+2] average [0] shell [10]: [12 gp]
  • a medium [0] poor [-1] coral [100]: [90 gp]
  • a medium [0] excellent [+2] pyrite [10]: [12 gp]
  • a medium [0] poor [-1] jade [100]: [90 gp]
  • a medium [0] flawed [-2] sardonyx [50]: [40 gp]
  • a small [-1] poor [-1] carnelian [50]: [40 gp]
  • a small [-1] poor [-1] opal [500]: [400 gp]
  • a small [-1] average [0] quartz (rock crystal) [10]: [9 gp]
  • a huge [+2] average [0] lapis lazuli [10]: [12 gp]
  • a medium [0] good [+1] rhodochrosite [10]: [11 gp]
  • a small [-1] good [+1] amethyst [100]: [100 gp]
  • a small [-1] average [0] opal [500]: [450 gp]
  • a large [+1] flawed [-2] quartz (milky, rose, or smoky) [50]: [45 gp]
  • a medium [0] average [0] pearl (irregular freshwater) [10]: [10 gp]
  • a medium [0] flawed [-2] spinel (red or green) [50]: [40 gp]
  • a large [+1] average [0] carnelian [50]: [55 gp]
  • a tiny [-2] poor [-1] diamond [1000]: [700 gp]
  • a medium [0] average [0] pearl (black) [500]: [500 gp]
  • a tiny [-2] good [+1] citrine [50]: [45 gp]
  • a medium [0] poor [-1] ivory [50]: [45 gp]
  • a medium [0] average [0] sardonyx [50]: [50 gp]
  • a medium [0] excellent [+2] opal [500]: [600 gp]
  • a large [+1] good [+1] shell [10]: [12 gp]
  • a large [+1] average [0] shell [10]: [11 gp]
  • a small [-1] average [0] malachite [10]: [9 gp]
  • a small [-1] excellent [+2] rhodochrosite [10]: [11 gp]
  • a large [+1] flawed [-2] coral [100]: [90 gp]
  • a large [+1] average [0] chrysoberyl [100]: [110 gp]
  • a medium [0] average [0] tourmaline [100]: [100 gp]
  • a large [+1] good [+1] spinel (red or green) [50]: [60 gp]
  • a huge [+2] average [0] pearl (saltwater) [100]: [120 gp]
  • a medium [0] good [+1] sardonyx [50]: [55 gp]
  • a medium [0] flawed [-2] pearl (black) [500]: [400 gp]
  • a large [+1] flawed [-2] obsidian [10]: [9 gp]
  • a large [+1] average [0] aquamarine [500]: [550 gp]
  • a large [+1] average [0] topaz [500]: [550 gp]
  • a tiny [-2] poor [-1] moonstone [50]: [35 gp]
  • a large [+1] average [0] opal [500]: [550 gp]
  • a huge [+2] average [0] emerald (brilliant green) [5000]: [6000 gp]
  • a medium [0] poor [-1] alabaster [10]: [9 gp]
  • a large [+1] poor [-1] onyx [50]: [50 gp]
  • a medium [0] average [0] pyrite [10]: [10 gp]
  • a medium [0] poor [-1] opal [500]: [450 gp]
  • a tiny [-2] average [0] citrine [50]: [40 gp]
  • a medium [0] good [+1] tourmaline [100]: [110 gp]
  • a huge [+2] poor [-1] pearl (black) [500]: [550 gp]
  • a medium [0] poor [-1] jet [100]: [90 gp]
  • a medium [0] average [0] diamond [1000]: [1000 gp]
  • a medium [0] excellent [+2] opal [500]: [600 gp]
  • a medium [0] flawed [-2] pyrite [10]: [8 gp]
  • a medium [0] poor [-1] spinel (deep blue) [100]: [90 gp]
  • a medium [0] poor [-1] pearl (saltwater) [100]: [90 gp]
  • a large [+1] average [0] shell [10]: [11 gp]
  • a medium [0] good [+1] azurite [10]: [11 gp]
  • a medium [0] good [+1] pearl (irregular freshwater) [10]: [11 gp]
  • a small [-1] good [+1] ruby [1000]: [1000 gp]
  • a tiny [-2] average [0] jet [100]: [80 gp]
  • a medium [0] average [0] opal [500]: [500 gp]

I used a weighted table of grades (1-5 grade 1, 6-10 grade 2, 11-14 grade 3, 15-17 grade 4, 18-19 grade 5, 20 grade 6) and I’m showing the input values so I can double check… basic verification.

So far, so good. More to come.

Just Decking Around

I had an epiphany of sorts last night. Also, insomnia; the epiphany might be nothing of the sort.

In my previous post about the card crawl I described PCs as starting at ‘second level’, and that each level made them better in one area of endeavor (martial, arcane, divine, skill), with a specialized skill within that. I considered the different pieces that can be assembled for the initial character builds and realized that I might actually want three levels at the start instead of two. Dwarves are classically powerful warriors and skilled crafters (argument for martial and skill), elves are magical warriors (martial and arcane), paladins are holy warriors (lots of martial with a bit of divine) and clerics are crusaders (lots of divine with some martial). It starts to make sense to have characters starting with three levels instead of two, especially since it allows initial builds to have uneven amounts of two areas of endeavor.

I originally expected PCs to start at second level and perhaps reach seventh or so. If the overland map is a 3×3 array, the PCs start in one corner and must travel to the diametrically-opposite corner to complete their quest they’ll have to pass through at least three and probably up to five of the other locations. This aligns closely enough with the design of Echelon that I can probably look at that for guidance. Start at third tier, each dungeon completed can result in a tier gain (and new cards are based on tier, so the later-game gains get to be pretty impressive)… this could work well for me.

Which led me to think: Echelon assumes that higher-tier characters are simply better than lower-tier characters, at least as far as adventuring capability is concerned. The d20 model of the game uses a 4e-style Level Bonus as a base modifier for rolls, and the dice pool version adds another die to all rolls at each tier (and talents improve the size of the die rolled). Higher-tier characters are more likely to succeed at tasks than lower-tier characters.

Having recently played some One Deck Dungeon (card-based rogue-like game) recently I realized that having none of something can be a problem. Higher-level characters are supposed to be better, and this can entirely hamstring them in some area. I am inclined to have each level provide a ‘general bonus’ (that applies to pretty much anything) in addition to the level-specific abilities. This gives space for higher-tier characters to be generally more capable than lower-tier characters, while actually reducing the significance of the potentially greater number of levels — I now picture gaining up to eight or ten instead of three to five — between characters of the same tier. That is, a sixth-tier character has six general levels (typeless, no specific ability, etc.) and up to six levels of martial ability, and acts with twelve martial and six anything-else, while another (four arcane levels and two skill levels) acts with ten arcane, eight skill, and six anything-else.

This can apply when buying new cards as well, though I might want to double the cost to account for the greater purchasing power available. Anyone could afford an ‘arcane 6’ card when they reach the sixth tier, but a dedicated arcanist could afford the card at the start of the game (three arcane levels and three general). This opens things up a bit for those who need to spread their abilities out, without requiring large diversions to get the basic ability needed to branch out at all.

I’ll want to keep an eye on that. There is merit to having an “arcanist” that is only good at magic and a warrior that is only good at martial activity. This might not work well in very small groups because too much specialization can be a problem… but it’s worth examining both options. I could even have both built in, but ‘hard mode’ means you don’t count the general levels.

More grist for the mill.

Keeping My Hands Off My Deck

… or not. I’m working around the edges of a card-based crawl game. I don’t know all the resolution mechanics yet, but I’m starting to see the shape of it.

  • Probably co-op (adventuring party)
    • Possibly competitive co-op: party has a shared goal, but each PC might have individual goals that score as well.
  • Card-based play. Randomness lies in the draw of the cards, card resolution is deterministic.
  • Hand management: strict limit to number of cards in hand and in play (stacks in play — if one card augments another, they count as a single card for hand purposes). Probably 5 or 7 cards, might get extended by certain powers or at certain levels.
    • You can play more than one card (major and minor actions?) each round.
    • End of each round you can draw up to 2 cards and keep up to your limit (if limit is 7 and you have 6 cards, you can draw 2 and discard any of the 8 you now hold — except curses).
  • Fatigue: if you are required to draw a card and cannot, you are exhausted and can only provide minor support (per Sentinels of the Multiverse hero cards).
    • Deck resets when team leaves a dungeon.
    • Deck resets when team defeats a boss.
  • Wounds: if you take damage you must discard from your hand/equipped or deck (running your cards out faster).
    • Hard mode: bury cards starting from hand/equipped, deck, then discard pile. Buried cards are not available on deck reset, but healing will restore them.
    • Wounds cannot be paid with curse cards.
  • Deck-building: hero decks build up over time.
    • Encounter rewards are added to a player’s deck (discard pile; must reset to be able to use).
    • Probably can spend cards from hand to buy new cards (to discard pile). Might not allow buying new cards in a boss fight.
    • Cannot spend curse cards to buy new cards.
  • Hero cards have two levels (chosen from martial, arcane, divine, skill; both levels do not need to be the same type) and a specific ability (which might be keyed to level and level type). Probably also have a keyword or two.
  • Gaining levels: defeating a boss makes two level cards available.
    • Each level card typically represents ability taken from defeated boss or ability representing defeating boss (defeating the Necromancer might mean you gain Guardian of Life to represent your being champion of the forces of life, or it might mean you gain Dread Arcanist to represent you learning knowledge of death magic).
    • Level cards can be applied any time before leaving the dungeon. You’d likely want to see all options available before assigning.
    • Each hero can gain only one level card per dungeon.
    • Level card increases level in one axis (martial, arcane, divine, skill) and keyword (special ability).
    • Level cards are applied to hero card, not added to draw deck.
  • Equipment cards typically represent objects with persistent effects, such as weapons or armor.
    • May be equipped (placed on table); still count against hand size.
    • May be augmented (other card added to equipped card to increase effect); augmenting cards do not count against hand size (already covered by item being augmented).
  • Spell cards typically represent magical effects.
    • May be immediate or persistent; if immediate may be played directly from hand, if persistent get ‘equipped’ and count against hand size.
    • Effects may depend on or be augmented by arcane or divine level.
    • Availability or usability might be constrained by arcane or divine level.
  • Technique cards are mundane ‘spell cards’.
    • May be immediate or persistent; if immediate may be played directly from hand, if persistent get ‘equipped’ and count against hand size.
    • Effects may depend on or be augmented by martial or skill level.
    • Availability or usability might be constrained by martial or skill level.
  • Might be ‘gish cards’.
    • May be immediate or persistent; if immediate may be played directly from hand, if persistent get ‘equipped’ and count against hand size.
    • Effects may depend on or be augmented by (martial|skill) and (arcane|divine) level, probably using the lower of the two or the sum of the two.
  • Curse cards are added to heroes’ hands under certain circumstances (described below). Added to deck normally and when drawn can be held in hand ‘with no effect’ beyond tying up hand real estate. When played may have immediate effect (and get discarded) or ongoing effect (lasts longer and may tie up an equipment slot as normal). Cannot be discarded or buried for damage.
    • Starting a dungeon but not completing gives each hero a curse card specific to that dungeon.
    • Encountering a boss but running away gives each hero a curse card specific to that boss.
    • Defeating the source of the curse removes the curse,
  • Card effects are deterministic. Play (or activate) card, effect happens.

Initial thoughts, and subject to change. Also, very flow of thought.