Spencer

This week I’ve been migrating over the sprint functionality into the new Item architecture and fixing up a few issues that have been long standing with the way we handle sprinting. Our old implementation was held together with sticky tape, which you can see if you fire a rifle while running and the muzzle flash goes off pointing into the sky despite the bullet going forwards, also by sprinting just after swinging a pickaxe where the sprint would play over the swing animation.

We had to explicitly tell the movement simulator a timeout for the player not being able to sprint after doing certain tasks. We set this timeout wrong in a bunch of places because we had to predict the amount of time each action would take, not to mention remembering to do it at all whenever an item pulled you out of sprint. There was also an issue where we had no way of delaying an action on the equipment until sprint had finished, we would just do the action instantly and try to snap the animation.

Now each state in the state machine can flag if sprinting is allowed in that state. This information is fed to the movement simulator as an intention rather than an actual sprint value. Due to the fact that sprinting doesn’t start and end instantly, just because a state disallows sprint, doesn’t mean we aren’t still blending out of sprint. The movement simulator feeds the actual sprint amount back into the state machine blackboard so the equipment can make decisions based on the real sprint value.

In the clips below, you can see the CheckSprint states holding up the fire transition until the sprint transition has ended. (Projectiles are disabled as I am still working on that system)

I also had a play around with the arrow draw mechanics of the bow, previously the fire/draw was a single animation. Adding new states in the simulation that was written in code was a massive pain in the ass and hard to get right. Now its trivial.

Other sprint upgrades

Strafing while sprinting will no longer pull you out of sprint, it will now change your sprint direction left / right slightly. And as per the 10 requests per day, you will no longer need to hold down shift after initiating a sprint. I am not going to put in an autorun at this stage, if you need to leg it over very large distances and afk we are doing something wrong in the design of the gameplay. I would rather fix the reason you need to do this, or put something in the way to kill you if you were to do that.

Mils

I’m the honorary member of the Crusty Demons this week. I’ve had a lot of fun as I always do modeling vehicles. This low poly dirt bike base is looking sweet. We made the fuel tank look like it’s been built out of sheet metal to give it a bit of a scavenged look. I still have some dents, damage bits and maybe some geo to add to the tyres, but the base of the bike is mostly there.

I’ll do up some concepts on Monday for 3 sets of fairing designs. After the concepts are locked in I’ll do the high poly modeling, UV mapping, normal baking and texturing for the base core of the bike.  After that I’ll build the 3 body kits (fairings) I may build some wheel variations after that but could be doing some work on combining the cities with the map.

Note: The spokes will actually be partly transparent normal mapped texture, to save on polycount.

Cow_Trix

I’ve been working on the raid drill this week! It’s been coming along pretty well. Functionally, it’s pretty done. You attach it to wall, insert fuel, press on, wall die. I’ve been trying to make it look super cool as well with a lot of small touches, that I hope will make the machine come alive a bit. For instance, some parts vibrate, and the drill bit will glow as the drill gets hotter.

However, we don’t want operating the drill to be trivial, something you set and forget. You’ll be able to control the drill’s RPM, where a higher RPM means more damage, but also more heat and quicker fuel consumption. If the drill does overheat, it will explode, taking out anyone nearby. It won’t take a rocket scientist to control, but nor will you be able to leave it alone. The drill might also jam sometimes, and require interaction to be unjammed. These are things that I’m currently playing around with, and trying to get something that feels interesting and dynamic, and where there’s no “stable” setting for the drill. You can hear it quite a way off, which will hopefully make it a risk as you have to announce your location. I imagine that the drill may take some balancing once it’s out in the wild, and the optimal raiding strategies change around it.

I also finally got round to fixing some cross-platform issues with the SDK, where it turns out the Mac OS filesystem has some… issues.

Gavku

Not a whole bunch from me this week. I finalized the textures/materials for the vests and moved onto more gear, specifically some pants.

It was whilst doing this I realized I would need to modify the player character model, extending the mesh of his torso down a bit further than it currently is. Since I was already going to have to change his UV’s I ended up moving them all around to better make use of texture space. I then baked and fixed his existing textures to fit the new UV’s.

We also decided that he should have a normal map in order to bring him into line art-wise with all his new gear. In order to do this I edited the player model, removing tris and tweaking some of the poly flow so that it would sub divide with a minimum amount of artifacting. I then took this mesh into mudbox and did a pass adding some detail and cleaning up some areas. Another plus is that it helps to smooth out a bunch of the lighting errors we would get in places like his ear and underarm etc.

 

Tom

This week I’ve been continuing on with vehicle changes. I started with hooking up damage and the broken leg debuff into the crash system. When you’re crashing, large collisions will be able to hurt or even kill you and you can also be left with broken legs like when taking fall damage. Here’s a quick gif of me sliding down a hill on my bike and caving my head in on a cliff.

I’ve also done a bit of work polishing how the camera works with vehicles. Now when entering a vehicle in first person your view will automatically shift to the front of the vehicle. When exiting in both first and third person you’ll stay aiming in the same direction. I’ve also added a setting for vehicles to force them to be in third person camera. Although I added this setting to force third person during crashing it should also be a help to any vehicle modders who are using car models without the interior.

Lastly I’ve been adding destruction to the vehicle system. Vehicles now have health and they will explode into a burnt out shell when it runs out. The size and force of this explosion will be increased depending on how much fuel is in its storage. The burnt out vehicle corpses that get left behind can also be harvested for resources with the right tools. Obviously this is a significant change that we will have to rebalance things around but we want to make vehicles easier to obtain now that they will be less permanent.

Cow_Trix

Hey folks! Been working on some bugs this week, which should be fixed in 0.3.6.2, out soon. Also been finishing up on getting modded vehicles in, working on an example project, and expanding some feedback for the UI.

There was a pretty nasty bug where structures wouldn’t load properly for clients, when connecting to servers under heavy load. The reason for that turned out to be “I’m an idiot”. To make client structures load a bit smoother and try to put the server under less load when player connects, I split the structure initialization step up to take place over a few frames. The logic was basically to get a pooled bitstream, fill it with data, and if we had hit the frame budget of structure data syncs, wait until the next frame to send it. Yeah… that was the problem. I got the bitstream, which is only valid for that frame, and then held onto it for more than one frame! On busy servers, some other networked object would come along, clear that stream, and use it, meaning the client would receive a garbled mess and not be able to build the structure. Thankfully this should be fixed now.

I’ve also been getting vehicles moved over to the SDK, which has opened up a lot of new modding possibilities. As a result of vehicles being in, other machines are buildable in the SDK as well. At this point, not only can you make a custom vehicle, but you can also make a custom inventory-based machine with Oxide scripting. This is because we also moved across a fair bit of UI scripting so the vehicle UIs live in the SDK as well. So, custom storage crates, and simple item-based machines are now entirely possible.

Custom vehicles are pretty cool as well! I put in what I called the Cancallare, a pretty cool sports car. It cost me $5 from the Asset Store, and was a breeze to implement! That whole library of
cars is pretty cool actually, check them out. Modded vehicles are a bit simpler than the Goat and Roach, as we can’t do things like custom items that make the car look different, or custom paints. These features will come soon. Check out the Cancellare on the Steam Workshop.

I also gave UI a bit of love, as part of putting in support for custom UIs. Itemslots are now much more consistent as they mostly build themselves by script, and should also be slightly more performant. They will no show when a slot is one-way (you can only place or take the item, e.g. ambers in an ownership stake) or locked (you cannot take or place the item, e.g. attachments on a vehicle). Previously you kind of had to figure this out by trying to drag items in and out, but now there should be some more intuitive feedback there.

Mils

The cities are now near a place where we are fairly happy with them. The city currently exists in a test map and so need to be moved into the actual map that will exist in the game. I’ll be working with Cow_Trix on this process when he is finished implementing some other game items. I finished off the public pool structure for the suburban area of the city and I built some high rise apartment structures.

While Cow_Trix is busy on his other tasks, I am starting to work on the Dirtbike, for now I have named it a ‘Kanga’ The base chassis is inspired by the bike below, which is a KTM 450. I’ll be modeling the chassis first then doing some concepts of the varying body kits later. Can’t wait to drive it. 🙂

Spencer

This week I’ve been finalizing the SDK setup of our Item creator so that everyone has access to the powerful tools we use. One of which is the seriously awesome unity plugin NodeCanvas. Big shoutout to our homies over at Paradox Notion for licencing us a re-distributable copy of their editor tools for our SDK! Any unity heads out there should definitely check them out.
Now that everything is loading nicely from asset bundles, I am going through the process of re-building all the existing gear and item functionality in the new system with the upgrades required for dynamic generation. Nothing fancy to show off this week but getting closer to the baseline of ItemV1.

Why aren’t these things in the game yet?

I’ve seen a lot of posts of people being confused where the content from the blog is, expecting it to be in game the week after we show it. Game development is a long process. What you see on this blog are things we are actively working on, but doesn’t mean you will see it in the next patch. Despite Hurtworld being in alpha, and lots of you being keen to try out half finished content, we like to get things up to a decent standard before putting them in game. There are some things that benefit from live playtesting while they are still in their infancy, but some things that would just cause havok on the current gameplay experience if put into the game before being ready. That said, if you see something in here, there is a 99% chance it will make it into the game eventually, but only when it is ready and can have its full impact. We could throw in all the creatures we have modeled, animated as re-skinned Bors / Tokars, but this wouldn’t do them justice. Instead we will wait until we have some time to allocate to coding some new and interesting AI for them, and have a new area of the map that suits them before releasing them into the game.

Things like weapon attachments will be released as part of a very big update that we have been working on for a while. As it will change the way items are found, crafted and used (along with changes to infamy), we need to rebalance most of the content in the game as a consequence. This isn’t a quick job, we want to make sure we get it right.

We also have multiple programmers working on different things. We release hotfixes when bugs come up otherwise they would remain unfixed for weeks / months while we finish working on content, this would really suck. So when you see a hotfix release, its not instead of a content release. Content is coming.

Tom

This week I’ve been working on the motorbike, more specifically, the crash system. I started getting the system I briefly mentioned in blog #36 up and running where the hips + torso are simulated on the server and the rest of the limbs + head are simulated client side. Unfortunately while this met our performance requirements it never looked quite right. I found the torso was able to move and roll too freely and when limbs were being rolled over they were often put into impossible positions on the client side causing strange artifacts and jittering behaviour in the physics system.

Unfortunately sometimes after using a physically based system the results are close but not close enough leaving us stranded somewhere in the uncanny valley, after reviewing this we decided to move away from ragdolls for crashing and back towards an animation driven system. Now we are making the player curl up into a protective pose during the crash. Luckily this pose can be well approximated by a capsule shape so the server side physics stay the same (note: I’m just using the surrender emote as a placeholder while this is still in programmer art mode).

The player remains in this crash state until they fall below a safe speed where they can start getting up.
This means some crashes can last a long time while you tumble down a hill or something similar.
As you can see in this clip I was lucky the cliff stopped me!

As you can see it’s still pretty rough around the edges so this coming week i’ll be polishing up this system and extending it so crashes will damage you and break your legs on a large enough impact. I’ll also be extending this crash system to the existing vehicles. This should differentiate the vehicles a bit more and give players the choice between safety (the roach) and maneuverability (the motorbike) with the goat falling somewhere in between. We don’t want the roach to be totally safe though and a large enough impact should be enough to send you through the windscreen or out the door (especially without panels).

Gavku

So I think I have become somewhat comfortable with Marvelous Designer. At least to the extent that I can handle most simple garments, and have an understanding of how most of the tool set works as well as the best non-destructive way to go about getting results out of it..

We used a basic tshirts/vest combo as a test case.

My workflow for this gear is to have something in Marvelous Designer and manipulate/sim it till I get the desired result. Then take the exported mesh into zbrush to clean it up with zremesher and add ( or subtract ) additional sculpt details. This results in a nice, clean, easy to read mesh that I can then easily construct a game mesh around in topogun.

Once this is done I bake out all mesh’s and texture in the usual way 😉

Textures are still a work in progress at the moment.

Tom

This week I’ve been pushing those vehicle related fixes into the latest patch, helping test the patch and also starting testing the city environment.
Performance is a big priority for us at Bankroll so I’ve been looking into how we can have all the extra detail of the city without a large performance overhead.
To achieve this I’ve been working on properly integrating the baking system I was working on in the first week into both the mapsdk and the Hurtworld client.
On the mapsdk side of things we tag all the objects that are part of the bake process as a ‘DetailObject’. Then when you run the bake process, the environment is broken into a 2d grid and all the detail objects are grouped based on the grid cell they are sitting in. Each cell is then baked together into the least amount of objects possible (Unity has a vertex limit of ~65k per mesh).
This step then repeats except it looks for ‘DetailLOD’ rather than ‘DetailObject’. These DetailLOD objects define a low resolution version of the cell that will be displayed whenever the high poly version isn’t loaded. We do this so we can still have important occlusion objects like walls and containers even if the cell isn’t fully loaded, without this a player could see another player behind an object once they were far enough away to unload the cell.
The next step is to grab all the colliders (these define the collision geometry) and bake these all together as well, now we remove all the detail objects to free up memory and reduce draw calls and create a new object to hold the data about the grid along with lookup tables so we can quickly turn a cell index into a list of either the high or low resolution renderers. Because these are destructive changes we save the post-bake scene into a new file ready for publishing or further tweaking.

On the game client side the player on load will look for the grid data object when they first spawn. If its not found the grid manager deletes itself to free resources, if it is found it rebuilds the grid with the given settings and gets the references to the lookup tables. The player then builds a list of offsets which essentially are a set of rules to easily find the index of the surrounding cells. The size of this adjacency list will be controllable from the settings allowing you to stream in more or less cells depending on what your computer can handle.

As you move through the level the grid manager activates the high poly renderers for all adjacent cells while deactivating the low poly renderers. Any cells that fall outside the adjacency list swap back to the low poly version.
Between this system and other gains we’ve made by not using the terrain system in the city we’re currently seeing performance similar to Diemensland on live.

Speaking of performance if you haven’t tried the deferred rendering setting I highly recommend it! Because our post processing pipeline relies on both depth and normal screen space textures and in deferred rendering we get these ‘for free’ as part of the usual rendering process.

Everyone who meets our minimum specs should be able to use deferred rendering and it should produce be a performance improvement for everyone so please try it out if you haven’t yet!

Mils

I have been adding more buildings to the industrial and residential areas. I have started building a few ‘hero’ structures, which will give character to the mass of buildings.

I created a ‘Smelter’ structure, which will be a good positional reference for people as they cruise around the industrial area. It’s tall stacks can be seen from a distance and used by a player to determine their location.

I am still working on a dried out pool, which will be in the suburban area. This would be a good contention point for resources.

Cow_Trix

Hey folks! Been busy getting 0.3.6.0 and 0.3.6.1 out and running this week, and fixing some bugs that came up with that release. This was one of those updates that seemed quite small on the surface, as is often the case in game development. We take something, tear it back, and build it back up to where it was but with a better structure. Same looking house, better foundations. However, it really should be a different ballgame now for modding as we know have a framework all set up.

I’ve got a big, ever-growing list of little fixes and bugs that I’ll move onto next. In terms of big tasks, I’m going to get modded vehicles in first, and then the ol’ raid drill. Modded vehicles should be pretty easy now. You’ll be restricted to four-wheelers at this point, Tom’s awesome two-wheel vehicles are still some time away. Got any ideas about cool custom cars? Let us know!

I’ll also be working on the raid drill, a new method for raiding. We couldn’t implement this device when it got made back in Dev Blog #20, but now with the new construction system it should be pretty trivial. We’ve been thinking about how the drill will work in terms of gameplay. While all of this is subject to change, we’ve got some ideas about how it can be different to raiding with C4. We think the drill will be a loud device that will draw attention, making it risky especially as you’re using it in enemy territoy. It may require maintainence, meaning you won’t be able to just set and forget it. You will need to either replenish some resource, or maybe just turn it back on. This is to increase the risk. But the advantage may be that instead of needing to rely on det-cap chance, you’ll be able to make raid drills using farmed materials. Something else to consider is making C4 less effective on some types of materials, and raiding drills be the more effective choice. This way, you can structure a base so that it forces any raiders to use both methods. It’ll be an interesting thing to implement, and we’ll definitely need to tweak and balance it carefully. It’s easy to see ‘balance’ as a simple set of scales, where you just add weight to one side or another. In a complex game though, it’s a bit more like a house of cards.

We’ll also be trying to pick up our game on Featured Servers, trying to get some for regions which don’t currently have any, and updating regions where servers have gone down or the playerbase has disappeared.

Gavku

So I am fully back onto character gear. Initially I started modelling up a variety of different types of pants etc so that we could preview them in game see how they look on the moving character. The screenshot below was a couple of those tests ( un textured )

During this process we came across a piece of software called Marvelous Designer that looks promising in regards to speeding up our workflow when it comes to being able to crank out a bunch of standard clothing. The software was designed to be used in the fashion industry there has been a bit of a learning curve but I think I am coming to grips with it now. Basically the workflow we are pursuing is to build a piece in MD, generate, construct a game mesh on top, bake, then texture.

Basic tshirt and pants.

This is a work in progress jacket. Still need to add a collar and lapels.

Spencer

I was planning on tackling recoil this week, but as the item construction was holding back creating any real complex items I started work on building the new Item creation system.

Item Creation System

Previously, we used a massive block of C# code called StaticItemBuilder to create our item list. As we move more and more of our content into the SDK to make it extensible, we rely on a new system of content creation that the core game has no knowledge of it (thus allowing mods to dynamically load in new content). Having items hardcoded into the game makes them very hard to modify, and even harder to author.

Over the last few weeks, we have been working on migrating our systems to be driven by ScriptableObject assets in Unity. The magic of these objects, is they can be packaged into assetbundles and loaded into the game at runtime. All we need to do, is create a nice editor for our SDK that allows definition of all the properties of a thing (eg construction attachments, items, vehicles etc) and expose those scripts via our SDK. We then create all the official content using the same tools we give to our modders, ensuring there is plenty of power there.

Back to the point, this week I’ve been working on the Item Creation editor! This little baby combined with the item behavior state machine editor, and the work Tom has been doing on mesh Baking, can configure everything needed to define something simple like Ash, to incredibly complex like a modular assault rifle.

We are at a point now for the firs time, where new items (not just simple ones) can be created without a single line of code! This is a big milestone for us, as it knocks down another wall between fast content generation, not only for our team but anyone who wants to see something in game.