Resourcefulness

When I first started working on the Ikosa Framework, I had the idea of a local folder system to hold system-shared and “module” resources; and also for players to have their own sets of resources, like pre-painted miniatures and character data.  I also wanted to be able to package up resources into easily portable format.  I eventually learned how to use the .NET API for open-packaging convention (OPC) files, and built my own little system of management around it that included a “parts” namespace that could reference object structures within a single serialized stream and across streams in the package.

Every time I did something major to the structure of the map object model, or some other major infrastructural change to the model space, I had to rebuild any test map I had.  Most of this was simply in reloading icons, images, and models (of which over the years I had created a fair number).  Even the improvements I made in the workshop UI to allow multiple-simultaneous import wasn’t quite cutting it; setting up a meta-model is a fairly time-consuming that is done almost entirely in the workshop.  (I’ll post on that a little later).

Ergo, I eventually defined resource references that could be added to the resource resolution space of the system and defined in a resource container (of which a local map maintains an instance).

I’ve already added quite a few

Image resources are used to source image textures for terrain and faces (I’ve conveniently labeled my references as to which one I intended for which).  Icon resources are used 2D XAML images used for the UI selection and presentation, and can be added to treasure troves markers to indicate what’s in the treasure pile.  Models are just that: 3D models used for characters, doors and furnishings…basically anything that has an ObjectPresenter to show itself in a local view.  Fragments are pieces available to construct meta-models (a type of model composed of fragments…obviously) allowing some in-workshop editing and customization.  Finally brush-sets are collections of texture brushes that can be used to paint the terrain.  The Brushes resources is a single brush set for texture resolution, which I think I should probably deprecate.  I believe it’s utility has been superseded by newer texture mapping features in the models and meta-models; or perhaps it is a fall-back texture resolution system?  I’ll have to look into it.

Both the “Faces” images reference and the “Fragments” Fragments reference point to the same Ikosa package, so I’ll give a quick peek into what’s inside:

Package contains a resource container

Images are all faces (duh!).  The fragments are a mix of body parts and weapons.  I haven’t created a good way to visualize what the fragments look like.  If I ever get around to it, I’ll have to add some meta-data streams to the fragments with preview images, it’s either that or hoist them into a meta-model to render them (which leaves open the problems of scale, rotation, and textures; so previews seems like a better choice).

Next up is the terrain Ikosa package, which is the source of references for “Terrain” images, the “Models” model resources, and the “Terrain” brush set.

Some of the images support the models, some support the brush sets

Finally, the icons; I’ve included images of these before, but I’ve expanded the set by a few icons lately so figured I’d add them in and put them in context of a post that explains Ikosa framework resources just a little more:

A couple of design scaffolding icons in there as well…

…I need to clean up that “rod”

Creature Templates

Reading the SRD, one might think there are only two types of creature templates (changes that can be applied to a creature to make it more powerful).  These are: acquired and inherited templates.

Acquired templates are supposed to be templates that are added to a creature well after it has acted as a a non-templated version of the creature, and includes such things as lycanthropes (were-wolves, were-rats, etc), ghosts, zombies, skeletons, liches and vampires.

Inherited templates are supposed to be templates that are part of the creature make-up from the beginning, such as fiendish, celestial, half-fiend, half-celestial and half-dragon (but which may also include lycanthropes!)

When attempting to program these, I can identify four semi-distinct categories:

Altered Species

Fiendish, half-fiend, celestial, half-celestial and half-dragon fall into this category.  Typically used for creatures that do not progress by character class (or have some progression with “racial power dice”).  Rather than use the standard species traits and progressions, the altered progressions and traits are used instead.

Replacement Creature

Ghost, skeleton and zombie fall into this category.  There is a base creature instance which is used to build out the replacement creature.  The original creature needs to be tracked in case the template is removed (that is, the condition that made the replacement creature is undone).

Replacement Creature with Advancement Alterations

Liches and vampires use this style.  The base creature instance is used to build a replacement creature, but the creature can advance in character class.  Any subsequent character class advancement may be altered from its normal class features (typically power dice size), but also may include strengths of special powers such as spell resistance.

Advancement Class Analog

Lycanthropes gain a number of “racial power dice” indicated by the type of lycanthropy.  These act like a character class, but care needs to be taken in removing the “affliction” (class and power dice) since it is possible to advance in character class level after gaining the “affliction”.