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.

