For the last few weeks I've been working a bunch on Inventory management, and a first pass of Zombie behaviour and visuals.
Basic Zombie Art!
I made a Zombie model for the game! It's nothing really to write home about, pretty simple, just a greyish looking bruised human with blood and tattered clothing.
The model in Unreal:
Models in the dark:
It wont at all be the final art used for the zombies in the game, but I wanted something as a standin asset that could roughly approximate the costs of the final zombie models.
Typically, I try and avoid including any art during the prototyping phase. It's too easy to become bogged down fiddling with art that you've fussed over - but this zombie only took a few hours to make, so as far as I'm concerned it's deposable! The key point is that its a clothed zombie, skeletally rendered and animated, and it has a triangle count approximately in the ballpark of the final zombies.
This gives me a great benchmark for how many zombies can be handled on a consumer machine, and what needs to change in the art pipeline to facilitate that. At the moment they are simply skeletal meshes, but later these will probably be ported toward vertex animated textures or some sort of instancing implementation.
I have some more WIP images here (WARNING - the images contain mild nudity):
And lastly, an update of the zombies animated:
Zombie AI / sensing!
Zombies now have rudimentary sensing capabilities. They have a primary vision cone, and a secondary vision lost cone - basically until they are alerted, they sort of have bad vision, but once alerted they have a much wider field of view. This is to stop players sprinting right past them or hopping over them and breaking line of sight when they really shouldn't be. You can see these 2 vision cones drawn in yellow / aqua below:
They also have a basic "memory", meaning that if they notice you through a window, and then you duck down suddenly, you won't just "vanish" in their mind - they will know where you are for a few seconds, and begin seeking you out in that area. After an extended period of time, they will eventually totally forget the players exist. I'm using the "Sense System" framework for Unreal, which is very capable and quite performant!
I've also done some work to ensure that zombies can properly navigate a dynamic environment - below you can see a visual representation of the path a zombie is attempting to take to their goal:
Zombie AI behavior!
I've also been working on the high level AI behavior of the target, and you can see an example of the state tree here:
The behaviours are pretty self explanatory - but TLDR its all the basic stuff you expect from a zombie. Meander around if they don't know you're there, but relentlessly peruse and attack you if they DO know you're there.
Something I want to really try and expand on at a later date is zombie "signaling" - so that the player knows without double when they have been spotted by a zombie (via snarls, growls and posturing), and when they have lost them (via frustrated grunts/noises/animations)
I'm prototyping the behaviour out using Unreal 5's new "state tree" functionality, so fingers crossed it should work for everything I need it to. *fingers crossed*
Inventory management
Heaps of work has been done so that items can now be generically moved between all inventory types. Before they were sort of jankily hardcoded just to get the feature off the ground and working in multiplayer, and I've since gone back and generalized it.
The game has several "inventory types" - humanoid inventories, corpse inventories, map inventories, and complex procedural inventories. Why so many? Well partly because its all prototype, but also because I have to have some edge cases in a world with millions of inventory containers in multiplayer.
The player facing change is that players can now drag and drop items between their personal inventory, and either the inventories of corpses, or the equipment of those corpses (and vice versa). I think its good to prototype and iterate on the requirements of the systems (but it would have for sure been nice to get it right from the start.)
State and Render seperation
Previously, map meshes/chunks were coupled directly with their state - this is no longer the case. So now I have an object and a container for all the map state, and an object and container for the RENDERING of that map state.
TLDR - I can render the map without having any state loaded for it - and once a player makes changes to a region, I can then store that state and begin replicating it in multiplayer. These changes are then spatially chunked and only replicated to players within that region. Typically with UE4 you'd have to do this with actors, but actors have such a prohibitively expensive cost when they are used at massive massive scales. So I had to come up with something a little more robust, and it seams to be working out well so far!
Summary
Not all of the above has made it into bleeding-edge yet, but itll get there in the next few days. If you want to follow along with the development more closely, feel free pop into the discord:
https://discord.gg/F3pZhnzeTP