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! 

 

Intro The Outro

 

Final Release Is Soon™

 Monsters Loot Swag gets it's final release soon - very soon. In fact 8th March 2025 if all goes according to plan keikaku. Not that anything has ever gone according to keikaku but that just seems to all be part of the wonderful world of indie game development ... but we are hopeful on this one ... 

The game received it's last big update on Steam, which fixed a few more bugs, tweaked some stuff and turned the higher poly poorly UV mapped catgirls into lower poly and infinitely better UV mapped catgirls. The whole "Souvenir" system is now live, and souvenirs drop from Monster Boss kills at a random rate, based on game difficulty and level progression. With this last bit of code and art complete, now all the available Steam Achievements are achievable.

 The game even now has an actual ending - well two endings, one for victory, which also gives the player the opportunity to continue playing in Endless Mode, were the difficulty ramps up even further as the levels restart, scoring is multiplied and Boss Monsters spawn before the Level Exit is complete. The other ending is the fail state, which is more likely on the law of averages, when the player is delivered the sad looking catgirl of butt whooped. Cue sad catgirl noises.

And here is what the fail state end screen looks like.

 These "plot" sequences all required a bit of Twillex, which is a system of animation called "tweening" that involces "tweens" which are a series of terms, that as a middle age man, I would not like to have on my internet search history. It actual means moving one image state to another, and after a bit of practise and good old maths, allows for some pretty nice scrolling, spinning and resizing of a static image.

 So the only thing left to complete is the animated "Intro Sequence", that will finally reveal the game's narrative "PLOT". I left this until last because, "reason why" didn't seem anyway near as important as "game actually working".

 The Intro Sequence has taken a lot of drawing, even with just mostly static frames and a lot of synchronizing audio - and there has been a lot more audio required than originally planned, as staring at a sequence of storyboarded images in relative silence just feels like it's missing something.

There are a few visual and audio gags and some references in the transmute/transformation sequence - which naturally every magical girl must have - preferably fan service heavy and complete with sparkles - lots of sparkles. This includes a reference to Battle Of The Planets - which I absolutely loved as a five year old in the late 1970s, and a parody of Kill La Kill (which to be honest I can't say the same for).

It's May tomorrow, the fifth month of the Space Year 2025, and it promises to be a scorcher ... that will then be followed by the resuming of normal service and thermal pants weather once again, and that's before any despot fills the sky with clouds of acid.

More Third Person Melee Mayhem

Finally, summer has arrived in the dreary part of grim northern climes, though July started as June ended, with weather best described as "crap", and a sudden return to wearing jumpers.

Game development-wise things have continued much as before, with the vast majority of effort being aimed at the third person melee project demo.

I had long wondered what the best way of getting different clothing and armours onto a model would be. Many moons ago there was a turn-based RPG there was a post-apocalyptic neo-Roman game ... who's name escapes me ... and they literally had to load every piece of armour that the player could wear onto a single model and use the "hide/unhide" commands. 

Well many moons on from this and it looks like the only way to accomplish such things appears to be in the same manner, as you cannot just mount meshes and have them conform to the character's skeleton and mesh weight painting. Deciding that making a single model with EVERY PIECE OF CLOTHING that could ever be considered was not a great method for potential later updates, I delved into the engine to see how best this could be accomplished with code and script. The answer was to add a list of meshes to the character model's constructor, though this did mean it all had to be done at preload and was thus impossible on the fly, so once again, we are back to "hide/unhide" commands. However, at least this way it could be automated to search for all available meshes (and their LODs, which have to be added seperately per mesh), rather than sticking it all in the model and never being able to change it later.

Behold The Hat Of The Ages!

The Shape Constuctor code for adding meshes was somewhat out of date and relied on directory locations, so I updated it to deal with the engine's asset system. I'm thinking it would be best to have a function look for all relevant assets - probably from a folder naming system - and then add them all at runtime preload to the character mesh, followed by immediately hiding the added meshes and then only displaying them on the model when specifically called for; eg: when the player slects clothing or armour. I am not currently certain what the limitations on numbers of meshes would be this way.

Orientated Box Outline In WorldSpace

 Speaking of coding, it took long enough to get my custom code and the debug drawer to agree exactly how an oriented box works in world space. I had an idea for testing for blocking and parrying by using the actual strike/bounds box of an object, except weapons are not actually objects at all but are virtual due to the FSM system. After some testing I decided it was going to be difficult enough to make a successful parry this way and will probably go down the Dark Souls route of using animation frame timings - though unlike Elden Ring, I very much want to avoid this being tested on the client side as that appears to highly exploitable to hacks.

 Whilst I had coded a lock-on target system a few years earlier, in practise at melee attacks it was not always easy to actually strike the target, regardless of it being screen centre, and quite often I could miss and my strikes would go just wide. I decided to code a toggleable "face target" system, thus allowing the player to decide whether they wanted to absolutely aim for the enemy at the loss of movement speed due to circling side to side or backing away.

This worked fine but seeing the player spin in place to face the opponent seemed very 20 years ago, so I went back into the animation system and coded a speeded up sidestep when doing it.

Artifacting gif is artifacting ...

Whilst adding things to the lock-on system, I thought it might help to distinguish which target it was by having a health or status icon. I started off with a health bar over the target that reduced in size the further away, eventual throwing the lock-on off if the target was too far away. After this I thought I might create a central lock-on icon, for instance Elden Ring has a tiny white dot at the centerpoint of the target. I found this and the opponent health bar to be a little too busy on screen, so made the central icon a circle which changed colour depending on the target's health.

Whilst testing lock-on I discovered an issue with my original code from a few years back, I had always tested it with the player moving around the target, but not the target moving. This turned out to cause some nasty jitter due to the client being a tick behind the server. Rather than mess around in the depths of prediction I just took some old "target heading and velocity aimpoint" code from my old Aeronauticals air combat demo, and retrofitted it to have the client look 0.064 ahead, 1 server tick and 1 extra tick for the client being an engine tick behind. I added this code to my resource on the Torque3D website and slightly rewrote some of the original lock-on code to make sure that everything was using the render transforms that the client was seeing rather than the actual server positions of objects, something which I had previously noted in code about displaying names above objects whilst looking into coding the health bar for the target.

In other news some muppet crashed half the world's computers and offered discount pizza as way of apology. It turned out at some point other computer systems had been updated too, and Monsters Loot Swag no longer worked on Linux due to changes with Wine and so the DirectX driver needed updating ... but apparently no one mentions these things and you just have to use The Force to find out. Turns out there was a slightly larger D3dCompiler47.dll which needed to replace the slightly smaller one. Monsters Loot Swag now once more works on SteamDeck.

And that was pretty much July, numerous other things happened which I cannot remember, I got a tan when summer eventually arrived because you just don't know when the free vitamin D is going to disappear around here. After months of drowning in a seemingly perpetual deluge of rain, I am back to hoping for some wet stuff coming out of the sky as my water barrels are empty and the veg patch is parched.

Next month is the 10th anniversary of Airship Dragoon being on Steam. I thought about maybe doing "something" but the models were all exported using a system which doesn't exist anymore (pre-Collada), so anything new would not be compatible with older animations ... which is a bit of a bummer. The past is a foreign place where they do things differently ... so I think I will just let sleeping dogs lie on that one.

Melee Working Redux

 

Last Month's Blender Animations Are This Month's Game Animations

I cleaned up my dev folder system, mostly because it had no particular system at all, and was just a mess of folders dumped into a single directory. Over the years this had grown to a somewhat considerable number of test builds, most of which were pointless duplications. Tidy all of this up into a few folders based on simple concepts such as "Game Builds", "Test Builds", "Modules", etc has made everything a lot easier to find.

The only casualty to all of this was the deletion of my Melee Build Test Area, which I had thought was just another test area, however it included some more up to date melee code than the named Melee Project. However it was not particularly advanced so came as no great loss, and whilst redoing the now deleted extra pieces, I actually improved them.

I imported my previously rotoscoped animations into the game engine, and set up a character to use them. With a bit of tinkering all worked as intended, though I have since edited the standard run animation as it contained quite a sharp hip flick which in turn sent the character's butt cheeks into rather a frenzy. This has since been toned down.

Next up was to reinstate hitBoxes to the character limbs. Unfortunately some of the bones rotations had developed a nasty roll , which sent the hitBoxes for the legs into a strange position and so I proceeded to fix this, and annoyingly all the animations which I had previously made had to be redone. Thankfully it was only the legs which needed retuning.

From Hell's Heart I Give You A Good Pokey-Pokey!

HitBox testing worked well, and I even changed the code as to how strikes work. When I had first written the melee code last year, I had for some reason had great trouble trying to get a box mounted on the weapon to use as a strikeBox against the target's hitBoxes, and had in the end settled for an armature bone system to measure between the bones for the length of the attack. 

I say "for some reason" because it all seemed quite straightforward now to set up a box on the weapon for collision, get it's measurement and offset from the handle/mounting point. So the hacky bone node system was retired in favour of the collision box size and offset being automatically stored on datablock preloading. And if there is no box to provide collision for the weapon, it will fallback to using the bounds box and work out it's offset from the mountPoint. So, not sure why all of this proved hugely difficult last year, but I expect "tunnel vision" which seems to happen quite a bit in game development.

The Cold Steel! They Don't Like It Up 'Em!

Expanding the original melee code, which already had a fatigue and rage system, I added stagger depending on how much damage the target had taken versus how much they had remaining. Stagger breaks the target's attack and defence, potentially leaving them open for a free strike. The lower the target's HP, the more they will stagger.

It took a bit of trial and error to prevent the code getting stuck in certain animations, but after a while I ironed out all the obvious bugs. I also rewrote how falling damage works, introducing a plummet system were the player just drops face first, and if damage on impact is high enough a custom plummetDeathAnim plays.

Elden Ring Style Stat Bar Reduction

The player Stat Bars on the GUI got an overhaul, when health or energy is lost the original level is now shown as a different colour and reduces until it meets the current Stat level, a bit like it does in Elden Ring (no I haven't played it, but I am aware it is a thing, and a thing with Stat Bars which do this).

The weapon FSM system got a whole overhaul, and light and heavy attacks now trigger in a way which does not require the player loop to count, freeing up a couple of write/read stream vars. A quick released attack button sets the FSM to interrupt the state and send a light attack var, whilst holding it allows the state to complete for a heavy attack.

There was probably a lot more "stuff" that got done, but I can't remember it all off the top of my head here.

Flaming June was more damp squib June for the second year running, and the strawberry patch appears to have already given up the ghost.

It's halfway through the year already which only goes to show how painfully slow game development is. 😩

Aurora Borealis And Prancing About For Rotoscoping

Chalmers: Yes, I should be--good lord, what is happening in there?!

Skinner: Aurora Borealis?

Chalmers: Ah- Aurora Borealis!? At this time of year, at this time of day, in this part of the country, localized entirely within your kitchen!?

Skinner: Yes.

Chalmers: ...May I see it?

Skinner: ...No.

But see it I did and it was spectacular. Alas I was only armed with an unfamiliar camera and had no tripod set up so the pictures were dark and grainy.

Monsters Loot Swag got another update, available on Steam here.

Much of the month revolved around me being ill with some sort of random stomach issue which has resulted in a detox diet, which isn't as bad as it sounds, though caffine has been kicked into touch.

When not feeling like death, I have spent the month testing more of my rotoscoping concepts for animation, still with only one camera. There has been much prancing around the vegetable patch. Cue list of gifs.

Two-Handed Lunge - The Disembowlment Special!

Wide slash with chopping followup ... The Double Whammy!

Two Handed Sweeping Uppercut - They Won't Be Expecting That!

With various attack types done, both single and two handed strikes, I needed more video of myself prancing around like a demented elf for standard movements, such as forward, back, sides, etc. This was however postponed due to WEATHER and lots of it. It had bucketed down days, possibly weeks, it's hard to tell when you lose all sense of the Space-Time-Continuum due to being excessively soggy.

Whilst waiting for the biblical deluge to wash the sinners into the gutter, I added a shield to my hack-and-slash base character model. Whilst I had posed with my arm out, pretending to have a shield - bokken I can muster, Viking rond alas not - I had not been too aware of sword or body penetration. Thankfully my sense of spatial awareness was quite good, and changes and rotations were kept to an absolute minimum.

It did finally brighten up today, and so I spent more time running about on the way too small available area next to the veg patch. After a quick rotoscope I have some basic forward movement.

Tip-Toe, Through The Meanies ...

After some consideration on forearm and hand deformation I thought it was getting a little too mangled at the wrists, and so edited the base character model to include wristTwist bones, which proved to give much better deformation than twisting the forearm and hand along the Y axis.

Slash With Shield

Skewer With Shield

Reverse Cut With Shield

So that was a very wet May, hopefully it will fair up come June, though ... how the hell have we got to June already????

Terrors Of Retopology Part Two

New UNLOCKABLE Character: Introducing POLARIS

 Monsters Loot Swag got a new update on Steam, this time featuring a new playable character named Polaris, who is a close range, melee based character with a pechant for saying; "Omae Wa Mou Shindeiru".

 Polaris utilizes the cleaned up auto-repology I created last month, with the character weighing in at around 8K tris, with a lower LOD of 4K - down from the standard 12-16K of the other characters. However that did get my thinking that I could probably make a perfectly decent lower poly base mesh with some decent deformation at the joint from scratch.

Base female mesh created from scratch with 8 face limb edge-loops

This weighed in at a mere 3K triangles and had fully working fingers, something I had not really bothered with in the previous character models. I had started off by deciding to have limbs with edge-loops of 8 faces and built it from there, using the silhouette of my previous base character, which was a chunky 20K tris. After creating this first LOD, I made another from scratch, this time basing the limb edge-loops on 6 faces, which weighed in at ~2K tris, including fingers and some other details which probably be removed for an in-game model.

2K tris LOD with 6 face limb edge-loops

After this I decided to make a base male character model using the same technique, something which I could plan my next game project with.

Next game project base male mesh idea

With that done I wanted to have another attempt at animation using rotoscoping. This would probably work best with multiple cameras, but I could only rustle up one working camera for a side view, so had to ad-lib for a facing angle. Initially it looked a bit wonky due to lack of space and cutting my own feet out of view, but when it eventually stopped raining for 5 minutes, I could go outside and refilm myself acting out some movements.

Rotoscoped Animation

And behold the end result was not too bad. The downside is that without exaggerating some foot movements, it tended to look like the back foot was getting dragged and just blending to position, but then the exaggerated movement looks a bit twichy. Either way, bottom dollar motion capture is perfectly feasible, and I may go looking for a second old camera, so I can get a front-on view as well as the side angle, which would help bone positioning in the other viewport. I don't think it's neccessary to glue ping-pong balls all over myself whilst doing this, but maybe not wear baggy trousers next time - but hey, Gen-X here, we even had a song about them.

The next game project is going to be the hack-and-slash concept I've had for a while, and whilst I would like to do another ridiculously giant project with an RPG, I have decided on a more contracted gameloop idea. I was tempted to make it a side-scrolling arcade style slasher, but have gone back to my original free-cam idea, were the player can rotate the camera view as they please.

In other news I was clearly too optimistic about the weather and whilst the Spring duvet remains, I quickly ditched the Summer pyjamas and went back to the Winter fluffy jimjams. It has been bloody freezing, but hopefully this will change. Fingers crossed for May.

Space Year 2020 And CO-OP Mode Works

The first month of Space Year 2020 is over. Which is kind of annoying as I always bemoan a month passing in the face of my meagre endeavours. However January has been rather productive.

I created muzzle flashes for the stock player character's weapons. Apparently there is a way to do this in Max using mesh visibility animations ... but Blender3D doesn't appear to have that so I had to fake it with the good old "make it really small and hide it inside the gun when not in use" approach.

 The gifts that keep on giving ... but not this much ...

I also went back and restructured a lot of the power ups. There is a rare power up which drops other temporary power ups - however I found this to be very overpowered, so I changed it to drop a small gift box which contains a 20 second buff to a single attribute - "buff" apparently being the correct terminology for this sort of thing. I also swapped a common single attack damage multiplier for a temporary damage booster that lasts 60 seconds.

The '80s called to remind everyone that it was the greatest decade in history ...

I also channelled my 1980s childhood for an Aliens themed range finder. This finds the nearest unopened swag parcel or node and informs the player of the distance. Originally I tried to get this information via the GUI itself before common sense prevailed that I should be getting it from the player object on the server and then send the result to the GUI so it was networkable.

 Me, myself and I ... and me again ...

Speaking of networkable, I finally tested 4 player co-op mode and it worked quite nicely ... until it all broke but then I fixed it and now it really does seem to work quite nicely. I created a little leader board so all the players can see how they did at the end of the level relative to each other. I had to rewrite how levels are loaded as my previous level loading was very much based around single player mode, but at least I have had the foresight to make all aspects of individual player progression networkable so has been no hitches in spawning clients in a new level with all their old swag.

I have made various other tweaks and additions too numerous to mention, though refractoring the difficulty curve was one. It now works much better in co-op and endless mode, when the player has finished the game but continues to replay through the original 10 levels.

One thing I finally got around to finishing was the model for the Terror Tower item, which creates a zone of protection that the player can hide in. It's a tower of gibbets with severed heads that scares monsters away.

Too Spooky - even for monsters!

After putting on half a stone over Christmas, all of which seemed to congregate in a band around my waist I went for a good 70 miles worth of hiking this month. I am still the same weight but the middle tyre has gone so I guess it's turned into muscle somewhere and now my leg really hurts. More hiking tomorrow but it's only 5 miles to a pub.

Anyhow, roll on 2020.

The Boring Look Back Episode Nobody Likes

It's the end of the year highlights show - which I am fairly certain no one likes. So first, here's what happened in December.

I got PTSD from Christmas shopping. Shopping is a terrible thing at any time of year but when the entire country is in panic mode over a certain approaching date this gets amplified even more.

I put on half a stone (that's 7lb or 45grams in new money) in 4 days, and the amount of nibbles that I still have lying around doesn't look like it's going away anytime soon.

I got back into modeling - you know, that thing that I am actually supposed to be doing - and created an animation for the defensive airstrike powerup.

Here's an animated gif, which has been converted into an mp4.

And here's a video of it all in action. It's a defensive powerup so it has a chance to be triggered whenever the player takes damage.

So onto the boring recap.

With the addition of tentacles, I finally completed all the basic enemies and their various special attacks, finally relegating the need for the red placeholder cube enemies which had been the standard for x years too many.

Levels started to get designed (I am about half way through them) and the flat grid world was finally relegated to history.

I eventually upgraded to the latest version of Blender 2.8, after having previously been using the 2007 version which I had found more than adequate for the last 12 years - read as; I don't like unnecessary change for it seems to be a right old faff around.

This change was partially enforced as it deleted another Blender version 2.7 I used for editing normals when v2.8 installed and then it was a simple case of "oh bugger, no going back now".

Thus I was forced by circumstance and the slings and arrows of outrageous fortune to get with the 21st century and learn how to export models and animations anew.

The good thing about upgrading to the latest version of Blender was that PBR suddenly became available, though it was another thing to learn on-top of everything else. Whilst I work on PBR related materials and design, my main test engine is still Dx9.0c for the time being, but will be updated later to brand new fancy Physically  Based Rendering capable Dx11.

Ears go up ...

 

Ears go down ...

Placeholder Player yellow cube was also retired, and replaced with what will hopefully be the first of several playable characters. It's GunGirl, leggy catgirl strapped into a propeller driven harness.

I made a start on boss monsters for each level.

And that was the year that was. Somehow doesn't seem enough. Progress continues next year.

I've made one ...

tl;dr Some things happened, something didn't.

So onwards and upwards. Can't wait for the Olympics next year.