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.
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.
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.
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.
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.
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.
[gfycat data_id="DistantEveryArieltoucan"]
Few little bug fixes for the patch, and the template laid out for the Skoogler rig too.
