A melee of Norse versus KievRus versus Saxons at the back
Warbands now look the part, with each individual faction having it's own style and shield markings, because in the middle of a disorganized melee it's not always easy to tell who the hell is who.
So, without further ado, let's have a quick rundown.
Avar Warband
The Lombards - could have been the Franks but France features more later on
The Saxons, featuring the cool Sutton Hoo helm
The Norse, not a horned helmet in sight thankfully
KievRus
The Magyars, pre-paprika
The Normans (boo!)
And so we have our initial warbands, and I am only up to the 11th Century. Whilst shields and helmets tend to be unique to each faction, the lower ranking peasant levies do tend to rather look the same, so I might have to add warband specific patches. Back in the days of the Anglo-Scot Border Reivers warriors would wear the cross or saltaire on cloth pinned to their armour ... usually with the other flag on the back incase they wanted to swap sides mid-battle ...
With all the warbands now equipped - at least except for bows as I haven't out the code needed for archery just yet, but it is coming - I needed to bring home the awesomeness of hitting someone with a poleaxe. For this I hunted around for some of the old death animations which I had got for Airship Dragoon and modified them for the new rigging system which my current models use.
And so the whole thing comes together with slashing sounds, the ring of parried metal, fountains of blood and the screams of the mortally wounded!
Pumpkin!
And of course it has been All Hallows Eve. Can you believe that there are some folks who carve a pumpkin but don't scoop all the food out? That was 1.5kg of seasonal veg going waste! I bag it up into portions and stick it in the spare freezer ... which turned out to still have last year's pumpkin in it because I'd forgotten all about it. More pumpkin on the menu now!
Next up for Untitled Medieval Warband Game - a land fit for heroes! Time to make an actual level with terrain and points of interest for looting, to give raiding parties something to raid.
Wearables are a thing. Technically we always had wearables ... but it was just a box that fitted on the head, now we have an array of helmets and various armour types.
And needless to say, all of these variations have ended up causing problems themselves ...
After making vast quantities of helmets, helmet variations for differing warbands, I discovered that mesh reskin was borked. Everytime I set a new skin on the mesh ... other skins would reset. After going through the shapeInstance code, I finally got it to agree with me that it didn't need to reset to base skin for all other meshes ... except it still did ... and this is when printf comes into play.
And it was a lot of printf, but it did let me back-trace through the code to discover the well of embuggeration that was causing the issue ... the shapeInstance appeared to be reinstanced when changing the skin. I must admit, I was not expecting to recreate the human DNA sequence from scratch every time I wanted to change into clean underpants ...
This threw a somewhat annoying spanner of arseholeness into my previously anticipated slick engineering. The main annoyance of course being that I had already made a huge number of helmet materials base on reskinning, but now I had to save the reskinning function for a singular mesh, which would naturally be the main armoured body.
So a minor annoyance in the end, as I would be fearful of breaking MANY THINGS if I tried to change how the meshInstancing code worked. I can still use reskin for the main body, but headgear will now have to be individually exported, and I think the variations of colour schemes for cloth aventails and coifs will have to be reduced somewhat.
Did I mention lots of helmets? Well here they are ... prior to me discovering the resking instancing issue.
Saxons
Norse
Lombards but could be the Franks
Avars
Normans
KievRus
Magyars
Now obviously not everybody is going to start off in their love heart patterned boxer shorts ... well, except the player who actually is. The Ai warbands are obviously going to start off equipped with their customized armour meshes, all based on rank and faction.
As I have started off with the first half of the warbands, chronologically there are more to come in time periods up to around the 16th Century ... when war gets really boring due to the preponderonce of boomsticks. The current warband factions do not much get passed the 12th Century, so armour is somewhat reduced to the primaries of cloth, chain and lamellar. Technically there is some brigandine in their but only as a defence class rating for superior helmets, so now I'm just getting pedantic. And who doesn't like to get pedantic? I mean why would you even bother with doing indie game dev if you weren't pedantic? It would take all the suffering fun out of it.
Assert dominance over the battlefield by T-posing, it is sure to crush the enemy's fighting spirit
I had also started to update my Collada format mesh files to FBX. Collada has always worked nicely but it's support is no longer being updated (thanks Sony), so changing to FBX seemed like the logical solution ... except that I had some errors with animations, like baffling errors, like it insisting on contracting the whole animation into the reduced key frames which it I had set, so that's going to require some more testing.
But, in the meantime, here's a video of wearables in action - cue Sabaton.
So, next up, is updating my wearable code to remove the skinning references to the helmets and use pre-exported headgear variants, and leave reskinning just for the main body armour meshes. Some sort of special effects for combat, most noteably sound and particles would certainly help too, and then it should be on to making a gameplay world which isn't a flat grey box.
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.
