We’ve been working on the first map – “Diemen’s Land” – for Hurtworld for quite some time now. We’re starting off with a monster – a 5km squared sprawling expanse full of weird valleys, deadly mountains, and places you’ll take one look at and want to make a base on. It’s been a huge learning curve for everyone, and it turns out to be a really tricky task. Starting off, we assumed it would just be case of throwing down some hills and mountains, a few trees, and we’d be set!

One of the biggest problems in designing a good, open-world map turns out to be occlusion. Occlusion is when something blocks you from seeing something else. For instance, if you’re in a valley, you can’t see the next one over. The rocks and hill between you and the next valley occlude it. This is great, for a bunch of reasons! The first is entirely about performance. If we can guarantee you can’t see it, we don’t have to render it, which means that if we can generally guarantee a certain level of occlusion, we can push the graphical fidelity more for close-range objects. Secondly, in terms of gameplay, we’ve found it feels better. The world feels bigger, there are more discreet zones to claim, and it decreases the odds of some fine upstanding Hurtworldian sniping you from across the map.

With Occlusion

Without Occlusion

Now, I’m a programmer, which means I’m lazy. I want everything done for me. So, potentially, I could run to every single point in the map, and see how far I can see from that particular point. Or! We could use some simple programming to figure out where problem areas are. I wrote a simple script that does exactly that. We go through the map bit by bit, and put ourselves 2 metres above the ground, and then we raycast (which, in laymen’s terms, is just asking “do I hit anything in this direction, and if so, what and where?”) all around us.

We can then say, well, this is a good distance to be able to see, and this is an unacceptable distance. Let’s say anything below 200m is fine, and anything above that but less than 500 is okay, but should be minimised. Anything above that however, is a bad area, and we should put more stuff there to block a player’s view. We can then give every point on the map a score, and show that score in an image. So what does this look like? Well, for the sake of experiment, let’s look first at what it’s like without any rocks or props in the level. White is areas where the player can see a long way, black is where they’re totally occluded in all directions. We can also spit out an exact percentage that tells us the amount of map that is a problem, which is the red percentage.

Not super great huh? We get around half of the map with an unacceptable amount of oclussion. I think we can do better. Now let’s try throwing some rocks in!

Mmm, Interesting! We’re really getting somewhere now. From this map, it’s pretty easy to see some areas that need some work. We can even integrate this map directly into the level, for some really fine control and feedback about the amount of occlusion at any point.

You can see that there’s a couple of hills that are still pretty white – I’d better get back to it!

– Sean

Hurtworld Alpha Update #6

Hey Guys!

Quick update to let you know where we are at. Although we’ve been quiet for the last few weeks we are very much working our asses off to bring you the best Hurtworld possible.

Since our closed alpha started, our alpha signups have gone nuts! Thanks to everyone who has streamed and recorded videos of the Alpha so far, without you guys nobody would know we exist <3

This is also partially the reason for a the delay on updates as Mailchimp became stupidly expensive for the number of people that signed up. We’ve now moved to a cheaper mailer so updates should be more frequent. If you signed up for the Alpha but don’t want to get spammed by my nonsense, the unsubscribe link at the bottom won’t remove you from the running for an Alpha key.

Performance

Something that came out of the alpha tests was that servers were struggling at around 17+ people.

This is much lower than we wanted, so I have spent the last couple of weeks doing a major refractor and performance optimization on both the server and the client to ensure we can handle around 50 players at once.

As you might have seen in other early access projects, doing major architectural changes to a game that is already in the wild takes much longer to get anything done. So while we could just throw it out now and fix things later, we would be building on unstable foundations and the work to fix them would increase tenfold.

These changes should fix all memory leaks server and client side, along with removing most lag spikes where the game would freeze for a second or two.

Structures also build in one tenth of the time, making joining older servers MUCH faster.

On the client side, we have heavily optimized the player model, and created a cut down low lod skeleton to be switched in when there are lots of people around to keep framerates smooth.

Security

Another area that needed some love was security. We designed the Hurtworld network infrastructure to be as cheat proof as humanly possible. All player movement and bullet detection is done server side, meaning the only cheating possible is a local area ESP and Aimbots which can be targeted by something like VAC.

However something that we glossed over with security was object interaction (storage crates, workbenches etc). Previously with the right hacked client, a player could interact with any object in the world from anywhere. As part of the refactor, I changed the interaction of items to be based on direct line of sight of the player on the server. Theoretically, if you have a storage create inside a locked room on a Hurtworld server, it is physically impossible for someone to access your items without legitimate explosives.

Fortunately the hard part is over. However, as with any serious renovation, we now have to start the process of a full regression test as I have modified thousands of lines of code and there will be bugs.

Update Schedule

While I’ve been busy fixing the foundations, the rest of the team have been powering ahead with new content!

We have decided that the rest of the content we have in the pipeline will go into the first Steam release. We feel that micro updates once a week don’t really give the content the experience it deserves, especially while we are in closed Alpha and player numbers are limited.

Post Steam releases will be similar to TF2 updates, with lots of content that compliments each other. When we drop an update we want it to be a reason to take Monday off work rather than login, look at a new item, and logout. We know survival games are best experienced with lots of people, and getting to figure stuff out at the same time / race for first to do something is a big part of the fun.

After major releases we will put out rapid hotfixes to keep things stable and work towards the next major patch.

When do I get to play!?

For those who don’t yet have an Alpha key, we will be releasing another batch in the next few weeks to test the new performance changes.

We plan on releasing on Steam as Early Access in roughly 2 months.

Peace!