next »

[AnomalousUnderdog]

Started working on the actual AI to be used for the Wooden Mannequin enemy. Shown here also is how the AI can be adjusted in the middle of the game for experimenting. I plan to add more attack animations for this enemy later.

I also still need to give it defensive moves (dodging player's attacks).

This is how the AI looks like now (click for full image):



I’ve also improved the AI editor a bit: collapsed nodes (like the “Find Target” in the image) will stay collapsed even after closing the editor (used to be, it all resets once I re-open the AI file). I’m using this to make the tree a little bit more readable by minimizing details I don’t need to see.

[AnomalousUnderdog]

So I had feedback that the dash particle effects were obscuring the vision too much and gets in the way of fights.

There was also feedback that it was weird that there’s lack of visual effects with him floating.

Which I all agree to, so I took time to change it. I added some blue fire effects on the feet (even when you’re not doing a dash). And I now keep the effects for dash close to the ground, so it wouldn't obscure your vision of enemies.

Do you guys like this better? Or is this even more distracting than before?





Here's the old dash particle effects for reference:





______

The trail module in the particle system is actually pretty nice. I ended up with this when I was experimenting. Will probably use this for something else. Perhaps an enemy’s spell, or just some effects in the place instead of on a character.

[AnomalousUnderdog]

New playable demo for my game is out! Please try it out and leave feedback.

https://anomalousunderdog.itch.io/ghost-knight-victis-agdg-demo-day-14

(Linux and Mac builds to follow)



Changes (since last AGDG Demo Day release):

1. Added graphics options to change screen resolution, and toggle various effects.
2. Added "swoosh" trails on normal weapon attacks. This is to help the player see the arc of the motion of weapon slashes, useful since the game is mostly in the dark.
3. Smoothened the camera tracking on targets. Previous behaviour was a little too dizzying since it made the camera move too fast.
4. Added health and stamina bar overlays on enemies.
5. Started improving the combat AI for the Wooden Mannequin enemy.
6. Changed look of Phase Dash. Previous one was obscuring your vision of enemies during fights.

Notes:

1. You can't restart the game yet. If you die, close the game then run again.
2. There's nothing much to do yet except kill the enemies. This is only a test for the combat part.
3. Can't customize key bindings yet.
4. There are no sounds yet.
5. The difficulty right now is not yet representative of the final goal. Enemy AI is still too simple, and no tweaks/balancing for damage and stamina cost yet.

[AnomalousUnderdog]

Enemies now have a resistance to flinching.

The rapier no longer immediately flinches the enemy, making it less useful (and giving it a sort of equal value to the spear). Instead, it will take a few rapier attacks in succession until the enemy will finally flinch (or you could attack with the spear, which will immediately flinch the enemy on hit).

Enemies now have a sort of “resistance meter” to flinch, which drains when getting hit with attacks specifically meant to build up to a flinch (i.e. the rapier attacks). This resistance meter naturally restores slowly over time (similar to the stamina).

Also not noticeable here, but I’ve integrated PoolManager (got it before when it was on sale), a pooling system, making the game run faster as resources like blood hit particle effects, and health bar displays are recycled as needed. This is my first step to make the “restart after game over” feature working properly.

_____________________

I recently needed to update because my game was getting compile errors when trying to build to Mac OS X. So I updated my project to Unity 5.6.0f3, but as I was testing it a few times, this happened. There’s these strange boxes on some characters in my TextMesh Pro labels.



Actually, at first, none of the labels in the dropdown box were appearing at all, because of a bug with Unity UI (RectTransforms getting NaN values). I updated to Unity 5.6.0p4, which fixed it, but I got those boxes.

I found out recently there’s actually a 5.6.1f1, so I’ll download that and try it too. But for now, I reverted to using 5.5.2f1.

It’s easy to blame Unity and say this is why it’s better to make your own engine but, to be honest, it’s not as if I can make a bug-free engine in comparison. So I’ll just wait until the new versions get more stable before I update again.

[xix]

This project looks amazing!

[AnomalousUnderdog]

So I got player respawning to work. I'm still not sure how the Game Over screen should look like, other than I want it to be fast, so no drawn out animations. Because I want to let the player get back in the game as fast as possible.

I'm considering adding a heartrate monitor flatlining sound with some accompanying animation (like the game over screens in the Metroid Prime games, as some people have suggested), provided I can make the whole thing fast and snappy enough.

@xix: Thanks!

[AnomalousUnderdog]

Based on the suggestion of a fellow developer, I’ve allowed the player to rotate in-between attacks (while not targeting an enemy).

I've also fixed a bug with enemies constantly facing the player even while the enemy is attacking (they shouldn’t). Where the character is facing (their rotation) should essentially be locked once they start an attack animation.

[AnomalousUnderdog]

New features on my Attack Editor: instead of hit detection coming from the weapon as a raycast/spherecast, you can now choose to use capsule, sphere, and box shapes. This can also be mixed and matched as needed (various different attacks would use different shapes).

The shape can be attached from the character's root (between their feet), or from the weapon they are dealing damage from. And various other options for positioning and rotating the shape.

The reason I made this is because the player later on will have an attack where he pounds the ground with his warhammer, creating a circular AOE attack that knocks back enemies.

[mirrorfish]

This is looking really cool dude. I like the trail particle dash but also kind of like how big and over-the-top the original is. One way to address the visibility issue would just be to make them persist for less long, or you could do some kind of custom shader to see enemies through the trails. Anyway nice work.

[AnomalousUnderdog]

Added ability for enemy AI to cancel their attacks, letting them execute their combos faster.

Also being shown here is the real-time AI editor.

This is looking really cool dude. I like the trail particle dash but also kind of like how big and over-the-top the original is. One way to address the visibility issue would just be to make them persist for less long, or you could do some kind of custom shader to see enemies through the trails. Anyway nice work.

Thanks! I will be experimenting more on the dash visual effects in the future (showing an afterimage of yourself upon dashing, making you transparent while in dash, etc.)

[Ashedragon]

So good! It is rather exciting to watch as it progresses.

[AnomalousUnderdog]

Originally, the thumbnails in my Attack Editor were actual 3d models in the scene, resulting in some dead weight during runtime. In deployed builds, this isn’t really a problem since the Attack Editor won’t be there in the first place. But when I’m testing the game in the Unity Editor, they’re there.

So I created some editor scripts to generate a spritesheet for any animation needed to be displayed on any character. They are saved on disk, so that they aren’t generated over and over.

It’s then the spritesheet that’s being used, instead of a 3d model being rendered in the GUI.





At first I was using a C# script to play back the animation of the spritesheets. When more than one of them was playing, it really lagged.

So I took this one step further and created a shader that does the same job. Since it’s now offloaded to the videocard, the CPU load is now really low, even when a lot of these animated sprites are being drawn.

I don’t know if it ends up distracting that the thumbnails are all playing at the same time. I’ll probably add a setting later on that users can toggle so that only the thumbnail hovered by the mouse will be played (like the original functionality).

[AnomalousUnderdog]

This weekend was also bugfixing weekend so a lot of bugs were worked on. Like this one:




I’m surprised no one who played my demo day builds have noticed it.




@Ashedragon: Thanks!

[AnomalousUnderdog]

I added the ability for enemy AI to dodge the player’s attacks, and they’re more competent now, even when taken on one-by-one. I tried taking on three at a time here, just to see how it is. You can see in the lower-right how frantically I’m pressing the buttons.





And with that, I think I'm done with refining the combat system for now. I switched to my artist hat and finally started working on the player's third basic weapon: the two-handed Warhammer. Here are some studies I made.



Eventually I settled on the ball-pein type. Having the usual claw as the other end of the warhammer is something I plan as an upgrade later on. The claw would allow either tripping or pulling in an enemy.

It has to Not Look Too Awesome Yet™ since it’s a starting weapon.

This weapon’s special property will be knock-back (attacks push enemies back to create space for you if you are overwhelmed). Meanwhile, the Rapier will allow you to parry (time your attack at the right moment and the enemy’s attack will be disrupted and allow you an easy counterattack), and the Spear will impale (impaled enemies are helpless while you duke out combos to it).

Here are some thumbnail sketches for the attack animations.

[AnomalousUnderdog]

Finished making the 3d model of the warhammer.





After getting feedback from yonder esteemed /agdg/, an anon was kind enough to provide a video demonstration of how a sledgehammer would be used in real life. Since I’m really just winging it in terms of the animations here, I was happy to check it out.

Out of all the lively and colorful replies I got, there were two opposing schools of thought:

• the video game style animation where it should be exaggerated with significant windup & follow-through, and the idle pose should look cool
• the realistic style where movement should be conservative, attacks should not overswing to prevent making yourself open to counterattacks (very HEMA), and letting gravity help with moving the (heavy) weapon when swinging

In the video above, the right stance is how I initially animated him, as it’s typical of what I see in other videogames. The stance on the left however, is how this warhammer might be held in real life: close to your chest (your center of balance), so you can move around easier.

Also in the left stance, the weight of the warhammer is distributed to both hands (very clever, even though someone called it a ridiculous “big lollipop pose”), while in the videogame stance, the right hand is shouldering majority of the weapon’s weight (it looks cool though).

In a real life context, how the weapon is carried is important since it will be held in your hands for an extended period of time, and you don’t want to tire yourself out before even getting to the fight. Remember that the head of the warhammer is a solid hunk of metal, so it is very heavy. But I fully acknowledge that as a videogame, this issue isn’t that important.

However, all things considered, I’m pretty open to experimentation. So my current plan is: the first 1 or 2 attacks in the warhammer combo will be more on the realistic side with conservative movements. The final attack in the combo will then do an exaggerated wide-sweeping swing. Hits on the warhammer will send enemies flying, if not push them back significantly, so that should help address the concern with leaving yourself open after overswinging.

In defense of wide-sweeping strikes that leave you open, I’ll let Alan from Sword’s Path explain it:

You can say that wide strikes provide a lot of openings for you to counterstrike. That’s true, but believe me, it’s easy to talk about openings and counterstrikes when there’s nobody charging at you, screaming like a wild animal.

…remember: seeing an opening is one thing - exploiting it is another.

From a gameplay perspective, it makes sense to purposefully make the player open to counterattacks, because it gives computer-controlled enemies a fighting chance. A game where the player’s moves are always perfect would make the combat system too easy and boring. But leaving you open after attacking will make it a fair challenge, especially since enemies are subject to the same rules (their attacks leave them open as well).

Also, as a last point, the realistic way of fighting applies very well with human, armed opponents. Against gigantic monsters (which I’ll certainly include in my game), the attack motions that are seen as overkill and needlessly exaggerated by HEMA practicioners might just be bare minimum when fighting monstrosities.

[AnomalousUnderdog]

First attempt at the warhammer attack animation. As mentioned in an earlier post, this is following the more realistic style, where movement is conservative.

The weapon is held this way so that the weight of the warhammer is distributed to both hands.

There’s no windup in the start of the attack animation because what’s really happening here is he’s letting the weapon fall down using gravity (this is a solid hunk of metal after all; very heavy, you can let gravity do some of the work for you), and then directing that momentum into a swing.

The swing produces forward momentum, so to keep up, he steps forward to maintain balance (although since he’s floating, he more of just raises his right leg). I’m making the animation in-place, so the forward step isn’t discernible here (I add the forward movement later inside Unity using my Attack Editor).

Once the swing reaches down in front of him, he stops the weapon, and brings it back to the original stance. This is to prevent from overswinging and leaving himself open to counterattacks.

[AnomalousUnderdog]

Tried my hand at creating a level when I realized I have no idea what I should do. This is the first time in my project that I leaned back and thought, “Wait, how am I supposed to do this?”



A level was not in my milestone target anyway so I won’t work on this yet. For now, I’ll do some self-study on level design, architecture, and urban planning (the game takes place in a modern day city).

[AnomalousUnderdog]

Worked on an experimental 2-swing combo for the warhammer. The idea here is using the momentum gained from the first swing to continue into a second swing.

Heavy weapons like these have their center of gravity (majority of the weight) at the head/tip, requiring considerably more effort to stop or redirect their movement once you get them swinging. Because of this, the way they are used is very different from balanced weapons, like swords (where the center of gravity is closer to the handle, where you grip it).

The windup animation is minimal: instead of exerting effort to move the weapon back for a swing, he simply tips the weapon over to let gravity propel it downward, then guides that that into a swing. With a heavy weapon like this, getting hit even when it’s only propelled by gravity will already hurt a lot.

When that first swing is finished, instead of bringing the weapon back up to a neutral stance for the next swing, he rotates his body to make ready for the second swing (it helps that the character has the supernatural ability to float). That’s because when making the next swing with a heavy weapon like this, it’s lesser effort to move your body around the weapon, than having to move the weapon around your body.

The second swing is more powerful, as it has a full circle spin behind it. But stopping all that momentum equally requires a lot of power. So I emphasized that in the recovery portion of the animation.

For anyone worried that this long recovery period would leave them open, you can cancel this to a lighter attack so you can move sooner (as is typical of some action/fighting games).





Finished adding the idle, move, dash, and hurt animations for the warhammer.

The attack right now is only for testing (because the game will bug out if I don't add at least one). Will work on the warhammer's combo attack animations, tweak damage and pushback values next weekend, among other things.

And with that, the player finally now has three weapons. Technically, this hits my milestone: a combat demo in a closed arena with 1 enemy type, and the player having 3 weapons. But I still have a lot to do before I wrap this up.

He can freely mix the three weapons during combos because it’s part of his magical ability to conjure weapons at will. There’ll be more attacks later on that capitalize this with weapon-based spells (spear walls, flying swords, warhammer tremors, etc.). There will also be more weapons much much later on, for variety (some planned ideas include: bident, basket-hilt sword, falchion, sledgehammer, iron-shod staff, etc.)

[AnomalousUnderdog]

Making the charged ground pound combo for the warhammer. There’s a slight pause at the start because that’s when the warhammer will be engulfed in blue flames before the attack.

This will work if you hold the warhammer attack button long enough for the code to recognize it as a charged attack, and normally it would just be one attack. But I'm going to make it that you can keep pressing the button right after that to continue the pound attack into a combo, up to a 4th very powerful pound.

[AnomalousUnderdog]

Just about recovered from a fever, so momentum slowed down a bit.



Fixed a bug with blur-behind-GUI effect not working if near a bright light source.

Also added a few tweaks like slowed down fading of movement animations if you're rapidly twiddling the left thumbstick, and stopped attack push if your attack hit an enemy.