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.