Devlog 06 - Animations and Streamlining

I started this build playing with my players animations, as that's one of my primary goals for this build cycle. There is a total of 11 "non-unique" animations that need to be created (i.e: animations that aren't derivatives of another state, such as running and running while shooting), but on that subject, shooting happened to be one of those animations.

This one was a bit tough to get the right feel for, and I'm not even quite sure it worked out how I wanted it to. I wanted her legs to sort of bend a little, like the recoil of the gun was somewhat affecting her. However, I originally made this too strong to the point that she was basically kneeling on the ground. This made her look very novice and untrained, but with the fact that I wanted to implement stuff like pogos from shooting downwards in the air, this didn't make a whole lot of sense.

On the flipside, I didn't want the gun to feel like it had zero impact on her, and so making her legs bend in just the right way proved to be a delicate balance.

I think I may have still pushed them too far backwards even after toning it down, but as I've said many times, these animations aren't final, but more to gain a feel of what the final ones *may* look like with more polish.

Once that was done, I shifted gears and tackled an issue I've been wanting to deal with for a long time.

One of the big things about Unity (and most game engines) is the concept of prefabs, which is basically a factory "copy" of an object that can be used to insert more copies in any scene. This saves time having to duplicate 10 different enemies and move them around, for instance, but rather instead you can just drag them into your scene pretty easily. It can also be helpful for placing objects in other scenes, when duplication is impossible.

A big issue, though, is that some objects can't really be made into prefabs (doing so generally also removes references to specific components, and need a lot of work to be set up properly), or are important game management objects that you don't want to waste time putting into every single scene.

Digging around, I came across on a few occasions unity devs talking about a process called "additive scene loading". In essence, rather than have a bunch of prefabs that you place whenever you want to start a new level/scene, you instead load one scene that acts as your level with things like enemies and environmental props, and then load another on top of it that contains things like your player, important game elements, UI, and such.

Then, when you want to load a new scene, you simply keep the scene with all the important bits loaded and just load the new level overtop of it, or just unload the bits for things like the main menu where you don't want the player or UI elements around.

To sort of drive the point I'm getting at home, in less than 10 minutes of actual coding, I now have a way to create new levels and sub-areas, and I can even further expand upon this whole concept.

I then tweaked the dodge a bit so that it resets your fall speed when you use it, but I forgot to reset the actual gravity strength as well to go with it, so if you dodge during a fastfall, you will then fall with the fastfall speed, which doesn't end up feeling good.

I made that modification, fixing a bug in the process where you can retain her dodge speed after dodging, which would be a potentially cool addition for a slide if it wasn't buggy.

During this time, I took some time up at my family's cottage. There, I got some new ideas, as well as made headway into a jump animation, completing the rising part of it (which I previously tested chatacters jump heights to find how many frames it took to reach the apex. This knowledge allowed me to design this animation so it smoothly transitions into a falling animation no matter if it's the lightest jump or a full press on the button.

A few days later, I finished a "falling transition" animation, which as written, acts as a transition between the apex of the jump and the falling animation that would eventually loop. I also started on the actual fall animation, and while I'm not completely satisfied with it, it does it's job pretty well.

I also started on a falling transition, but was kind of getting burnt out of just animating, and so I took another crack at music. After many hours of learning the program and making do with the limited set of instuments I had, I created a track for the game, titled "Haunted Daydream". Whether or not this track will end up in the final game remains to be seen, but it was a good enough break.

I finished the jump on top of a dodge animation, and also worked on implementing a charge shot. As well, I started thinking about a new system currently titled "Flower Power".

Essentially, one of the problems I'm thinking about with my game is how to add an incentive to not mash shoot 24/7 without it devolving to waiting, because I could add something like a bar that charges when you don't shoot, but that then devolves the gameplay down to "wait for the bar, attack, repeat" and that's not fun.

What I settled on was a decision to reward accuracy. In essence, every time a shot lands against an enemy, a gauge builds up (likely represented by flower petals), while misses decrease it. At max charge, the player gets a free powerful attack, and then the gauge resets. This rewards more skilled players without punishing the skill floor in any real way. This will likely come in once I start implementing the animations.

The other thing I want to do is rework the dodge a little bit. Recently, I was playing Smash Ultimate and started seeing similarities between Yuni and the Smash rendition of Joker. I especially like the idea of the gun dash, and I may want to lift that.

My plan is to allow players to dash forwards or backwards after shooting, at a distance that will be move you faster than stopping, walking forwards, and firing again, but slower than just walking (as not to act as a complete substitute for it)

I feel that this will make shooting more of a decision and de-incentivize just spamming your shots.

While considering these ideas, I did make one other major decision that would have a huge impact on the project's development. Up to this point, I had been working around a lack of an internet connection through various hacky methods. This worked fine to a certain extent, but some very major issues were starting to crop up that I had to have a connection for. And so, I bought an adapter.

This allows me to do many, many things, including streamlining a lot of processes that used to take ages, but one of the major ones was the ability to finally have a proper music library, and what better way to test it out than to redo your old track.

The track utilized a lot of instuments I didn't have access to before, including things like a violin, music box, and some really cool synths. This one will be in at least the beta for the game. There's a chance that I'll remaster it way down the line, but as of this moment, it's a part of the soundtrack.

Also, while the two renditions are very different, the original gave me a lot of ideas for the remake of it. Furthermore, I've been considering leaving the beta version in the game as well, though any "museum" is a project for another time.

I finished with the animations and began work on implementation. Most of it went fairly smoothly, but the shooting in particular proved difficult.

The reasoning for this was due to the fact that, up to this point, it was just "click to shoot" with the only restriction being whether it was on a cooldown. Now that it was animation based, however, there were far more restrictions, on top of the fact that I was changing a lot fundamentally about how shooting worked.

Additionally, having a muzzle flash animation proved more of something that I had to navigate around than I anticipated. That being said, I did eventually get it working well.

So, thoughts on this build:

-I wish I hadn't spent so long making animations. I could've easily done that in a month or so.

-Most of my progress outside animations stemmed from streamlining the development process (proper music program, internet connection, learning better methods)

-I can now start to work on the more fun stuff, and I'm hopeful I can get a lot done in the next few weeks/(hopefully not) months