Spencer
This week we’ve been focusing on getting our survival systems back to baseline for ItemV2. I’ve been putting off re-implementing the legacy progression as most of it will change soon, however its been hard to get a grasp on what needs to be fixed while we can’t play the game. So cow_trix and I have spent most of this week fleshing out the basics needed for simple survival. For me this included bringing AI into ItemV2 land, and implementing a new loot table system that is based on ScriptableObject assets instead of hardcoded C# files.
Just like all our other asset based configuration data, these loot table files will be inside the SDK and will be easy to tweak and replace without any coding or oxide knowledge.
Here is an example of the first cut loot table configuration:
I also implemented the new AR15 mils has been working on, I will push it out to the Deathmatch branch tomorrow.
Mils
I have been adding components to the AR15. There are two sets of parts now for it, we are testing the parts in game to see how they feel so that I can get the go ahead to texture them. I’ll be making parts for the Mac-10 this week and maybe looking at other guns too.
Gavku
I am currently finishing of a pair of low riding jeans with player boxers peaking over the top. Below is a picture of the pattern from Marvelous Designer, with the white parts being the boxers, and the blue the jeans. It took a fair bit of noodling around, activating the sim, pausing, pinning, repeat to get them to sit right. I had a placement belt which I later replaced with one I made in max.
This is the resulting sculpt in Mudbox. I am currently retopologizing and finishing of the low poly.
Cow_Trix
Hey folks. This week I’ve been working on getting Hurtworld back to baseline survival.On my end this has meant getting navmesh generation working in the SDK, setting up Nullius and solving some regressions in map generation, laying out spawns and loads of bugfixes.
First up was a bit of work on my road tool, fixing some issues with generation where a connection between two nodes would sometimes be “flipped”, so that if you asked it if a point was within or outside a connection, it would always get it wrong. This meant that some connections wouldn’t affect the terrain properly. I also figured out a bit more how to use the Unity Editor’s ideas of selection and focus, which solved a lot of bugs around clicking on nodes and selections and Unity instead selecting the objects behind those objects. I also fixed some issues with how meshes were stretched along the spline – I was previously using the natural time of the spline to translate the mesh points along it, but this led to some weird artifacts, so I changed it to a uniform time.
I’ve been trying to get the basic elements of Hurtworld running in the new map – gathering, crafting, hunger, and heat. This meant getting all the spawners up and running, all the biomes configured, and all procedural. There’s still a couple of things we need to do to make generation completely procedural, there were a few things I was left doing by hand at the end of the process. There’s just no comparison with the pipeline we used to have though, things are a lot easier.
Something we can do really easily to play around with increasing biome difficulty as you move around is Overlay biomes. These mean you can have a root biome, which is your starting point for things like temperature, effects, hazards, and lighting settings, and then permutate it as you move out to harder areas instead of having to make an entirely new biome from scratch. So, instead of having to specift a MildDesert, MediumDesert and HarshDesert each with their own set of properties and settings to maintain, we can instead have some BaseDesert biome that specifies our baseline, and add Overlay biomes that for instance increase the temperature by 10 degrees across the board while making the sunlight strength higher.
At this point Nullius is looking pretty good. While the map is still pretty basic in it’s spawns and and probably a little too forgiving – there’s about 4 resource nodes every couple of meters at this point – it’s a substantial step!
Tom
This past week I’ve been working on integrating character customisation into ItemV2. Our design is to interrupt a player’s spawn (both loading into a server and respawning after death) with a window presenting the customisation options. Once the player has picked their setup they’ll spawn like normal once the spawn timer is finished (the spawn timer also runs in the background while you pick your look).
Currently you can pick between the base types that Gavku has been previewing over the last couple of months (Current default, female, asian and african) along with different hairstyles and beards depending on the type.
We also plan to let you pick hair and eye colour here but as of writing I’m still working on it.
Working on this exposed some problems with our mesh baking system so I had to dive back into it to decouple materials from mesh attachments, create a new layer of abstraction with a mesh configuration object to allow assigning materials to mesh attachments and then add another object abstracted above that, that defines the setup for an item, referencing groups of mesh attachment configs for both first and third person (many items have a high detail version for first person view as they take up a large percent of the screen and we can guarantee there will only be one at any time so the performance costs aren’t bad) as well as a mask that can turn off parts of the base mesh (for example, turning off the torso and arms while a jumper is worn).
This new setup is a lot more memory efficient, we no longer need a new mesh for each material variant and items just hold a reference to a configuration object rather than multiple references to all the mesh attachments it’s using.
So far it’s coming along well, I’ve got the spawn interrupt and base type, hair and beard picking working and synchronizing over the network, now with the mesh attachment baking in a better format I can move onto colour picking both for hair styles as well as gear.