Mils

So this week we tested out culling methods for all the trash and objects that we will be adding to the street level. We had planned on using groups of objects placed and repeated around the city at first. The idea is that Unity will batch objects that are the same and therefore use less resources.

In the image below the yellow blobs indicate object groups that would be visible to the player within a specified radius.

After doing some further testing it turns out that placing objects individually then using a grid culling system is actually more efficient. This version (which I’m very glad won out) allows me greater control with placing objects. I can get more unique scenarios if I am not restricted to predefined object groupings.

In the second image below the shaded in yellow grid spaces show all objects within that grid space that would be visible to the player. This version is the more efficient.

And some images of a few more items that I managed to create after going through the object cull testing.

Tom

Hi everyone, I’m Tom, the new developer at Bankroll. My first week has been mostly been getting setup and trying to get up to speed with the codebase.
I’ve been working with Mils on our environment workflow, creating tools to bake mesh objects together intelligently saving on both memory and draw calls. We can also bake groups of objects into clusters given just a custom cluster size, this provides a nice workflow to setup LOD and culling groups. So far we’ve seen good results from baking lots of detail objects as well as larger modular building pieces. Once these tools mature a bit internally you should see them pop up in the MapSDK for everyone to use.
I’ve also been prototyping baking skinned (animated) meshes together at runtime to speed up our equipment system as well as being able to load and re-target imported meshes to our skeleton at runtime. At the moment I’ve got bugs that look like the kraken has been released (see below) but hopefully this will eventually serve as the beginnings of a system to allow you to share custom equipment through the Steam Workshop.

Cow_Trix

This week I’ve been working on a couple more optimizations, fixes for exploits and bugfixes. Large servers should load a bit quicker, and the issue of players getting disconnected for high ping when joining a large server should now be resolved. We also plugged up another exploit that could be used to create rock bases, which are a really sucky thing as they do give a player or group pretty much raid immunity. We should be pushing out a patch, 0.3.5.3 within the next 24 hours, depending on how testing goes. This patch will contain lots of little fixes, some mentioned above, as well as double loot crate spawn speed in Diemensland, which should make towns a bit more viable for farming runs.  Multiple terrains should now also be supported, which some community maps have been limited by up to now.

I’ve also started on creating an architecture for mods and extensions to Hurtworld. I’ve talked about this before, with extending the construction system to allow for community made construction pieces. Players will be able to make furniture, new walls, new material types, new attachments, new decorations, you name it! We’re pretty excited for this. What’s required first though is a system to manage the mods. Luckily, Steam Workshop and Unity do a lot of the heavy lifting for us, and will make this architecture (hopefully) much more painless than it would be otherwise.

When you connect to a server, the server will share a list of dependencies, a list of mods that it needs to download from the Steam Workshop. This is done right now with community maps. Then, your game will download all the required mods (or just find them if they are already downloaded and up to date), load them into the game, and you’ll be good to go! While this sounds simple, it does require a bit of a rework as to when things are loaded and unloaded into memory. Currently, construction attachments are initialised and cached when the game starts. We’ll need to move this initialisation step into when you join a level, and make sure we’re properly unloading the assets when you disconnect. Otherwise, joining servers with different mods enabled consecutively is going to result in some pretty broken and weird behaviours!

We’ll be putting all these tools into the SDK (do we need to get rid of the “map” bit now and just call it the Hurtworld SDK?). Just as we did with the maps, we’ll give out all the current construction attachments in the SDK as well, so you can pull them apart and see how their made before you make your own. I’m really pumped to see what the community does with these tools!

Gavku

More character stuff for me this week 😉 I foresee I will be doing character work for a while as we have quite a few ideas that we wish to implement and test. Before jumping straight into creating the new gear, modelling the high poly, retopologizing, baking out maps etc, I have been knocking up rough approximations of some of the forms we may wish to use. This gives us a way to eyeball shapes and silhouettes and figure out if they are a direction that we wish to head, and hopefully raise any issues we might stumble upon down the road and lower the amount of reworking of assets.

Troublesome areas tend to be where sets of things intersect ie: the waist or neck are. I generally need to make sure that pieces play nice with each other and hopefully avoid any traits that we dont find appealing like soggy hips that can make it almost look as if the character is wearing a nappy.

Here are a few more character concepts showing mechanical/engineering type gear and some random facial pieces.

There is also a sheet showing a sort of early game light armoured ranger type set and a more heavily armoured set.

Spencer

Most of this week has been working away on the Item system. As I am deep in code land, there isn’t much high level stuff that would interest non technical people. Instead I will go into a bit of detail about the internal workings of the Item restructure. Beware: Here be dragons.

The existing item system used a hierarchy structure, where a base object defines behavior that all is descendants require. For example a weapon item needs a list of effects, a mesh attachment to the player, some simulation logic for equipping etc. Then each more specific version of weapons like Automatic Gun or Hatchet require less boilerplate code to implement.

This works to a point, but as most systems in games, the hierarchy gets so large that items end up with an array of functionality that they don’t actually require because some ancestors required it (kinda like humans with an appendix).

As in the near future we will be proceduraly generating items with vastly varying properties, visuals and behaviors, duplicating all of the data stored for a typical item would result in you running out of ram very quickly. Some servers get up to 50,000 item instances (1 stack = 1 item instance) after a couple of months of playtime. Currently as our items are static, these item instances simply refer to one of a few hundred item definitions that don’t change. Once we start pumping out completely new items and runtime, the item memory footprint will become exceedingly large. This leaves us with 3 simultaneous challenges:

• 1. Support generating similar items without having to redefine common behavior (in both code and memory)
• 2. Be simple enough to configure that we can move the definition to the mod sdk
• 3. Support all future types of items we can imagine
• 4. Not have any negative performance impact

To solve this I have been working on breaking the Item system from a hierarchy of inheritance to a composition model (similar to the structure of Unity itself).

In this model, the item object doesn’t have much information on it at all, instead it becomes a collection of simpler building blocks with limited knowledge of each other. This was very difficult before as the driving force behind equipment simulation was blocks of monolythic code that needed to be synchronized over the network. Since the restructure to let a configurable state machine drive the simulation and simply fire off events for more complex happenings, there need not be a central piece of code for the simulation of each item.

An example of building blocks to make up an item:
Static Mesh Attachment (Configured with a reference to the pickaxe model / material)
Item transitions (Turn to ash when temperature gets too high)
Effect builder (Configured with 15 player damage, and 15 mine damage)
Simple tooltip builder (Configured with name/description/reference to effect component)
Mine impact event handler (to receive events from the state machine when a mine raycast should be executed)

All of these components can be re-used across many different items and more can be added to produce any functionality that can be easily re-used, the configuration of which will be done inside the unity editor with a custom inspector I will create over the next few weeks. This should make things like new guns, player gear and other items trivial to create inside the SDK.

I have also been working on a concept to extend the vehicle skinning system to enable coloring of player gear pieces. We now have a technical proof for the system which will allow a schematic item dropped from a creature to have randomly generated colors on parts of it, and also allow dying your pieces to recolor them. I will probably handball this to Tom in a couple of weeks.

If you are wondering why I am spending so much time on rebuilding the Item system when I am working on Infamy, this is a required building block for the changes we intend to make. Significant changes needed to be made to items, so while here is probably the best time I will get to improve the foundations in all areas needed to support future plans. This makes changes take longer in the short term, but will start paying dividends in a couple of months.
 

Spencer

Lots on this week as I push on with ItemV2, new patch is now live which should really shake up raiding with increased explosive drop rates, construction resistances and starter huts.

Studio Upgrades

I’ve also spent a bit of time this week upgrading the work environment for the team. We have expanded into a larger space, re-organized the office (needed some room for a vive :P) and most importantly opened up space for new people! For a few months we’ve been on the hunt for kick ass programmers to expand the team and help us push out updates more quickly. There is a massive amount of stuff we want to do with Hurtworld, and our bottleneck is always on the code implementation side. I have pretty high standards when it comes to programmers, there was a danger of growing the team too quickly after release that we would lose the quality standard we are aiming for. Today I am happy to announce he who will be known as “Tom” has joined our ranks. We are still on the lookout for more top programming talent in, or willing to move to Melbourne. If you have shipped real games, have Unity experience, writing code is your passion, and can work from our office we want to hear from you.

ItemV2 Progress

I now have item state machines running on a deterministic client side predicted model with no corrections (yay!). I’ve taken the extra step here to build some infrastructure around loading the state machine data from JSON config files which will be streamed from the server allowing full modablility. Here is a sample of the melee weapon logic:

Not the easiest thing to edit by hand, I should have a UI tool to add to shigitools for the map sdk soon.

Gavku

This week I have mainly been working on coming up with some new character gear. Hopefully with a larger variety of gear we can start to move away from players pretty much running around looking like Ronald McDonlad with red winter jackets and yellow rad pants. 😉

These are a few examples of more of a scavenger type of armour, bit pieced together, and one with a nod to an aussie icon.

These ones have a bit more of a modern feel. With tactical vest and pants.

A few more examples of different types of vest and armour, these ones feel a little bit more in line with our aesthetic. Also a take on a more heavy duty hazmat suit.

Lastly a take on a more heavy armoured set up, and some lighter bone armour.

Also I have been testing the build to make sure that the new update runs smoothly. As can been seen below 😛

Cow_Trix

Lotta work this week getting the new patch out. There’s been quite a few optimizations, especially with the construction system, that should improve things across the board.

There’s nothing like the wild for stress testing new systems. Since the construction system came out, you guys have been pushing it to its limits. This has shown where it’s good, and where it could use improvement. I’ve done a couple of significant optimizations with how the construction system stores and transfers data over the network.

One of the biggest bottlenecks was a bandwidth issue where, on massive savegames, players would take a substantial amount of time to connect and sometimes fail to connect entirely. When connecting, the server sends a stream of information to you about the structures in the world. This includes what attachment it is, it’s position, and rotation. What attachment something is is represented by the Attachment Identifier, which is basically made up of a Category, Subcategory, Size and Material. Previously we sent this whole chunk of information, which was actually of undefined network size as Category and Subcategory were strings, but was at minimum 32 bytes. Now, we precalculate an index of the attachment, which we can store in a ushort at a much smaller 2 bytes.

We also saw that the construction system was taking up a lot of RAM. Using the SEA Infini Wipe server save, as that server has been really struggling with the RAM load, I tried to track down where we were spending this RAM and where we could be saving it. There’s something very cool about loading up saves and seeing people’s bases – we get to walk around and see what people have been making. I found that we were allocating a majority of memory in registering attachment points. The issue turned out to be how we were representing overlapping attachment points of different rotations. When you look at a point and right click, and an attachment rotates, you’re actually cycling through multiple attachment points which are rotated in different directions. It turns out we were accounting for every rotation, and not just the six which are possible. So this was an enormous saving for memory usage. We saved about 60% of memory allocation associated with the construction system with this optimization.

Mils

Before making more decoration for the cities I was also tasked with getting the new version of Easy Roads (V3 beta) to work so that we can create better roads. Since the plugin is in beta it took a bit of time to find a workflow that will allow us to create the improved road networks we want leading out of the city into the suburbs and industrial areas.

I’m adding more street level decor to the City at the moment. Adding some parks to the city, using some one-off feature objects to create a memorable gamespace. The dried up water feature/fountain, circular low wall and some stands of trees help create this park space.

Adding low walls and electrical boxes to the sidewalks is helping add to the clutter that I think we need to make a convincing street level scene.

These street level assets are great but we need to do some optimising to keep the frame rates up. This week I will be grouping small clusters of assets together and duplicating them throughout the map. We need to do this because of a bunch of inefficiencies that come in to play with large numbers of game objects and lod groups. By clustering meshes together we can cull big chunks at a time. We could cluster our entire city together, however this would bloat our mapsize and therefore ram usage and load times.

Spencer

Hey Guys,

This week I’ve been working towards a construction / explosion patch to finish things off before getting back into the meat of the ItemV2 changes. We are aiming to release the explosive / construction changes next Monday and although pretty light on new stuff, it should really shake up raiding and construction.

I’ve been continuing work on explosions, build costs and wall resistances. I am pretty happy with where things are now. We now use a bunch of sphere casts to determine what is hit by the explosion. We project around 220 of them in all directions and do damage to anything hit for each bounce. If the object is destroyed, the cast will keep moving and hit things behind it, if it isn’t destroyed by that hit, it will bounce off like a soccer ball.

Here is a very slowed down visualization of how it works, yellow lines indicate a hit, grey ones indicate the cast running out of steam.

I have also configured all build resistances to use a more physically accurate damage model. Each construction material has an armor rating, and each construction prefab has a volume multiplier based on a standard wall as 1.0.

I based the armor calculation on the Dota2 armor formula:

Negative armor increases damage positive decreases damage.

So for a C4 explosion, each ray does 4 damage per hit with a falloff over 7.5 meters, also reducing in damage per bounce.

If a C4 is placed on a wall, it will do full damage, and about 30% of the casts will hit the wall on the first bounce.

Each wall starts with 100 health, and is then multiplied by its volume. Walls are 1.0, so we are working with 100 health.

Armor values are currently as follows:

• Wood: -20
• Stone: 35
• Metal: 100
• Concrete: 30

If 60 casts hit a stone wall at point blank we would calculate the damage done like so:

Armor Damage Reduction = 1 – 0.06*35 / (1 + (0.06*35)) = 0.32

60 * 4 * .32 = 76.8

This will effectively leave a stone wall on 23% health, meaning it will take roughly 2 C4 to bring down a stone wall.

The same calculation for metal gives us 0.14 damage multiplier and 33.6 damage, thus C4 will take between 3 and 4 C4 to blow through.

4 C4 for one wall!? I quit

Slow down tiger! Along with making C4 for the most part much less powerful, I have buffed the drop rate of det caps significantly. There will be roughly 3 to 4 more C4 in circulation, which I think will make raiding much more interesting as you come up with creative ways to use your C4 to do maximum damage to a base. Things like creative use of bounces and targeting weak spots will be key.

Building is too expensive, now people can blow up my base also!?

As a third measure of balance, I have changed most of the building costs. Everything is cheaper, and should be balanced relatively to their blast resistances. I will continue to tweak this over time. What this does mean, is bases are faster to build, faster to bring down. Overall the pace of the game should bit a lot faster in preparation for the upcoming content patch (no we don’t have a date set for this yet).

Lowering barrier to entry on construction

Another barrier in the way of the infamy changes to increase punishment for death, is the barrier to entry on building a base. More importantly how much stuff you need to gather before you have an opportunity to stash it somewhere and save your progress should you die.

If even bambys can stash their loot every 10 mins or so to some degree of security, it means when we start encouraging more PVP through infamy changes they won’t be left out in the cold.

What we have added is a starting constructable hut with no attachment points. Think of a shanty town house, that isn’t particularly secure and you can’t share it with others. It will however provide you with a spawnpoint, and somewhere to build a storage crate, without having to craft a hammer and totem and gather heaps of materials. It is craftable at the workbench, its spawnpoint has a cooldown (to prevent it being used as a cheap raiding outpost), it can be melee raided, and it can only be built in the starting biome.

This is not a safe place to leave your most valuable possessions, it is simply an option for players to temporarily store and have a respawn point while you save enough to build a house.

New Music

Our composer ghostsoul has been working away on some new music for the game. Its been a bit of an experimentation process to determine what music works well in a PVP survival game if any at all. The main issue is the number of hours spent in game can make anything grind on you after a while, for that reason we have large silences between playing a piece of music and try to keep out any repetitive elements like drums and grinding loops. We are a little more weighted towards darker themes than I want at the moment, the next batch will be a bit ligher as I think too much darkness causes fatigue over long play sessions, however the main thing I’ve found is more the merrier to keep things unique as much as possible. So we will be pushing out new songs as Mr ghostsoul creates them.

You can check out the latest batch here (will go into next patch):

Mils

I have been busy adding traffic lights and street lights and other types of signs to the city. This definitely helps kill the ghost town feeling that the city has had so far. I also added some off/on-ramps to make the freeway accessible. There is a carpark structure in the works also. Most of the time taken with these objects is in the placement of them. Each light is placed and rotated so that it makes sense, as it would be in a real city.

We will add more objects to the city at ground level in the future, but we decided to focus on the outlying parts for the city for the moment before we push ahead on the CBD. The idea here is to blend the city into the outer areas creating places such as industrial areas, parks and suburban zones. This will somewhat follow the structure of a real city as it blends into the natural surroundings.

Below is a rough blocked out warehouse structure. I will make a few more buildings to suit the industrial zone.

Using Google Maps 3d View is a great reference and inspiration source for me to create interesting structures. The following shows what could be described as a dirt mine 😛 I made the wall structure from this reference to add into the industrial zone.

GAVKU

I think we are getting towards the pointy end in regards to working on construction prefabs, at least for the time being.

Often there are a bunch of things that we would like to add, but end up discarding due to a trickle down effect of complexity. Basically with this stuff we might think of something we want to add, I’ll model it up in max and try a heap of different construction combinations seeing if any issues arise, or if I need to build extra pieces to fill any spacing problems or holes that might come up. Then if it is holding up, take it across to unity where Sean will place it into the build system and we will go through further testing.

 

Cow_Trix

Mostly been working on some bugs this week, as well as putting in new construction attachments from Gavku. I’ve also been putting in some more feedback for construction validation, so when you can’t place an object you have more of an idea of why that is. So, how exactly do we validate if an attachment is in a good place or not, and how can we give feedback on that?

Attachments currently have a whole bunch of ways they can check they’re being placed in the right place or not. The most basic of these is volume – what space should the attachment take up? This might not necessarily be the same as the collider, as some things needs to be able to intersect. It’s generally smaller than the collider to account for this. This is usually ok feedback wise as we get a sense of the volume by moving the piece around. They can also check if there’s anything between them and the ground, for things like plants. Or, for drills, if there’s any other drills around within the exclusion distance.

We can also check if the player has line of sight to an object. This is useful if we don’t want the player to be able to place things where they can’t see (for things like ownership stakes this is especially important), but it also addresses a caveat in the way PhysX detects collisions. Simply put, if you ask PhysX if Shape A is colliding with Shape B, and Shape A is completely inside or equal to shape A, PhysX will not consider them to be colliding. This was the reason why, in the old construction system, you could place short walls in larger walls – because the collider was perfectly aligned on the X and Z axis, and contained in the Y axis. So we put line of sight checks on a bunch of stuff. However, when this fails, it can sometimes be annoying if you’re not quite sure it was the cause. For instance, placing floors through support trusses can be pretty frustrating, and it’s this check that is the cause of that. Now, an icon will show up at exactly the point you need to be able to see to place it. It makes it much easier to place these objects!

I’ve also been working on putting Deferred Rendering into the game. This is one of those “Unity does 99% of the work” things, and it’s been an issue of blocking bugs preventing us from doing this previously. Deferred rendering is just a better way to render stuff. We currently use Forward rendering, which has some significant downsides, especially with Hurtworld. Simply put, a lot of light sources in the game will make even the strongest video cards struggle with Forward Rendering. With Deferred, however, we don’t have this restriction. We can have as many lights as we want, and it won’t dent performance. This is pretty big, considering Hurtworld is a game where you can put light sources wherever you want!

We should be able to put this out as an experimental feature, enabled in the options menu. As we road test it, and iron out all the bugs, I expect to transition to Deferred as our default pipeline in the future. You probably won’t notice a difference, but your video card and FPS will when you’re in a base with 40 torches lit!