This week we ran into some road blocks with the geometry that caps the open ends of items, it wasn’t doing it’s job as well as we originally hoped and the next best solution involves a bit of back tracking so while a good solution is in the works I moved on to a set of matching pants for the vest, they are still in the early stages but are looking decent at this point. A lot of different materials have been added to break up the the monotony that would occur in game had they just been a basic set of pants with a camo pattern on them. Adding in lots of different materials takes full advantage of our PBR set up and adds contrast to materials with dull specular reflections like fabric, this needs to be done due to the fact we can’t fully represent fabric with something like a knitted style pattern in the normal map as this would become far too noisy visually.
I also made a small start on some of the non-equippable items, due to these items being world items as well they need to make sense rolling around on the ground. They are also have a very low triangle count and will need to be very easily readable at small sizes, which will definitely create interesting challenges for some of the items that need to be done. From left to right: Tree Branch, Ingot, Magnet, Seeds.
Hey folks. This week I’ve been implementing multi slot items, which is coming along nicely. You might have seen multi-slot items in other games like Diablo. For us, they serve a two main purposes. They create a configurable cost of storage – similar to mechanism like encumbrance and item weight – which gives us an interesting design tool to play with. They also let us show off the new icon rendering a bit more and gives cool items like gear and weapons way more space to show themselves off in the inventory.
The extensions has been pretty simple, but there have been some interesting gotchas I’ve run into which I’m working on solution to. An item can now have a size, which is a whole number between 1 and whatever – although it will probably be an absolute maximum of 3 in practice. For instance, I’ve made the AR15 have a 3×1 icon. When in your hotbar, however, it’s smart enough to go back to a 1×1 icon.
I also added an item movement visualisation, that shows where you’re telling the game to put an item while you’re dragging it. This made it a lot easier to figure out what was going on, especially when you had started dragging the item from like the bottom right cell and it was offset.
I’m still figuring a few things out with design, and finding all the places in our code where we’ve assumed that items are handled a certain way. For instance, if you drop a multi-slot item over a bunch of smaller items, you would probably expect the one item to swap places with the many, but only if there’s room. Check out a cool gif of playing with the new inventory stuff below!
I had some holidays last week, so only worked a couple of days, but I managed to get an item finished and one halfway there. First up I made another Magazine for the AR15. This one is the cast plastic type that varies from the other folded sheet metal variety. Came out very nice.
Next up I got the Red Dot sight’s normals baked, and it came out right the first time. Now to add some normal details also known as greebles. I’ll add the detail work like screws, logo work, dents, scratches and other details. This will get finished tomorrow hopefully and then I’ll get onto the other Silencer.
Once again I’ve been working on improving our mesh baking/combining system by offloading its work onto background threads so it doesn’t block the main Unity process.
Unfortunately I’m a bit behind where I want to be again but making progress all the same. I’m now at the stage where I’ve got all our assets transferred over into the new format and all the in game systems have been switched over to the threaded baking although some bugs remain in the icon rendering system causing it to fall back to the default crate. The data is structured to support LODs but I still have to extend the priority system from vehicles to players, creatures and world items that choses the detail level based on how relevant they are (this can be more than just a distance based calculation, players aiming at you should have a higher priority just like occupied vehicles are higher priority). The other major job left in this system changeover is updating our model viewer. CowTrix has been doing some great work here while working on the item previews allowing you to load any mod’s asset bundle and preview any mesh attachment on any compatible skeleton. Converting over to the model viewer over to the new format has been pretty pain free so far, I’ve got a bug about custom colors not showing properly that I need to resolve as well as a bug with resolving dependencies across mods to find compatible skeletons and then it should all be functional. To finish the model viewer I’ll need to create some lighting snapshots from the live game so the model viewer will match the live game as closely as we can get.
Is on Holidays this week, he will be back in action with more news for the next Dev Blog.
Hurtworld Update #76
11 04, 2017
Hey folks. This week I’ve been making leaps and bounds on bringing content systems up to a playable state. I started the week working with cow_trix to bring the icon rendering to a decent level of output quality and managed to get them looking pretty nice as a baseline. Besides working on fixing the icon aliasing issues that cow_trix describes below, I also spent some time posing and configuring how things are rendered, I gotta say this system is awesome. Currently there is just a simple black glow around items to make them pop, but the system supports some pretty amazing stuff like animated glowing backgrounds on rare items, HDR rendering so we can do things like having blooming glows n stuff and eventually rotating 3d views of the icon.
Lighting on icon rendering still needs work but am waiting on some bugs in world light bleeding in to be fixed before polishing that up.
Persistant world items
Now that everything renders as their correct world items, I really want to incorporate more things in the world that will remain where you left them in world item form instead of despawning. I envision things like your garage having a stack of wheels in the corner, your favorite rifle lent up against the wall etc. I think this will make the world feel a lot more interactive, and the lodding work Tom has done on the vehicles will soon be applied to everything, meaning we should be able to handle enormous amounts of world items without a perf impact.
I finished my first iteration of the prototype loot hunt progression this week. Part of this was going back through the map generation tools cow_trix built a few months back and designing up a procedural map that fits with this new prototype progression. Once I had a simple test biome generated in our nullius test map, I created an automatic creature level map clamping to each 5 levels (meaning creatures go up by 5 levels on each border).
I would say as far as the test went, it was not great. Using blueprints as the loot hunt target at the early stage of the game feels pretty shit when you are gated by some mechanic until you can find a blueprint that gives you the stats that you want. I was ending up with 5 bow blueprints when all I needed was to be able to craft a better axe.
I was hoping to do away with the giant list of blueprints that you can craft from birth, but as this sucks I am going to push these mechanics further into the late game and we will ease into them. Another thing that seems like it should be a solid rule, is not to gate the player using a rare drop. Rare drops should give welcome bonuses, but not be the only way to progress.
The second problem I came across was it being very hard to tell how the difficulty of the world has progressed as you run through it. Having creatures with slightly different colors doesn’t give a good indication of how much they will mess you up if you fight them. MMOs usually allow you to look at an enemies level before fighting it, I’m not really a fan of this but might give it a try this week and see. Not to mention the aggro range on creatures being very long, you never really know who you are picking a fight with until they appear behind you. On this note I will be reducing the granularity of the creature spawn levels to be more hand crafted rather than a one size fits all approach. The good news is, handcrafted creatures with different properties are really easy to manage now due to the creature spawn mutator system, so not much time wasted.
Now that the game is playable again in survival, the iteration should be much faster. I will be rolling back to something closer to legacy for the next iteration and try using the new elements we have introduced as an extension to the original structure, rather than a replacement. While focusing on balancing for full loot.
Lastly here are a couple of the new biome experiments I liked throughout the week
I climbed LOD mountain this week. I made 3 LOD’s for all the current AR15 models. We can now use these to test various systems that require LOD’s. I completed all the Normal maps, UV layouts and texturing on a new Iron Sight for the AR15. This Iron Sight is very simplistic and gives the gun quite a different silhouette. I also got started on the next magazine, which is a cast plastic type, as opposed to the folded steel that the first magazine was made out of.
I before I got onto the Simplistic Iron Sight (above) I got stuck into this more techy looking sight. I was going to go ahead and bring that up to finish, but Spencer said he wanted something simpler. I’ll get round to this one eventually though, so no work wasted here.
This week I continued my work on the mesh combining / baking system, ran some promising experiments with optimising our animation systems, setup our ragdolls to work the mesh combiner as well as a couple of bugfixes in ItemV2.
The work on the mesh combining system is coming along well although a little slower than I hoped. I’ve resolved the complexity around custom uv replacement and the threadsafe job dispatcher/consumer is working well but importing our assets into the new format, taking the system out of a testbed, integrating it with the game and updating our tools accordingly is still giving me some troubles. With that said I’m making good progress and am aiming to have it fully completed (with the LOD system) by the end of the easter break.
I ran some experiments optimising our animators using some inbuilt Unity functions where Unity will remove your skeleton hierarchy of game objects and instead write the transform matricies (basically the new position, rotation and scale of the bones after animation) directly to the mesh. This reduces a lot of load on the CPU around transform management and skin deformation (calculating how the bones move each vertex on the mesh). This system isn’t designed to handle runtime mesh generation (like our new mesh combiner) and its internal workings are hidden so my first experiments didn’t go so well but they did produce some pretty frightening characters.
Luckily I got this under control and was able to optimise our baked meshes in a test environment and the results look promising. The shot below is from the profiler running 100 animated players, after optimization around 3ms is saved on the animator updates (the purple part, saved from transform management) and another 3ms is saved from mesh skinning (the green part).
So after sorting out my workflow for sculpting and baking for Hurtworld last week, this week was spent going over a few different levels of texture detail before landing on one that looked good in game, the hard part is adding enough detail to define a material without adding to much causing the normal map to become noisy and distracting in game. After a day and a half of trial and error getting the vest in game and on the player it read well and looked decent with the basic textures. Today I got used to setting up my textures for RGB masking and had to beat out a few texturing habits I still have from working on mobile games. Due to needing 4 colour channels but only having 3 we used one of the colour channels at 50% of itself throughout the camo patterns, as most camo consists of 2 values of the same colour, which worked out really well and makes choosing good looking colour schemes a bit easier. These were some of the basic colour schemes I made using a toned down version of our colour masking shader. A lot of potential for good looking unique colour schemes.
I also spent a day capping items of clothing (the caps are in red) so that when they are rendered for icons or dropped in the world you can’t see massive holes in them that would appear see through due to 1 sided faces. Ignore the red you can see clipping through the clothing, that’s just Maya view port errors.
Hey folks! This week I’ve mostly been fixing bugs in the new item rendering and world item system, as well as playing a bit more with it and seeing what it can do. I implemented a pretty cool icon effects system, which is a nice little system for blitting a rendertexture through arbitrary amounts of image effects. With this, we can add glows, drop-shadows, backgrounds, foregrounds, pretty much whatever we want! I’m still working out the best way to handle animated effects without bringing FPS to a halt. More on this soon!
So one issue we found with the icon rendering was trouble blending a texture into an arbitrary background. We found that the camera background would bleed into the image when we let it sample bilinearly. This created a “halo” around the render of the background color, even at native resolution – you can see this below where we’ve changed the background color to magenta to make it more obvious. We spent a bit of time figuring out a good solution to this issue. We figured out that the only real way we could prevent the background color from bleeding in was to sample the rendertexture in point mode, which means we don’t blend between pixel data. However, this also means that we get some pretty bad aliasing on the icon, especially around the edges. So we pretty much wrote a custom downsample shader that does what a normal bilinear sample does, but is smart enough to premultiply alpha so we don’t get any background bleed. Check it out below:
As well as fixing a bunch of bugs, I played around with how blueprints could appear in the world. You can see here a prototype where hovering over a blueprint shows a “hologram” of the item you craft with it.
Hurtworld Update #75
03 04, 2017
I finished another barrel guard this week, it’s quite a techy looking little number. It was a bit more difficult to get the normal maps on it right, but I got there in the end. I was going to push forward on the rest of the 2nd set of components but due to the need for LOD’s (Level of Detail) meshes I switched over to that. Tom is updating the Static Mesh Baker again, to be more efficient and more artist friendly (thanks Tom) We need LOD’s for that and possibly the inventory system, so I am smashing through them early this week. The Static Mesh Baking tools will be not only appreciated by me, but by anyone wishing to Mod Hurtworld. They have come so far in a short space of time, making it soooooo much easier to create static meshes for the game. Static Meshes are used a lot, and the improved tool set is a big time saver and brain melt saver also.
The top LOD will be what the First Person sees, the second one down will be used for situations like inventory, world items, medium distance versions of the guns equipped to the player and any other situation where the highest LOD just wouldn’t be the focal point. The bottom version would be for when the object is fairly distant, for example 50 metres away and further. These only need to convey the silhouette and colour of the object.
Hey folks, this week I’ve been bug-fixing and stress testing the new item visualisation stuff. I improved caching a lot, and added support for complex items like guns built from multiple sub-components, vehicle parts, machines, and more. Realtime icons now support custom colors, and the way I ended up caching them means that cool things happen like if two different guns have the same components and colors, the icon rendering system will have them share a texture and world-item data. I cleaned up responsibilities and structure a bit so now items don’t actually know anything about the concepts of icons and world-items, that’s all completely component based now.
I also stress tested the world item generation and I’m pretty happy with where that’s at. The biggest bottlenecks are now in the mesh baking system, which Tom is in the process of moving to a different thread. When that is done, even spawning hundreds of world items in a single frame shouldn’t cause that much of a stutter. I had to change how items are synchronised between the server and client, as we didn’t have a concept before of non-equipped items that needed to be synced to all local players – important so when a player drops an item that none of the other players around them know about, the server knows to tell the surrounding players everything they need to know to render it. You can see some screenshots below of me spamming spawns and ending up with a landscape littered with various objects – and it all performed pretty well!
Next up is figuring out some changes to the inventory and hotbar, that we’ve briefly discussed in past dev blogs. We’re going to take a look at multi-slot items, which will mean that there’s plenty of room to render pretty icons, as well as changing up the hotbar to maybe be more of a shortcuts bar than an actual storage space.
This week I’ve been working on improving the new spawning system as well as our mesh combining / baking tools.
The spawn window has been redesigned as more of a game over screen for the survival game mode. After dying and watching your ragdoll fall down the game over screen will show, displaying your cause of death as well as the options available to you. The cool thing about these options is that some or all of them can be set dynamically on the server with the option to set a time the option becomes available (to implement things like spawn cooldowns). Just for testing I changed up our spawn behaviour so spawn options were given to spawn at any authorized stake (very unlikely that this will ever make it to live though as it incentivises suicide for travelling and also helps players not be in the world therefore avoiding fights) but ultimately it’s up to the type of game mode to implement its potential options and because it’s defined from the server, oxide mods will be able to add their own options in.
I’ve been giving our whole mesh tools pipeline a bit of an overhaul. The mesh attachment class that holds all the mesh data (things like vertices, normals, uvs, triangles, bone weights, etc.) no longer needs to be managed by the content author, instead they manage a configuration asset that references all the data needed to create mesh attachments. The mesh attachments themselves won’t get built until building the mod (in ItemV2 ALL our content is implemented through default mods) or they can be built just in time if they are required by the editor (ie. for previewing the item). This gives us a few benefits, the workflow is much simpler for one, once the configuration file is setup the artist can make changes to the source file in their tool of choice and have the item automatically update in game after rebuilding the mod. Another advantage is that we store all the material variables without assigning a material (although a material override can be specified if not using our generic custom color shader) allowing us to defer material creation and assignment until later. This will let us do things like atlas a few items together so they share the same material (saving on draw calls).
I’ve also been working on making the mesh combiner / baker do most of its work on a separate thread. This gives us a huge performance gain as Unity no longer has to wait for a bake operation to complete before it can move on and render a frame. Now the main thread queues up the bake jobs while the worker thread takes jobs out of the queue, combines the group of mesh attachments then runs a callback on the main thread again to push the combined data into Unity’s mesh class (this is done because Unity’s API is not threadsafe, anything that inherits from UnityEngine.Object can only be touched in the main thread).
I’ve got a basic version of this working now but I need to extend it to handle some of our special use cases (like assigning new custom UVs for color lookup in the event the assigned texture space is taken by another item) so I’ll be doing that through the coming week as well as extending the vehicle LOD system so it affects all combined meshes.
Hey people, this week has been spent finishing off assets on the vest and getting it to a game ready state. I’ve had to spend a lot of time refining my workflow since my first day here which has slowed down my work output a bit but it’s definitely been for the better. I’ve been building my models/sculpts up from a much cleaner state than before which means very little to no time spent trying to massage out lumps and bumps that are going to show up on the normal map, this allows for a much more readable final model that Unity won’t have a problem with. As you can see in the vest below, the surfaces have very little in the ways of lumpy detail while still having enough information to suggest different types of materials, this can be a difficult balancing act to get used to. The texture used for this picture is a plastic/rubber test material just to see how nicely the high res sculpt baked down, as you can see by the wire frame to the right, the mesh has a pretty low triangle count (around 3700) but can still go a fair amount lower without losing the over all silhouette. The pouches can also be used on other vests and have their UV maps layed out in such a way they can be scaled up to take up a single texture sheet of their own or scaled down and fit nicely into other clothing UV maps without changing any actual UV islands. The process after this step will most likely be working out a good looking colour scheme (possibly changing the pouch arrangement) and getting it set up in Unity to test in game.
Hey guys, this week I’ve been working more on filling our new systems with content. I made a pretty big breakthrough with connecting different semi detached systems together via a thing I call reference curves. The problem they are designed to solve is, as the depth and breadth of our progression grows, configuring simple things like item recipes, damage of weapons, armor resistances etc creates a level of configuration paralysis where there really isn’t a way to keep all the required information in my head at once to get something close to balanced in a reasonable time.
An example is PVE weapon damage. As you progress through difficulty tiers on the map, the health pool of the creatures you will face increase along with their damage, and other properties. To keep things interesting, we increase most stats at an exponential rate.
The reason linear increases are shitty for RPG progressions, is this: At level 1 you start with a bow that does 1 damage, all good. Then you level up to 2 and get a new bow that does 2 damage! You can now kill the same creatures twice as fast with double the damage of your previous weapon, you are pleased. Fast forward to level 75, your bow does 75 damage. You level up to 76 and get a new bow… your bow does 76 damage 🙁 a whopping increase of just over 1.3% which will have almost zero impact on your ability to kill stuff.
Just a quick disclaimer on the word “Level”. It’s not a level in the classic sense of the word, we’re not introducing experience or anything like that, it just helps us compare things that we expect to be at a similar level of balance.
By using an exponential progression, our numbers increase faster as we get higher level keeping the feeling of the upgrade well into the levels. The tricky part about this is we have hundreds of pieces of configuration to create that all depend on this curve. When authoring a weapon for a specific part of the progression, we need to ensure that its stats match up around what everything else will be around that level. Eg: a weapon’s dps value needs to be in the same order of magnitude as the health pool of the thing you are attacking.
The real questions I am asking myself while designing much of the content is things like:
“What damage should this bow do to kill a creature in 4 hits at its equivalent level”
“How much wood could a player around level blah farm in 20 mins”
“What sort of temperature would I expect to have to deal with at level blah”
Having to continually figure out exact values for these questions for specific parts of the progression was mega tedious. My solution was to in a way store the exact question above.
This is where ReferenceCurves come in, they are an asset object that can be defined in our project (or mod), that represents a value as it progresses through the levels. Then when designing content, instead of saying this bow does 10 damage, or designing a damage curve per level on the bow item, only to have to do it again on the next item, we can defer to the reference curve for the answer to common questions.
A concrete example is a reference curve that represents “Creature health per level”. When mapping the PVE damage of a bow, I can now say “get the value from this curve and multiply by 0.2” which will set the bow to kill a creature of equal level in 5 hits. Obviously this isn’t going to be exact as creatures have different health pools, this is fine as long as we are in the right ball park.
This then lets us tweak the base health curve of creatures per level and equipment that is dependent on it will update automatically. However this sounds pretty boring, if everything is perfectly balanced always it will feel like Oblivion.
We can go one step further and slightly decouple player to creature DPS and creature health pools by creating a player to creature DPS curve that references creature health and can be manipulated relative to the creature health.
Configuring a weapon now looks like this:
Then when creating the recipe for the blueprint for this item, I can instead of hard configuring “10 wood, 15 metal” etc, I can configure “0.2 x wood farm per hour”, “0.5 metal farm per hour”
We can now write new content without thinking about stats or value ranges at all. If there is something we don’t know yet, we can create a curve for it, refer to it and figure out the formula for it later. This creates infinitely faster generation of content. These curves will also not only be referable from mods so you can slip content into our pre-existing progression with ease, you can also override any reference curve formula to tweak the balance of your server. Want creatures to do more damage? Change one curve. Think the crafting cost of blueprints is too high for wood? Change the “Expected wood farm per hour” curve. The most important thing here is that this allows us to not lock in a heap of work into a specific set of numbers. By deferring the balancing to very simple config files, we can easily tune our progressions in the likely case that what we initially come up with is shit.