The Slug is ready to be implemented by Tom this week. I got the texturing finished last week and it’s looking beast! I’ll be putting a heavy slot hauler trailer thingy on the back soon too. There’s a simple colour mask on this so we can vary the paint. This truck right now won’t get the same optional panels that the other vehicles have because it’s more of a utility vehicle. The tyres got a new treatment which made more sense than the original design, which was too ‘toony’. This is going to to be a great game play addition we think and I can’t wait to drive it.
I also got going on the Recurve Bow components again. This is a nice start on the ‘Gnarl, Riser’ This is the sculpt, I’ll be moving onto the low poly today.
Hi Guys, for this Fridays experimental patch we will be rolling out the following: Silencers, In Game Map, Sound Improvements & Entity Spawning Optimization. As usual we will aim to push it out at 5pm Melbourne time and will include a wipe of all experimental servers.
I started the week implementing silencer mechanics for our AR15 and AWM along with giving the pistol some new sounds. While working on the sounds I realized working with the Unity built in distance falloff curves for anything remotely spatial is impossible. I wrote a custom falloff curve generator that gives much more predictable results and should fix the issues of creature sounds being audible over massive ranges.
There are thousands of network entities around the map like doors, resource nodes, creatures, lockers. We don’t want you to have to load everything in the map at all times for performance, so we only spawn for each client what is directly around them. As you travel around the map, some objects are destroyed on your client and new ones spawned as you subscribe to new network cells.
This is a good start, however when you join a new cell (40x40m or so) with lots of creatures or an epic base with 40 cars, there is a lot of work that needs to be done to spawn everything. If we did this in one frame, your game would freeze for upto 5 seconds while everything spawns in.
To solve this, a long time ago I built a deferred spawning system, where when joining new cells, at most one network entity would be spawned per frame. The result is instead of instantly spawning 500 entities, we spawn 1 entity per frame for as long as it takes to get you up to date. At a tick rate of 80hz (most our servers), this process can take around 7 seconds to fully add you to a cell. This is usually fine as we add you a long time before you are actually standing in it, even in a vehicle.
The problem we face now is when you respawn (or teleport due to a mod), the game isn’t able to predict this ahead of time and is stuck trying to load everything as fast as possible. This is often the time you want to interact with objects most to get back out in the world and kill the guy who robbed you.
In our old system, if a player wasn’t 100% spawned into a cell, the networked objects in the cell would be in a pending state as it was too difficult to determine which ones were ready to communicate. A side effect of this issue was your storage containers showing no items because they tried to send messages before your client was ready to receive them and assumed you already had everything you need.
In this In this Friday’s patch there are 3 major changes to entity spawning:
1. Any entity that has spawned on your client is now interactable regardless of if you have finished loading all entities (If you can see the object, you can use it)
2. Deferred spawns will prioritize each entity type differently in this order: Doors, Storage Containers, Machines, Ownership stakes, Everything Else
The effect this should have is, your lockers should spawn almost instantly on respawn, you should be able to interact with them as soon as they spawn, and doors will spawn first so minimal raiding hints can be obtained while still loading objects. There is one more optimization I could do by prioritizing spawns based on distance, I will wait and see how this feels to people on busy servers before going down that hole.
In Game Map
Cow_Trix has banged together a pretty kickass map system in the last week, there are a few reasons why I decided to put this in game. I’ve held off doing something like this in the past as learning your way around can be an interesting challenge. I was concerned making navigation too easy would take away from the natural skills people can develop in the game, given that everyone uses a map from the internet (me included) this point is sort of moot.
What I am really excited about with the addition of the map, is the ability to easily mark geographic locations, areas and shapes for different gameplay mechanics. One example is localized weather events are very hard to warn people about and make visible in the distance so people can avoid them. Because of this we can’t really add weather events that are particularly harmful as its pretty much random luck if you get stuck in one, however if we can mark an area on the map ahead of time players can adjust their plans around what is going to happen.
This doesn’t just apply to negative events. As I discussed in previous dev blogs, we are currently prototyping making resource hot spots less static, but we still want people to know where they are so they can contest them rather than just stumbling across one and farming it in peace. The map makes all these things really easy to prototype without needing in world effects that can be very time consuming to build, and costly to your FPS when they are in the distance.
Hotspot Competetive Experiment
I am currently prototyping a competitive test mode, paced much faster than existing Hurtworld, where most resources come from airdrops and meteor showers that happen very frequently and are visible on the map if you are close enough. I’m looking forward to lots of gunfights over interesting Terrain, death actually mattering because your base won’t be right next to the point of contest, and freedom to build anywhere again.
I’m also playing with much denser occlusion. More trees, more frequent and smaller mountains, making it much easier to get lost when you want to. Having a map to help navigate and hotspots on the map to pull people together and means there isn’t as much reliance on large open shared spaces that are easy to navigate and spot other people. I think this will help solo players a lot as people will have more choice over when they engage in a contest over loot, and should be able to scrape by in the middle of nowhere if they aren’t up for PVP or are under geared. I aim for progression to still be possible without contesting hotspots albeit much slower.
Heya folks. This week I’ve been working on the new in-game world map, coming soon with many of the features you guys and gals have come to expect from a survival/online map. At this current iteration you have a small minimap up the top right-hand corner of your screen that shows your local proximity, which can expand up to a full screen map. There will also be a permanent compass sitting at the top of the screen. You can see ownerships stakes, shacks, and your death – with a countdown of how long you’ve got to go claim your stuff until it despawns. You can place a waypoint, and while I’d like to figure out some way of sharing that waypoint easily with your friends, that may take a bit more work on the social structures of Hurtworld. Most of my time here has just been in trying to polish this particular feature a bit and make it easy and intuitive to use, trying to draw on other games with similar UI features to make a bit of a common language. I’m excited to see what we can do with the map, and I think it opens up some doors for being able to do cool stuff somewhere, and being able to easily tell the whole server about it.
I’ll probably keep polishing up the in-game map this week, and then also try and get a new version of the actual map, i.e. Mangatang, out this Friday. The last build we did of Mangatang had a bunch of issues from the small to the large (whoops, one spawn point anyone?) so that should be fixed.
Hello, this week I made some changes to the cargo crate to give it a sense of scale while in the air and made a bunch of LoDs for everything. I’m much happier with the new look, it actually has a sense of scale to it now. I sized everything properly so nothing feels too large or too small in relation to another object. I couldn’t help myself and made some little scenes with cool lighting cause I never get to play with assets like these haha.
I also started working on a 2d rendition of the map to be used in game. This is still a huge work in process, I’ve done a couple maps before but they were all very stylized and also weren’t really going to change so I could take my time, but our map is going to change a lot and needs to be updated constantly so I have to find the most efficient way to make this look good.
This week I’ve been continuing on with bug fixes, reintroducing caching for the mesh baker system and starting to setup the Slug.
Starting with vehicles I’ve fixed the issue with the inventory UI breaking when switching to the storage tab. I also fixed an issue where you would always get your hits denied when shooting someone in a vehicle that wasn’t sitting upright. This was because we weren’t saving rotations properly in our hitbox history buffer but this rarely caused any issues as most entities only rotate around their up-axis and their collider in the forward-right plane is symmetrical.
I also fixed a bug with our vehicle cameras, when the camera updates its position we do a series of raycasts from the screen corners to the camera pivot point to make sure we aren’t placing the camera through a wall inside of someone’s base or some other geometry. When inside a vehicle this camera pivot point wasn’t being updated correctly and it was instead being taken from the players first person camera position. This was most noticeable in the ‘crash vehicle’ the player enters to simulate crashes, when rolling along the ground the players first person camera position would dip under the terrain and then the raycasts would hit the terrain telling the system that the terrain is blocking the camera and we should put the camera in front of it. The player would then roll out of this state causing some nasty motion discontinuity as the camera would quickly shift under the terrain and back again. With this fix you’ll be able to crash without the camera freaking out.
I’ve also been diving back into the mesh baking system to re-enable runtime and build time caching.
Runtime caching means each time we combine meshes we store the result so if we need that combination again we can just retrieve it from storage rather than doing all the work of putting it together again.
Build time caching is an improvement to our mod build process, our mesh baker relies on us pre preparing our mesh attachments so they already contain the full set of skinning data and skeleton bindposes and also transforming all meshes into the same space (so all the meshes have the same up, forward and right directions). Previously we were doing all this work every time we kicked off a new mod build, now we store the prepared mesh attachment after each build so we can skip that work and speed up our build process. To make sure the mesh attachments are always fresh we delete them whenever their configuration changes (eg. which bone they are attached to) or whenever changes are made to their source mesh.
In the coming week I’m going to be setting up the slug and start playing around with our heavy slot concept where you’ll want the slug to move these heavy items around. We’ll be experimenting with movement debuffs, blocking equipping items (so you can’t use guns/tools) and taking up many inventory spaces but then having special dedicated slots for heavy items on the slug.