Today, trying to hammer out a few more enemies for Zone 1.
Did a "Treant" pretty easily, as it's morphs worked as advertised.

For enemies, I am generally just doing a Pose for the bestiary, and an animation sequence for when they are in combat (usually just running, flying, standing around).

I find the IK (inverse kinematics) a bit wonky in DAZ3D, but I figure it ultimately comes down to the original artist for the model.
I remember using TrueSpace4, and painstakingly adjusting the resistance for every joint, so that when I went to use IK it worked just right.

While animating a potential boss fight monster, I realized the animation was a bit boring.
Then I realized what I was doing wrong.
I was going A-B-A. Thus, the second half of the animation is just a direct redo of the first half.
Thus consider the 'purity' of the frames: AAA, AAB, ABB, BBB, BBA, BAA, AAA.
Since AAB and BAA are ultimately the same, and ABB and BBA are too, that 6 frame cycle (skip the second AAA) is only 4 frames of unique.
As long as I remember that when importing the images, I would be able to cut the file size down considerably (limit approaches half, as tweens increased).
[The term tween is short for in-between, and refers to the computer generated frames in-between the keyframes I craft]
If I did A-B-C-A, it becomes AAA, AAB, ABB, BBB, BBC, BCC, CCC, CCD, CDD, DDD, DDA, DAA, AAA.
Thus only the AAA frames would be duplicated, making for a more interesting animation.
So, for the (potential) boss fight I changed it to A-B-C-D-A, adding D to make it just a bit more interesting (also the wings go up-down-up-down-up).
At this point, the only animations that will suffer from this A-B-A oversight are the wyverns, so I may or may not decide to go back and redo them.
It'll bug me until I do, so I'll see how many days I can hold out.

I need to step up enemy generation, and move on to level generation and game logic.
The core moment-to-moment logic will be pretty simple.
I especially like using Flash for things like this.
Each bullet sprite is its own "class", but instead of staring at pages of text/code, I work in an animation framework.
If I want a different behavior on a particular frame of animation, then I just put the code that triggers it on that frame.
[I do tend to use different layers for code initialization/functions, code triggers, and animation]

Consider gravity and wind resistances, some projectiles (realistic ones) are affected by them, while others (sci-fi) aren't.
The decentralized approach though does mean each projectile can have its own logic for handling the physics, which would get annoying to keep maintained.
So, in all likelyhood, I will make a projectile base class that is boring code, and inherit it for each projectile.
But, if each projectile is unique enough, it may not really result in much benefit.

When I think of "sprite" I think of the show "Reboot".
I like how the sprites do their own thing once created.
When programming systems like games, we'll often write loops that run through all the bullets, do task, loop through all the enemies, do task, loop through all the possible user inputs, do task, etc.
With Flash that is abstracted away.
When I throw a bullet onto the surface, I can forget about it.
Flash will trigger a frame change for the bullet (and each enemy, etc) so that I don't have to think about writing that.
The frame change will then trigger animation changes in the bullet.
Those animation changes will then trigger the running of code.
The code will then do checks such as "did I hit something yet?" which could easily be a call to a centralized function.
That centralized function would then have a loop, so that breaks the illusion a bit.
If it hit something, it could then tell the thing it hit "oh, hey there, I've just hit you, I'm at this angle, I cause this much base damage, have this much armor penetration, this much fire damage, this much ice damage, etc".
The thing it hit would then say "oh, I've been hit, I'm a goner... oh wait, it didn't kill me yet... but it did set me on fire..."

So, the decentralized approach can lead to some issues with interfacing objects:
* what if an enemy doesn't know what to do with fire damage, does that equate to 100% resistance?
* what if a bullet doesn't report that it does 0 fire damage?

Thus, having central handlers is most beneficial.
Having the bullet say "here I am, and this is the damage I am doing this cycle, and my target is 'enemy' sprites" to the center.
Having the center say "hey guy, you've been hit, tell me your stats" to the enemy that got hit.
The enemy replying "bummer, well my health is blah, my stats are blah blah blah, and I have an extra shield facing blah with stats of blah blah blah".
Then the center calculates the resulting damage and says to the enemy "okay, well our calculations show you take this much damage".
To which the enemy now says "I'm a goner... starting death animation...".
That death animation could then do whatever it wants, such as firing a bunch of bullets off in every direction.
The center then says to the bullet "you caused blah damage to the enemy".
The bullet then says "I'm done then... starting death animation..." or "I still have damage to cause, onward to victory!".

Consider if the bullet was some sort of RPG rocket:
* the initial contact would cause a little damage
* that damage triggers the bullet's explosion animation
* the explosion animation then causes massive damage
* while exploding, the bullet won't go away because of damage it does, it will go away due to time.

Consider a rocket like Gjallahorn:
* the initial contact would cause damage
* the damage triggers the bullet to explode, but also triggers firing 6 smaller rockets
* the bullet's explosion causes damage, while the smaller rockets fly around
* the six smaller rockets home in on the target, causing them to circle back
* each of the smaller rockets will individually make contact with a target (maybe not the intended one), cause damage, explode, etc.

Several days of not being able to devote time to this project.
Have taken some scraps of time to further categorize the assets into specific zones.
Now I have a handle on which enemy assets are appropriate for just one zone, and which I'll have available for balancing things out.
The player accessories and customizations were much easier to partition.

Earlier I commented that I really don't like when enemies are just re-colorized in order to be a "new" enemy.
But, as I went through the assets, I did find a few that I will make exceptions for.
Namely, wolves, bulls, and big cats.
Zone 2 will use wolves and bulls as normal creatures turned robo-zombie, and can be freed.
Zone 3 will use horror versions, such as a large Fenrir inspired wolves, and Last Unicorn inspired red bulls (though now that I say that, the energy drink comes to mind too).
Cats don't fit super well into too many of the main game zones, but consider a mountain lion (cougar) in zone 2, and lions/tigers (which are much bigger/stronger) in future zones.
I very much enjoy the idea of playing as a unicorn, and fighting a giant red bull... that always bothered me about Last Unicorn.
I like the unicorns in Overlord, and Warhammer, as they are combatants.

Did the animations sequences and renderings for one of the enemies, in two color variants.
One is a "spring wyvern" and the other is an "autumn wyvern".
The spring one is a younger version of the autumn one, which makes it sensible that they will have different stats.
They aren't just different colors though, many features on the spring one are reduced (horns and claws) to make it "younger".

Again, late and not much to report.
Just before the day ended, I further sorted the assets between in-game zones.
This also helps me to identify the nuances of themes that will be used for the zones.

The mapping of accessories to zones also helps me see how to incentivize the player to return to old zones.
For instance, a hat that fits with zone 2's motifs would not be appropriate to sell due to zone 2's theme.
Theme and motif are similar, but different. Here I am using theme as a major element (such as "horses are realistic") while a motif is a lesser element (such as "steampunk").
So, a steampunk hat would be unlocked by zone 2, but in zone 2 you wouldn't buy a hat for a horse.
But, in zone 1 you may buy a hat for a horse.
Thus, the hat is unlocked in zone 2, but purchased in zone 1.

Another example being cute skull branding (cutie marks).
The horror zone would unlock them, but the MLP themed zone would sell them because it is the cute zone.

Mapping out the enemies let's me know which assets are "pinch hitters" and which are bound to a zone. Then, I can use those pinch hitters to beef up zones that don't have as many bound assets.

Boss fights also require assets, so identifying which ones become normal enemies, and which become the bosses still has to be done.
I imagine pinch hitters will be useful for bosses, as the boss needs to stick out.

Terrain assets are often individual high detail scenes.
For those, I think a spinning side-scrolling combat would work best.
This reminds me of boss fights in Mayhem Makers.