Autumn Arrives And Ai Attack

 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 ...

Anniversary 10 Years On Steam

  

Airship Dragoon has been on Steam for 10 whole years. Even Albert Spier only got 30 years in Spandau ...

To celebrate this monumental event I put the game on discount of a whoppinh 95% ... but Steam only allowed a 94% discount due to transaction charges converting into US dollars. So 94% it was, slightly odd number that it is.

One of the interesting things that I found was that the Far East of Korea, Japan and China did make the top 10 for sales. This was especially gratifying as I knew there were plenty of pirated copies in the early days floating around China due to the amount of traffic my website got to download the additional map pack.

In other news, August draws to a close. A month of scorchio sunshine, sitting out by the veg patch, absorbing vitamin D in non-capsule form and sewing myself a medieval bag hag (summer pattern), going to make a winter one with felt to ward of hypothermia later. 

Alas the baking sun meant that the veg patch was going bone-dry, especially as the water barrels had been emptied. Roll on some rain, in fact after the utter soaking for the first half of the year, if it could just have kept a bit back for mid-August instead of swinging from "I need to build an Ark" to "I need a Thumper to distract the sandworms", it would have been appreciated.

Behold my mighty carrot crop! That was it ...

 When it finally did rain it did at 3.30am, so I was outside changing water barrels over with a coat over my jim-jams. If anyone has a working weather control machine who is not CIA, please could I have some more rain.

I also updated the demo for Monsters Loot Swag, to the most modern working build of the game. The old version of the demo had been removed due it being built with Ye Olde game engine version which predated Torque3D 4.0 and the fancy asset system and PBR (Physical Based Rendering) materials.

In other indie game dev news, I finally fixed all the networking jitter I had previously been fighting ... by simply ripping out the custom player class code I had written and using an actual seperate camera system. I had always had a sneaking suspicion that trying to go through the player class and directly use the player object's own cam/eye node might not be the best way of doing things, and in the end, said sneaking suspicion was more jumping up and down suspicion with total loss of stealth abilities.

I decided to use the Open Source 3D Action Adventure Kit camera system as a base, and after a bit of modding I got it to work with my existing lock-on target system. Behold - moving AI who have been locked on by both hosting client and remote client - now without any jitter!

So that was August, and now we will be onto September, named after the Greek "sept" meaning seven, because it's the seventh month ... or at least was until two despots added new months after the sixth one, and conveniently named said months after themselves ...

Anyway, next up on the dev frontier, Monsters Loot Swag only needs 1 more level with enemy boss, and 2 more unlockable players making, before a bit of tidying up to finish it off. I am not in a rush however, as I would rather ship in early to mid 2025, and thus give myself time to get the next game concept furthered more, hopefully to the point of having some real gameplay and a store page available for coming soon™.

As my previous attempt to drum up interest with the Monsters Loot Swag early access release didn't achieve any support, I might try an open beta next time.

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.