Design Concepts for PCGen

In general, there are a number of key considerations that are driving the code decisions and architecture of PCGen.

Subsystem Isolation

Overall, we want the subsystems (loader/core/output) to be sufficiently independent of each other that they don't interact except through a well-defined API and also so they only operate at the appropriate times... Meaning the once load is complete, the loader system should not need to be called again. Also, output should be called during output and not during regular character processing. Unfortunately, both of these are not true with the existing systems... it is possible to write a token that both uses items from the output tokens as well as is parsed at runtime - meaning all of the systems are intertwined today. The strategic designs that will prevent that interaction are described below.

Catch Errors Early

Errors in the data files should be caught during data file load, and should not trigger runtime errors.

Eliminate Hardcoding

Eliminating hard coded values and special cases that currently exist in the PCGen code base will allow PCGen to more easily support our existing systems and non-d20 systems. The side effect here is an increasingly data-driven design.

Order of operations clarity

There are two order of operations items we are trying to address

In Data

Right now, for a token like REACH, there is an order of operations ambiguity - what Template is applied is not exactly clear. This is one example of many in the system. The new formula system handles this one with PRIORITY=x.

In Code

Effectively there are certain things that must happen "first" - except in many cases, there are loops or other conditions that mean we need designs and technologies that overcome those "reference before constructed" situations.