"Raven Errant" is the name of my new game, who's development I have been showcasing on this blog for the last 12 months. It's a third person hack and slash were roaming bands of raiders move about campsites looking for loot and plunder, often from each other.
The player starts off wearing a pair of comedy boxer shorts with a love heart print, and steals the clothes off corpses, flogs them in exchange for XP, and then upgrades their stats to equip better clothing, armour and weapons.
The player can enlist in these roving warbands - if they will have then, or they can wander alone, picking off stragglers and leveling up to become a one man master of battle. There are some good reasons for enlisting, firstly safety in numbers, ask any school of fish, but also that if you follow a team around you get rewarded with free XP, making stat upgrading a little less of a hardship.
Friendly Carolingians are friendly
Raven Errant will be launching as an Early Access title soon™, initially featuring 8 Raiding Parties which is around half the planned number, and in chronological order is from around the 5th Century (Avars) and up to the 11th Century (Normans). When complete there will be twice the number of Warbands and much more equipment, armour and weaponry will be available.
Raven Errant is currently waiting in review on Steam, so the Store Page is not live yet, but will hopefully be available in a week or so.
I used to be an adventurer like you, but then - whizzzzzz ack! Since this video there is a cool motion trail effect courtesy of a ribbon particle behind each arrow as it cuts through the air.
So archery has been somewhat missing as I have been concentrating on devising an animation led melee combat system. This now work rather nicely (except when it inexplicable doesn't play the prepAttack animation and I have to throw in a safety call to get it back on track) so it was time to get on to ranged weaponry.
Cue Clannad and the greatest decade in history, the 1980s.
Now, because I've upended the whole stock animation system, it turns out that mouse aiming system no longer works, because who wants mouse aiming to override a melee based animation system? Well no one, so that will take a bit of looking into to fix. However the actual aiming and shooting works, even if the AI and client Player doesn't currently animate correctly to look like it, due to the removal of most of the blend animation code.
I have a variety of ranged weapons coded, both differing sizes of bows and crossbows, with bows requiring greater stats in both STRength and DEXterity for use which make them much more expensive in XP spend to use, but having hugely quicker reloading than crossbows.
Projectile damage is based on a singular strike to the target's hitboxes, so whilst a heavy melee attack can cause damage to multiple hitboxes with a wide slashing motion, arrows cause damage based on range to target to simulate increased velocity from loosing up close and the archer's ability to pinpoint weak areas in the target's defences. Getting struck at maximum range whilst wearing a full harness is most likely to plink off, but getting shot up close with 300lb of draw weight is another matter.
The main level has had a bit of a revamp, with more trees and shrubs in the open side of the map, but there is still plenty of nice open space for longbows to wreak havoc.
I also converted my AiPlayer routines to use the new stock engine AiController system, which can be attached to any playable class including those usually restricted to clients, to turn them into Ai controlled - hence the new classname. This class has a lot of dynamic avoidance and automatic repathing systems, but even without those I found it to be very heavy on processing. Whilst still useful for being able to control the usual client based objects, it's clearly something to be used sparingly, and to keep the standard Ai based classes to themselves.
Archery is pretty much the final part of the Ai warbands and battle system, and with it now functioning materially (if not animating aiming perfectly) I need to integrate it's use into the AiPlayer combat routines. The most obvious example is for a warband that outranges an opponent is for them to stop, hold fast, and pepper the enemy at distance whilst they themselves seek to move to attack.
Whilst this is all in the works, here's a video of meeting engagement between the Norse and the Magyars, the latter of whom will be one of the more heavy ranged weaponry factions in the future.
Aside from fitting archery into the individual AiPlayers' combat routine, I need to come up with a method of allowing the player to use archery effectively, regardless of their third person rotatable camera system. The obvious cop-out here would be to follow Elden Ring's lead and switch to first person for aiming. Maybe I can come up with something else which retains the third person view ... ?
Speaking of the player, to be honest they haven't really got a lot to do at the moment, as all my efforts have centered around making the AiPlayer's work as cohesive raiding parties, so next up after I tackle the blended aiming animations, is to give the actual client player something to play.
It's February, and it's ending early, somebody stole 2 extra days that I could have been coding!
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.
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!
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.
As the year 2024 comes to completion, so has the list of playable characters for Monsters Loot Swag. Schiavona is the 8th playable cosplaying catgirl character and fourth and final character who has to be unlocked via achievements. She is a close range, melee based character, with fairly average physical statistics, but is very heavy on inflicting damage.
Cue video of her in action:
All that remains for work to complete the development of Monsters Loot Swag, is now the final level with boss character, and few art related pieces such as an intro containing plot, as if 8 playable cosplaying catgirls battling 8 waifu level bosses needs such flippery as plot!
Airship Dragoon has been on Steam for 10 years
Airship Dragoon got two updates at the beginning of December, the first was due to a new Steamworks SDK which had broken some of the 10 year old code for Steam integration, and the second was because, whilst testing the first update on Steam to make sure it actually worked ... I found a bug from 12 years ago ...
Thankfully, 12 years ago me ... who may still have been in his late 30s ... had left a code comment incase something happened that was not supposed to happen - and during this test of the new Steamworks code ... it happened.
The ancient code comment made it relatively simple to track the "something happened that was not supposed to happen" down to a specific function were pathfinding was sent if it completely failed - something so rare I had never had it happen, not anyone report it in the last decade, but I had not added an escape of any kind to this failure state, and so quickly scripted an emergency "move elsewere" command, so not to get stuck.
Rounding out the year work-wise, I finally filed my tax return with His Majesty's Robbers And Crooks (HMRC), something which the gubbermint has gone out of their way to make ever increasingly difficult. Their oh-so-helpful system active attempts to stop me from paying them money and every year I send feedback telling them that their crappy website has been broken for the last 7+ years and tell them how to fix it, every single year.
I ran out of characters typing into the complaint box
For 7+ years they have not done this
As it's Decemeber, and the time of eat, drink and get indegestion, I bought the biggest steak at a reasonable price that I could get.
Hello Vitamin B12!
Suitable Protective Clothing For Roasting Such A Beast
Went For Medium-Rare For Fear Of Some Folks Freaking Out If It Was Still "Bloody As Hell"
As Monsters Loot Swag comes to the end of it's development cycle, I naturally have one eye on the next project. Previously I had posted some of my test work on a third-person melee combat system. As my previous two projects have taken so long, I had been wondering about how best to make a short form game that could be expanded on if it received due interest from players.
I noticed that there had been quite a lot of complaints on the new Stalker game, about how it's open world design had broken it's previous a-life simulation, and I thought that maybe going down that route could be interesting - both in gameplay but also in coding the concept.
So, something along the lines of a 4km square map (not too big), with bands of enemy warriors from different areas or periods (Saxon, Norse, Magyar, Venetian, Chivalric, Landsknecht, etc) wandering about, picking fights, fleeing greater enemy forces, with a smattering of random loot and treasure chests, maybe some wild life plodding about.
I had a brief test to see the ballpark range of having lots of Ai players visible, having them invisible, not rendering but still having to update physics each engine tick. This was done in debug mode whilst running an IDE so naturally the framerate was terrible, but it did quickly prove what I had suspected, which is rendering 200 skinned meshes is a lot more overhead than just processing the physics for 200 Ai players.
In a player build test without the overhead of debugging, the framerate was 500fps empty, 80fps with 200 characters rendering, and 350fps with 200 characters not rendering but still updating their physics. Not that I would ever consider having 200 Ai players battling it out right in front of the player's camera.
It will be interesting to see what sort of load I put on my processor and gpu if I remove the Ai players when they are nowhere near the player and turn them into scriptable objects who would then approximate their actions using RNG as they move around the map, out of the player/client camera fustrum and view range.
Anyhow, that is all for a later date. I hope you have had a Merry Christmas, and here's to Space Year 2025!
The big Summer fan has been put away - not that it got much use anyway - and the Autumn duvet (which is just a second Summer duvet doubling up) is out. The slow cooker has been dusted off for comfy one pot meals, and the hot water bottles are at the ready.
And it finally rained, and my parched veg patch was happy, and all the water barrels got filled up, and now it won't stop raining and the veg patch is flooding.
Code wise, I've been working on my Melee Combat Demo, getting the Ai to fight one another.
The first problem was, well, the other Ai, and them getting in the each others way. In Monsters Loot Swag this was a more simple problem, as I could just have them jostle each other out of the way, with a variable to succumb to any charging monsters who were "coming through no matter what", like bosses.
In Melee Combat Demo I don't really want to shoving everyone and everything out of the way so much, especially if all the people in front of Mr.Ai are already engaged in combat. It's not very helpful to shoving your comrades onto the sharp pointy bits of your foes' weapons.
I came up with a simple; "is there a better target?" check. And if not; "can we easily get around the side?" of the queue in front of us, and if not then just wait. And if no useful data comes back, then to hell with it and go charging through like a bull in a china shop.
Ai use an alert system for readiness, which decides on how fast their thinking routine is called. It starts off at "chilled", increases to "look for trouble" and hits the summit of "oh shit things are kicking off" ... also known as 1 to 3. All these schedules for looping the think routine are modified by the skill or leveling of the Ai, and that is currently based on what weapon rank they are using.
Starting alert looks to do something, but at the moment all I want them to do is test combat, so they move to search mode and head towards any enemy that they can find. There is a brief lull between this and going into combat alert which means that in the test they do make physcial contact between the two teams before all hell breaks loose.
And here is the result of the testing, after I inserted many, many lines of debugging to the console to find out which bits of my maths were bad. Team Bill the blocky blue guys massacre Team Bob the purple-ish LODed guys with a score of 5-2.
Needs more work but it's a decent start and at least does work as team based melee combat.
In non-dev news, I actually played a game recently - shock horror.
Not since Ace Combat 7 came out have I actually played anything, but I got Kingdom Come Deliverance on sale some time ago, and took a couple of weeks out to hammer a good 130 hours into it. I wasn't really playing the story much, just bimbling around medieval Bohemia accidentally finding side quests and generally shooting bad guys with arrows to slow them down and then stabbing them in the neck if they got too close. It's a strategy I'm sure worked in the 15th century too.
The game world is quite pretty to look at, the first person combat is autistic but passable.
So to the future, more getting Ai melee combat to work nicely, and then start thinking about equipping the characters with more kit. I'll probably also start thinking about making another playable character to be unlocked in Monsters Loot Swag, and probably complain about the weather more, but that's probably called sport to my Saxon blood. Also three probably's in one sentence is terrible grammar, so I'll probably stop writing there ...
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.
The Dreaded Lurgy is a Rare SWAG Power-up. It is an Attack Based event which causes the targeted MONSTER to succumb to the Dreaded Lurgy. The infected MONSTER is highly contagious and will transmit the Dreaded Lurgy to any other MONSTER who they come into contact with. However, after receiving the dark gift of the Dreaded Lurgy, the victim is now immune from further infection.
Annoyingly
this is also a thing in real life, and I have spent the last month
suffering from The Langshan-Po Lurgy - a free internet to anyone who
gets the reference, but Gen-X (greatest generation) here, is probably
just showing his age.
Needless to say 3D vector maths, gimbals,
quaternions, cpp and general cerebral activity, has been somewhat
compromised with lurgy brain fog. In celebration at the cerebral
degradation - which hopefully will only be temperory - I have revised,
both the icon and the in-game activation event art, for
The Dreaded Lurgy.
However
during this time, Steam has snuck out a new update to Steamworks
(v1.56) ... which broke previous coded
SteamGameServer::getAuthentication - thank you Valve devs for the code comments which gave a good explaination of the new changes.
It has also spent all month raining again - just like last month. So it turned out in the end there really was enough rain for April showers. In the midst of all these downpours there has been a frequent visitor, and pidgeon numbers are being reduced.
Who's a pretty boy, then?
In the world of melee combat coding I decided to try a new way of doing things and ended up on some terrible code carousel, going round and round in circles - and having the Dreaded Lurgy did not help brain function.
I had wanted to look down a list of the target's hitboxes and check if they were within the bounds of a weapon's hitbox. This caused far more problems than I had preceived, with a total lack of being able to get the transforms and orientation of the hitbox meshes within the model. When I could get the hitbox mesh itself it wouldn't allow me to translate it to into world space because it was the wrong class, when I had world space I could not access the hitbox mesh because that was then the wrong class.
I could test a strike against the target bounds and check for intersecting but then to get the actual hitboxes still required using a raycast against all hitboxes to get their transforms and then suddenly we were into more load than I had before.
Dave is made of hitboxes and the raycast is checking alignment of the forearm hitbox
The only thing I can think of is to create a whole series of points within each of the target's hitboxes and and then check the Box3F of the weapon hitbox against all these points --- and once again we are into even more load, and not the less I was hoping for with just intersection checks of boxes.
Giving all of this up as a bad job, I decided to use the 4 main edges of the weapon hitbox and fire a raycast down each length for more accuracy than a single, central raycast check. This has turned out to be infinitely simpler than going down a list of up to 20 hitboxes checking for intersections.
I also coded up a fatigue system for heavy attacks, sprinting and swimming, and completely rewrote how fall damage works. I started to add attribute statistics for the player, which are fairly similiar to standard RPG stuff with STR, DEX, CON, etc, and the start of a leveling and experience system.
Next up will be to code classes and jobs with bonuses for these attributes on how fast experience points boost them.
Next month I am not certain whether I will continue with the melee action RPG prototype or start porting Monsters Loot Swag to the newest an shiniest version of the engine - I expect it will be a bit of both.
The Dreaded Lurgy is finally subsiding and I am down to a dry and
somewhat sore throat with an occaisional dry cough. A pox upon the ...
er ... pox!
It seems to have been raining forever - at this rate there will be no water left for April to have showers ...
Monsters Loot Swag has had it's 13th Early Access Update! This fixed a whole load of minor issues and one major one - the awful openAL crossfade falloff has finally been slain ... with, naturally, a 2 line fix. 😫
Turns out it all that was needed was to feed openAL an ini file to tell it to stop dropping the fall off so early.
Also our leggy, harness encased, propeller powered catgirl has been testing an engine upgrade with glorious PBR! For which I made a Cornell Box in Blender 3D.
Reflections! Shiny, shiny reflections!
Now, updating the whole game to a new engine build which features not only shiny stuff like PBR, but an entire modular system is going to take some time.
However, talking about new engine builds with funky modular features, I have been coding an animation based melee combat system in C++.
So far I have light and heavy attacks, activated by either tap or hold input. Both kinds of strike share a single Prepare Attack Animation, which works like a charge-up, and is based on weapon type. Light attacks are randomized, whilst heavy attacks are based on player input at the end of Prepare Attack Anim.
Each weapon has it's own attack speed and the player themselves have a "rage meter" which increases attack speed with the more blows they land on an opponent.
There are also primary and secondary types of damage, for instance a broadsword is primarily for slashing but can also stab. I plan on introducing different styles of armour (gambeson, lamellar, chain, plate, etc) which offer varied protection against the major types of attack damage of slash, blunt and stab.
Here's an animated gif showing a light thrusting attack - this was before I added weapon specific speed modifiers.
Light Attack - Yellow Circle Capturing Button Input
So that it was it for the wash out of a month which was March. I had was planning on setting up the Spring duvet for my bedding, but it's been so miserable and cold I think I will stick with the Winter duvet for another month. 😰
.jpg/480px-Flaming_June%2C_by_Frederic_Lord_Leighton_(1830-1896).jpg)
- thank you Valve devs for the code comments which gave a good explaination of the new changes. 
