The Visualization Overview section is now available in my growing tuning series. I struggled with being somewhere between a catalog of functionality (and going too deep), an API overview (and being too shallow), and a design justification (and getting too long-winded).
Ultimately, the idea of the system overviews is to provide enough information so that the tuning pages I’m going to create have some context on what I’m tuning without me having to do it in-line and detract from the actual tuning content.
I just added some background information on the packaging assembly as part of my documentation set for experiences and insights on tuning the Ikosa framework.
Finally finished off and published the first (non-bloggish) page of a “series” of pages I’ll be adding to (eventually) that I’d collected thoughts on about optimization stuff in the Ikosa Framework.
It’s been just slightly over a year since any substantive post. Again, as the sole resource on Guildsmanship (Ikosa Framework), I get more from the coding than from promoting to the small set of people who are even slightly aware I have been coding the D20 system (v3.5) for the past decade (or so).
Last January: more furnishing things (mostly model generation)
February: even more furnishing things such as drawers and doors opening, UI workshop, in-game manipulation actions; ended with some drawing optimizations in the workshop and client
March: continuing on optimizations
April: even more optimizations (it’s easy to get addicted to performance numbers!)
May: got back into furnishing movement (push/pull/slide/rotate); also got into climbing, moving on furniture; and UI bound jump-down and hop-up actions
June: (slow month) but I added a new ModelCacheSelector; and here’s a quoted comment from a check-in: “Furnishing default implementations tend towards solid convex cuboids
overrides for hollow/cabinet/surface mainly change covered face exposures” (which I think was a refactoring to a base-class so I didn’t have to copy/implement certain geometry features)
I’ll add some more later today while I’m on a roll.
Lest I appear idle due to a lack of posts…
And a small sample of the check-ins over the past few weeks:
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.
Spell components (component pouch, devotional symbol and verbal).
Map redraw on invisibility state changes.
Creatures: bugbear, hobgoblin, orc, kobold, half-orc, gnoll, ogre, grimlock (light-sensitivity, weapon proficiencies, giant-type)
Classes: barbarian, rogue, ranger
Tacticals and class-features: evasion, improved evasion, rage, trap-sense, sneak-attack, uncanny-dodge, flanking, overrun, legal-position checks
Prerequisites now part of LocalViewer instead of a docked tool window, fixed some minor problems with responsiveness of controls,
Made single option, check and save prerequisites work with button arrays instead of combo-boxes.
Fixed poisonous natural weapon process flow and binding on spider’s bite attack.
I also spent some time working on trying to work out non-tactical settings and regional settings; but nothing that I can add into the core of the experience just yet.
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.
One of the other things I’d been working on was swimming (haven’t really tested it yet), and in the course of working on it I revisited falling, which I had worked on years ago when coding flight movement. In the Ikosa framework, falling is a type of movement, albeit a (largely) uncontrolled one. What I was trying to bridge recently was the transition between falling and falling into water (and falling through water), and ultimately sinking (that is, if you aren’t swimming, but are in water).
So, here’s the narrative:
1) i had to alter my playground setting to add water and a big diving board platform; and move my test creatures (wizard, spider and animated object) up to it. The following picture is from the POV of the “wizard” (using a largely unpainted greatsword wielder figure) standing at the edge, waiting to step off the platform
2) the character takes a step off the edge (into a region unsupported by gravity), and immediately gets to roll a reflex save to avoid falling. If she succeeds, she gets to void the movement.
3) Like climbing, the falling is sent as status back the the user controlling the character.
4) There’s actually a couple of falling steps and pathways depending on whether the liquid falling continues past a single 5 foot cube, but in this case the water is deep enough that damage is requested and (potentially) applied on the entry into the second 5 foot cube. At this point the system uses the fall distance accumulated from the original falling movement to determine how much damage to give.
5) This UI shows (but doesn’t pop) on the host UI at the moment. I haven’t worked client-server mechanics for a game-master specific UI notification as of yet. The GM needs to click “Edit” (very old UI I haven’t played with in years) to get an editor dialog as shown next.
6) After clicking OK, the damage prerequisite is met, the damage application step is processed and the client is notified, with the result’s showing on the log and the character sheet.
7) Finally a visual from the character after plunging and sinking. This image exposes a small deficiency in the visualization system…namely that under water screen masks (should be a bluish hue) are only applied directly against a surface boundary at the moment, and the character is actually only adjacent to a surface edge (the edge of the platform)
So, I did manage to get climbing basically working a little while back. Here’s a quick run-down:
1) walk the spider to a wall
2) switch from Overland to Climb then begin a movement straight up (Shift+S)
3) Immediately make a climb check
4) even though I’ll only have to make that at least once every move action (or if the difficulty changes past my previous check’s value) I’ll get bored quickly rolling that quickly, so I change the Climb skill to a take 10 for 10 rounds
I also switch accelerated movement on, with a climb of 11 and a difficulty of 15 for the surface I can afford it
Also, check out the information passed back to the client in the log on the change of status.
Finally when I get high enough I look down on the “wizard” and animated crate below.
Pretty good, but I don’t have bonuses for being wedged in a corner or with opposing surface yet. Not sure there’s going to be much call for climbing in the “Alpha Quest” maps, but there should be a spider or two.