Very busy week of bug squishing… as always, post feedback and bugs on the subreddit! Bases on the EU server have been looking good ^ … enjoy it while you can, building just got a lot more expensive.
Welcome to all our new players in the Alpha, we sent out 3 waves of keys early this week. You guys revealed some new issues we think we have under control now.
Unable to Connect
This was mainly around downloading structures from the server. A few weeks ago I said this was one of the last areas that need some love, yesterday I got the chance to refactor things to what I had in mind. We put out a patch last night and this looks to have solved the problems. If you’re still having connection issues please get in touch.
These suck, we appreciate your patience on this one. There was an issue causing the save game thread to break and never come back, we lost about a day on the EU #1 server and possibly some time on other servers. I put out another patch this morning which should guard against this happening again.
Earlier this week I had some time to start working on some exciting new content involving vehicles. More details on this soon.
Sean is working hard on bug squashing, level work and localization code (the latter is pretty much done). He also posted a really informative piece on optimizing occlusion in the level, which you can read here.
Mils is back from exploring Japan and is working on something secretive.
Gav is still chipping away at the old block… here are some nice sub-shards of ore.
TacticalMyth requested weekly dev updates on our Reddit page, which we think is a good idea. Starting this week, we will give a bit of a rundown of where each of us is at. Not everything that we are working on, just the most interesting.
Most of you would have noticed the lack of server population in recent weeks. This has been intentional, very few keys have actually been released. To put things in perspective, there are more Hurtworld videos on youtube than there are active keys. We are very happy with the first phase of the Alpha.
We didn’t feel there was much point letting more people in while there were still large outstanding issues.
Today we will be releasing the first set of keys since the Alpha launched. What we need now is to cram as many people into the same server as possible and see how it holds up. While we have run simulations, nothing compares with real people doing real things over real world internet connections. To make it fair on the new players we will be doing a wipe of all official servers. In future we will try to give warning when this will happen / keep to a schedule.
This will also begin the phase of balancing the content for populated servers. There is no point us fine tuning mechanics where there is no threat of being killed by other players just to release chaos and hope it all goes well. We hope to get lots of feedback from you guys on this too, reddit is the place to talk about it.
Roadmap to Steam
We have tentatively set a Steam EA release date for mid November. Steam shouldn’t really affect much in our camp and we know the Steam tools are well battle tested so we won’t be releasing any Steam keys before release.
On the Steam integration front, we are now ready to go. Server browser, friends integration, all the good stuff. You can even see us in the Steam server browser right now!
The Steam release will get our first major content update, we will be releasing details on this over the coming updates.
A couple weeks ago I came across a request for keys from the dudes over at Oxide Mod. If you don’t know about Oxide, it was originally a Rust Legacy Mod tool (like bukkit for Minecraft) that has been adding support for other games.
I’ve since been working with Wulf to get Hurtworld integrated and am happy to announce we will have Oxide mod support on our Steam release.
We are starting to think about integrating custom made maps and the toolset we can give you, more on this soon.
One of the biggest issues with server performance degradation turned out to have nothing to do with memory leaks or CPU usage. Now that all the other stuff is fixed it became quite clear that the longer a server was running the more jerky animation became.
This was caused by a floating point precision issue that after 3 days of uptime, the clock wouldn’t have enough resolution to interpolate properly. Physical objects, vehicles and other players would stutter like hell until server restart. Clock precision is now good for at least 5 years uptime.
Sean is busy writing the code to enable localization.
Sean está ocupado escribiendo el código para permitir la localización
Sean besetzt ist das Schreiben des Codes , um die Lokalisierung zu ermöglichen
Шон занят написанием кода для того, чтобы локализовать
Gav has been working on many things, amongst them… Raaaaawks.
Chris has been working on character incidental animations to fulfill some single instance needs. Like flipping the bird.
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.
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!
Hurtworld Alpha Update #6
02 09, 2015
Hurtworld Alpha Update #6
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.
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.
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.
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.
Development Update #2
10 06, 2015
Hey guys, here is the second edition of the Hurtworld development update:
Vehicles are something I’ve been itching to do since day one. I put them off thinking it would be too much work and we would just patch them in later.
This week I got sick of waiting and I’m pretty glad I did.
The first problem we had to figure out is how to network them.
This post assumes you already understand basic networking concepts. If you are new to multiplayer programming Glenn Fielder has an amazing series of in depth articles on everything you need here.
Most moveable objects in the HurtWorld universe are synchronized at a variable update rate with a combination of interpolation and extrapolation. They often run a decent amount of time behind the server because the player doesn’t ever drive them directly. The only thing up until now that the player can control is the player, which runs client side prediction and a few other latency hiding tricks to ensure that input has zero latency.
Vehicles get a little trickier… In Unity we use a character controller combined with a series of raycasts to move the player around. This allows us to simulate multiple movements between frames without having to wait for the physics solver. This is crucial for being able to rewind and replay for client side prediction.
A vehicle will need to rotate (character controllers can’t), simulate wheels and different physics constraints that would be a pain-in-the-ass to re-implement manually. So for now we are constrained to using the PhysX solver.
Here we run into a limitation of the Unity implementation of PhysX. The solver goes in one direction, at a fixed speed in a single universe. We can’t rewind, we can’t create an isolated island of physical objects and simulate it at will, there is one physx simulation, and it progresses with the entire Unity scene.
Fingers crossed in the future unity change this so we have access to the PhysX API directly or at least some unity specific rewind capability, not holding my breath.
Running only server side
This leaves us with one option, run the PhysX sim on the server, and tell the client about it the best we can.
First thing we need to do is get our input to the server. The client runs no simulation, just sends an RPC fairly often with the input controls we need.
Then we simply setup a rigid body on the server with four wheel colliders attached, modify the slip, torque and suspension settings as if it was a single player game.
Once we are happy with the simulation, we need to figure out what the client needs to know to simulate the car visually with minimal data.
Lets start with the body of the car. This can be synchronized like any other moving object in the world. In our case, it uses the exact same code as the rigidbody crates that spawn when you drop an item.
There are many ways to do this, ours is a simple interpolation of known states with an update frequency of 20 times per second of position and rotation. If we do nothing else, the car still simulates like a car because the server is doing all the work for us. The client knows nothing about wheels at this point, but it still looks like a car.
So we are pretty close with only a Vector3 and Quaternion per update, and these can be compressed later.
One thing to note is we have a round trip delay on any input now, as the server simulates our vehicle. Because of this we need to make sure the handling isn’t too sluggish otherwise the delay will make it feel unbearable. To compensate we made the our vehicles handle almost too well, so with an added delay they feel right.
Auxiliary data we need to simulate the car on the client
We could ask the server what the state of the suspension is per tick, but this would get expensive quickly and is mostly a waste.
Its pretty easy to assume where the wheel will be based on the chassis position. To do this we can just do a raycast at each wheel on the client up to some maximum value, then move the wheel to either touch the ground, or sit at max extension of the suspension without any data.
First thing we want to do is steer the wheels, how accurately you do this is up to you. I only needed three states (left middle and right). Then, I just smooth them out on the other end. This only uses 2 bits of a byte which we can use later on.
Secondly we need to rolling rotation, this one is a bit trickier to assume, even if we tracked relative ground movement and just rotated them, we would miss out on things like burn outs or handbrake turns because the wheels would always track with the ground. We don’t need a massive amount of precision on these values as mostly the wheels will be a blur. You can compress the RPM value into a single byte using something like the following:
We also don’t need separate speeds for left and right, with the exception of if you have a differential simulation and what to see it, we just send one RPM for the rear and one for the front.
This part isn’t 100% necessary unless you have gears and you want to hear the revs increase and drop. This can also be packed into a single byte using the method above, make sure you get the max range correct though, you won’t notice wheels hitting the RPM ceiling, but you will with engine RPM sounds.
If you’ve ever tried to implement audio for a car engine, you’ll know just pitch bending a single rev loop sound terrible, even with fading of volume. There is a great example in the Unity 5 standard assets for a 4 channel car audio system that blends between the following:
Low revs accelerating
Low revs decelerating
High revs accelerating
High revs decelerating
The idea is that when the throttle is down, the engine sounds vastly different from when your foot isn’t on the accelerator. To do this we need to know when we are throttling.
I tried just checking if the engine RPMs were rising, this sorta worked, but caused it to sound like you were running out of petrol while cornering or going up hill so we added one more bit for throttle state.
Remember above we had some spare room inside the steering byte, we can pack it into there for free
Lastly we want to show smoke and play screech sounds when the wheels are losing traction, again we could try to assume whats going on based on movement of the point on the rigidbody vs. wheel RPM, that would work fine as long as our RPM values are accurate enough. As we have a few free bits leftover inside the steering byte we can throw this one in for simplicity.
Currently I send a bool for front and back axles and treat them equally, if you are making a racing game you would probably want more precision.
For a fairly quick implementation without too much optimizing we have a decent looking car for around 640 bytes per second. I’m sure better can be done, but this will do us for now.
Here is the final result in our 4WD test terrain
Animals of Hurtworld
02 03, 2015
The art style we are currently chasing is a somewhat chunky, slightly stylized modelling aesthetic, with fairly strong diffuse texturing. Not being overly concerned with blending of colours and fairly subtle specularity. Pretty much the two main reasons for going down this path, is for the shortened time/resources it takes to make such assets………..and we like it!!!
Below are a couple of the animals that inhabit Hurt World.
The first is a Bor who tends to stick to forested regions, foraging through the undergrowth and being pretty disgruntled by any player who wanders too close.
The second is a Tokar, who is a nimble predatory animal that attacks its prey from a distance before closing for the kill.
Lastly is a Shigi. They were the first animal made for Hurt World and are small passive animals who wander peacefully around grazing and seeking out any Owrongs ( plantable and harvestable fruit ).
We hope to have male, female and baby versions of a lot of the Hurt World animals in an attempt to breathe some life into the world, rather than just having wandering beasts who fulfill x task of a game mechanic.
Fake Brands That Amuse
01 03, 2015
I just love making up stupid jokes, puns and the like. Which has all our cohorts here at Bankroll groaning/smirking, or grirking/smoaning.
These are a few of the fake brands that we are keen to put into the game, with a few more to come. Most of these have a level of subtle humour and research depth uncommon to my particular brand of amusing.
I decided to get out the thesaurus and Google translate, to help me craft these logo’s. I had some genuine belly laughs while I flipped words like broken, smashed, dodgy, dicey & exploding around in translate. The variations that came out of the various languages, produced some barely pronounceable but funny letter combinations.
While we want humour in the game we don’t want to force it down peoples throats. We want our players to create their own laughs out of the tool set we have provided. That being said, there will be more amusing tidbits added as more content fills the game.
14 02, 2015
We are initially working with a male player character that can be customized as you advance with different clothing and equipment. Gav has modeled the character and a number of different clothing items that can be fabricated in the world using collected resources. Different items will have different properties, allowing you to survive in some of the harsher biomes present in hurtworld. These are all compiled into the rig/prefab. Animation wise, we are going for a ‘stylized realism’ – Not toony but also not mocapped photorealism. Rather than risk TL;DR, here are some vids for your enjoyment