next »

[AnomalousUnderdog]

You guys are probably sick of seeing posts of these animations (I am kind of getting tired of making warhammer animations myself), but I want to get this working at least passably before I move on to the next task.

This is, for the moment, the finished 2-hit combo for the warhammer (standard attack).





For its standard attacks, I needed wide arcs that hit multiple enemies coming from different sides, because this weapon is meant to give you a bit of breathing room if you're surrounded. So I made simple horizontal swings. This is really a gameplay need, more than anything else.

I've been basing the timing from warhammer attack animations in Fable 3 and Bloodborne.

I've made all the necessary warhammer attacks for now. I'll add them in-game and just tweak afterwards as necessary.

Here's the version where he only attacks once:

[AnomalousUnderdog]

Added warhammer attack animations for testing.

The enemy's hurt/death animation when getting hit by the warhammer is incorrect, I will perhaps make some new hurt/death animations for this.

Also, the pound attack at the end of the video is supposed to add flame particle effects on the weapon since it's a charged attack, but I haven't added it in yet.

_______________

One thing I like about Blender is just how customizable it is. Here's some add‑ons that I made that made my life easier when I’m making animations. I released all of them in MIT License so feel free to make use of them if any of you use Blender!

[AnomalousUnderdog]

Here I have a two-hit combo, but the second attack doesn’t transition back to the first attack smoothly. This was already using cross-fade in Unity, so a manual tweak to the animation is necessary.

I created a variation of the first attack animation, this time it flows from the second attack much better. This variation is then used if coming from the second attack.

In the Attack Editor, this is a new animation property I call "Wrap-around". It should work even for combos that have more than two attacks in it. But it’s really only needed if the last attack animation in the combo doesn’t transition back to the beginning attack nicely.

______________________

Fast movements cause the cape to get stuck inside the character’s colliders. So I added a Boolean (on/off) property to Attack files that would forcibly reset the cape’s cloth simulation to its initial state when that Attack is performed. It’s not perfect, there’s still some unpleasant looking sharp bends where polygons look like they’re being crumpled (I think to really fix that, I need to redo the weight painting for the cape’s cloth simulation), but it’s better than before.

Also shown here is the Warhammer pound combo. I still need to add some appropriate visual effects for this, like maybe some fire or clouds of dust rising up.

[AnomalousUnderdog]

Got a visual effect for the Warhammer's charging loop. It's still lacking the visual effects on impact, and I'll probably tweak the colors, but I'm happy with how it looks like so far.

I activated the Rapier's charged attack in the video for comparison.

Also shown here: I’ve moved the player’s health and stamina bar from the top-left to the bottom of the screen. I’m experimenting with this since having to dart your eyes to the top-left is a little annoying; it takes your gaze out of the action for a moment. This is important when you're fighting: you wouldn't want to get hit while your focus was somewhere else.

I'm not definitely sure if moving it to the bottom is going to be better overall, so that's why I'll test it. I’ll leave it like this for the next Demo Day to gather feedback.

[AnomalousUnderdog]

Finally added a nice looking impact visual effect for the Warhammer's charged attack. Also got an appropriate swoosh trail for this (kinda plain looking but at least it fits).

I might try experimenting with some camera shake as additional juice for this, but I’ll leave it for now and move on to other tasks.





To be able to play those impact particle effects in the first place, I actually needed to add new properties to attacks: the ability to spawn prefabs from any moment in the attack animation. I also added in the attack editor some tools to let you position the prefab from the weapon's position, or from the character's pivot point.

Technically you could put any prefab, but as seen here, I made it for spawning particle effects. I’ll probably have more creative uses for it later.

I also added the ability to specify what kind of swoosh trail effect to play for each attack, as these pound attacks needed a different kind (that thicker bluish trail upon the swing). And I needed to be able to force attacks to play the weapon's fire particle effects in the 2nd and 3rd pounds of the combo.

I suspect I'll need to change the UI/UX of the Attack Editor now that I've been adding more and more features to it. Probably in a succeeding milestone.

[AnomalousUnderdog]

Implemented the new hit effect type Knockdown, specifically made for the Warhammer charged attack. Testing it with a non-hostile AI.

Damage values still need to be tweaked. Placement of blood hit effects need adjusting. Also, the enemy’s cloth simulation is passing through the ground since it was never meant to collide with that. I’ll need to figure out a way for that.






Implemented the Rapier’s parry ability. The first two attacks in the Rapier combo always parries. I’ve had to do multiple takes on recording this one cause I keep messing up the timing while keeping track of the screen recording software.




A little productivity tool improvement here: I added copy-paste of hit detectors. After meticulously positioning a box to fit the weapon, I don’t want to have to redo that for the next attacks, so I made code to just copy the values and I can paste it somewhere else, even on a different attack file.

I did it the same way copy-paste of components in Unity work here: you can paste onto an existing item, meaning it will just copy the values used, or you can paste it as an entirely new item added at the end of the list.

____________

I was converting my repo to use Git Large File Storage. In the end I decided not to use it. I’ve already successfully created a duplicate of my repo that uses LFS, but as I was learning it, I realized it makes the repo centralized (you’re now very dependent on the remote server that is hosting the large files). That made it really important where you choose to host your LFS.

I was using BitBucket so it was natural to go with it. I only get 1 GB of space for LFS files in my free user account. To increase this, it comes at a price of $10 per additional 100 GB used.



GitHub is a little more granular: $5 will give 50 GB.



Obviously, my project won’t ft the 1 GB limit for free users, so I’d have to purchase something here, whether I go with BitBucket or GitHub. I’d really rather not spend money on a project this early. This endeavor isn’t paying for itself yet right now, so I’m reluctant. I’m already spending about $10/month for Photoshop CC. I don’t want to add more to that.

As it is, I’m more willing to dump my raw binary files to my Google Drive (got 117 GB of space there for free), even if it’s not under version control.

I’ll just continue using removable drives as backup remote repositories.

[AnomalousUnderdog]

Thanks to Demo Day 16, an Anonymous from /agdg/ suggested me something that is probably going to make the attack input better. Right now, attacks trigger on button release, not on button press. I do that so that I can recognize holding the button long enough for charged attacks.



The suggestion was to immediately trigger attacks on button press instead, and if the button is still being held long enough, blend it into the charging animation for charged attacks.



I tried it out and while I still have some bugs with my implementation of it, it does make attack input faster.

The problem is that it changes the way you do charged attacks. This new style means if you want to do a charged attack, you'll have to do a regular attack first, so you'll have to consume stamina for the regular attack, on top of the stamina cost for the charged attack.

Some attacks also have a very different pose from the charging animation, so blending them looked awkward. I decided I needed to make alternative charging animation poses, depending on which attack you came from.


Current Attack Input

Pros	Cons
1. It already works 2. If you do a charged attack, you only consume stamina for the charged attack.	1. Input delay when attacking

New Attack Input

Pros	Cons
1. No input delay when attacking	1. To do a charged attack, you do a regular attack first (you consume stamina for the regular attack on top of the stamina cost for the charged attack). 2. Still some bugs I'm fixing. Right now it's inconsistent when exactly the attack animation is blended into a charge animation. 3. More animation work for me due to needing to create alternative charging animations.

Despite all the cons, this new attack input method is very promising, because the attack buttons feel a little more responsive now. I will try to work on it more next weekend to fix the bugs.

[AnomalousUnderdog]

I fixed the bugs with the new attack input system. Charge animations now fade in at a consistent manner, and the character no longer gets stuck in the charge animation if the user button-mashed the attack buttons.



What I did was put all charge animations on a new layer on top of the base layer. When an attack animation is played, the charge animation for it is also played at the same time so they are synchronized. But even though the charge animation is played, it won’t really be seen yet (weight of Charging Layer is set to 0 at the start).

When a charge is requested (user held the attack button long enough), the only thing that’s really done is just smoothly move the Charging Layer’s weight towards 1.0 to effectively blend in the charge animation that was already being played.

This is kind of similar to a blend tree, but I want to play the charge animation regardless of what state the base layer is currently in.

I also fixed the bug when the player gets hit and can’t move for a while even though the hurt animation has finished already.

[AnomalousUnderdog]

Testing out the in-progress spear impale attack. You impale enemies with your spear, plant the spear on the ground, then conjure another spear for yourself.

It’s missing some visual effects, I’ll need to fix that awkward choppy animation, and the behaviour isn’t fully implemented yet (impaled enemies can’t get free yet).

The idea here is that this will temporarily put impaled enemies out of the fight. They’ll be able to break the spear once their stamina is full, so you’ll want to tire them out first before attempting to impale. That way, they'll be out of the fight as long as possible (their stamina regain will be slower while impaled).

You can continue to hit them while impaled, but this will also damage the impaling spear. If the impaling spear breaks due to your own attacks, the enemy will get free immediately.

So this is a question of whether you use the impale attack defensively or aggressively: you can impale some annoying ranged attackers, then leave them alone while you deal with other enemies (this will keep the impaled enemies disabled long enough for you to finish your other fight before going back to them), or you can impale the enemy you’re fighting in front of you to interrupt their attacks and hit them more while they’re helpless.

Naturally, not all enemies can be impaled like shown in the video, and I’ll probably make it that you can only impale maybe 2 or 3 max at any given moment, and maybe have upgrades to increase that limit.

[AnomalousUnderdog]

Working on particle effects for the Spear Impale, testing it on a non-hostile enemy. There’s a few more things I want to add here: an appropriate hurt animation when the enemy gets impaled (it doesn’t have any right now), dripping blood on enemy while impaled, some more effects when the spear is planted on the ground, and some effects when an impaling spear shatters.

_________

I fixed the odd framerate hiccup when you impale an enemy (you could see that in the video of my previous post). Surprisingly it had nothing to do with the impale code. I thought my act of parenting a whole enemy into a weapon was causing a slowdown. But it was actually Unity loading things needed for the hit particle effects (the shaders and textures they use).





I was already preloading the hit particle effects by manually placing them on the scene so they’d get loaded, when the scene gets loaded. But turns out that stopped working as intended.

At one point, I placed them deep below the ground (50 meters below) so they wouldn’t be seen when the game starts. Because that would have looked weird, the player seeing some hit effects at the start of the game. But I guess placing them far away made Unity decide not to load them at all.

So the fix was, I moved them closer (2 meters below the ground). Seems that was enough, since doing that got rid of the framerate hiccups.

[Pixel Noise]

Just found this and skimmed through - love what you're doing! I don't mean to oversimplify, but are you sort of combining Souls-esque combat with Persona-esque life-sim management? That was my first impression, from the front page. I hope that's not insulting - those are my two favorite IPs, so I'm all for it!

[AnomalousUnderdog]

Just found this and skimmed through - love what you're doing! I don't mean to oversimplify, but are you sort of combining Souls-esque combat with Persona-esque life-sim management? That was my first impression, from the front page. I hope that's not insulting - those are my two favorite IPs, so I'm all for it!

You basically hit the nail on the head there: Persona with Dark Souls combat certainly is the idea. At least, that's the direction I'm taking it initially. The game's still shaping up so I can't say if that's how the final game will play out. I'm still working on the combat system, so it'll be a long while before I can experiment with the "persona" part of the game.

I had been wondering if people would be receptive with combining those two games, since I'm worried that action game players might feel alienated with the idea of having to play a life sim part, and same with people who play persona games. Good to see you like the idea at least.

Thanks for the reply! I was having a feeling nobody's been reading this thread lately!

[Ashedragon]

Fear not, I'm always reading! I just don't have a lot to say.

[AnomalousUnderdog]

Fear not, I'm always reading! I just don't have a lot to say.

  Hahaha! Thank you!

[AnomalousUnderdog]

Fully implemented the spear impale behaviour: enemies break free once their stamina is full, but the spear will break earlier if you attack the impaled enemy too much. While impaled, the enemy’s stamina regain is slower by half.

I also added more particle effects and blue light on the impaling spear itself.






I decided it'd be better if I add blue light on charging attacks as well.

[Valar05]

Always love seeing stuff from your game- the style is just fantastic!  I remember seeing a gif up on reddit like a year ago, didn't realize you were here too.  I'm a sucker for soulslikes, so anything that resembles one gets my approval.

It's also cool to see another solo developer going the 3D/PBR route.  Most indie games you see are pixel art- makes me feel like doing it wrong by going any other route. 

[AnomalousUnderdog]

Always love seeing stuff from your game- the style is just fantastic!  I remember seeing a gif up on reddit like a year ago, didn't realize you were here too.  I'm a sucker for soulslikes, so anything that resembles one gets my approval.

It's also cool to see another solo developer going the 3D/PBR route.  Most indie games you see are pixel art- makes me feel like doing it wrong by going any other route. 

Thanks! Before I started this I actually had been thinking of whether I make the game 2d or 3d, action game or turn-based. If it was 2d, I would have done it Vanillaware style (Odin Sphere, Muramasa, Dragon's Crown), but realizing the amount of art work that would require, I went with 3d. Especially since I've had prior experience with doing 3d and 3d animation. I went with 3d simply because I'm already used to it.

I don't have anything against pixel art style, I have a handful of pixel art games I love (Hyper Light Drifter, Dungeon of the Endless, Sword and Sworcery, etc) but I really just don't see myself doing games in that style.

There was no conscious decision to go PBR. I only had that because that's what Unity gives you by default nowadays. If Unity didn't, I would have had no problem sticking to non-PBR graphics.

[Valar05]

Thanks! Before I started this I actually had been thinking of whether I make the game 2d or 3d, action game or turn-based. If it was 2d, I would have done it Vanillaware style (Odin Sphere, Muramasa, Dragon's Crown), but realizing the amount of art work that would require, I went with 3d.

I kind of started out going this route, using 2D bone rigs to get those smooth rotations, but yeah I found out that you had to do a lot more drawing than it initially seemed in order to get things to look fluid - different parts from different views, etc.  Just having a 3D skeleton you can pose any way you want just feels so much more intuitive - even if you may have to do more work to get to that point.

There was no conscious decision to go PBR. I only had that because that's what Unity gives you by default nowadays. If Unity didn't, I would have had no problem sticking to non-PBR graphics.

This is something I still kind of struggle with.  I love cel shading - it's easy to make just a flat diffuse map for a character and the only hard part is picking a nice color palette.  I enjoy both the look and the simplicity - and like pixel art it also kind of "indie-izes" your game, making it clear you're not trying to compete with the graphics of the next AAA dude-bro shooter.  I kind of ran into a wall when it came to making environment textures that match the cel shaded look though - they seemed to require hand-painting, which I am terrible at (and I have so many other things to do I don't want to learn).  Enter Substance Designer with its PBR workflow- I found it reasonably straightforward to make environment and character textures that look like they mostly belong in the same game.  I enjoy SD's node wrangling way more than painting- but I do still miss the cel shaded look.

That's all about me though- I think your textures rock!

[AnomalousUnderdog]

Spent the day fixing some animations. As I realized, lot of my animations end up a little distorted. I suspect it’s my asinine way of setting up the rig in Blender (I use Rigify but I ended up editing it a bit, but I can’t remember why) and how I set it up for Mecanim.

I was always annoyed that the character wasn’t holding the warhammer properly when I do the charged attack. It’s as if the warhammer was moved up, outside his grip. When I checked it in Blender, he was holding it properly, so I suspect there was something wrong with the way I set it up for Mecanim.



They way I set up my animations, I separated them into many .blend files, because import time when I change an animation is so slow in Unity. It gets even slower the more animation clips are inside one .blend file. Which is why I ended up separating them in the first place.



I ended up with the habit of separating them per weapon, and per groups of related animations, so rapier attack animations are in one file, rapier movement animations are in another, spear attack animations in another, etc.

The trouble was getting them all to work the same way. Like in the image below:  left is the 3d model I use for the game, right is from the .blend file of the warhammer attack animations.



Somehow, the animations weren’t getting retargeted properly. I ended up copying avatar definitions from the warhammer attack animations, and that fixed it.





It’s weird though, their rigs are set up the exact same way (they all started as copies of the same file) so there shouldn’t have been a problem in the first place.

___________________

For the forearm, I had to edit some animations because for some reason, Unity is showing them with some really weird rotations.





Left side is in Unity, right side is how it is in Blender. Notice the cowter (elbow armor) pointing the wrong way in Unity.

Again, I suspect I set up the rig wrong somehow. Then again, I may be positioning the arm too awkwardly and Unity’s way of doing wrist rotation is having a hard time keeping up? I don’t know, but if I relax the arm’s pose a little bit, the effect is lessened.

[AnomalousUnderdog]

Testing torso leaning up or down. I will be using this for the times when the enemy you targeted is either above or below you.

Right now if you play my latest demo day build, your attacks simply won’t hit if your targeted enemy was somehow crouching down (the enemy’s third attack ends up doing this), even if you were standing right in front of them. The arc of your rapier’s slashes simply doesn’t reach them.

So I experimented with adding torso leaning via code (and yes, it does indeed give you the reach to hit crouched enemies).

It works surprisingly well as the added lean angle is applied regardless of what animation the player is doing. It works while you’re moving, and even while doing a charged attack.

I just need to give it sensible upper and lower limits to prevent the torso from rotating too much (as you can see in the video!).

I’m surprised at how easy it is to add. The bulk of it is really just calls to Transform.RotateAround on the bones you want affected by the leaning motion.

In Unity, character bones become empty GameObjects with Transforms that can be manipulated. And the nice thing is that if you move the Transform of those bones in code, the character mesh will follow.

As long as you do so in LateUpdate, it will work. This is because character animation is applied after Update. If you had moved the bones in Update, their values would just get overwritten by the animation being played.

(this is from the Execution Order page in the manual)



Update is executed first, then animation is applied on the bones, and LateUpdate is executed last (you can ignore those “yield” statements in the middle for what I’m discussing here).

This means LateUpdate is the perfect place to apply added motions on top of character animations.

As for the code, a simple call to Transform.RotateAround on the bone's Transform does the trick:



point is where the rotation will start from. For this, I use the position of the character’s pelvis.

axis is what direction the rotation will revolve around. Imagine it being a can of Pringles, and how the can would roll around will be the direction of your rotation. Since I needed the torso to lean downwards or upwards (and not sideways, or a twisting motion), I use a can of Pringles that’s laid out horizontally to the character. In code, this is easy: I just use the direction pointing to the character’s right (Transform.right).

angle is, obviously, by how much to rotate the bone’s Transform. This value is in degrees, so it’s easy to visualize.



In addition, I don’t rotate just one bone, I rotate the whole spine, but each bone gets bent lesser and lesser as you go up the spine, giving the whole thing a more natural looking bend.

I added an additional “percent” property for each bone to specify how much lesser it gets bent. And when each bone is rotated, the angle it uses is the lean angle, but multiplied by its percent property.

Essentially, I’m controlling the influence of the leaning motion for each bone.

To help explain, here’s a simple demo of it using spheres parented to each other.