Warband Revolution

 

To the victor, the spoils - all 3125 of it

 

Work on Warbands and their strategies has progressed well during August, a month were the weather couldn't decide whether it wanted to be the height of summer or mid-November, leading me to keep both the Big Summer Fan and Autumn duvet at hand.

Warbands now traverse the game world - which is still a completely flat and open test area - in search of "Points of Interest" - which are currently tall blue cones to make them visible. Holding an area allows healing of wounded troops, and looting for good old fashioned cash/points.

Warband can now decide that maybe their battered team of a few survivors don't really fancy taking on the huge opposing warband which they have just encountered, and may evade battle by fleeing. Eventually, once I have bows and crossbows working, warbands will have more options for battle than just fight or flee.

Combat now ends with one group deciding that it's time to leave pronto, with unit cohesion breaking down and a total rout breaking out. Pursuers will attempt to block off routed enemies and hack them to bits - it's good for individual XP which can be used to upgrade stats whilst healing at a "Point of Interest", and also for looting loot from the defeated corpses. A routed warband automatically drops half of it's loot in panic.

 

So there is the battle, which the top pick is the final result of. I didn't video all the battle because much of it was just surviving warbands moving from lootable position to new lootable position, so here is just the action.

I also upgraded the weapons, filling out most of the planned classes. This meant modeling some new meshes, and requiring new animations for attack and movement, because a spear obviously does not work like a broadsword. The new attack animations are based off the old ones so look a bit rough at the moment, and will do until I get chance to rotoscope myself cocking around with pole weapons.

 All fine for one handed weapons, but a Viking Long Axe kinda needs it's own moveset where BOTH hands stay on the pole, and so I cried; "once more unto the breach!" and had another look at Inverse Kinetic tutorials.

How IK tutorials are supposed to look - it doesn't work of course

 Now there has been a long running issue with IKs for ... oh about 18 years. Mainly that I never got them to work way back then and ignored them ever since. To be fair, the number of tutorials and easy of use idiot proofing of them has grown exponentially since I first picked up Blender3D in 2007. The idea is, you give the pole an armature with a hand bones high and low, and a central root bone. When you want to move the arms you move the pole's root bone.

And how it looks in game - busted

 

Naturally this doesn't work, because life would be easy if it did. In the above image, Left Side: the lower hand is offset from it's target in the game engine, and in Blender; Right Side: a second pole (selected orange) shows what the actual mountPoint angle is, just as it looks in game. Even though the mountPoint is parenting to the weapon pole armature. No matter what I did, the rotation was always wrong.

So I came up with a solution. 

MountPoint parented but not connected to hand bone

 Now I have previously noticed that Blender and Torque3D open source game engine, like to think that the origin of a bone is at opposite ends, which caused a bit of trouble when parenting hitBoxes to the character previously. So I extended the tips of the hand bones to be level with the mountPoints. 

Hand bone tip level with mountPoint

 The mountPoints themselves will go all over the place if IK'ed - because they are not connected directly to the other bones - so I used the hand bones for the IKs. The weapon had 2 bones now, the top hand point bone was now IK'd to the character's own right hand bone, and then the character's left hand bone was IK'd to the weapon low hand point bone. Dem bones, dem bones, dem ... dry bones!

Weapon IK'd to the right hand, left hand IK'd to the weapon low bone

Now both hands remain in place on the pole because the pole itself is IK parented to the character, and the character is IK parented to the pole. They are no longer ... poles apart! Thank you, thank you, I'll be here all night!

I have since cleaned up the twisting in the left bicep

 So, with IKs finally understood, and working in game I set about animating for two handed pole weapons ... and immediately hit another snag. The weapons themselves needed animating for different states of their ShapeBaseImageData FSMs, otherwise they would be held in the wrong places at the wrong times, holding a pole close when moving had to different from slinging it out to maximum reach in battle. 

After that I had to synchronize the speed of the animations to keep pace with the changes in animation speed of the character's actions, because everything speeds up or slows down depending on making a light or heavy attack for prepAnim or attackAnim. Because attacks use the same button with release time being the deciding factor between light and heavy attacks, light attack for the weapon FSM was being called faster than the prepAnim was ending, so I took the transition to fire out of the FSM and moved it into Player Class animation code for when the prepAnim ends. If it's interrupted there is already a fallback in the FSM for that.

Long Axe is Long!

 I also changed how shields worked. Previously I had them as StaticShape objects, but now I moved them into the ShapeBaseImageData with weapons for easier mounting/unmounting. They share the same parry values as weapons but are seperated by a simple isShield flag. As weapon "images" are not real objects they should also be easier on network load than mounted StaticShape objects, especially with lots and lots of heavily armed warriors running about.

 

  August is over, summer ends - though to be honest my little patch of God's Own County didn't get much of that, when everyone else was going hysterical about "heatwaves" I was shivering under sea fog.

Next month, the cunning development plan is to start actually modeling the armour of the characters, and develop a system were different warbands equip unique looking items. A lamellar helmet and early spengenhelm may be the same class in game but there is a big difference between what an Avar or Lombard helmet looks like and a Saxon Sutton Hoo helm.

Autumn is here! 

 

Shields, Spears, Seaxes and Warbands

Saxon Warband - you can tell they're Saxon because of that one guy with a Seaxe and the bad teeth

So after getting parrying work last month, it was time to work on shield guarding. Shield Guarding is the easier version of parrying, were you hold up a shield and let the other guy hit you, and the shield absorbs the damage but the defender loses Stamina. If the attack does more damage than the shield's defence rating, then the defender will lose even more Stamina, and if their Stamina reaches zero, their guard is broken and they are staggered - cue free hits. Shield Guarding also slows the player's movement speed.

 With shield guard added to dodge and parrying, the basics of combat are pretty much finished. I did some tinkering with the Ai and they now hunt their opponents on actual sight rather than the previous positioning system I had in place. This makes combat a lot more fluid, and here's a video to prove it, including a brief "look the Ai can now Shield Guard" at the beginning.

 I also noted that the Player themselves could only lock on and off of a target. The camera would then revert to whatever direction it had  before the lockOn occured, and this could be rather disorientating if the Player had done a lot of moving around. Now the Player can cycle through targets left and right by line of sight, and when they end lockOn, the camera stays where it is and just gives input control back to the Player.

 Next up is the crux of my game concept ... warbands!

Warbands are basically teams - and I've got 16 of them with full equipment lists -  that will trudge around the game world, looking for loot and combat. Whilst the main theme is warbands wandering around fighting each other and the Player scavenging equipment/coin/XP from the dead and dying, I am planning on letting the Player eventually being able to join or ally with one, probably for a Danegeld or something. So they'll be a friend/foe system based on previous encounters and the warbands won't always be in a rush to spill each others - or the Player's - blood until something kicks off and vendettas occur.

Norse warband - you can tell their Norse because of their armour stats which I don't currently have models for ...

 I am testing the warband system with just two teams at the moment, Saxon and Norse. This has meant a sudden influx of modelling, as for testing equipment I have needed, axe, longAxe, spears, seaxe and a variety of shields, Targe, Rond and Kite. And then there is the armour, cloth, leather, lamellar, chain, brigandine and plate. The armour is equipped fine and the defensive stats get set, it's just that I don't yet have any armour models so to show that the armour has been successfully equipped everyone has taken to wearing a box on their head.

I also only really have one handed sword animations at the moment, which tends to look a little odd when someone is holding a two handed Long Axe, and combat with a spear involves more thwacking than poking at the moment.

 Each warband has a list of ranks which, apart from equipment, basically detail the attributes and available XP for upgrading that character. Ranks are based on warband type, so the Saxon Fyrd is heavy on low quality levies for the shieldwall with a single Thegn (elite/Knight) and a couple of Huscrals (Men-At-Arms/Heavy Infantry) and no standard Soldiers, whilst the Norse are a more professional outfit of raiders, which make them much more expensive. Both side have few archers and I the datablocks and animations for projectile weapons are still very much on the todo list. For the moment I am concentrating purely on melee, and getting the warbands to move from one location to another as a vaguely cohesive force.

Rather like good old Warhammer, each warband will get the same amount of army build points, set to whoever is the most expensive for a basic force of 10 troops. All other warbands will then get the opportunity to deploy more men, so the largely peasant Saxon army will field 19 troops for every 10 Norse. Whilst the Fyrd's levies may have poor armour, and no bonuses to physical attributes, that is still a lot more spears to be sticking out of a shieldwall. 

Eventually I will get round to battle tactics, such as shieldwalls, but for the moment it's just charge at the enemy and start swinging like a madman.

Next up is getting the warbands to move around to certain points of interest which are just markers placed in the editor. Once I have an actual terrain map these points of interest will be a lot more interesting.

Once the warbands are fully up and running I will start on modelling armour so they finally begin to look the part. 

July is over and it's already August in Space Year 2025. Stop the world I want to get off! 

Monsters Loot Swag - New Game Plus

Steam Summer Sale 2025

 Steam Summer Sale is upon us, and just in time for Monsters Loot Swag NG+ update!

This major update give a whole host of modifiers for repeat playthroughs (New Game +) , which can be selected individually or as multiples. Here's a quick rundown ... 

After completing the game by gaining Final Victory in the Final Level over the boss's Final Form, NG+ is unlocked, allowing for the following modifiers.

•   House Of Fun: All enemies drop explosive funballs on death, and enemies which dropped them in standard game mode now drop more. +20% Score Bonus.
•   Test Of Strength: Both Players and Monsters do triple damage critical hits with every attack. +20% Score Bonus.
•   O Fortuna: No SWAG parcels spawn, instead there is a RNG for monsters dropping SWAG on death. Chance: 5% monsters, 10% elites, 50% Bosses, and a 1% chance of dropping a Nerve Gas Bomb. +20% Score Bonus.
•   The Harder They Come: All enemies spawn as elites, even Bosses. +20% Score Bonus.
•   Targeted For Termination: Every 9 minutes of gameplay a specialist team of Anti-Catgirl Assassins will spawn, 6 members with 6 unique special attacks. +20% Score Bonus.
•   Endless Mode: The game continues after level 8, cycling back through the levels with ever increasing difficulty.  

With the exception of Endless Mode, which is it's own bonus scoring system due to the game never ending except via the Player's defeat, each selected gameplay challenge adds +20% to the Player's scoring. 

Saved Games Display Their NG+ Modes

And here is the whole thing in action on video:

 In other news ...

Flaming June was flaming hot

 Last year the weather was so bad I grew a single, tiny strawberry ... this year I have buckets of strawberries, more kale than I can fit in the freezer and one hell of a tan!

It has been proper scorchio, but the pursuit of free vitamin D hasn't prevented me from getting back into coding on my Melee Combat Demo.

I have spent the month, (inbetween updating Monsters Loot Swag, harvesting my bountiful veg patch, and absorbing vitamin D in non-capsule form), to working out the finer points of defense in the Melee Combat Demo. 

I have a combined a Dodge system into the Jump input, with a tap of the Jump button being a Dodge whilst holding the button down to apply a Jump. The dodge defaults to away from the camera view, as I expect the Player will be looking at an opponent most of the time, but the dodge can be made in a selected direction by the Player putting movement direction input in before the button tap is completed.

 Getting this working and networked for the player was not too much trouble, and I eventually got it working the AI aswell, as can be seen in the below video were I telegraph a heavy attack to the AI target. 

A bit more coding and a lot more maths, and the AI now checks which is the best way to dodge from an incoming attack in the obvious choice is blocked.

 During coding all of this I discovered that the hitBox collision resource I was using had the minor drawback that there was no boolean option for actually disabling checking for hitBoxes on hitBox enabled objects when I just wanted to test ONLY against their Bounding Box presence in the game world. 

As CastRay is used EVERYWHERE in the engine it seemed like a fool's errand to modify every single instance of that, so instead, after much methodical backtracing of how the function worked, I created another version that would always ignore hitBoxes, and so CastRayNoHB was born.

After all of this I have set about coding a  Parry system, which has been even more complicated. The real problems come from the fact that a Player, unlike the AI, might not actually be locked-on to the enemy they are about to hack at, and what happens if there are two Players, with neither locked on to each other, or someone is standing near the target and is also going to get hit in a wide, swinging, heavy attack - well maybe they would like to parry too.

So, I managed to code a system, based on AI skill modifiers, that checks proximity, parry ability, direction, weapon parrying attributes and a whole load of other stuff which I have forgotten off the top of my head. It doesn't actually use i-frames, but checks against a; "where is the incoming strike in relation to how far we are into the parry animation", and even a successful parry may be overwhelmed by a larger weapon, but does then limit damage. Too many times I have seen games were a Bollock Dagger blocks a Zweihänder with no ill effect. A fully successful parry staggers the opponent (technically it's knockback for the duration of the attack animation rather than full stagger) which allows for a light attack reposte that will hit for critical damage. No video of this happening yet, as I am still debugging the code and working out animations.

After Parry, the final defensive measure will be Shield Guard. Shields will not be used for parrying per-se, but will absorb damage dependant on Shield type which will deplete the defender's Stamina, whilst reducing any damage that does get through the same as parrying works. If the defender runs out of a Stamina their guard is broken and they will be staggered.

I suppose I could also throw in Roll-Slop, and give the Player the opportunity to decide if they want to use that instead of the dodge mechanic, but that would be decision for a later date.

Anyhow, happy strawberry munching everyone.