One thing that had bothered me about the wings, file size wise, was how much data is used for when the horse is running rather than flying.
Then it occurred to me, if you have the wings equipped, then you'll be able to fly, and thus should always be flying, from a gameplay mechanics point-of-view.
So, when putting things together, I'll go back and make it so that there is no "running" animation for wings, but that instead the wings always fly, and the main body is the only thing with two animations.

I was reviewing some very old notes that reminded me that I want the player to be able to set the weapon angles for each combat mode.
For instance, you have a weapon on the right side of the horse:
* in top-down view, the weapon can fire forward, backward, or to any right-facing angle in-between
* in side view, the weapon can fire in any direction
* in rear view, the weapon can fire forward, up, down, right, or anywhere in-between (this'll be the most difficult to aim)
Once the player has flight capability, this makes things like aiming downward a viable choice.

I want to do boss fights as 360 degree spins (boss in center, player runs in circle), typically around an interesting terrain prop.
If the player is facing the boss (fight is in rear view), then the weapon angles can make sense, but running in circles doesn't make sense.
If the player is broadside to the boss (fight is in side view), then the weapon angles don't make sense, but running in circles does make sense.

Figured I'd work on the "metal" effect I want to use for the robo-zombies.
What I'm wanting to do is use the same images, but have Flash turn them into a metal-like appearance.
This is as opposed to re-rendering everything with a metal texture directly.
Re-rendering may one-day have the benefit of allowing me to use a different animation for the robo-zombie than for the rescued creature.
But, for now the rescue-able creatures don't have very intimidating appearances, so their "attack" animation can be re-used for their "running away to safety" animation.
I figure I will scale the images up and apply the filter for their "enemy" version, then use the smaller full-color version for their running away animation.

So, I looked online for how to use Flash to change the colors.
Most of the links I found took me to Flex instead of Flash.
But, once I found what I was intending to find, the Adobe documentation was rather clear.

using Flex:
http://flexdevtips.blogspot.com/2011/01/grayscale-images-progressbar-rating.html
the Adobe docs for the Flash version:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/filters/package-detail.html

In my case, I want to start with the ColorMatrixFilter, in order to turn the image grayscale.
To do that, my matrix starts with:

var gf = 1/3;
var gray =
new ColorMatrixFilter([
gf, gf, gf, 0, 0
,gf, gf, gf, 0, 0
,gf, gf, gf, 0, 0
, 0, 0, 0, 1, 0
]);
this.filters = [gray];

Then, looking at the documentation, I found the "glow" effect to be quite versatile, such that I think it can be useful for a couple different purposes.

First, I think it can be used as a way of indicating an enemy's difficulty, in the cheesy "let's just change their color" way that I want to avoid.

var glow = new GlowFilter(
0x00FF00, 0.6
,35, 35, 2
,BitmapFilterQuality.HIGH
,false, false
);
this.filters = [gray,glow];

But, if I allow the player to keep playing past the story's end, I may eventually need to fall back on such cheesy things.
Maybe the glow can indicate they are "infused" with some super-extra power, and that is why they are suddenly 30 levels more powerful.
So, keeping that stowed in my pocket.

Secondly, I'm thinking "damage indicator" using the inside glow option.

var glow = new GlowFilter(
0xFF0000, 0.6
,35, 35, 2
,BitmapFilterQuality.HIGH
,true, false
);
this.filters = [gray,glow];

This way, the player can get some feedback as to how badly the enemy is hurt.
There are several variables that can be adjusted to deliver this effect.

And, both glows can be applied, but the order does matter.

var glowG = new GlowFilter(
0x00FF00, 0.6
,35, 35, 2
,BitmapFilterQuality.HIGH
,false, false
);
var glowR = new GlowFilter(
0xFF0000, 0.6
,35, 35, 2
,BitmapFilterQuality.HIGH
,true, false
);
this.filters = [gray,glowR,glowG];

Finally, to make it look more "metal" I can adjust the factor I used.
A factor of 1/3 results in a proper grayscale conversion.
A higher factor will bleach out more color, but I can also add an offset.
So, where I finally end up will be something for another day.
I can't really decide what factors to use until I see it play out on the world maps, and in a field of bullets/arrows/pulseguns.
This is what I'll use until that phase of testing:

var gf = 2/3;
var of = -30;
var gray =
new ColorMatrixFilter([
gf, gf, gf, 0, of
,gf, gf, gf, 0, of
,gf, gf, gf, 0, of
, 0, 0, 0, 1, 0
]);

It seems to bleach out many colors, and looks more like aluminum foil to me.
If I were to use multiple instances of ColorMatrixFilter, I could gain effects such as clipping the lightest and/or darkest colors, making an even more artificial appearance.

So, building a battle map seems like a good next step.
For this, I'm going to try using WorldBase XT.

As I go through my assets, I found horse jumping things, which reminded me I wanted to make jumping a feature.
It isn't "too late" to add it in, but it will have many affects.
The biggest being that a horse with a carriage/wagon won't be able to jump.
Originally I thought this would be a good element, as it would give the player a choice:
* more weapons, no jump
* jump, but less weapons
At some point, I thought this was "too cruel" to the player.
But, it is always in the back of my mind as a game element.
To allow the player to be agile but lightly armed, or clunky but heavily armed.

Back to WorldBase XT.
Finally found the folder it was under (DAZ3D's CMS is not working on my computer anymore).
It seems to be a skydome + "rings" + ground + "patches".
It creates a very vast looking area of terrain, that looks quite non-procedural from a proper camera.
From the editor cameras, it looks smaller and procedural.
But, I don't need a lot of camera views.
I had toyed with the idea of building a stage completely in DAZ3D, then rendering out some images and splicing them into a continuous image in Flash, but this idea was fraught with problems, so I'm going to do the normal/standard thing.
I plan on doing this in layers.
For any given object, I will render out some frames of animation.
Likely, I will just use 1 frame for any given object, and just slide it across the game surface from within Flash.
With enough layers, it will create a spiffy effect, as nearby terrain moves by quickly, and farther terrain moves by progressively slowly.
Rather standard technique all in all.

WorldBase XT easily provides me with many layers, probably more than I realize, but these are the ones I am intending to use:
* Sky * OutHills * InHills * Trees * ground
It looks like it has 4 clusters of trees, so I'll play around with using multiple to create a "forest" effect.
The mountains (Hills in WorldBase) are an important story element (separate zones), so I will need to make sure they can be seen on occasion, if not always.
WorldBase also provides some nifty fog effects.

But, looks like that will be something for tomorrow.

A few more enemies rendered out.
An aspect of the game I am doing is "rescuing" [certain] animals from the clutches of the robot-zombie effect.

One technical aspect I am aware of, and worry about, is the processing it'll take Flash to resize+layer rendered images.
I think Flash will be efficient.
But, originally I did intend to use Flash to "trace" the images into vectors.
Then I would also render the images in a cartoon fashion so that the traces come out cleaner.
While Zone 1 would be a good place for cartoons, the other zones will be ill suited.
So, I'm starting Zone 1's assets as 'realistic' and will see how it goes.
Now that the animations are made, re-rendering them isn't too frightening.
Replacing all their cameras with toon versions is a bit more daunting (but less than replacing all their surfaces with toon shaders).

To get a feel for how it'll play on different devices, I'll test on: Android tablet < Android phone < laptop < desktop.
My desktop is obviously the first/foremost device I'll use.
It's also the most powerful of the devices, but is a chimera of tech: nothing cutting edge, but still more powerful than many desktops I see for sale in retail outlets.

One thing I have to keep in mind always, is that when I modify something "new" in a DAZ3D keyframe, I need to go to both adjacent keyframes and un-modify it.
While I find it tedious, it actually is pretty neat.
I could have wings flapping to one set of keyframes, and arms/legs/fire-breath moving to another set of keyframes.

I'm looking forward to doing a few mechanical models now.
Few/No moving parts.
I intend to make one of the mechanical mini-bosses become a friendly companion character once rescued.
A machine becoming a robo-zombie, and then being rescued... seems a little weird, but I think it can play.

I intend to make other companion characters too, such as riders.
Likely the first riders will be robotic looking, to cut down on customization ability.
Customizing riders can become its own strain of customizations, like the horses.
I do plan on doing that one day, but not for the base story.
Custom riders will be bonuses for extended playing.
Riders will also be able to use weapons like pistols, which I don't intend to let the horses use directly.

Conversations will get a little more complex once the player starts unlocking more characters.
That, or, I just have the conversations play out with the same characters always, regardless of which the player is using actively.
Then, if having acquired special side-mission characters, they could add new life to old conversations, or maybe even new options.
Thus, will my conversation engine just be Flash movies (using dynamic objects for the characters) that I get to customize with any logic I want on a per-conversation basis.
Or, will it be more container-ized such that I make the conversations in a text file, and then watch it play out.
The text file approach would allow better handling of internationalization/multi-lingual support.
That reminds me, I'll need to work on "expressions" for the horses (eyes, ears, mouth).

So, my earlier statement of "a few more" turned out to be wrong.
Getting the Puma to animate in a way I liked was a little tougher than I expected.