Lamentations from Ground Control (Patreon)

It hasn't exactly been a linear recovery, but I do seem to slowly be getting better. And I'm eager to get back to business.

Though I feel a bit like I'm spinning my wheels in the mud here. I really want to rocket off into progress, but shit is just Broke rn. So this isn't a fun update, but I'll be giving a bigger picture look at the state of things and what the obstacles are.

Unhealth Bars

Hey did I ever post that we added these
Maybe this -is- a fun update, if briefly.....

[ID: an image of our test battle scene showing health bars of various colors. they are diamond shaped and empty from right to left, hovering to the top left of a unit.]

So these show up in battles now. Player units always show. Enemy units show when damaged. Every team has its own color. Also, to help visibility if the unit is specifically full health the border is a little brighter-- you can see the star in the middle is actually missing like 1 hp.

So that's cool!
Ummmmm except unfortunately they broke saving in battle. All forms of it. We were pretty mystified what was wrong with saving until Perry figured it out.

But here's the reason-- those health bars gotta move with the characters right. So we thought we had a really clever solution of appending them to the character graphics. Turns out, that's not so great when they end up getting saved along with the characters. The code that writes save files tries to save the health bars and, for reasons unknown to mankind (and too low level to be worth exploring), just vomits them back up.
On a cosmetic level, it also means things like shadows and light affects that display over characters......... also displayed over the health bars.
Oops.
So that needs to be rewritten and in the mean time not being able to save in battle sure puts a damper on testing other things like for instance AI issues that have cropped up.

How to Not Fight

I'm really trying to get the tutorial chapter done, right. So one of the things we're doing to help teach new players the system is to put the combat into a no-fail state for their first time. This way players can see what it looks like when they succeed an attack in the rhythm combat.
While this worked at the time I implemented it, it since broke in two ways:

• - I refactored combat to be integrated with overworld battles rather than requiring models. A few loose ends there made it so that the tutorial would never -leave- the no-fail state once it entered it, even once you succeeded.

• - Classes and unit stats are kind of in flux right now, so the tutorial targets stats changed in such a way that it was harder to hit them. The hit block became so small that it could not be hit even in the no-fail state.....

The two of those together meant the tutorial actually became something of a.... no-success state. And also soft locked you.
Oops!

The fixes to those ended up being simple but it was the kind of simple where I spend five hours staring at code and trying stuff before I ultimately arrive at a one-line change that fixes everything.
Programming, everybody.

A Class Act

In the demo, "classes" were purely surface level. All of the units with the same graphics had all of the same stats (intentionally, for consistency) because I copy-pasted them that way rather than because of the game having any real understanding of what a Class does or even how to construct a unit.

So we've now added some skeletal class and unit construction in, but part of that means we now also have Logic for what graphics should be loaded. Only, loading currently happens when you enter a map, and we're not making units until you start a battle on that map ...... at which point it's too late to load through our current system. So we gotta untangle that too ..,.,..

404.2 Not Found

We no longer need combat animations for the battle system to function, but they are still an aspiration. As such I want to make sure that the tools our team has to make animations are in good shape so that they can do their thing while we do our thing.

So we're using Spine for animations and as of 4 days ago, they released a new version, 4.2, that features two important improvements.

• - PSDs can be imported natively

• - Physics.

The first one was the case for Dragonbones, the janky slightly dying software we used to make animations for the demo. But Spine was surprisingly lacking this feature. They included a script for Photoshop to do it but my PS version rejected that script until I Obtained a new one fairly recently.

So a few months ago the workflow was this:

• - Falcon creates a combat art in Krita

• - I touch it up in Clip Studio Paint

• - I export it as a Photoshop document

• - and use a separate Gimp script to send it to Spine.

So we cut GIMP out of the equation at least but with 4.2 we could skip the Photoshop script as well which would be nice and a similar level of convenient as we had for the demo.

The real prize is Physics though. In this context, Physics is things like... Gravity.

So for the battlers in the demo-- Star jumps forward to attack. The actual animation of her body and limbs are one thing, but the devil is in the details and baby we're working on Hell. So her skirt's gotta swoosh as she moves. Her hair's gotta swish and then fall. And she has ribbons on her boots and another at her waist which all need to be animated and fall into place too. They're small details, but the sum of their effect goes a long way to 'selling' the animation as fluid and natural. So those are four things which I can count and list, but all of those things also themselves have multiple parts and Layers to be able to move freely. There is currently no way to do that but by hand. Ultimately, animating the small details is a significant part of the workload-- I might say even a majority of it once rigging is done.

But Physics. The idea is, we could say hey this ribbon or this hair piece obeys gravity to this extent, and the program will automatically handle a lot of that animation for us. That would significantly reduce the workload for our poor animators and speed up their ability to make cool stuff. So, we want that.

The problem is we need support for spine to work in our engine, and more specifically through our graphics library, Pixi. Our current library of support was created by the Pixi devs, but hasn't really been updated for a year or so. And we're on an older version so it looked like a slim chance they would update for us. But I went poking around Spine's site, and lo! What do I find? But in the change log from 4 days ago, the say they are now providing their own support for Pixi! I need only click this link to receive the boon of the spine gods, and--

404. The link leads to a non-existent page.

So. Um. I don't really know what's happening there.
M-maybe they'll fix it. I asked on their discord and someone thinks they haven't made the support yet....
B-but this means... they will, right? It means-- there's hope for us, right??
Please pray to the Spine gods to smile upon us .......

A Particular Point

Last year, I had the pleasure to play modded Fire Emblem Engage. Engage is a super fun game... but, and not that I'm endorsing piracy, playing it on PC is just such a superior experience compared to on Switch. For one thing there's already a ton of class expansion and rebalance mods to freshen up and polish the gameplay, but for another, the game looks incredible when taken to full resolution and 60 FPS. They have some especially beautiful animations, so naturally I spent a not insignificant amount of time staring at them and studying them. Actually, I'd like to go back and study more frame-by-frame.... ah, perhaps I should leave that to the animators though.

But one thing I did notice is some of the ways Engage "cheats" with its animations by using particles. For instance, when the main character is swinging a sword at a target, the physical models do not have to actually appear to make contact. A slashing particle appears on the target near the end of the sword, and the animation feels 'close enough' as a result.
Another way-- weapons are often animated with glowing edges or points, but that glow does not always match up exactly to where the end point of the weapon on the model actually is. The ribbon of the glow traces beautiful soft curves and dramatic arcs (one of the core tenets of animation), suggesting visually appealing motion without stressing the model itself too much.
That sounds handy, doesn't it?

As it is right now, our handling of visual effects is pretty archaic. Take the basic smear frame. This is another core tender of traditional animation-- when something is moving really fast, there will often be a frame or two where it is animated as a blur, or smear of paint. Personally I find that it is near impossible to create a particular good feeling fast motion without that. But doing so in models is ... challenging. We very much want to use those for our weapons because that's where a lot of the feel of a powerful hit comes from. But in order to show a smear, it has to be part of the model. Which means it has to be drawn and rigged. So whenever we show a smear frame, it's because it was actually there the entire time. We just turn it visible for the moment of motion and then hide it again afterwards. This is, predictably, a pain. It's also not very flexible. Engage simulates this effect with particles as well.

We have some particle handling in the demo-- elemental particles fly off of a target with you hit them. But it's very rigid. The extent of our control over those particles is we can kind of guess where a model is and tell it to play there. So today I have been hunting through the Internet and through the models' data structure to try and figure out how to more specifically return the coordinates of a certain Point of the model -- such as the tip of a weapon. I've gotten like 90% of the way there, but there's a margin of error I haven't quite figured out yet. Needs more research ... but promising.

With a few choice particles, I hope to make animation easier and battles feel much better.

Drawing Boardless

Aside from all that, I've got some visual work to do. A map to finish, a menu to design ... I have a great tablet for it, but. We also just moved again. And one of our desks actually didn't survive the -last- move. So I don't ... actually have anywhere to set up my tablet right now. I considered an upside down box. It's a little short, but it might be my best bet ,.,...... It's a pinch.
We'll get a new desk soon, it's just another awkward thing limiting me.

The Cats Cradle

And then, of course, there's all the other small issues piling up. Mouse support needs to be told to not be active during combat now that that's part of the main scene. Something broke the attack-move qol. The pause visuals got yeeted into the sun. There's that entire AI issue I mentioned at the start. Last I checked, character sprites flitted on and out of existence while moving. Battle scenes can play mid combat.

It's-- it's wimdy.......

Sometimes when I'm out here getting lost in the animation sauce, or on my sixth consecutive hour of trying to figure out only the first of Several programming issues I hoped to resolve, I'm feeling like
... Remember when I wanted to make a video game?
Wtf am I doing?
I don't want to find the six hidden parameters for computeWorldVertices, I want to design neat class effects and interesting tactical scenarios.


I try to remind myself that spending extra time on the system is in fact normal and expected at the start of development. Once the overall system is set, once the rocket is built, then we can take off and fly to the moon.
But I keep sitting here on the ground with half-assembled rocket pieces and wondering why I'm not at -least- in the sky.
And Reborn was a looooong flight.

But c'est la vie.
Oh, yeah, the French translation for Reborn came out earlier. Big shouts to the community for that.
How do you say "could not find property of null object" in French?