Not a particularly productive week, but progress progressed nevertheless.
The main thing I achieved was creating and implementing the Harvest animation. This is actually something I came up with the idea for relatively recently, but the idea is that, rather than the ‘sparks’, or ‘souls’, or whatever, which you collect in the game just flocking to you whenever you defeat an enemy, you’d actually have to take time out of combat to collect them. This is the animation for that, for taking a moment and focusing so that all of the nearby souls will flock to you:
There may end up being a bit more to the animation than this as I develop it further. It’s possible I’ll want to add more frames of animation to the harvesting state, something to give the impression that Something Important is happening, but this is good enough to be getting on with for now. I can test out better versions as I go.
The other major piece of progress this week is finally having something of a breakthrough on how I want to handle the animation problems I’d discovered a few weeks ago. Here’s my write-up on the solution from the daily devblog:
Okay, so there are two premises behind this idea: First, though I am planning on having the character animations shift between chapter, most of the changes are either subtle or modular. By this, I mean that they’re mostly either changes in one or two specific animations, such as the run cycle, changing timing and tilt to make her seem more in control and balanced, or they’re adding/changing out a particular part of the design, such as giving her full movement of her left arm. Second, though I have, as mentioned, 300+ frames, most of the movements between frames are fairly subtle, and don’t really demand the drawing of a whole new frame.
Here’s what emerges from the first premise: Only those animations which are substantially changed should be re-drawn, and only those limbs/accessories which are changed should be drawn as components. Thus, the run cycle will be drawn once for each chapter, since this is the animation that will change the most. As for all of the other animations, all of these will be drawn without the left arm, and the left arm will be changed as necessary so I can swap it between chapters. The same goes for any other design changes: They will be omitted and then composited in.
Here’s what emerges from the second premise, though I’d imagine that this is fairly obvious to most animators: Keyframing. This is a concept I’ve used a lot, naturally, coming up with the prototype animations, but there’s no reason not to use it again in a different way. Basically, instead of hand-drawing all of these (ugh), I will draw a selection of the most distinctive frames. Once they’re complete, I’ll bring them in Photoshop for the coloring and polishing phase, and using Photoshop I’ll edit the keyframes into the appropriate tween frames until the motion is smooth. There are a number of huge advantages to this: Not only do I have to draw maybe a third of the frames I would have to otherwise, but I should find it easier to create a smooth motion in spite of any weaknesses in my drawing skill, and I can easily add new tween frames to smooth any motions that still need work.
So, with all that being said, it’s still going to be a while before I end up tackling all of these animations, since I want to test all of the prototype frames extensively to make sure they work before I start creating the considerably-more-difficult-to-fix hand-drawn frames. Still, it’s a tremendous relief knowing I have a game-plan for how to approach solving that problem when I get to it.
For this coming week, I think I should work on really nailing down all of the prototype animations. This means A) Creating the air attack animation, B) Re-tooling the jump animation so where the character is going to land is more obvious, and C) Reviewing all animations to see if any need improvements before being drawn out. Also, possibly, D) picking out those frames suitable for being keyframes when it comes time to draw all this stuff out.
Sorry that this week’s update is kind of late, and sorry if it’s kind of disjointed. I’m a bit out of sorts at the moment, due to reasons. Thanks!
There’s a small concept I’d been kicking around in my head for a few months about “XP orbs” flocking to you after a victory, and it also has to do with tweaking the mechanic from “receiving” to more of a “collecting”:
So as you mow down enemy upon enemy, you build up some score that grows exponentially, represented by the floating orbs. At any point during combat, you can BANK those orbs and reset the score multiplier. Or you could continue your combo and risk losing everything if you get hurt or otherwise break your combo.
I thought it’d be a nice way to break away from the standard XP orb trope and add some risk/reward.
Reminds me in turn of another game concept I was working on at one point, experimenting with variants on the classic Snake game that comes on cell phones and whatnot, called Ouroburos. When the player failed and inevitably, eventually, self-collided, the snake would consume itself, back to front, and the player would be scored based on the total size of the loop. Thus, keeping the snake going for as long as possible would be important, but not nearly as important as ensuring that when the snake consumed itself it did so as close to the tail as possible.