Combat System, part II

It was certainly a challenge to get the upper body and lower body independence to look believable. But it is mostly working now.

Here is a rather big gif file as demonstration: 

https://gfycat.com/GleamingScratchyLeopardseal for full gif. Warning: Large file.

Here is another view from different angle. Note that the actual hit system is not implemented yet.

Here is a more detailed explanation of the the combat system for those unfamiliar:

Controls: 

• <DIR_KEYS> (WASD) -> movement 
• <ATTACK_KEY> (mouse1) -> attack 
• <GUARD_KEY> (mouse2) -> guard 

Movement: <DIR_KEYS>

• 2 modes: walk and run 
• when walking: unit is facing direction the unit is looking at (eg. camera), moves at slower speed than run 
• when running: unit is facing the direction its moving towards, moves at faster speed than walk 

Guard <GUARD_KEY>

• turns guard on 
• running is disabled/ unit will only walk during guard 
• direction of guard is based on the prev pressed direction key. So for example, <LEFT> + <GUARD> means to enter left-guard, or switch to left-guard from a different guard direction 
• Guard persists even if <GUARD> key is let go 
• Guard is canceled when player double taps a direction key (starting a run) 

Attack <ATTACK_KEY_DOWN>

• prepares an attack, there is a minimal period of time (affected by weapon/stats/skill/perks/etc) before the actual attack swing is released 
• if <ATTACK_KEY> is held down: 
• the attack swing will only initiate when the <ATTACK_KEY> is let go 
• charging longer than the required time will increase the amount of damage dealt, up to a limit 
• if <ATTACK_KEY> is immediate released (eg. a click): 
• the attack swing will immediate commence once the minimal required amount of time has passed 
• direction of attack is inputed in a similar manner as guard 
• an attack can be canceled with the <GUARD_KEY> before it is "released" 
• Running Attacks is possible 

DETAILS

• Blocks are only successful if the direction of block matches the direction of attack. So for example, a <UP_BLOCK> is ineffective against <RIGHT_ATTACK>. 
• Successful blocks are not 100% guaranteed to interrupt/stop the opponent's swing, but will reduce the damage taken. 
• Attacks have cleave by default, the swing is not stopped after hitting the first opponent but will continue on, possibility hitting multiple opponents with every swing 
• No location differentiation (hitting head same as hitting leg)

[Patreon] - v0.51

Patreon LINK.

"Might as well get this out of the way now.

This version fixed all the bugs that are reported so far, if I missed anything, please let me know.

A new feature added is the ability to change the game's speed. Some people felt that the game was too sluggish so now its possible to speed up the game. Up to 200% of the base speed. Default is 120%. (so ~20% faster than previous versions by default)

A few also wanted a hard mode of some sort after beating Story Mode. I tried but the current setup doesn't really allow me to easily add interesting encounters. And at this point I don't want to make major changes to the game.

Besides, since you can play the character in exhibition and team mode the game provides all tools available to create your own challenging encounter. As such, no changes to Story Mode are implemented."

Combat System

Added Inverse Kinematics to engine and implemented enough functionality for independent upper body and lower body movement.

Kind of tired of talking about tech so lets do something different this time.

As mentioned before, the next game will feature weaponry and directional attacks and guards. Eg, 4 attack directions - up/down/left/right and 4 block directions. A block is only successful if the block is in the same direction as the attack.

So here are the 4 blocks for a sword user, can you match them with the guard direction? (up/down/left/right)

Models support

While waiting on the poll result to come in, I implemented the placement and removal of arbitrary models to the engine well. They allow for far greater detail than merely sticking to voxel cubes.

Working on getting girls on screen and towards something playable now.

As for the combat poll, the majority are in favor of independent attacks and movement. And some suggested that the movement freedom can be limited base on what kind of action the user is performing. Perhaps heavier attacks are more restrictive and/or stats should have a role.

A good idea certainly, but the tech wasn't quite there yet. (HR locks in movement during attacks). Basically what needs to done is to have separate action for upper body and lower body. That part is easy. The difficulty lies in "joining" them together.

The tech for "joining" the body parts together is inverse kinematics. Something I am actually very interested in implementing. It have other applications as well, such as placing hand more firmly on the different sized boobs rather than hover/clip :).

Anyways IK is the last piece of tech to implement before the shift towards content. It shouldn't take too long.

A question about combat. (patreon poll open to everyone)

POLL HERE

Implemented collision handling across multiple chunks. The "seams" in between chunks were a PIA to handle but it seems to be working correctly now. Also added save/loading functionality for maps. And after sometime playing basically Minecraft-lite, made this:





Anyways, what this means is that the voxel terrain system is functional enough for me to start considering implementing/porting gameplay elements. And while I decided on the Mount & Blade directional attack/block system, I am undecided on whether or not characters should be able to move in any direction while using their melee attack.

So for example, in fighting games, and SoulBourne games, the characters can not control the movement during their swing; once they start their melee attack, their movement pattern is set from the start to the end.

In contrast, in Mount and Blade and say, shooters, attacking is independent of movement. So a character can move freely while attacking.

Which one do you prefer?

POLL HERE