Visions of Aestia

I’m really pleased with the bits of Blue Rose I’ve used so far. The wealth mechanic makes equipping characters far simpler and does not seem to be as prone to abuse as I originally thought. I thought the sea-folk racial traits were nicely done, and the six-point buy is just stellar.

Now, I’m going to playtest the magic system, and what I’m seeing is pretty interesting, if a headache to integrate into an existing campaign world.

There are 49 spells that work like skills. If you know a spell, you are assumed to have maximum ranks and make checks to cast it. A handful of spells can be cast untrained if you have access to the discipline.

There are two ways to get spells. You can take a feat (Arcanum) that gives you access to a single spell. If you take one or more discipline feats (such as Psychic Talent), you get the ability to use some spells untrained; in addition, you can start taking a feat (Arcane Training) that grants access to any two spells in your known disciplines.

Finally, there are 10 spells that are only available as feats. This restricts access to more powerful spells by establishing prerequisites.

A quick back of the envelope calculation indicates that a fully dedicated Blue Rose character will never get access to more than 38 spells maximum, and that’s only if they neglect all other aspects of their character. There are no bonus spells for high ability scores; instead each spell has a key ability just like a skill.

Finally, instead of a spells per day limit, some spells require fatigue saves (with cumulative penalties), some spells require concentration checks to maintain (which hinders casting other spells), and other spells can be used freely but are of little consequence.

Certainly it’s easier to keep track of 60 spells than the typical 250-300 spells in standard systems. And NPC spellcasters are likely to have nine or 10 frequently used spells instead of a list of two dozen prepared spells you never otherwise use. No tracking of spells per day and no readying/memorizing means less bookkeeping for players.

Even if I want to add more spells, I’m unlikely to end up with more than 100 tops. This is interesting.

I started working on an implementation of VTD-XML in Python, using the examples provided as test cases.

It’s not quite as straightfoward a conversion as I expected for the main parser. After the encoding detection, the core parser is a huge switch statement with lots of embedded conditional logic. This is very procedural and very, very ugly, especially since Java is so verbose.

So, I’m implementing this very slowly so as not to get lost in the deeply nested regions. The two changes I’ve made so far are using Python’s native codecs package for the character iteration and actually implementing the state machine with the State design pattern. Making each state a class allows me to break up the conditional logic further so I know what’s going on.

Once the parser is done the rest should be relatively painless. I might initially go with an array of tuples instead of bitpacking the lookup tables.