Boxes In Boxes

 

According to the weather forecast, she will need a jumper ...

After getting mild sun burn sat out by the veg patch with a bottle of wine, we are now back to standard British weather of needing a jumper for late Spring and early Summer ... Flaming June looks like it means that the fireplace will need to be lit ...

Steam brought out an update to the Steamworks SDK, sneaking it out again as they did in the previous month without any fanfair. Once again they had made changes to the authentication system, and once again I had to wade through code comments to find out what it all meant - except this time I also had to wade through the online documentation, complete with it's links to various 404 dead pages. To quote the docs at https://partner.steamgames.com/doc/webapi/ISteamUserAuth:

 NOTE: This call requires a publisher API key to use this method. As such this API MUST be called from a secure server, and can never be used directly by clients!

So, yeah I'm good, this was just splitting up web-based games from the standard Steam Client authentication. Also feel free to click the api.steamworks link at the bottom of that page for more helpful advice. 😉

In April I had attempted to create a melee combat system of checking through a defending player object's hitBoxes for intersection with an attacking object's hitBox - to see if this would be faster than using a raycast system of quad edges projected from the attacker's weapon - all whilst suffering from the Dreaded Lurgy.

What I found, during illness enduced brain fog, was that there was no current system to determine whether rotated worldSpace boxes intersected (OOB) only AABB. Now without the brain fog I had another attempt at coding a solution to this, with a nice easy early out if half longest box sides added together were beyond central distance, though ended up using raycasts after all for the actual connection checks, which were oriented in worldSpace with the attacker's box and then a perpendicular test if no initial result was found.

The end result was that I found checking through the defender's 12 hitBoxes (but potentially up to 20) could easily take more than the standard 4 raycasts which I had been previously using. On top of that, box intersection would take more the boxes behind the initial hit into account, nearly doubling the struck areas, so a big melee swing would 98 damage rather than 40 something. To order these results in worldSpace would require another raycast or more maths based on location and orientation.

tl;dr - I've kept my original melee system, it works fine for what I want, but I might use the OOB intersection for weapon on weapon parrying.

So, that was the month that was. Flaming June awaits, with a promise of thick jumpers and hot cocoa ... 😒

The Dreaded Lurgy

 

 

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. 

The Steam update for Monsters Loot Swag is here.

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!

Damp Island is Damp

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