Spencer

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.

Durability

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.

Cow_Trix

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.

Mils

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.

Tom

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.

Gavku

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 😉