World of Warbands

 

FromSoft eat your heart out

Work on an actual in-game level has proceeded, so my brave little warbanders of expendable warfighting warriors have somewhere to run about in that doesn't look like the default flat, grey plane when you load an empty level into the engine.

Grassy plains, perfect for archery - which I have not coded yet

 

To go with my low-poly warriors, I decided on a return to the art style of Airship Dragoon, and the same sort of colour scheme, eg: brighter and greater saturation of colours than drab old reality. It's still all very much a work in progress, as I was forced to spend a good week plus incapacitated after my lower back went one way whilst I went the other, and sitting for long stretches became unbearable.

You just know that there's gonna be a camp fire in here

Whilst I was planning on level desgin, I decided to relearn how to import heightmaps, specifically heightmaps from reality. To get DEM style heightmaps from around the world there are a few free websites available, such as https://tangrams.github.io/heightmapper/ which has the whole world as an open map and https://dwtkns.com/srtm30m/ which has it sectioned into blocks for convenience.

The Peak District from Spaaaaaaaace

 

The Peak District in Gaaaaaaame! With the heightmap overlayed as a texture

Whilst this all worked very nicely, I thought it was best to craft a level by hand and eye that would fulfill my needs for gameplay. So I created a land surrounded by mountains (the old trick to stop the player from falling over the edge of the world without needing to create the horror of invisible walls to block them in), with internal areas of flat plains (good for archery, which I have yet to code), rolling hills, scalable cliffs, marshy flatlands with small islands and dense woodland (good for ambushes).

Robin ... woo-hoo, the hooded man ... dun dun

As I say, all still a work in progress, I currently have a few models still to make, mainly rocks to give a bit of depth to the flat mountain sides, and various building parts. I am planning on module ruins, so I can have a Weathertop, and of course a bridge is needed to cross the deepest parts of the river, which will be a nice choke point when two or more competing warbands try to cross at once.

More than enough of the white stuff to bring the entire country to it's knees

 Autumn ends here, and it is officially meteological Winter. The UK has already had it's first taste of snow, a thing which happens briefly every November but for some reason is more than enough to bring the whole nation to the verge of hysteria and cannibalism. Remember when we ruled the world and strapping lads would volunteer to trek into the polar regions so they could show off how stiff their Imperial upper lips were whilst starving to death? Great days. We used to be a proper country. Now I was all a flap trying to get a mixed case of whiskies ordered before the budget went through last Wednesday - and don't even get me started on Christmas, I'm trying not to think about it.

So, next up is  finishing off the warband world, and then getting pathfinding operational, which is something I haven't tinkered with for a few years. After all, we don't want our hardened warriors ignoring the bridge and running straight into the depths of the river in full armour before a blow has landed ... them fleeing in routed disarray after a blow has landed and drowning in the river would be quite historically accurate though.

 

Wearables

How it started

How it's going

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.

 October is here.

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!