Hi Guys, a much more positive note this week. For the first time in ages, Hurtworld is playable again. Our Friday internal build was close enough to releasable I am confident we should have something to push to experimental this Friday!
With that, I will outline our plans for the next couple of months. However you probably know by now to take whatever I say with a bag of salt 😉
Over the weeks / months of internal testing I’ve tried to do, I’ve found that my goals for the systems we’ve been building aren’t as simple as “throw them in and game is 100x better”. We are trying a lot of things that really haven’t been done before, and with that comes a lot of stuff that doesn’t work first time. The hard part here is determining whats a bad idea vs sub par execution. The only way to figure these things out is keep trying different things, rapidly iterating and scrapping until we break through the barrier.
We have established the wipe schedules, which have obviously become stale after a long period no new content. We plan to turn this on its head.
The current live branch will remain for those who want a more stable experience, and each week / fortnight we will be wiping and releasing drastic changes to the experimental branch. One week might be on a massive map with an RPG progression, the next might have guns everywhere and make C4 super cheap. We are going to prototype drastically different types of survival without worrying about staying true to our roots. The ultimate test of these experiments will be how much you guys want to play them. We eventually hope to distill the perfect survival experience from these experiments, and refine it into a polished game.
Our tools and your tools
Probably the most exciting thing about the Hurtworld post ItemV2, is that over the last 8 months we’ve been working our asses off to restructure the way we work to give modders almost as much power over the game as we have ourselves. We now author content for vanilla Hurtworld using our own mod tools, meaning while we are flipping Hurtworld on its head making experimental builds, modders can start doing the same. Like a configuration from one of our experimental weeks? Grab a copy of the mod project and keep working on it or install it semi permanently on your server.
What experiments come out this Friday?
This weeks build will be a much buggier version of the current live branch of Hurtworld (not super exciting). As much as we can cram into our new systems, we aim to match what we already had. This is in the interest of walking before we can run. We need to test our new systems at scale before thinking about game play experiments, we have done an enormous amount of work under the hood, so this week will be to let everything break and give us some time to fix it in a controlled environment. The awesome part about re-implementing the legacy progression is how easy it was with our new tools, this means iteration will be mega fast.
What after that?
Once our new systems are stable, I expect this to take about a week maybe 2, we will start to introduce the new gameplay elements I’ve been talking about in the blog for ages. Things like blueprints, how and where resources come from, punishment for death, kill loot, durability, repairing, respawning mechanics, teleportation, raiding costs etc.
Each new experimental wipe, I also hope to include drastic map changes. What we are releasing on Friday will be a completely procedurally generated map, meaning by tweaking configuration values we will be able to deploy a new map with very little effort. As a minimum we can change the random seed to generate a new map with no effort, but I hope to slowly improve it as time goes rather than it stay as a monolith that I don’t dare touch like daemonsland. We have a truckload of buildings and city assets waiting to go into the map, more and more of these will be added to the generation landmark sets as we go.
Pre-early access all over again
So we are sort of back where we started, which I have no problem with. Nobody would say we got Hurtworld perfect the first time, and I think its safe to say the survival genre is still a bit of an awkward experiment straddling between Arma and World of Warcraft. I still believe there are amazing possibilities to explore.
We do actually want (and need) your feedback
We’ve been a bit quiet on the old community interaction for a while… we haven’t released anything new for a while, it doesn’t really make sense to get feedback. We’ve discussed the live branch to the ends of the earth, we just needed to get stuff done. Now that we are releasing the experimental builds, we will be ramping up our presence in our community channels, tell us what you think, we will be listening.
Re imagining of live branch in ItemV2 on experimental branch this Friday for stress testing (if all goes to plan), then weekly or fortnightly wipes with drastic gameplay experiments on the experimental branch over the coming months.
I’ll leave you with the procedural bot configuration (which picks eye bleeding colors), and running them down on a bike.
I’ve been making some alterations to some of our existing assets this week. Firstly I was tasked with combining the eye of the Shigi into the rest of the mesh. Using some weight copying to assign the mesh the correct weights got me most of the way there. Turns out Maya’s copy weights tool is not the best. The tool copied most of the weights across without issue, however the front feet lost some weight data, and I had to manually paint them back in. I got there in the end but I feel that if the tools weren’t so dodgy it would have taken far less time.
The next small project I was tasked with was modifying the FPS version of the arms. This model is used to show the arms and hands in fps mode. The FOV (field of view) has been modified on at least some of the guns, causing the tops of the arms to clip through the camera plane. I removed the shoulder parts for the arms and initially had just rounded off the shoulders to be a kind of stump. I didn’t love the stump look so I made a cross section of cut off meaty texture instead. These were a hit with the other guys and so we decided to keep them. They have now been dubbed ‘Steak Arms’ I also had issues with copying the skin weights over. The fingers had issues where the weight maps were copying onto the wrong parts even though the geometry is exactly the same. Sorted that out too though.
This week I’ve been continuing getting ItemV2 ready for the experimental release. It’s been awhile since we’ve ported the bugfixes over from the live game into ItemV2 so that’s been my focus this week. The last time we merged in changes from the live branch was just before we added sleepers so I’ve had six patches worth of stuff to merge up.
Unfortunately any kind of auto-merge wasn’t really appropriate because some of the fixes were for systems that don’t exist or have radically changed in ItemV2, some were fixes that were ported over from ItemV2 and for some things like Unity prefabs or our item objects the serialization has changed so much that no kind of auto-merge was possible.
Luckily because I’ve been doing most of the bugfix patches the changes and reasoning for them are relatively fresh in my mind so I’ve been able to get through them at a good pace. Currently we are now synced up with 0.3.8.5 except for the sleeper system which I’m working on as I write this and should finish soon.
Unfortunately we didn’t make it to experimental release last week as hoped but we managed to get our internal test build up and going on Friday.
Whilst this contained some bugs we are working through now and it also needs a bit of an early game rebalance due to the nature of full loot we are feeling pretty happy about where it’s at and as long as no major disasters occur you’ll be able to play it this week!
Had an enjoyable week designing different ammo containers, looked at a lot of vintage ammo boxes for inspiration, back before design principals existed. Due to the simple shape of the boxes, the colour selection had to differ greatly other wise players could potentially become confused about which ammo they had, which is not a great situation in the heat of battle. Made some changes to the 5.56 ammo crate, took out a lot of the noise from the texture making sure it fit into our style a bit better. The quiver ended up with a very primitive design which I think suits it considering arrows can be crafted pretty early in the game. The arrows are very low poly as the poly count needs to be kept down considering you can throw out a ton of world item, which is why they look very square. The feathers will possibly change once the arrows get done properly.
Getting pretty close to finishing the list of world items I have, Concrete, String and Wood Planks next! Still trying to figure out the best way to go about texturing shiny things like Amber and Diamond stuff, most likely a job for someone on the technical side of things.
Hey folks. This week I’ve been fixing up and extending some of our commonly used shaders, implementing some performance improvements and fixing various broken things for the ItemV2 patch. We had a good play on Friday, and it’s all looking and feeling pretty sick!
First up this week, I changed how we copy the EntityStats to a creature when we instantiate a new instance. We’ve talked about EntityStats on here before, but if you don’t know, it’s the system that Hurtworld uses to simulate things like temperature, health, damage, nutrition, all that stuff. Every instance of a creature, player or machine needs its own instance of it’s EntityStats. Previously, we did this with a very expensive JSON based clone method that was very easy, but very very slow. I remembered that Spencer had built a pretty awesome Ahead-Of-Time clone attribute a while ago for Items, and I thought that it might work well for this use case as well. It was awesome! With just a few little adjustments, I could generate concrete AOT cloning methods that would create deep, new instances of these complex objects. You can see how much of an improvement that was to the server startup time! We went from 18 seconds, to < 1.
I also spent some time getting our commonly used shaders up to scratch. Our shader workflow is pretty successfully in the Unity Standard PBR now, but there are some things where that just isn’t possible. Namely, water and tree billboards, which are transparent and complex. As they are transparent, they don’t (nor should they) draw to the depth buffer. This means that post effects like atmospheric scattering don’t work out of the box like they do for opaque objects. Previously I had to do this whole thing where I extracted the atmospheric scattering logic in a way that could work easily for vertex shaders, but I was in luck! The Time Of Day 5.6 patch contained functions that easily did all this so it was much easier to implement this time around.