Press Kit Wiki

Hurtworld Update #45

Gavku

So the basic pants have been finalized and skinned to a presentable level. Next up is an all purpose jacket which will round out the majority of the basic player gear set.

PantsFinal2

Also the player FPS arms have been finished, bringing them into line with the look of the 3rd person model.

FPS_InGame

Mils

I’ve almost finished the sculpts for the Kanga, the chassis and body kits are done, just gotta add wear and tear to the wheel sets now. I’m trying a new baking tool which I’ll use to create the normal maps. The new tool is called Handplane Baker, a great new tool with a lot of modern features, and it bakes quicker than good old XNormal. Not sure how Handplane will work out, so if need be I will use XNormal, but my hope is that it will produce maps faster and with less micro seams where the UV islands join up. This will give a cleaner normal map. Gavku uses handplane for his bakes, and I originally wanted to as well but I got inferior results because of some difference between Handplane and Maya vs Handplane and 3DMax. I’ll try simply sending my meshes to max and re-exporting them from there, and I may be able to get the same results as Gavku.

Sclupts1 Sclupts2

Cow_Trix

This week I’ve been putting natural landmarks, structures and simple roads into the map structure, as well as further expanding the MapMagic tool.

One of the big problems in Diemensland was that the formula we arrived at for the general map creation led to maps that were quite difficult to find your way around. In many parts of Diemensland, every direction looks much like the other and there are few landmarks. Even after hours and hours of play, I still find myself very easily lost. For this reason I want to make the new map be much richer in natural landmarks, to allow people to find their way much more easily. You can see some of the natural formations I’ve created to be scattered around the map below.

landmarks

Something I think was really missing from Diemensland was movement. I really like how the waterfalls create some movement on the screen, it makes the world feel a million times more alive. That’s something that I’m going to try to get a lot more of in this map.

I’ve also been making some man-made structures, like this small outpost. You can try climbing to the top, where some rare ores will spawn, but it is a risky endeavour!

Outpost

Getting roads in this system has been a challenge, and I thought it would be one area where we’d have to break out of the MapMagic tool and use some other tool such as EasyRoads. However, I had a go implementing a basic road with MM and it turned out pretty good! While it is slightly more constricted in what we can do in terms of aesthetics, as we’re dealing with a splat and not a mesh, the advantages of having it all tied together may outweigh the cons of it perhaps looking slightly less realistic.

roads

Tom

The work on the Kanga continues! This week I merged the Kanga branch with the current live version, incorporating the raid drill and a host of other bugfixes and backend changes.
We’ve also been making some changes to how the rider animations are being driven, while we are keeping the same blend tree from blog #42 we are driving these blends from a derived client side state instead of directly from input. To set the turn speed we now compare the direction of velocity to the direction the bike is facing, the back/forward air blend is now driven by the pitch of the bike in the air rather than the throttle.

After last week we got the bike to a pretty good, controllable baseline so this week we wanted to add back in a bit of nuance and skill-based play that could allow players to differentiate themselves. To this end we’ve added in a wheelie control.

Holding down the wheelie button generates a torque lifting the front wheel into the air but only when you are accelerating at the same time. You have to be careful you don’t overcook it and flip over backwards and this requires feathering either the wheelie button and/or the throttle.

Whilst the wheelie doesn’t directly do anything new it comes in handy in a few ways. Because we dampen any twisting motion when only one wheel is grounded a little power wheelie out of a drift is a good way to quickly straighten up. As well as this you can use it to get your front wheel up and over various obstacles.

We’ve also toned down the air stabilization to a large degree, adding a cap on the maximum force it can apply, highly increasing its damping and also turning off stabilization all together if you get yourself into an extreme pitch in either direction. This last change combined with the wheelie button allows you to generate enough momentum to overpower the stabilizer and get yourself upside down so you can flip.

I’ve also been doing polish that doesn’t make good gifs, things like creating an accurate collider set for the kanga from the low poly, creating a way to mark colliders as ‘bottom out colliders’ that act as the bottomed out wheel, don’t apply damage or play effects when in a collision and have a special frictionless material. For the roach and goat we can use the vehicle chassis as the bottom out bumper but the shape of a bike requires a hard collision response long before the frame touches anything. I’ve also made optimisations to the crash components so they only watch for crashes whilst the vehicle is occupied.
The bike is getting pretty close to functionally complete now but there are still a few steps to go before it will truly be ready:

  • Final bike art for all variants complete
  • New crash and get up animations to replace placeholders
  • Create items for the bike variants (currently just working from 1 baseline itemset)
  • Validate crash spawns so players cannot use crashing to glitch through walls and into rocks
  • Balance pass on vehicle health and damage
  • Balance pass on vehicle spawns and loot, taking into account less vehicle permanence through destruction and a slightly diluted vehicle loot table (eg. It will be harder to collect a full setup for your target vehicle as 3 types can drop instead of 2).

Spencer

Good progress on ItemV2 this week. While working on recoil, I came across some issues around serialization of ammo counts and other dynamic pieces of state to do with items, which turned into a decent refactor on how and when we tell players about items. Previously clients would only know icon information about items until they either equipped them, or looked at their tooltip as the structure of the items was too complex to serialize on every update like we do currently.

However while thinking about what creates the state of items, I realized by only sharing the data needed to generate the Item, we would only need to send a generator id (the asset in charge of procedurally generating the item) and the configuration block (which in most cases is just a random seed).

Then if things like attachments are added, we simply send the id of the item modifier with its configuration block.

This makes the amount of data required to serialize an item almost negligible regardless of how complex the state is, allowing us to always send everything about an item (except some special cases like transition times) exactly the same way was we were in the current live version of the game. Eliminating a heap of complexity, ram that would need to be stored, and bloat in the save games.

The second benefit to this is that since the full item definition is on the client, we don’t need to build an entirely new tooltip engine as mentioned in the last devblog. We can just use our current system with some small enhancements. This should save us a couple of weeks work.

The second big change this week was removing a large layer of indirection between inventory and items. The actual instances of items were transient, and would be constantly re-allocated / destroyed with no sense of uniqueness to each instance. Now our GlobalItemManager will keep an inventory of all known items which match up to an identifier. This greatly simplifies code related to item management and enables the serialization described above.

Hurtworld Update #44

Spencer

Finally making it through the woods of engine upgrades and starting to see some new features creeping into the game. I’ve put the final touches on the new camera system which was one of the last truly ugly systems in the engine.

Now the view can be clamped inside the vehicles and is calculated serverside also, we can do firing from vehicle seats! In reality the driver won’t be able to shoot, but this was easier to record. We still need to implement animations pivoting from the hip while pinned to a seat, but that’s the easy part.

Next we have a new headlook feature, similar to the arma engine allowing you to look around on a limited swivel while running / aiming in specific direction. Useful when crossing a valley in sprint and checking your surroundings. (FPS animator needs some touchups so it doesn’t look weird in side angles, not a big issue though.

Lastly we have the completely unrestricted Roach back seat that allows crouching / standing and 360 degree freedom.
This video also shows the improved third person aiming system, notice the arrow is now accurate regardless of perspective.

Once again, I should be able to get to recoil this week. Those wondering what the ItemV2 ETA is, we are still a couple months off.

Things that need to be implemented before we can go live:
New tooltip system that supports itemv2 state
AI for new creatures
Upgrade loot table system to generate weapon attachments / procedural stats
Cow_trix finish new map

No more fucking around

Now I am through most of the serious upgrades I need to do, I am switching gears into delivery mode. I wanted to take the time necessary to make sure we deliver some really game changing stuff with the upcoming update, however I am starting to see some patterns emerge that I see in other games that never get finished. I always thought that the reason games that have some initial success slow down after the early access launch was due to a lack of motivation / cashgrabery.

I see now how easy it is to get caught up in trying to make everything perfect once the pressure of going bankrupt in the next week is taken off the table. We are still working harder than ever, but we really need to start focusing on pushing this release cycle out the door and stop trying to cram every feature we ever wanted into the game. There is plenty of time for more features, in future releases, I see now we still need to make compromises in the short term if we want to finish anything.

That said, ItemV2 has become more like Hurtworld V2 as almost all elements of the game have been improved… a lot. We can’t wait to get your hands on it, hopefully I can make that not too far away!

Mils

This bike is starting to shape up nicely. All the high poly versions of the wheels, fairings and chassis are done now, the next step is to add some damage to these by carving into them. If you look at the image I have added, you can see some damage has been added already. These are the types of damage that affect the silhouette of the model, and so are also present in the low poly mesh. The next step is to UV map the low poly and then bake out the normals maps so that texturing can begin. Vehicles have high polycounts so this takes a bit of time, especially when baking normal maps, as you can never be 100% sure that they will come out right the first time you bake them. This is especially true when it comes to more complex shapes. Any part of geo with an angle over 90 degrees will generally cause a normal baking disaster. Adding in a little more geo in these areas by simply adding a bevel on the offending edge of the low poly mesh will usually fix this, but you must be careful not to start beveling edges everywhere and blow out your poly budget.

HighPolyDone HighPolyDoneWheels

Gavku

This past week I was focusing on nailing the workflow of getting mesh’s skinned in maya, exported, and viewable in Toms new Vis Scene. This involved a little bit of back and forth with Tom, especially in regards to having the player character display as close as it can to what it does in game ( which it now does ). I went through and modified some of the previously made clothes to better fit the new body shape, and they seemed to come across pretty well. We noticed that just lowering the head a little and applying a normal map makes him look a bit more jacked, which we don’t mind.

Topless

ShirtJeans

I also have been updating the fps arm model to bring it line with the other character changes. This involved getting rid of some of the acute sharpness that was in the original model, especially around the forearm/elbow, as well as decreasing the fingernail size and blocky-ness of the hands.

FPS_Hands

FPS_GameMesh

Tom

I started the week out working with Gavku bringing the new character model into the itemv2 branch. We found a few bugs that we were able to squash and I added a whole bunch of useability improvements into the model viewer. The viewer now uses the same lighting model as in game and uses the same dynamic skybox so you can adjust time of day and other variables to view the player under all different conditions.
I’ve also added a simple equipment ui that allows you to swap between any gear in your project easily along with selectors to preview any skinned or static mesh in the project without having to create an item and setup the visualization component.

Also this week we spent some time testing out the motorbike build which didn’t go as well as I’d hoped. We found a lot of bugs with how proxy players were trying to sync animation data and also some ease of use concerns where basically the motorbikes were way too easy to crash. To have a place within the metagame of hurtworld they needed to be more reliable otherwise they would just be outclassed by the other vehicles. To this end I’ve adjusted the leaning system so it has special case handling for off-camber corners (corners which are banked opposite to the turning direction), clamped the target lean value and removed crashes being triggered from leaning too far. The handling has also gotten a lot tighter with an increase in the steering assist twisting force plus higher sideways traction for both tires but especially the rear. I’ve also made the bike dampen its yaw velocity when only 1 wheel is grounded to prevent the high traction tires from spinning you out.
I adjusted the collision crash component so it should only be triggered in large head on collisions (like driving flat out into a wall) and also added in an air stabilization system where whenever the bike is airborne it will correct itself into a safe neutral orientation. Because roll in the air was now being controlled by the stabilizer we changed the left/right inputs from roll to yaw (meaning you can now do 360s instead of barrel rolls).
I’ve got a new list of fixes to work on for this week but we’re definitely getting close!

Cow_Trix

Hey folks. This week I’ve been further iterating on the map work, making a lot of progrees in making a procedural map that retains the Hurtworld feel. A big part of it as well has been figuring out how to conceptualize the map generation in a procedural way, finding the methodology that works.
An interesting problem I had to solve was the generation of the initial hills. Something we settled on when making Diemensland was that for the map to have good occlusion, generally the hills had to be roughly the same height. I initially tried to generate these shapes with a Voronoi noise map, which worked okay, but had the problem where it was difficult to make the hills all the same size without distorting the shape. What I then tried, which worked way better, was a “stamping” technique where I took a single hill of the shape that I wanted, and then stamped it all over the map in the same kind of pattern of valleys separated by ridges. This way we could guarantee much more that the slope and heights of these hills would be consistent.
1
What I’m going to focus on next is generating the macro layout of the map. I’ve got my head around generating the micro, but I’d like to be able to feed in something like the diagram I showed 2 weeks ago of the general layout of the map, and get something out that resembles that layout. That’s going to be an interesting challenge, the biggest problem being I think having this information laid out in a way that works logically and is maintainable. The whole mask workflow that we used previously for Diemensland has some maintainability issues where a change to one mask causes a cascade of changes to every mask it touches. I’m thinking of basing it directly of biomes, and seeing if that can work.
ProcForest
I’ve also been experimenting with placing hotspots and structures in the map, which we could make as little areas to explore and loot. I’ll be looking into a similar system to put in natural artifacts – for instance, things like the stone arch in Diemensland – but I can see that being a bit more involved.

Outpost

Hurtworld Update #43

Gavku

This week I have been finishing off ( hopefully ) tweaks to the main player and getting rid of any errors that have popped up. One of the main ones was obvious seams where the character had been split apart. Previously I had hand edited the normals anywhere the player mesh was split which would often get rid of anything visible, but was very time consuming and left us with a mesh that was fragile, with them sometimes resetting when moving between max and maya.

Now that the character has a normal map I had originally thought that that alone would take care of it, however this was not the case and still left seams of varying visibility depending on workflow/how it was baked.
In the end what ended up working was to make sure each separate piece was individually uv’d, then I would recombine all the pieces into a single mesh but not weld the verts along each join. I would then bake out the normal map using this as a target mesh with a generous amount of padding and convert the map to tangent space with Handplane. This seems to work fine.
JoinErrors
I also went and finished the textures for the new hair/beard combos.
HeadBeards

Tom

This week I’ve been having heaps of fun doing stuff like this:

 

 

 

The motorbike and the vehicle refactor are coming together well, I think I’ve found a good balance between realism and fun given the relatively limited control scheme (it’s hard to handle turning and leaning well without an analogue input like a thumbstick). I’ve put a early build together that we’re going to be testing internally and we’ve been talking about pushing out the vehicle changes before the itemv2 update so watch this space!

I’ve also been doing some more work in itemv2 working on the backend of our baking system pooling groups of datatypes used by meshes. This allows us to preallocate the memory the baking system is going to use rather than request it at runtime. When working with high level programming languages like C#, systems like this are essential for good performance as the garbage collector (named because it turns no longer used objects back into free memory) isn’t fast enough to work smoothly in real time and frequently leads to framerate spikes. If we preallocate all (or at least most) of the memory we need on start up and don’t release it we can massively reduce garbage collector use.
I’ve also developed a system for turning static meshes into basic skinned meshes by binding them 100% to one bone.
This should help modders out creating items like hats and masks easily, I used this horse mask from the asset store, bound to the head bone to test it out.

 

Cow_Trix

Hiya everyone. This week I optimised a lot of the city assets, and played with a new map-making tool.

One of the big challenges with the city, as we’ve mentioned before, is getting it to perform well. It’s a complex problem with some distinctions from optimising an open terrain like Diemensland. We get a lot more out of aggressively culling objects, and it’s much less noticeable due to the amount if culling we get from the buildings. We started of as you can see at around 30fps in most scenarios, and up to 3 million polys.

The first thing I did was write a tool to find the objects hogging up the render time – where were we spending these polys? Well, it turned out we were spending a lot on very small amounts of texels at a distance – that is, lots of polygons were making up very few pixels. I put on my 3D modelling hat and made some quick and dirty LODs for the worst offenders. Thanks to Mils’ modular design of the city, this meant I only had to make a few before we got some real dividends.

lODS

You can see a before/after performance comparison below.

lod_final

I’ve also been playing around with Map Magic, a recently released procedural terrain composition tool. Hopefully we should be able to streamline our map making process using middleware tools like this in the future. As worthwhile as Shigi Tools was, and probably will be for some niche procedural generation, the more tools we can outsource, the faster we can make content. I’m working on reproducing some of the basic microstructure that we ended up with in Diemensland. Think the hills, rock placement, tree placement. These were all iterated over a lot to try and get a good feeling of scale and place. Reproducing this in an entirely procedural way will really allow us to lock in the micro and start playing around more easily with the macro. This has meant I’ve gotten to right some cool procedural heightmap generators – check out this custom warp generator I whipped up!

Warp

Dev Blog