Spencer

Hey yall, this week I’ve been exploring ways to utilize some of the cool shit we’ve been building over the last year now that we’re back to expensive permanent items again. The theme of the week is making your items unique. This includes aesthetic and stat upgrades to get to a point where each core item in your gear set is different from most others in the game.

I started the week with putting the finishing touches on the runtime Item modifier framework that is a major part of ItemV2, this allows us to do things like change any of the components or data stored on an item at runtime based on some event (like say a modifier gem applying +5% attack speed to a pickaxe), and have it serialized properly to the people who need to know and write into the savegame correctly and efficiently.

I will be phasing these in slowly as not to break the balance we’ve gotten back to being close to legacy. The first one will be an incremental attack speed increase buff that can be stacked on melee weapons / tools. This will be a rare drop from creatures at this point. I still need to figure out the logistics of capping this somehow, I guess for one build I’ll allow stupidly fast attack speed melee weapons after many upgrades.

Item Naming

The second use case I will be introducing is the ability to name your items after you craft them. This will be done via a scroll item that can be found in the world, that can be applied to a single item once. Once an item is named, it cannot be changed again. Meaning that pimped out bow you spend a long time perfecting that was stolen during a base raid, will retain its name for the new owner, and if you get it back you will know its yours. You can also link the item in chat and taunt your victims. This is all working and will be in the next patch.

Town Events

I’ve also been working on the new town world event system this week. This system will randomly choose a town in the map (there will be heaps more than diemensland, some big some small), and initiate a pre planned event in that location that will incoorperate the design of the town or landmark. These events will mostly be competitive PVP / PVE scenarios that require you to hold an area, or clear a bunch of mobs to reach some win condition. On completion the event will drop some valuable loot to the winner. Events will be marked on the map ahead of time, which should give players enough time to travel to the location and compete for the spoils. This is the next step in our efforts to get people out in the world and away from the security blanket of their base. If you are far from home, you are risking more, its more of a natural encounter in the world than naked guy with spear runs around fortress over and over with no real reason to enter into battle with people who are there, therefore doesn’t care about protecting themselves unless they found something good which happens rarely. This is also to stop the core game loop of checking empty containers for loot over and over again, this is mega boring. The event system will basically guarantee that if you succeed you will get something of value and draws people together from far parts of the map causing conflict for a good reason. The events will be designed to create interesting combat scenarios that require skill and prep to take down. Splat has been designing the first prototype see below.

I will likely tune the frequency that there is always an event going somewhere on the map. If you want to run events and get into fights, you can do this continuously. This peppered with airdrops, meteor showers and dynamic hostile weather I think will bring the map to life in a way we haven’t seen before. I’m really happy with how meteor showers and air drops are feeling in the current build. It obviously needs some tuning, but I’m really excited about where we are heading 🙂

Next Experimental Wipe

The next experimental wipe will be on Thursday the 22nd of Feb with a fair bit of cool stuff.

Mils Lord of the Dark, Keeper of Weasels

So we played a lot of Hurtworld on the weekend on the public servers, I had so much fun. It’s great that the world is fun to explore again. The balance of things is feeling pretty damn good right now and I haven’t felt bored at any point. I think this is mainly because of the Meteor Drops and Air Drops.

I have been deeply entrenched in the UV mapping for the Mozzy Helicopter. UV mapping complex vehicles takes a bit of time, but some of thew new UV mapping toolkit tools in Maya are really helping speed these tasks up. It seems that Maya has very similar uv tools to a plugin for Maya called ‘Nightshade’ as of the 2018 version. These tools are really getting a lot better. I got the high poly modeled last week, and found a new way to do that stuff a lot faster. JOY! I’ve finished the UV mapping and about to start on the Normal Baking. Wish me luck for it is a dark art. 😛

Below is a sneak peak of the object grouping technique I use to logically group sections of the mesh so that you don’t get baking artifacts. Basically I group these based on whether they are touching or if their bake cages would start to intersect (not touching but still too close together) The grey areas are bits that I don’t need normal baking on. The body kit will be UV mapped and placed onto the 4096 px texture after the chassis is done.

TEHSPLATT

This week was spent learning Cow_Trix’s map tools, there’s a fair bit to learn so I’ve basically had to document my process as I go. Earlier In the week I when I was still going over some Map Magic stuff I made a more detailed forest biome just to push a bit further than our normal biomes. It was a fun test and although it was pretty unusable for the actual game it gave some good insight into the use of much taller trees and detail meshes for grass instead of billboards. I also did some concepts for a re-do of the higher tier resource nodes. At the moment they seem a bit sad in comparison to the earlier resource nodes.

Last night I went a bit crazy after drawing a map idea for these new town events. I play a lot of FPS games and knew I couldn’t just jam a bunch of stuff together and hope for the best, especially with these town events being a battle for what I imagine will be some pretty good loot. The event zone had to be a fair battleground that gives all players a chance to win if they use good strategy. The insane web of red lines are all the different lines of sight from different vantage points. The challenge is making sure that no one spot is over powered, this means that if you have a good view from one point then you will most likely be vulnerable to your blind side and if you are completely safe in a little camping spot then you shouldn’t have a long or valuable line of sight. I made sure to grey box the level before hand to get figure out all this sort of stuff before building it out of assets. In the future the levels will be tested in a proper death match environment in their grey box state before building them out of assets but as I was already pretty deep into this one I wanted it to look good for testing (great decisions generally aren’t made at 2am).

Cow_Trix

Hiya folks! This week I’ve just been continuing to polish up Mangatang, and fixing some bugs with the current patch. I’ve been trying to speed things up a bit in terms of the terrain workflow. One of the big issues has been the file size of the terrain layers, so I’ve been putting in some data compression. That’s worked really well and reduced the filesize of these layers substantially. I also wanted to take a look at the road parallax issues (i.e. the road appearing to float above the terrain). This is a bit of a tricky one, and I am still working through possible solutions. The most promising one so far has been a two-pronged approach. First, we drop the vertexes based on distance to the camera, which reduced close parallax while keeping the road from clipping through the terrain at a distance, when the terrain begins to lose resolution. Secondly, I fixed the render queue for the shader so that it write to the depth buffer immediately after the terrain, which means other geometry will correctly depth test against it. Check out the results below:

I also fixed a few bugs here and there. It turned out that an exploding raid drill could actually take out a door, due to the way we’d set up the door armor. This wasn’t intended, and was actually a general problem with how we were applying damage to structural machines like doors, pillboxes, that kind of thing. The solution was just splitting explosion damage into two different effects, structural and everything else. I also fixed things like creatures running into shacks and wrecking you, wrote a map based spawner for controlling meteor shower spawns, fixed the options menu resetting all of your options every time you opened it, and tweaked a number of spawns in Mangatang.

So finally, bit of an announcement from me. After almost 4 years working on Hurtworld, I’m going to be heading off as of next week for my next adventure. It’s been an amazing experience bringing this awesome game to you all. If you want to keep in touch, and see what I’m doing, you can follow me at @cow_trix.

Tom

Hey Hurtworldians, this last week I’ve been back in bug fixing mode. In the 0.5.0.0 release we had the mesh attachment building step of our mod build process fail for our base content bundle, without us catching it. This led to a couple of machines having to fallback to the generic crate icon, luckily it wasn’t the art bundle otherwise items, players and vehicles wouldn’t have been visible (although this one would have been easy to notice)!

The mod build step has been our bottleneck for content creation and iteration speeds so I’d been doing everything I could to speed this process up. As part of this I took a lot of the asset modification out of the Unity editor and changed it so we edited the text serialization directly, this allowed us to dodge most of the overhead of Unity’s asset database and having to load a lot of assets we didn’t really need to load. Unfortunately this could create some strange race conditions that I was never able to fully eliminate and after much frustration I decided to move the process back inside the editor because consistency is more important than the small speed improvements. Lesson learned: don’t work around Unity unless you really NEED to.

Other than the build process issue I also fixed a problem we had with shader variants not being included in builds. Our uber shader has a few shader features that can be toggled like backface drawing and saturating the custom colors rather than linearly blending them in. Usually Unity knows to include these shader variants in the build because assets that use the variants are also included in the build. Since we have moved over to building all our content out of the SDK this no longer applies to us so instead we force include a few simple materials referencing these variants. This problem was tricky to track down because it didn’t occur in the Unity editor as shaders are compiled on the fly when they are requested (which doesn’t happen in the final build).

I also removed the terrain layer from the construction line of sight checks to make it easier to build walls and other structures partially intersecting terrain and rocks (all the other construction validation still applies).

I also did a pass of our item list removing all our older items that had been broken in updates from our content bundle, this makes the ‘g all’ command safe once again for admins and will hopefully lead to less problems due to plugins accidently creating the wrong items.