[Starlight] lots of words but three gifs (Patreon)

round 2 here, let's go. this is all gonna be about progress for starlight's coding. as a refresher for clarity, when i'm referring to the larger tRPG of the game i'll be talking about the 'battle system' and when discussing the focused 1v1 exchanges within the battle system, i'll be calling that the 'combat system'. i think the two are usually interchangeable, but not here.

so i've mentioned it a couple times before but specifically since taking back to it my focus has been the combat-- and particular with getting the combat models we've made to actually do the combat things. 

so, for example, as such: 

so firstly, you may notice: now we're in widescreen. great.
more importantly, the battlers now actually dodge when you miss attacks. 

in order to make the dodge happen at the right time, we have to manually specify what frame of the attack animation the attack would connect on, and work backwards from there so we know when to play the animation. i've decided to keep all dodge animations to a rule of the moment of dodge being about halfway through them, so fortunately the attack impact frame is the only thing we have to specify, making it fairly practical. 

we can also do a lot with that same timing. for instance, calculating hp loss right then (which is currently not set up for that timing yet, but, will be), and: 

the 'damaged' animation, as well as accompanying effects. you may also notice that the hit blocks on the track disappear on a successful hit as well. we'll get an animation for those disappearing later, but it's a step.

the damage animation works the same as dodge, but lines up about a quarter of the way through instead of half, since the character isn't preemptivley reacting there. however, the complicated part of this has been what you see as the flash there. 

so, we're using a program called dragonbones to animate these battlers, which we then use a third party plugin to make compatible with rpg maker. rpg maker itself has no latent support for the dragonbone armatures, and dragonbones has no support for things like playing sound effects, flashing the battlers a color, and so on... but those are all things that rpg maker's animation editor does quite easily. my primary goal over the last month has been to get those two halves to play together nicely.

doing that has not been easy. it's probably the lowest level work (as in, most removed from the code i'm working with-- higher level is easier) i've had to do since starting to program this. this is because an rpg maker animation needs a target, and that target is usually either an overworld sprite or a (default system) battler. both of those things are Sprite type objects, as are the animations themselves, and so all three share a number of properties innately which lets them work together very well. unfortunately, the armatures from dragonbones, not being from rpg maker, are most definitively not Sprite objects, and thus have nothing in common whatsoever and thus under normal circumstances sprite animations cannot play using them as targets. 

so, the two main obstacles here were: how do i get animations to play on something that they don't normally play on, and how do i get the armatures to be something that they can play on.
for the first part, i eventually found a second third party plugin that allows animations to target Pictures. "Pictures" is a vague term here but it's basically RPG Maker's catchall for any other image you want to display on the screen. for instance, reborn's train ticket intro is made using pictures. pictures are also a Sprite object, so someone basically just replicated all of the code necessary to make them work for a new target. perfect, because that gives me everything i needed.
unfortunately, the armatures are not pictures.
i'll skip ahead a bit here. basically i cloned the entire Sprite_Picture method, murdered it, carved out its internal organs, and then shoved the armature up inside its leftover skin and skeletal structure.
and that made everything* work magically!

*except for all of the things it actually does to the armature, such as flash, fade in/out, etc... basically half of what i really wanted.
because yeah, still not a sprite object.
so i also had to rewrite the functionality for all that stuff which was difficult because it didnt seem like it existed but then it did and now we're here yay great story the point is it was a pain in the ass and the little flash you see in that gif is only a small landmark of a much greater victory

a lot has been set up for the future as a result of all this:

• we can do different colors based on the element of the attack
• particles per element hit too
• sounds are already in place, you just can't hear it in gifs
• screen flash is enabled for critical hits
• an animation can be matched to each individual attack animation to control all of the sounds and particles for it externally, which is so nice even though we haven't done that yet cuz i gotta draw the stuff
• the battler can be hidden and unhidden by the animation, which is useful for damage flickers like pokemon uses
• different animations can use different flash lengths and sounds for strong/weak/neutral hits (i spent a lot of time organizing a working sound library for this as well)

basically the baby flash there is the most simple version of a much larger system that's now ripe for abuse. it took all month, but it opens a lot of doors for us, and makes a lot of things much more simple. please believe me.

ame will now stop writing multiple paragraphs about a tiny flash in a gif and will instead post another gif for a feature that you can actually already see a little bit in the above gif:

here we're controlling nova because there's still no difference between enemies and allies for player control which is helpful. but that's not the point. the point is the fade in/fade out across rapid attacks.  
so the above is basically spamming the attack button (though there is a cooldown already)

basically, this is a handler for if a unit is attacking faster than its attack animations. the animations shouldn't be a constraint to the gameplay part of attacking, so we need to figure out something to do about that.
incidentally, if you've played older fire emblem games, you may be aware of the fact that swordmasters in the GBA era were really cool and also lyn especially because of their crit animations for basically Double Teaming into five places at once.
it's not five places at once, but that kind of thing is basically what we're going for here. to that effect, i may end up allowing one more model to be on the screen at a time (since each 'copy' of the attacker has to be its own model) but for now this at least gets the functionality going.

that's pretty much everything i have to show for today, but it's also pretty much all of the functionality that's needed to be made for the models. i can draw the attack-specific animations whenever, so that's not necessarily a priority. next up will probably be making the combat scene itself more flexible now that the models can follow along appropriately.

until next time. love y'all