Sunday 31 March 2024

Terrors Of Retopography

4K tris versus 8K tris

 Amongst a slew of bug fixes I have been designing a new unlockable playable character. This has once again led to problems of topology - or more accurately retopology from a not very high poly character to a much lower poly character.

You would think that there would be some automated plugin that could do all of this for you, that it could take a mesh with a lot of triangles and reduce it whilst keeping some semblance of the vertex point weightings. And there is, and it can ... except you have to kiss goodbye to your nicely laid out UV map. Now you try modding this ...

Behold the computer generated horrors beyond your comprehension

It does a really good job of decimation and a really terrible job of UVs, textures and materials in general.

The problem appears to be that my starting mesh is some +20K tris, which is great for an up-close viewing of the character - especially in the viewports of Blender - but not so great when you want it reduced auto-magickally. Especially as I hate manual retopology due to it being the utter epitome of donkey work.

If only you could just remove edge loops in a sensible way - but wait! You can! Blender has it's own decimate modifier, and surely loops can be reduced just as the can be increased? Yes but no.

Just auto-reduce loops bro! Yeah but nah, but really wtf is this?

However this is something that could be cleaned up, and in the end I did, thus using that as a new basic mesh to work from, and it's a much more reasonable 6K tris. And after customizing that to a new character, it can be manually reduced by merging loops to keep the bone weights and UV maps intact.

Try and spot the difference from the actual game camera height

 Once again the real problem seems to be the tunnel vision of working up close in the modeling editor, and I am sure that that 4K mesh could get some more reductions without anyone ever noticing. However it appears to be not just me that goes overkill on character meshes ...

Squint percentage per eye ...

Dragon's Dogma 2 character creator allows for squints by percent per eye ... but in-game, your character is barely a third of the screen in height. Not sure that is going to be all that visible when your character's head is only 64 pixels.

My new playable catgirl cosplayer is called Polaris, and does that 北斗百裂拳, Hokuto Hyakuretsu Ken thing minus the waaa-ATATATATATA battle cry, so you'll have to shout it yourself. The character portrait isn't completed yet and I'm still balancing the stats and attack attributes, so update to Steam should be next week.

It's British Summer Time, at least horology wise, I am removing the winter duvet, so naturally the weather has taken a turn for the worst. Maybe with April here Spring might finally start, as it seems to have done nothing but rain and be generally miserable since October.

 

I also had a thought about the methodology of making a roaming brawler, one where the player could upgrade to the move sets and customize their own controls based on fighting styles and how to code this as combat events. This brought me back to thinking about the melee combat system I coded an example of previously which uses hitboxes, and whether that would be good gameplay system; a (probably side) scrolling roaming hack and slash where you level up your character not just with attributes but also armour and weaponery, restarting each "run at the game" with all the new stuff you earned in previous runs. This way the player would start off very weak and get killed quickly, then spend whatever XP you acquired on better stats or kit and go again, eventually leading to the player becoming massively OP in early levels. It would work a bit like reverse permadeath, with the player's XP being permanant and allowing the unlocking and equipping of better weapons and protections but also melee based move sets that could be customized to control binds.

As Monsters Loot Swag near completion, 1 more level with enemy boss, and 2 more playable characters to add, I am beginning to think more of what the next game will be, and after having created the proof of concept for MLS NINE FUGGING YEARS AGO I think I need to work on a shorter development cycle for my next project.

Thursday 29 February 2024

Leap Into The Future

Monsters Loot Swag Now With HDR And PBR

February has arrived ... and by the time you are reading this, it has also gone. But not before Monsters Loot Swag got a huge update on Steam, and has been ported to a completely new engine build.

This included finally retiring the old engine build and replacing it with the latest game engine build, complete with all of those 21st Century shiny things like an asset system, HDR lighting, Physical Based Rendering of reflections and so much more. The changlog itself ran to some 36 items.

In other game development news, I also ported my old "Aeronauticals" proof of concept demo to the latest engine version. You can download and play that here and watch me do just that below.


 February 2024 is a Leap Year! And soon to be leaping are what is in this pond! 🐸

However since this arrived there has not been much froggy activity due to the weather reverting to being bloody freezing for the last few weeks. Thankfully it looks set to become milder and much croaking was heard earlier.

So that was the month with a strange number of days, and all because two despots mangled the perfectly working 10 month calendar by inserting their egos into new months and totally throwing time out of order every 4 years.

Wednesday 31 January 2024

Space Year 2024 Is Go

 

DIY gambeson, with padded arming cap (not visible) to stop sallet wobbling on head - it's everything you need to keep warm on a cold winter's night ... or possible prepare for the GREAT HAPPENING when modernity crumbles and all is returned to the ashes ... 

Monsters Loot Swag has received it's 24th Early Access Update, available here.

Speaking of which, I ran some of the game engine's internal debugging tools - which I have previously been unfamiliar with - to see what was happening with networking. Alas these debugging options were not as helpful as I had hoped ... 

TORQUE_DEBUG_NET for NetConnection packet logging, DebugChecksum guards to detect mismatched pack/unpacks, and Detection of invalid destination ghosts. Link to PacketDataChecksum disagree code.

TORQUE_DEBUG_NET_MOVES for detailed console logging of net moves. Link to moveChecksum disagree code.

What I got was kind of annoying and much less useful than I had hoped ...

Test1:

Spawning into a loaded level, with the randomized gameplay assets unbuilt (the Swag), I got 6 packetData and 17 moveChecksum disagrees, all from loading the level to the client and then spawning the player object.

Shooting 6 times gave me 3 packetData and 3 moveChecksum calls.

Moving around in a small circle had no effect.

Test 2:

Spawning into a loaded level which had then been populated with the randomized gameplay assets (the Swag), gave 4 packetData and 38 moveChecksum calls.

Shooting 6 times have the same 3 calls for each.

Moving around in a small circle for a few seconds gave 57 calls for both packetData and moveChecksum.

Conclusion; everything that gets loaded AFTER the level has been loaded is going to throw checksum disagree calls with every update of the client's position just because it wasn't in the original level file. Now add hordes of monsters, explosions, projectiles, etc and there is a huge amount of console spam with very little debugging value for networking ... :/

The good news would be no packet dropping showed up.

Anyhow, we perserve.