I finally broke the back of the upgrades to the equipment system this week, its taking longer than I originally expected but needs to be done so we have the infrastructure to push forward. One of the biggest wins from this week is integrating a tool that is going to save us a heap of time, and paves the way for mod driven equipment. We are now using a visual state machine editor for simulating equipment. If you’ve ever tried to code something that simulates a state machine without building a framework, you would know it usually ends up a massive mess. That’s what our equipment was before.
The simulation now looks like this:
This will heavily reduce the amount of logic we need to hardcode into equipment. All this configuration can be serialized into JSON, then fed from the server to the clients on connection. This means server side mods can mod client side predicted equip behavior.
This framework also exposes a solid implementation of behavior trees which kicks ass for AI. We have a custom implementation of something similar, but it never reached a stable maturity and is a pain in the ass to work with. I have high hopes this will give is a bit of breathing space to create some more interesting AI behaviors for the upcoming creatures.
Part of this integration is the tricky process of refactoring equipment code so that it stays in sync with the server. This system gives us the ability to consistently synchronize state behavior from server to client and to player animations without a heap of glue code massively reducing the overhead of creating new weapons and equipment.
The hope is to get a working prototype of most weapons implemented in the new system this week.
I have been working away on creatures, as well as a few fixes and additional changes for the big character-controller/gun-play Spence has been working on.
Here is some “Rig Pr0n” for those who are into that sort of thing. It is a task that takes quite a bit of time, though not sexy for most ;P.
mmm… sexy matrices
Here is a quickie of the Skoogler skoogling, to wet your appetite for some hurt-turkey…
Interestingly, Gavku pointed out the Cassowary (upon which we draw inspiration) makes the following noises;
I have been putting together all the City components and have made a pretty good basic fleshing of how a real city would look. The few different textures I previously built along with the ability to vary the shape and heights of the buildings has actually come out quite well. These are just the basic structures. I will later add the extra dressing that we want to add to give some of the buildings a unique look.
We tested this for performance and I gotta say it’s not amazing right now, but not to worry we are now figuring out ways to cut down on some of the polycounts. This is needed to maintain our high Frames Per Second standard. We will probably have to cut down on the amount of floors each building can actually access. Using some clever LODing we should be able to get the polycounts down and maintain a reasonable quality. If it were 5 years from now and we had future Graphics cards we could probably get away with each floor being accessible.
Once we have the main city building block performance under control, I can move onto messing the city up some more. We want to add some standard assets which you might find strewn around an abandoned city. Items that can fill the road space and the interior spaces whilst looking like the place has been long since ransacked. I guess watching The Walking Dead will be on the cards for me. 😉
I have still been working on updating all the construction textures. The wood, stone, and metal textures and materials have all been done, focusing on bringing them in line with other textures in the game and making sure that repeating textures aren’t overly obvious.
I have also updated some of the meshes of certain construction prefabs. Pictured is the new ramp and support truss. As well as unifying the art style, I also reduced the tri-counts which should help give us a little bit better performance.
I have now jumped onto creating new construction pieces with Sean, with the hope of giving players a host of new possibilities in regards to personalizing what they build, as well as some additional functionality.
This week I’ve been continuing work on the construction system. Some cool stuff is coming out of it, that I’m looking forward to getting into the wild.
One of the biggest things to get done is allowing individual structure pieces to have distinct properties. For instance, now a wall (or any other piece) can have a health value, an armor value, anything we want! We can even put color in…
This also affects something I’ve mentioned before, how explosions will work with building damage. As now we can do much more accurate physics about how something is hitting a building, we can do much more realistic simulations of explosions. The blast can be blocked by structures that are strong enough, bounce off structures, and have it’s damage reduced when it does bounce off of something. This is going to make explosions much more physically realistic and dynamic.
Me and Gavku have also been looking into expanding the flexibility of the prefabs themselves, by adding new ones and changing the way we use the existing ones.
Part of this is giving more fine control over your buildings, so giving some smaller options for construction pieces. Currently some things like support trusses and floors are only 4m2 blocks, but there’s no reason we can’t give players 2m2 blocks instead and let them design much more intricate spaces. We’re also looking at things like diagonal walls, aesthetic trimming, ladders, windows, and more.
I’m really looking forwards to giving players the ability to customise and distinguish their bases and buildings more stylistically. The more customized a base is, the more its not just a functional space. It starts to become a home, and you get attached to it.
The approach we’re taking is we want to see buildings in other games, art, or the world that we think are awesome, and then provide the tools to be able to build that in Hurtworld. What kind of base do you want to be able to build? Let us know!
Hurtworld Update #26
21 03, 2016
Hey guys. Couple of new things this week, including construction, and looking at highlighting community servers that are doing cool things.
When I haven’t been getting this patch sorted, I’ve been looking into revamping the construction system. Currently, the system has exactly the same mesh for collisions and rendering. Because complex mesh colliders are very expensive, this means that the building generally have to look very simple as well as collide very simply. It’s also tricky to do things like complex level-of-detail, finding out what part of a building a projectile hit, and more complex destruction.
So, I’ve been looking at expanding the already very nice construction system to be able to accommodate all of this! First, a bit of information about how the construction system works, specifically the passive construction system. Things like machines, firepits, storage lockers, we refer to as active, and are just objects in the world we treat like individual things, because they need to do stuff. However, if we did that for every single wall piece in the world, the game would be unplayable. So, for things like wall-pieces, trusses, foundations, etc. we gather them all up, and bake them into combined meshes to save on both physics processing, and rendering.
Basically, say you construct a new wall. The game goes and finds the whole structure, and tells it about this addition. The structure adds this information to a list of things that have gone into making up the structure, and then goes and rebakes whatever meshes it needs to – in this case, all the combined walls.
So one tricky problem we had to deal with was this. Say you’ve combined a building into one big collider, and then you shoot it. How do you tell which of the original building parts it hit? The physics doesn’t have any distinction anymore between one part of a building and the next, it just treats it as one big object. The solution we figured out was to count the mesh triangles. Let me explain. Meshes are made up of a list of triangles, or tris, that describe an overall shape. When you raycast against a mesh collider in Unity, one of the bits of information you get out of that is what the index of the triangle you hit in that mesh was. We also know how many individual triangles were in each piece of the building parts. So, we can simply count upwards, adding on the total triangle count for each piece as we move through this list of additions, and when we get to the range surrounding our number, we know we’ve found the piece.
Awesome! This opens the door to cool things like stats for individual parts of buildings, and much more dynamic destruction. You might be saying C4 already does what seem like fairly dynamic destruction, and you’re right, but the way it does it is very expensive and not particularly good. This method is much more flexible and future-proof. We can start saying this piece of wall has this amount health or heat resistance or anything, really.
Featured Community Servers
Something we’ve wanted for a while is a way to highlight community servers that provide a good experience for players, or are doing something really cool with mods. We’ve introduced Featured Community Servers, so we can highlight servers that we think are cool and should get some more love. Of course, we want to do this with the server owners consent, so we’re not flooding someones intentionally small server with attention and new players. We’ve had some awesome feedback and lots of nominations on this! It’s been really awesome reading about how much you folks love the servers you’re on and want to see them get the recognition they deserve.
If you’ve got a community server you think should be featured, let us know here!
This week I have started to update our construction materials and textures. The process I use at this stage is to usually grab a photo ref texture base, tweak it in photoshop ( mainly levels and saturation, sometimes quick painovers ) then take it straight into unity and throw it onto some construction pieces. Making sure that the tiling isnt overly obvious is the first thing I pay attention to, either tuning the tiling settings in the material setting, or scaling the texture in photoshop. Having a large structure built like the one below helps in this and I will move to various distances to check the readability as well as occasionally changing the lighting conditions. During this time I am also taking into account how the colours read and whether or not something is standing out too much against its neighbor. I then take the base texture back into photoshop and paint out a lot of the photo real detailing, making sure that everything still tiles ok as I do.
I want to add normal maps and spec maps to the new materials ( nothing crazy just something to add a tiny bit more pop and personality ) so when I have a texture that I think possibly looks ok, I will paint a height map and use that to generate a normal map. I also use the height map as a fairly decent start point for a spec map.
I’ve been hard at work on the upcoming equipment restructure and infamy changes. As part of these changes I am taking the opportunity to do a major refactor of the equipment system which will provide massive improvements to the stability and quality of gunplay. Now that we are starting to see some deathmatch servers coming up (with new awesome community made maps), we have a better platform to iterate over the gunplay and push them to the quality we have been aiming for.
I am still a few weeks out on getting any of these things in game.
Item Schematic Concept
I’ve spoken a few times about wanting to introduce procedural loot drops (think diablo / borderlands) and have been trying to figure out a way to fit them into a more survival crafting oriented style. The biggest challenge I see is the difference between finding something awesome, and crafting something awesome. In a lootfest RPG, you constantly sift through trash loot until you find something that is an upgrade for you, stuff you don’t want is of no cost to you. Some RPGs also contain a crafting element where you collect resources and basically get one roll with a decent chance of good stats. In reality you end up crafting 10 of the same item hoping for something decent and throwing away the rest, as your gear gets better the chance of getting an upgrade gets lower and lower meaning having to craft more are more for less returns.
I personally never buy into these systems as it feels like a waste of resources, and re-crafting the same thing over and over isn’t much fun.
Now take a survival game, where most things are crafted from resources. How do we infuse the loot drop excitement with resource gathering and crafting without it being a very expensive gun slot machine?
The solution I am leaning more and more towards is having creatures / loot crates drop single use schematics that have already revealed the random bonuses on the item. The item still needs to be crafted at an advanced crafting table with variable resources required depending on the quality of the item, however there is still the gathering and crafting element similar to the existing items in the game right now.
I feel this will be the best way of delivering loot with varying quality, stats, bonuses and attachments while still fitting into a survival game. Upgrading the gear after the fact isn’t out of the question however this would be much more expensive.
I will be fleshing out this idea over the next couple of weeks, and it will hopefully make it into the game at the same time as procedural loot (still a while off)
I went on a Road Trip this week. Having created a good range of pieces for the Buildings, Sidewalks and Roads, I moved on to creating the proper assets within Unity. Firstly I made some tower prefabs, which after some thought, seems to be the best way to quickly build various shapes and sizes of structure.
Next I built a network of roads, and the idea here is that they be modular as with the buildings. I had to create a few more pieces as I went to plug small holes and generally make the system more flexible. I can think of 10 more meshes at least that will help the road system along. I need to dirty things up a lot more in general also.
Hurtworld Update #25
10 03, 2016
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.
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.
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.
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.
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.
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.
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.