Press Kit Wiki

Hurtworld Update #25

Meow

Spencer

Hey Hurtworldians,

It’s been an exciting week for us as we start to dig our teeth into the more juicy changes to Hurtworld we’ve been wanting to get to for a while. This blog is a lot more technical than usual, with a less pictures. It should give you a good idea about where we are headed over the next few months.

Infamy changes Part 1

Over the last couple of weeks we have tossed up pretty much every possible scenario to improve the issues posed by the current implementation of infamy. This included looking at everything we have committed to so far with the direction of the game, and asking the question “How married to this are we. Does it create more problems than it is worth?”

The first thing that stands out is tying prevention of griefing to penalty for death was a dumb idea. Griefers gon’ grief, we shouldn’t destroy the game trying to prevent that. The first thing we need to master is penalty for death, so for the first iteration of these changes, that is all we will be focusing on.

The second thing we had a long hard look at was “Is storing progression value in gear a good idea?”

In my previous infamy devblog I spoke about the extra challenges we face by having so much progression value stored in gear without looking at if this was really improving the state of the game. It was just a given, that’s what we do.

The more we discussed different options to make progress securable while still creating constant danger for the player from death, the more we realized that we are making our lives harder than they need to be.

Regardless of any suggestion we or anyone else came to about how to fix the current problems, the glaring point that came out of it was the problem is far too hard to solve using our current tools. There are simply too many factors involved that we have no finite control over to ever reach something balanced.

We need a cap on item value

As long as the value of items can constantly increase, balancing loot is going to be impossible. When you craft an item, it can have infinite value to you because you will have it forever. We balance for this by making things very expensive, this is what makes full loot suck.

As I described in the first infamy blog, we will be shifting some of the value from items to other places like your base. The upcoming C&C machine and others is perfect for this purpose. Instead of investing 100 iron and 100 mondinium in an AR rifle, you would invest that in a machine that can craft rifles, then pay a cheaper price to craft the rifle.

At this point losing the rifle will only take away the cheaper cost to create a new one, but not the whole investment, yet your attacker can get the bounty of the function of the item.

Nothing lasts forever

This poses a new problem for us, if the reproduction price of the item is low, first person to get the production facilities can deck out his whole crew with guns that will last forever. Anyone who kills someone that is pumping out these guns also instantly gets decked out.

To give us more control over balance we need to be able to restrict the lifespan of an item. The best way to do this is to introduce durability.

With durability on items, we can say, one creation will net you x amount of gathered resources before you either need to repair or replace it. It serves as a currency sink so one person doesn’t end up with 100s of useless pickaxes, and most importantly limits how much you lose if you drop an item, as even gear is a finite resource.

The second problem I see here is that the manufacturing facilities being shared, gives larger groups a massive advantage. While we can’t completely balance PVP with groups of different sizes, we can do our best not to give them more advantages.

To counter this, our plan is to also introduce durability to machines. Meaning that initial investment in production of an item isn’t infinite, so depending on how many people are trying to share it, they will need to spend more to keep it running along with the crafting costs.

What this means for infamy

I think its probably a good place to stop calling what we are dealing with as infamy. Infamy was an experiment with a cool name, it was a standout differentiating factor from other games but ultimately wasn’t workable solution to all our problems.

The problem at hand here is penalty for death, to which infamy is no longer the solution.

What will drop on death

At this point I am leaning towards balancing for partial loot (everything except clothes always drops), with a view to eventually go full loot. At least with the above changes, full loot will be significantly less punishing stupid.

There are still some issues to work out around respawning in an area that you can’t survive in without gear, that we need to work through, so initially we will keep clothes as unlootable with durability loss on death.

As with any game design choice, testing is key. We will be working towards the above changes over the next couple of months and move from there.

We may still have some sort of amplified punishment in future for killing people, but we will look at that after we sort out penalty for death and get it right.

This brings me to the technical limitations we need to overcome to implement these changes.

Items 2.0

Something that I’ve been meaning to implement since I first started work on Hurtworld is the ability to store complex state on a per item basis. The fact we have survived this long without it is due to a few dodgy hacks, and nothing really needing it that badly.

Currently all items are static. At compile time we create things like Assault Rifle, Cooked Stake, Shaped Iron etc. The only things that can make 2 copies of the same item different are ammo count and how soon it will transition to another item (like being cooked or smelting).

This really isn’t a workable solution going forward. We could hence I have started work on Items 2.0.

There are quite a few goals for the new system, which I think is going to bring a lot to the game:

1. Ability to store and display durability information on each item
2. Ability to store ammo in a non buggy way
3. Supporting different ammo types loaded into guns
4. Weapon attachments
5. Random weapon / tool stats (think Diablo / Borderlands)
6. Proper client side prediction of weapon / tool simulation
7. Cleaner bullet simulation
8. Improved UI that can display things like how long until a steam goes off etc
9. Item stats that can modify things like reload speed and mining speed.
Most of these are self explanatory, I will go into more detail about a couple:

Client side prediction of equipment

Client side prediction is a tool which we use in network games to ensure you don’t have to wait for a response from the server before you see your input acted upon. Eg: When you run forward, you expect to instantly move despite the server needing up to 200 milliseconds to verify that you have moved.

When predicting things client side, we basically assume with some reasonable assurance that we know what is going to happen on the server when we do something. If we try to walk forward, we expect to move forward. Pretty simple. The server gets our instruction to walk forward some time later, runs the same simulation as us, and sends back the result.

By the time we get the confirmation that we walked forward for time tick 3, we are already at time tick 6. We check what position we were at time 3 (we kept a log), and verify we predicted correctly. If so we keep on ticking from time 6. If we got it wrong for some reason, we need to rewind to time 3, and replay our input to time 6 (we kept a log of input also), compare the new time 6 to the old time 6 and smooth towards where we should be. This smoothing is what people call “rubber banding”. The more lag on a server the more often we get slightly out of sync and need a correction.

Although quite tricky to get right, its not complete rocket surgery thanks to the brilliant mind that is John Carmack not only paving the way, but open sourcing the Q3 engine for us to all learn from. This is implemented for player our movement and is fairly rock solid.

For guns and tools, we predict what is going to happen, but have no way of knowing if we got it wrong let alone executing a correction. You may have seen times where the gun jams, and only re-equipping it can fix it. Or when the shotgun gets stuck in a reload loop. The reason we haven’t attempted to fix these yet is that they require a big refactor of items. Since we are changing a lot in this area, now is as good time as any to fix these foundations to bring weapon prediction in line with player movement.

Timeline

As you may have already noticed sticking to a tight schedule isn’t our strong point. The above is a fair bit of investment, that will result in not a lot of updates in the next couple of months.

What we can achieve in 2 weeks with 2 programmers is not going to enable us to do much with the game. The stuff to get excited about takes months, so that’s how long we will take. We have been on the lookout for another senior programmer to get things moving a little faster, but like every other software industry, good programmers are in very high demand and thus hard to find. The search continues.

Mils

So I am still grunge-ing up the city. This week I have been breaking the walls structures up, which takes quit a bit of time. I have now got a couple of broken wall sections per wall type.

BWalls2

To achieve this I have just cut up the existing undamaged wall sections and moved the meshes around on the existing textures. I didn’t have to add any new parts to the existing textures to get this result which is always what you want where you can manage it. This will save texture space for all the things we want to go in like; Garden Planters, Garbage Bins, Piles of Trash & anything else that will break up the street level space.

BWalls1

Oh yeah, and I also made some rooftops that will probably eventually have doors, so you can lock down the stairwells. Useful to stop sneaky flying people from getting in.

Cow_Trix

Community Communication

Hey Hurtworlders! This week I’ve been looking into ways to get more feedback from the community, directly in game, as well as getting some level of communication from the us to you in-game as well. While we have the Steam forums and some other channels for feedback and developer communication, we find that a significant majority of players don’t interact with these. So, optimally, we’d like some kind of announcements panel in the main menu, where we can put things like news, polls, patch notes, and more! We want every player to have at least some exposure to the wider Hurtworld community than just the server they play on. Dota 2 do this pretty well I think, if you’re still trying to picture what I’m describing.

To do this, I’ve been looking into integrating a webkit browser into the UI, which would give us the ability to display pretty much whatever we wanted. This means we could just display a web page as part of the UI. We could update it dynamically, without needing to put out a patch, and it would be extremely flexible in what we could display. To change the look and feel of it, we could just update the CSS, and to change the content it’s a quick edit to some html. Awesome!

Things like polls showing up right in the main menu are exciting, as it gives us a very broad sample base for polling. If we posted a poll on the Steam forums, we’d get some really important information, but we’d also have a pretty huge selection bias. Most Hurtworlders just don’t frequent the forums, and we want their feedback as well.

We hit some frustrating road blocks in this, or I reckon it could have made it into this patch. There seem to be some issues with how the webkit plugin interacts with the Graphics Layer, which causes crashes from mis-timed render events. Basically, the webkit plugin tries to interact with Unity’s graphics at the wrong time, and Unity doesn’t know how to handle it, so it has to crash. Hopefully we’ll get some love from the plugin developer and have these issues resolved, but I think its gonna be pretty awesome when it’s done.

 Gavku

This week I have been modeling and texturing the Monkey-Bat guy thing. Initially I had built him in a more leaned over neutral pose something akin to a Baboon, however we have decided to go with a more upright bipedal critter.

MB_Wire

So essentially I cut up that model, rotated and manipulated the geo, then stitched it back together. Because I had already done a bunch of the texturing I was able to bake that across to the new model as a decent starting point. This is what it looked like after being stitched back together.

MB_1

I then began repainting in mudbox and photoshop, fixing up all the seams, and giving it some characteristics more in line with a bipedal creature.

MB_2

Dazzler

I have been carrying on with the cat animations, which are almost done. He has been a challenging creature to animate, trying to get that nice fluid power. Aggression is easy. Smooth is easy. Smooth Aggression is quite hard! Here are two transition sequences between aggressive idle poses.

Few little bug fixes for the patch, and the template laid out for the Skoogler rig too.

Hurtworld Update #24

Cow_Trix

Hey Hurtworlders! Couple of things I’ve been working on over the past week.

Ambience and Music

I’ve been setting up the infrastructure to do more complex ambient sounds, as well as some music tracks. We’ve got at least 2 ambient tracks per biome, one for day and one for night.
This meant a bit of refactoring of how we create the soundscapes of Hurtworld. What seems on the surface like a pretty easy thing gets complicated fast once you start digging a bit. For instance – it starts raining, which makes noise. You can just overlay the rain over the ambient sound, but this ends up being a bit of a cacophony. Optimally, as the rain gets louder, we want the ambient sounds to get quieter. We’ve got a finite amount of volume to give to all ambient sounds, and we need to figure out a way to share it out.
So, the new architecture gives ambient sounds three options – Greedy, Normalize, or Overlay. Overlay is the simplest – this doesn’t care how loud other sounds are, and other sounds don’t care how loud it is. We use this for things like the irradiated effect. Normalize means that the sound should try and fill whatever volume it can, but it should never reduce the volume of any other sound. This would be all ambient background tracks. Finally, Greedy would be the rain, which consumes whatever volume it wants and leaves the Normalized sounds to fight over the scraps.

I’ve also been adding in some music tracks, which will play randomly every so often. Don’t worry, there’s a volume slider if you’d rather blast some death metal while spearing nakeds. All in all, these new sounds add a lot of atmosphere and ambiance to Hurtworld.

Exploits

Hurtworlders love to break stuff – which is great! We’ve come a long way in fixing exploits since release, and we owe that to the community for finding and reporting these. Remember that time you could double-jump by opening your inventory? The series of events that made that possible in our code was… pretty mind-boggling, and we may have never found out about it without your help.

It turns out that there’s one scenario that creates exploits a lot, and that’s whenever you transport the player. This happens a lot in vehicles.

So, a simple scenario. You’re on a goat, and you decide to get off. This is basically a teleport – you just kinda poof off the goat, and appear somewhere else. But where do you appear? It’s a simple problem when your surroundings are simple – say, you’re just on a flat surface. Just appear next to the goat, problem solved. As your surroundings get not complicated though – say, a bunch of rocks, buildings, etc. – there’s a lot of trickiness introduced, and it’s difficult to always answer that question properly. When it gets it wrong – say, teleporting you halfway into an object – that’s when exploits happen.

I’ve been making this system a lot more robust so this can’t happen. This means, however, that there are some situations where there is no good answer to where you should exit. Say, if you’re completely surrounded by walls. There’s nowhere to go, so what do you do? Easy, right? You just tell the player that they can’t get out. Problem solved! But wait – there are situations where the player has to get out of the vehicle. When you disconnect, or the vehicle is destroyed for some reason, you must exit, because its nonsensical not to. Really, the only solution to this is to kill the player when they end up in that kind of scenario. And I mean really, if you’re trapped that bad, you’re probably going to have to suicide anyway. The moral of the story is – don’t disconnect when you’re in a vehicle.

We’ve also had some reports about sneaky people getting under the terrain! Fortunately, it’s pretty easy to check for this and just kill the player.

Spencer

This week I put the finishing touches on the Map SDK which is now live. This isn’t much use without a tutorial on how to use it, so I’ve been also recording my first dev videos and uploading them to YouTube. Definitely not my forte but I’m sure they will get you started on using our toolset.

Getting the SDK

The SDK is downloaded through Steam under the Tools section of your library. I am currently working with Valve to ensure everything shows up as it should, if you can’t see it now give it a couple of days.

To use the SDK you need to first download Unity 5.3.2 P4. To build maps you need to make sure you tick the Windows, Linux and Mac Standalone support in the installer (not enabled by default).

https://unity3d.com/unity/qa/patch-releases

Usage beyond that can be found in this video series:

YouTube / Hurtworld – via Iframely

The focus on these videos was not to tie up too much of my time editing and rendering, so excuse the roughness. The final part of the quick guide is rendering now and will be added to this playlist tomorrow. I have a new found respect for youtube / streamer fam as I now see how much work it is to plan record, edit, render and upload a video to YouTube!

Infamy Stuff

Going through all the infamy stuff this week was pretty time consuming, I appreciate everyone’s input on the discussion. I feel that writing it out in a blog was useful for myself to lay out the next steps to take with fixing the problems.

I have a pretty clear idea of what approach we need to take, some things pretty drastic, I am keen to get back to working on it as soon as we get the engine upgrades and current patch cycle released.

Server Perf

I’ve seen a few posts about server performance getting pretty shitty on the infini wipe servers. This was expected at some point, we are now 26 days into the wipe schedule, far longer than ever before. There is obviously some areas we need to look at to ensure perpetual servers are sustainable, we will be looking at that this week.

When’s the Patch?

There won’t be a patch this Friday as there are still a lot of things that need testing. The patch won’t require a wipe when it hits, so I will aim for mid next week.

Gavku

We are big fans of the Skoogler, so I did an extra skin, making a version that gives it a more dirtied up, slightly diseased look. Such a filthy Skoog.

DirtySkoog

I have now moved on to a new creature, who is sort of a monkey/bat hybrid. Hopefully they will have fast movement and a decent sized leap, allowing them to both chase down players and also attack via leap/harassment. We want to make the critter something that players will think twice about engaging. Potentially making it nocturnal giving it it increased stats or perception etc during the night………….I also think some sort of Howler Monkey esq sounds as they chase players down might be cool.

MonkeyBlog

We’ve been pumping out creatures while we still have our creature animator full time. That role will hopefully be transitioning into a programmer so we can through the bottleneck of game mechanics work.

battlemu1e

Not much from me this week. After spending some time in official servers over the last few weeks I have been hanging out in community servers this week meeting players and making contact with server admins. During this time I have been amazed at the creativity and community surrounding the servers I have visited. I have seen events ranging from deathmatches to dodge ball, taken part in a purge and have seen player structures varying from castles to pyramids. It is always great to see the different ways players are having fun in game.

On the other side of the server list I have been monitoring official servers. Last weekend full loot servers went infini wipe leaving 14 day servers as the only servers with scheduled wipes. The next scheduled wipe for these servers is at the end of the week and there won’t be any changes to wipe schedules or server numbers as part of this.

As always I’ll be in and out of servers so if you see me in game feel free to say hi!

Mils

Destruction is my name this week. These individual rubble pieces make up the bulk of the rubble. By making a few detailed bits at the start I can then stick them together in a variety of ways to form unique looking piles.

Rubble02

Rubble01

I made 3 Normal mapped blobs of geo after to stick the individual pieces into. I think 3 piles will give a good variety which I can then smoosh together and scatter around to create more individual shapes.

Rubble04

Rubble03

These have turned out quite well. I will be breaking more of the city moving forward.

Infamy – State of the Union

infamous

jitsuin requested a dev response to the infamy questions. Its about time we addressed this and my response became so large it deserved its own Devblog.

Lets start with the logic behind infamy

One of the main goals of Hurtworld was to create a survival progression with something closer to that of an RPG. Where once you can handle the starting area, you get some more gear and move up in the world, find better stuff, keep going. What we have currently is a prototype of this progression, it works in some cases and not in others. Once we can get the formula right we plan to create many more tiers of loot and PVE challenges.

The more you let a player progress while still in full loot, the more they have to lose. Add on to that fact that in a PVP environment, a death can be caused by wrong place wrong time and there is nothing you can do about it.

So we have established that we have players carrying possibly weeks of progression that could be lost on death, and being killed could be caused by no fault of their own.

Lets look at ways that other games deal with progression loss

Rust: Materials for a full kit of gear can be farmed relatively quickly, the main progression here is blueprints. If you have the blueprints, even from a fresh spawn you can get back up to speed quickly. Towards end game, items you are holding generally don’t have any value, meaning a death doesn’t set you very far back. Being raided is a larger setback but still doesn’t take away your blueprints. Blueprints look to be replaced by MMO type levels soon. Levels will have the same effect as blueprints, progression that can’t be looted on death.

Day Z: Gear is easy come easy go, a lucky run through Cherno as a fresh spawn can kit you out completely. Death truly does lose everything but the progression ceiling isn’t very high here (based on my time playing the mod, not sure how it is now)

Ark: Though I have never actually played this, my understanding is much of your progression is tied to the level system. PVP seems to play out much like an MMO where higher level players will always win against lower level players. Gear doesn’t seem to hold a great deal of value.

Where does Hurtworld store progression value?

Currently in Hurtworld I would say on average 70% of progression value is stored in gear, 30% stored in your base. Nothing is bound to your character. The reason full loot sucks in Hurtworld, is that losing 70% of your progression (which could be weeks of work) in a single bullet to the back of the head isn’t fun. Its not hardcore, its just stupid. We store much more progression in gear than other games, nothing is secured in your character. Our progression is going to get much deeper and its already too much to lose in one death. Full loot is not the solution!

Lets separate the 2 parts of infamy as they are unrelated

Although these are tied together under one system, there is really no need for them to be related. Our two goals for infamy are:

Punishment for death

People should always fear death. Currently sometimes they do not, this needs to be fixed. However they should not fear death so much that there is no point to living. Investing in progression is pointless if you can’t secure it to a point.

Punishment for murder

The decision to kill someone should come at a cost, this cost should always be lower than death, but never become trivial. This is broken because the punishment for death is usually too low. The prospect of losing a core piece of gear is usually far worse than losing what you have gathered this farming run.

This is a consequence I didn’t foresee

Given the fact that the value of your gear constantly increases, a single farming run diminishes in relative value the further you progress. Meaning the cost of death with no infamy decreases vs the cost of losing a piece of gear due to gaining infamy. AKA Shooting someone sometimes costs more late game than death. This makes the formula above much harder to balance.

The second factor at play here is that with no infamy and all materials banked in your base, death has absolutely no punishment. This needs to be fixed first.

How do we fix it?

We have a few options here, we will probably require a mix of the following:

  • Add more or an altogether different penalty for death so regardless of the situation, you don’t want to be killed. Ever.
  • Change the penalty for murder to something that doesn’t benefit the person being killed. It was a nice perk that an infamous player would become a target to gain items from, in practice it rarely plays out like that. It would probably work better if the penalty didn’t benefit anybody else like it currently does.
  • Reduce the penalty for murder late game, we aren’t trying to discourage PVP
  • Shift some of the progression value from gear to another place like your base, then making players drop more items on death, as losing less progression value wouldn’t be as devastating. This would give players of a similar progression something to gain by killing each other that might outweigh the murder penalty. If balanced right, the murder penalty would be more expensive than what you stand to gain from killing fresh spawns. A problem this opens up is that progression invested in your base can be shared across teams (investment in production facilities etc), giving large clans a big advantage. We could add machines that can only be used by the owner, however as the reasoning for this isn’t clear to the average gamer, we would be barraged with “Why can’t I use my friends C&C machine, this is stupid!?”

The important thing to see from this isn’t that any of these things are the golden bullet to the problem, but that there are lots of complex elements at hand. Every choice a player makes in the game comes down to priorities. The questions we care about here are: “Is it worth shooting this person in the face?”, and “Death, am I too afraid of it or not afraid enough?”. Most of the suggestions I see are only valid for one scenario, and would be exploitable in another. A balance that works for early game will likely be totally broken late game and vise versa. Something that works for players with full gear will likely be broken if someone just runs around naked with a single weapon. Something that works in a 1v1 situation will likely be broken in a 1v5. Not everyone plays the game the same way you do.

We need good feedback on these systems, not knee jerk reactions to patch notes. See how something plays before giving your opinion, and please give it in a way that doesn’t make us dread reading feedback.

We will be adding in changes to address the above points over time, its not going to be perfect over night. Its an iterative process, good games take years to build, not weeks.

Dev Blog