Putting all the fragments together gives the basic shape of a meta-model, but doesn’t explain how to get to this:
The first thing to do is to define the set of brushes that can be used to paint the miniature. This is done by opening the “brushes” node for the meta-model in the package explorer.
Resulting in the brushes editor:
From within it is possible to add colors, images, gradients and stacks. Colors are pretty self-explanatory, they are solid colors. Images are images available to the model either bound directly to the part, or referenced as a resource in the package. Gradients are linear gradients based on WPF gradient brushes. Stacks are sets of brushes that are overlain on top of each other (assuming that the upper brushes have some transparency. Stacks allow multiple directionalities to gradients within a brush.
Next, opening a gradient brush shows the gradient editor:
The directionality of the gradient is selected via the array of buttons with arrows. The gradient stops are modified in the list box and buttons on the right side. The slider to the left of the gradient stop list box specifies the gradient stop relative location for the currently selected gradient in the list. The striping effect of the gradient is controlled by the “spread” combo and the slider next to the combo (which determines how the pattern repeats when it ends and how often the pattern repeats).
Now, to the actual painting back in the meta-model editor.
The “brushes” tab lists all the named areas that can have brush references mapped, and the currently mapped reference. Right-clicking one and selecting “assign” brings up a visual list of all the brushes that can be applied.
These references are the “global” (for the meta-model) brush references. It is possible to apply variations to individual fragment instances; and this applies to brushes as well as “parameters” such as lengths and radii, and to place more than one fragment in a reference connector.
For example, on the left arm, the first “arm.xaml” segment connected to the torso doesn’t have anything mapped for the “arm” brush, but the “arm.xaml” mapped in it’s “connector” has it’s “arm” brush overridden to be sleeve, which is effectively a reverse direction of the “shirt” brush so that the visual jump at the elbow isn’t so jarring.
Also, I mapped another segment “balljoint.xaml” to the left-arm slot on the torso to create the slightly bulging shoulders.
Finally, to reduce the relative thickness of the forearms, I select the forearm segment, switch to the “doubles” tab, unselect the “yield” checkbox for arm-diameter and freely adjust the diameter.
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).
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:
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.
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:
After playing around with tactical movement (which I’ll hopefully be getting back to shortly), I spent a few weeks playing around with magic item creation. Rather than go through the litany of development, I’ll cut to the finale: the ring of invisibility; a somewhat classic trope of fantasy.
I’ve had basic support for invisibility built-in for quite some time as the creature awareness system needs to be able to determine what can and cannot be seen. What I hadn’t completed (or worked on) until the past week weeks was the invisibility spell, nor magic items (nor apparently any in-game actions to put on or take off body-slotted items).
So here we are now:
The command-word activation isn’t currently running through an environment interaction, I haven’t completely normalized how the sounds propagation works or which actions require verbalizing (apart from spells with verbal components). One of the many things on my to-do list.
One of the oddities of the invisibility spell is that it requires a will-save:
Well, if I saw myself before, I don’t see myself now…
Just to get an outside perspective, I’ll switch to another viewer, Spidey the spider…
Looking through spidey’s eyes and checking his awarenesses, the Wiz is definitely gone…
Removing the ring will deactivate the invisibility effect…
Well, I can obviously see myself again, now to check Spidey…
I have that loosing awareness doesn’t clear the targeting queue in the UI. That’s a minor problem since on the server you still won’t be able to target directly. Mostly needs some client UI work since the targeting system is all client-side.
Here’s what I was really working on when I mentioned slots a few posts back. Workshop setup of spell slots. I’ll capture a picture of casting a spell in the client a little later.
Also, with about 10-15 minutes of time and existing model fragments, I put this together:
I’ve been meaning to put together the model fragments (and the whole model) for a spider or awhile. Ta da! Now I just need to get Climb Movement in the game engine fully implemented (and various web actions and effects) so the spider can be more menacing.
I have a targeting system and activity builder I’ve been working on to pick targets for actions. One target type that I’d been working on a lot over the last month was attack targeting. I’ve got it fairly well along, so I figured I’d go back and apply a similar design principle to awareness targeting.
Attack targeting requires making attack rolls and needs to know certain things about the type of attack such as whether the attack is with a hand held weapon in melee range versus a reach or ranged weapon, and the effective attack launch points. Awareness targeting requires a simple selection of creatures or objects of which one is aware. I already had a basic system that used all the things the actor is aware of in a drop-down list, but wanted it to work more like attack targeting in which if I pre-select items, they are the only things that show in the list.
Well I eventually got the two fairly similar, but hadn’t worked out all display characteristics for the selection list items. So I was testing and picked the first two items in the list for my two magic missile wand test. I hadn’t quite realized I had targeted myself until I didn’t see any missiles visibly flying to targets, but the tell-tale impact splash was centered on my camera.
Dutifully I rolled both missile damages, then watched as my display window went black…I had knocked myself unconscious and dying.