This week I finally implemented the dynamic item generator framework as the final system needed for procedural loot. What this does is control injecting random properties into item definitions on creation based on difficulty and rarity of the creature that was killed, and of course randomness. Its sematically similar to CowTrix’s creature mutator system and will be fairly similar to configure.
My test item isn’t very exciting, but shows 5 copies of the same item with different random properties applied to it on creation. Variations on the pick include colors, attack speed and mining power. The paintable pickaxe is a rubbish programmer art test also, but it proves the concept ready for proper content. The thing that stands out most here is the lack of an item icon renderer that shows any difference between them, its on the list of things to do, but for playtesting its not needed so I’m putting it off.
From the SDK side, the randomization of items is configured like this:
Also Mils spent a bit of time making some awesome icons for our SDK, so our custom types aren’t all just white squares anymore and you can actually tell them apart.
Today I’ve been putting together the blueprint system so that loot sources can drop a procedural items blueprint, you can decide if you want to craft it based on how good it is / if its an upgrade then load it into a workbench for limited uses. I should have that going by mid week, we are hoping to have an ItemV2 super rough prototype RPG progression test build up, with procedural creatures + loot working together for the first time internally by Friday. If this ends up being fun at all, I will push it out to our experimental branch and you guys can check it out.
This week I have mainly been working on allowing us a to spawn variety of enemy types via the custom colour shader that Tom has mentioned previously. This involves isolating sections of the albedo texture via a RGB mask and allocating the strength that the RGB mask has on your texture via the alpha channel.
RGB Mask example.
Example of an Alpha for the RGB Mask
Hey folks. This week I’ve been fleshing out the spawn building, fixing a few bugs in the HurtDatabase, looking into some possibilities for creature scaling, and setting up some temporary gating mechanics for creatures so we can test progression. Work was a little slowed by a big reorganisation on Tuesday, but we’re back to 100% now.
Spawn builders – the thing that takes a spawned object like a creature or a resource node, and changes it to fit the environment it was spawned in – are now a lot more fleshed out and easy to extend. I spent some time moving them across the Spencer’s generic value generation stuff, added in support for changing mesh attachment colors, and they are pretty much ready for content generation.
I’ve been looking a bit into exactly how we can gate harder creatures for players, so they have some kind of gear-check or skill-check. This led me to find a couple of issues with how we were using EntityStats on creatures, mostly with them being entities that didn’t think themselves for performance reasons and so more complex operations didn’t work with them. I implemented some prototype concepts like armor (player’s must do above x damage to a creature for it to apply), health regen that can stop when the creature is getting attacked, and a real temporary gating mechanic which pretty much means if you attack a creature above some magical number, you get killed real bad. Now emphasis on all of these is temporary, it’s unlikely that the real creature progression will work like this, but for now it gives us some temporary levers to pull as we figure out what the item, crafting and weapon progression looks like. I’ve pretty much just laid out a gradient of difficulty in a test level, to try and crunch down the game into as small a physical space as possible to focus purely on mechanics.
This last week I’ve been finishing up the 0.3.8.2 patch that was just released. As well as the rock check fixes I talked about last week I also patched up a bug in player to player collisions that was allowing people to see through walls. This occurred because we had a slight mismatch in character collider sizes where the colliders of other players clientside were slightly bigger than serverside. This meant when running into other players the client would stop before the server where it thinks the player collider is but then because of our server authoritative netcode it receives a correction to where the server collides. The problem is this ‘corrected’ position is now inside the other player which stuffs up all the collision checks being made during clientside prediction allowing players to run briefly through walls and other geometry before getting a correction from the server.
I also finished up the model viewer changes to allow previews with any characters implemented under our new mesh attachment system (players, ai and vehicles). It also can preview any animations assigned to the character and recolor any colorable attachments that have been setup, this allows you to preview content without having to rebuild your mod pack and load it in game.
I got the normal baking and 90% of the texturing done on the AR15 Receiver this week. The baking went fabulously, thanks Handplane Baker! I switched to this a little while ago because while XNormal is great, Handplane Baker has some time saving features. Everything baked out without much fuss. I moved onto the texturing and got most of the way there. Smart materials in 3D Coat are performing smoothly. I also added a few variants of custom plastic smart materials to my tool set, which were used on the AR15’s Grip.