This week I’ve been fighting against rock bases again, getting a patch ready that will be released in the next few days and will be followed by a full infini wipe on Friday the 17th of February. We received some reports that rock bases are still around so I did some investigating and it turns out there is a very narrow edge case where the ‘am I inside a rock’ check fails when checking an area overlapped by multiple rocks. To deal with this edge case the check first scans through the raycast generating a list of expected colliders, after the standard raycast is complete it checks to make sure all expected colliders were hit, if not it runs the same raycast explicitly against the missing collider/s (ignoring everything else), adding all hits to the original hit count (the method counts hits going in and out of the rock and compares them to determine if inside).
That will hopefully solve the problem of players placing ownership stakes inside rocks but we also need to stop players getting inside the rocks in the first place. I don’t want to spill the beans about this just yet until the fix goes live but we’ve identified 2 ways players are doing this and developed fixes for both.
On the ItemV2 side of things I’ve been working on improving our model viewer, making it more generic so it can load more than just the player and also working on the ui so you can see what mesh configs are attached, adjust any custom color channels and quickly enable/disable visibility. I’m also adding search windows in for selecting mesh attachments to preview without having to build an item or a mesh config group.
I tweaked the metal smart materials in 3D-Coat last week, they are looking fii-ine. We may still tweak these, but they are getting really close and so is the workflow needed to reproduce this over all the guns. I did a lot of organising and folder restructuring of the assets in the project and in my personal working files, which was necessary so that I don’t end up in file chaos hell. There are a lot of parts and construction files that go into the guns, so now that I have something I won’t get lost in I can press ahead.
I also worked on the AR15 Receiver (Main Gun Body) Hi poly mesh and got that done on the weekend. I will be UV mapping and then baking in the coming days. Can’t wait to see the new materials on this. 😀
Note; these are renders of the Ironsight out of 3DCoat are at 4096 texture sizes, and while the in game guns look great they won’t be quite this texture density.
The AR15 Upper & Lower Receiver High Poly. Added a few dents and some repair work to add life to the mesh.
Good progress on the new progression this week. I implemented durability that can be applied to any item and extended item slot UI functionality to allow any item components to feed data into the progress bar (in this case used as a durability meter), and also for items to request that an icon overlay be displayed in a modular way. This will come in handy when we have items with things like battery power. I’ve also been thinking about moving item transitions into using this system to make things like cooking and going moldy easier to read in the UI.
Here is the system in action (with drastically accelerated rates of wear):
This week I have been finishing up some of the hair/beard sets and making sure all the separate eyebrow meshs/mats work as intended. I also wrapped up the Harem Pants.
I have also been going through the project and tying up loose ends, making sure that assets are in a finalized state and without errors. Removing, renaming, or replacing any such items. As well as making sure that work files and some archived older work and in game content share naming conventions.
Hey folks. This week I’ve been working on dynamically spawned entities. Before, when we spawned an object we would spawn exactly that object with no changes or randomness. A Shigi is always a Shigi, with the same health, texture, mesh, behaviour and so on and so forth. However, as discussed last week, we want spawns to be a lot more dynamic, different and diverse. Some Shigis should be Legendary Shigis, some should have crazy textures, or some mesh attachment, or anything like that. Diverse dynamic objects make for an interesting world. It also means that we’re dealing with way, way fewer prefabs as we don’t have to make an entirely new one to get some variety in objects.
So how this has ended up working is we give a builder object the difficulty the object was spawned with, a seed for making random decisions, and a rarity (things like Common, Uncommon, Rare, etc) that will all influence which object is spawned, what it looks like and how it will act. This has evolved into a pretty fully-fledged system for making these kinds of decisions. For instance, we can occasionally spawn Rare or even Legendary creatures in areas that are difficult enough, that have higher health and attack but drop way better loot. Check out an example of how we can mutate the Bor over harder and harder difficulties!
Itty Piggy -> Boss Hog
I’ve also been moving the creatures over to the new MeshAttachment system that the player uses for gear, that the rest of the team have been using and building for a while. We currently don’t have any art assets that take advantage of the system, and really we only swap out materials at this point, but it’s a step towards creatures having attachments that can distinguish and individualise them.
Hurtworld Update #66
30 01, 2017
This week I started off working on fixing up how our variable item state is communicated to clients from the server. There were a few issues where our old item authority system didn’t quite give us everything we needed for determining who needs to know about an item. Previously, if you couldn’t access the storage that an item was in, you didn’t really care about it. Now we have situations where another player is wearing an item, and its properties change how it looks. In this scenario we have a second criteria for eagerly sending variable item state to non authorized players. To get around this, I came up with a memory efficient system for determining if a client already has the most up to date version of an item from the server. Then when an item is equipped on a character (this includes vehicle parts), we send its dependent state to all other clients that are subscribed to the characters network lod cell (aka are near it). This is the last roadblock for paintable gear that Tom has been working on.
Modular AR Implementation
I also implemented the first modular weapon using embedded items. The UI stuff is all pretty placeholder but it allows things like silencer, sights and magazine mods to be added to a weapon, and some removed. While I was at it, I improved on the item context menu system a bit and added the ability to unload a weapons ammo.
I’ve now started work on the durability system workflow in prep for the proper ItemV2 loot hunt / progression prototype. I’m hoping to have something very rough ready to play in the next week.
Heya everybody. This week I’ve been working on the spawner system, implementing the changes and logic that Spencer and I discussed in our blogs last week. The problem has been an interesting one which I thought I’d briefly discuss.
Now the first question to ask is what properties we want our spawning system to have. Well, firstly it needs to be predictable – a given density map should output roughly the same amount of spawned objects over time and over server restarts. Secondly, it needs to be fast and scalable, as a large map can have up tens-of-thousands of spawner cells that need to be updated in a timely enough manner so that the predictability requirement is upheld. Thirdly, it needs to be unpredictable on the micro level. This is a new requirement that is necessary because of the fact that multiple spawner cells with a free density less than 1 can “share” spawns. With this requirement, removing an object from the spawned objects (say by mining a rock) should mean that the spawner shouldn’t always put a spawned object back in the cell it was, but also try to place it in other areas.
First, a quick rundown of how the spawner system works. Obviously, we only spawn objects where players are in a server, for performance reasons. We split the world up into cells, and pass our spawning system a list of cells where players are doing stuff, and the spawners should be active. Then, we update the spawner cells in that player-activity cell so that they can spawn stuff if they need to.
So this is one of those problems that turned out to be a sort of different problem once I got into it. Collecting many spawns with <1 free space all together to “share” a spawn is basically a packing problem. You can sort of see what I mean with the image below. This is a grid of spawns with 0.5 density that therefore have been paired off by the spawner and colored the same color. The little white boxes are spawned objects. If a square is grey, there are no spawns in it.
So obviously we could pack the previous image better, to eliminate those 3 empty grey cells. But unfortunately, our 2nd and 3rd requirements prevent doing this. We don’t have time to try multiple packing configurations to try to minimize empty spaces, nor can we always pack optimally as we need the result to be semi-random. This means that actual spawned numbers of objects will always be slightly lower than the expected result. For instance the image above has 49 cells with 0.5 density, and spawns 22-24 objects when we might expect an optimal 25. I think this slight low-balling is a unavoidable side-effect, but I might be wrong. If I am – let me know!
Next up on the new spawning system is making the actual spawn smarter off the Difficulty value that’s passed to them – making creatures harder, resources rarer, and all that stuff! More on that next week.
I have been testing PBR textures this week and ironing out the kinks in some new baking workflows I have been trialing. I am experimenting with a mid poly mesh workflow with my normal map baking. This means instead of starting with a low or high poly mesh, I start in the middle which lets me add or lower geometry for the respective models. This I hope will speed up the baking process on the large quantity of bakes coming as I move toward texturing the guns. I find that fixing geometry on the low poly mesh which has a lot of triangles (due to the nature of hard surface modeling) takes a fair amount of time. I feel that a mesh that still retains mostly square poly’s will be easier to turn into a high poly version.
I’m continuing to work on the PBR materials, especially the black oxide coated metal. We want to get a nice balance between believable metal, and our game’s stylistic art.
This last week I’ve been continuing refactoring our mesh baking system and tools. What started as something very player character specific has now become nice and generic. I’d been shoehorning vehicles into the system but it required a lot of special handling and was quickly becoming a bit of a mess, with customisable characters happening and potentially a female character that would require more special handling it was definitely time to clean it up. Now mesh attachment configurations store a list of compatible characters so we can now just throw all the potential mesh attachments into the baker and it will just ignore anything it can’t use making item configurations much easier and less error prone as well as allowing functionality like allowing monsters or vehicles to equip items and have them show as long as their is some compatible mesh defined for their character. It also deals neatly with the female character where some gear can have the same look but others like chest slot items will need a different mesh. Now we also treat the FPS player as another character type so we can remove all our special handling to deal with this.
Speaking of making things easier I’ve spent some time making vehicles easier to configure and much easier to mod. Previously we had all the vehicle attachments stored inside the vehicle prefab with a key to reference it and at startup the vehicle would turn them off and hide them away until an item referencing that key is equipped and it gets turned on again. This means the prefab needs to be configured in multiple locations and also adding a new item (say for a mod) means adding the item into the vehicle prefab and then rebuilding the vehicle pack. Whilst this works it bloats the size of the mod considerably and also makes it impossible to combine mods (say you make a new wheel and someone else makes a new bumper bar you’d never be able to run both mods at the same time). Our mesh baking system uncouples the look of the vehicle from the prefab but vehicle attachments also have hitboxes of their own and may run some of their own logic as well (like a light or an attachable seat) so we still need to be able to attach prefabs to vehicles.
To deal with this I’ve created a new item component that will attach a prefab to a bone in a skeleton when equipped with configurable offsets and scaling.
I’ve also created BoneReference objects to reference a bone in a skeleton, these are much easier to work with in configuration rather than using the index of the bone in the skeleton and will also save us lots of maintenance time if we change the setup of the skeleton, if indices need to be shifted we only need to fix the index on the reference object rather than trying to find every place we reference the bone by index and fix it there.
This week I was doing a pass over a bunch of the hair and beard assets. I made sure that there was no longer any eyebrow models incorporated into the hair models, they are now going to be handled separately. As I was already touching these assets I added detail to the sculpts helping with surface variance, and allowing the spec maps to work better.
As these have been baking I started work on a pair of Harem Pants. They might end up a little tricky to skin, but we figure its doable and worth a crack 😉
Hurtworld Update #65
23 01, 2017
Heya folks. This week I’ve been working on visualisation tools for the editor, as well as taking a look at a revamping the spawning system.
A common problem we’ve had to solve with the SDK and map-making is displaying large sets of spatial data like spawns and biomes. We ended up with a few different systems that dealt with visualisation and painting of these datasets and it was a bit of a mess, and most importantly just couldn’t handle the size of the data we were throwing at it without reducing the editor to a crawl. The main cause of the performance hit was using the UnityEditor.Handles class to draw the cells in our data, which was a process that had to be done every frame and turned the editor into a slideshow above ~3000 cells. Drawing even a low-resolution biome map in Nullius required around 9000 cells to be drawn, so obviously we had to do something completely different. Another motivator for implementing this was the changes to spawns, which I’ll talk about a bit later.
So, to solve this issue I changed individual calls to the UnityEngine.Handles class to instead building and maintaining a single, hidden mesh object within the scene. This mesh object has a vertex for every cell that holds a color. This single vertex is turned into a quad with a geometry shader, which is much faster than having to build every vert manually and means we hit the 65k limit much, much later. This works really well, and means the only real workload is when we invalidate the mesh. Check out this gif of painting on the map!
So these improvements were partly because of discussed changes in the way spawn maps are going to work, which meant that this part of visualisation and painting really had to be up to scratch. One of the problems right now is that spawns are really tied to the map – you look at an area and you say “I want exactly 3 iron rocks to spawn here”. This works, but it makes balancing difficulty. Spawns are one of the things that most server-owners play around with, so we want to defer those decisions as late as possible. So, what we’re more shifting to is a spawner based around two maps – density, and difficulty. A density map will do roughly what the spawner map did before – say how many objects there should be in an area. However, we’re going to implement a system that supports non-integer and <1 values for these cells, so, for instance, two cells next to each other with a density of 0.5 will try to have 1 object spawned between them. The difficulty map – see below – is a general value that will determine what will be spawned in an area. So, for instance, a high difficulty value for a creature spawn would make it be a harder creature. This gives us a lot more easy knobs to play with to balance a level.
Adding more parts to the Mac-10 and new parts to the existing Beretta this week. They look really nice even at this level, the techiness is really satisfying to look at. I’ll be testing some UV unwraps a little this week and continuing to add parts to the Beretta. I want to get the texture scaling right when you are up right near the Iron Sights and various Scopes.
So I finished off the Low riding jeans, and did a temp skin on them.
I also did a bunch of clean up of my assets within the project, organizing things and updating head assets like hair, beards, masks etc to make sure they fit correctly, skinning them and baking them. I did a pass over the player face as he had a sort of creepy thousand yard stare, and tweaked it to give him a slightly more friendly look. The changes were subtle but still enough that they caused errors in the game mesh that meant I had to go back change the sculpt, re bake his maps, re skin, and re bake his game mesh to test. His eyebrows were also replaced.
I also spent some time cleaning up and reorganizing a bunch of my work files so that if someone else need to access them they can tell what is what. This involved placing files in easy to find folders and making sure that PSD’s have correctly named layers. I am currently going over the spec maps for hair sets, then will jump onto some more player items.
I’ve spent most of the last week continuing on with work on the customisation system. It’s been pretty tricky to develop a system that meets all of our requirements but we are getting close. We wanted a system where the player can colour their gear on a per item basis and where items using the same shader could be combined into the same material to save on draw calls.
Our current vehicle customisation system wasn’t quite up to the job as its customisation works on a per vehicle level rather than per item (ie. the vehicle has 3 colour slots rather than each vehicle attachment having its own colour slots).
Whilst we could use the same shader to colour the gear after baking it all together if we want to use the same material to reduce draw calls we need a way to tell different parts of the baked mesh apart so they get their own individual colour customisation (ie. colouring a hat slot and a chest slot differently), this is further complicated by the fact that GPUs don’t deal well with branching if the condition is changing within the same draw call (so we can’t do conditional selection based on the type of gear).
Our solution is to create a small texture with 3 pixels reserved for every item type to represent the 3 customisable colours, we then use an extra UV channel in our mesh to find the customised colours (UVs are texture coordinates that are used to map textures onto a mesh, they are normalized between 0 and 1 so they can map to any sized texture, 0,0 is the bottom left texture and 1,1 the top right). Zoomed in our texture would look something like this (without the overlay text).
The UVs are slightly offset so they match to the center of the pixel rather than the corner. I’ve only listed the UVs for colour1 as this is all that the mesh knows about, the other two colours are retrieved by the shader automatically shifting the pixel over. We are using a 32*32 texture, giving us 1024 pixels meaning we can represent 341 items with 3 customisable slot colours at a time. When an item with customisable colours is equipped it sets the pixel colour depending on its slot type.
Now if we combine the other textures together into an atlas we can use the same material for multiple bits of gear allowing us to batch things together efficiently reducing draw calls (each material is at least one draw call depending on shader).
I’ve also been adding a new shader for custom colours. Previously we were saturating the diffuse texture with the custom colours based on an rgb mask where each rgb channel corresponded to custom colour 1,2 and 3 respectively. The amount of saturation was based on the brightness of the colour channel in the mask. The new shader doesn’t use saturation but just a simple blend instead. Now we use the brightness of the mask colour channels to tint the custom colour (see how in the example below the overlay colours fade to black towards the bottom) and added an alpha channel to the mask that controls the blend weight. This method doesn’t require a desaturated diffuse texture and gives more control especially when blending into and out of the mask.
Here’s a demonstration where purple, yellow and green have been picked as the three custom colours.
Good progress this week, we had our first internal play test of ItemV2 in survival mode. Still a broken mess, but marks us being pretty much on par with the master branch feature wise. I pushed out an update mid week to the ItemV2 Experimental build which contains the new assault rifle model and the broken survival build.
I’ve had my design hat on for most of the week, fleshing out the details on how gun attachments work, how you find them, what can be removed / added vs what is fixed.
Unfortunately as this is all theoretical design, I have no pretty pictures. Just a wall of text.
I’ve gone over the ItemV2 details in the past, but it is scattered through lots of posts so I will re-summarize here:
First of all, the below is designed and balanced for full loot aka no infamy. The objective is to shift some of the gear progression storage to things inside your base, making it less painful when being killed deep into a progression without taking away the punishment of death. Also giving other players valuable item drops while limiting their value should they kill you.
Recipes for Weapons, Gear and Tools beyond the very basic will be obtained in the world by killing animals, looting ruins and gathering resources. You can think of this as the loot hunt similar to something like Diablo, where instead of finding a complete usable item, you find a blueprint to a specific item.
Every blueprint generated by the loot system will be unique. You will be able to see the stats of an item before you attempt to craft it. Blueprints with better random rolls will be more expensive to craft.
One blueprint will give you a limited amount of uses before being destroyed.
Each blueprint will need to be loaded into a dedicated crafting bench, and once loaded can not be removed.
All tools and gear will have durability, after a set amount of use will become broken.
Crafting benches will be able to repair items if the item’s blueprint is loaded into it. Meaning only the creator of an item can repair it.
Weapon blueprints will contain roughly half of the weapons attachment configuration. The rest will be able to be added and removed on the fly.
Example – Assault Rifle
Blueprint generated will randomly roll a lower receiver, barrel and stock. These items will be generated at blueprint time, with randomized stats and will be fixed for the life of the weapon.
Additional items can be attached for: Silencer, Sights, Scope, Magazine which will modify the stats and operation of the weapon further.
All parts of the weapon will be paintable with custom patterns and colors.
Map Spawn Generation
To support the large progression we are working on, we need to move away from manually configuring each individual creature, loot table and placement in the map. We are moving towards a more semi procedural solution where we specify difficulty of an area and the density of each type of spawn we want and we let creature and resource generators do the rest with algorithms. Cow_Trix has been working on the source data for these systems, I have been working on taking that data and spawning things.
The objective is to have our systems determine something needs to be spawned based on density and difficulty, and pass a set of parameters into a random creature or resource spawner which can be configured to generate all sorts of variations on creatures and gatherables.
An example would be, instead of having 3 different types of Tokar hand authored, we specific ranges of damage, speed, colors, mesh additions like horns, and sounds that occur at different difficulty settings and let the creature generator spit out a random variation based on a few dice rolls. At this point we could also inject rare spawns into the config, so we could have a rare albino Tokar spawn anywhere in the map a very small percentage of the time.
With random creatures, we then need loot to match. With too much configuration requirements we usually end up copying stuff from other loot tables and changing them slightly (hence the higher level tokars that are pretty much the same).
To follow on from this system, we will pass the spawn information we used to create the creature to the loot table once it is killed, allowing us to automatically scale up the loot dropped depending on the difficulty rating and rarity.
I see this as being a very important step towards pushing out our content by orders of magnitude. We want to push towards 50+ tiers of loot instead of our current 4 or so.
I’ve also been working on the implementation of items being able to store other items. Initially I was going to make all loot generated at blueprint stage and fixed for technical reasons, but as I just know everyone is gonna want to modify their weapons a lot, I decided to change the way we are going to do attachments.
Attachments are now item instances that can be “equipped” on a root item.
Eg: An assault rifle lower receiver will have multiple child items in the form of a barrel, stock, silencer, magazine, scope etc
This will also make modding for weapons a heap easier as modders will only need to make an item that fits the silencer slot of the AR to integrate it into the existing game.