Finally making it through the woods of engine upgrades and starting to see some new features creeping into the game. I’ve put the final touches on the new camera system which was one of the last truly ugly systems in the engine.
Now the view can be clamped inside the vehicles and is calculated serverside also, we can do firing from vehicle seats! In reality the driver won’t be able to shoot, but this was easier to record. We still need to implement animations pivoting from the hip while pinned to a seat, but that’s the easy part.
Next we have a new headlook feature, similar to the arma engine allowing you to look around on a limited swivel while running / aiming in specific direction. Useful when crossing a valley in sprint and checking your surroundings. (FPS animator needs some touchups so it doesn’t look weird in side angles, not a big issue though.
Lastly we have the completely unrestricted Roach back seat that allows crouching / standing and 360 degree freedom.
This video also shows the improved third person aiming system, notice the arrow is now accurate regardless of perspective.
Once again, I should be able to get to recoil this week. Those wondering what the ItemV2 ETA is, we are still a couple months off.
Things that need to be implemented before we can go live:
New tooltip system that supports itemv2 state
AI for new creatures
Upgrade loot table system to generate weapon attachments / procedural stats
Cow_trix finish new map
No more fucking around
Now I am through most of the serious upgrades I need to do, I am switching gears into delivery mode. I wanted to take the time necessary to make sure we deliver some really game changing stuff with the upcoming update, however I am starting to see some patterns emerge that I see in other games that never get finished. I always thought that the reason games that have some initial success slow down after the early access launch was due to a lack of motivation / cashgrabery.
I see now how easy it is to get caught up in trying to make everything perfect once the pressure of going bankrupt in the next week is taken off the table. We are still working harder than ever, but we really need to start focusing on pushing this release cycle out the door and stop trying to cram every feature we ever wanted into the game. There is plenty of time for more features, in future releases, I see now we still need to make compromises in the short term if we want to finish anything.
That said, ItemV2 has become more like Hurtworld V2 as almost all elements of the game have been improved… a lot. We can’t wait to get your hands on it, hopefully I can make that not too far away!
This bike is starting to shape up nicely. All the high poly versions of the wheels, fairings and chassis are done now, the next step is to add some damage to these by carving into them. If you look at the image I have added, you can see some damage has been added already. These are the types of damage that affect the silhouette of the model, and so are also present in the low poly mesh. The next step is to UV map the low poly and then bake out the normals maps so that texturing can begin. Vehicles have high polycounts so this takes a bit of time, especially when baking normal maps, as you can never be 100% sure that they will come out right the first time you bake them. This is especially true when it comes to more complex shapes. Any part of geo with an angle over 90 degrees will generally cause a normal baking disaster. Adding in a little more geo in these areas by simply adding a bevel on the offending edge of the low poly mesh will usually fix this, but you must be careful not to start beveling edges everywhere and blow out your poly budget.
This past week I was focusing on nailing the workflow of getting mesh’s skinned in maya, exported, and viewable in Toms new Vis Scene. This involved a little bit of back and forth with Tom, especially in regards to having the player character display as close as it can to what it does in game ( which it now does ). I went through and modified some of the previously made clothes to better fit the new body shape, and they seemed to come across pretty well. We noticed that just lowering the head a little and applying a normal map makes him look a bit more jacked, which we don’t mind.
I also have been updating the fps arm model to bring it line with the other character changes. This involved getting rid of some of the acute sharpness that was in the original model, especially around the forearm/elbow, as well as decreasing the fingernail size and blocky-ness of the hands.
I started the week out working with Gavku bringing the new character model into the itemv2 branch. We found a few bugs that we were able to squash and I added a whole bunch of useability improvements into the model viewer. The viewer now uses the same lighting model as in game and uses the same dynamic skybox so you can adjust time of day and other variables to view the player under all different conditions.
I’ve also added a simple equipment ui that allows you to swap between any gear in your project easily along with selectors to preview any skinned or static mesh in the project without having to create an item and setup the visualization component.
Also this week we spent some time testing out the motorbike build which didn’t go as well as I’d hoped. We found a lot of bugs with how proxy players were trying to sync animation data and also some ease of use concerns where basically the motorbikes were way too easy to crash. To have a place within the metagame of hurtworld they needed to be more reliable otherwise they would just be outclassed by the other vehicles. To this end I’ve adjusted the leaning system so it has special case handling for off-camber corners (corners which are banked opposite to the turning direction), clamped the target lean value and removed crashes being triggered from leaning too far. The handling has also gotten a lot tighter with an increase in the steering assist twisting force plus higher sideways traction for both tires but especially the rear. I’ve also made the bike dampen its yaw velocity when only 1 wheel is grounded to prevent the high traction tires from spinning you out.
I adjusted the collision crash component so it should only be triggered in large head on collisions (like driving flat out into a wall) and also added in an air stabilization system where whenever the bike is airborne it will correct itself into a safe neutral orientation. Because roll in the air was now being controlled by the stabilizer we changed the left/right inputs from roll to yaw (meaning you can now do 360s instead of barrel rolls).
I’ve got a new list of fixes to work on for this week but we’re definitely getting close!
Hey folks. This week I’ve been further iterating on the map work, making a lot of progrees in making a procedural map that retains the Hurtworld feel. A big part of it as well has been figuring out how to conceptualize the map generation in a procedural way, finding the methodology that works.
An interesting problem I had to solve was the generation of the initial hills. Something we settled on when making Diemensland was that for the map to have good occlusion, generally the hills had to be roughly the same height. I initially tried to generate these shapes with a Voronoi noise map, which worked okay, but had the problem where it was difficult to make the hills all the same size without distorting the shape. What I then tried, which worked way better, was a “stamping” technique where I took a single hill of the shape that I wanted, and then stamped it all over the map in the same kind of pattern of valleys separated by ridges. This way we could guarantee much more that the slope and heights of these hills would be consistent.
What I’m going to focus on next is generating the macro layout of the map. I’ve got my head around generating the micro, but I’d like to be able to feed in something like the diagram I showed 2 weeks ago of the general layout of the map, and get something out that resembles that layout. That’s going to be an interesting challenge, the biggest problem being I think having this information laid out in a way that works logically and is maintainable. The whole mask workflow that we used previously for Diemensland has some maintainability issues where a change to one mask causes a cascade of changes to every mask it touches. I’m thinking of basing it directly of biomes, and seeing if that can work.
I’ve also been experimenting with placing hotspots and structures in the map, which we could make as little areas to explore and loot. I’ll be looking into a similar system to put in natural artifacts – for instance, things like the stone arch in Diemensland – but I can see that being a bit more involved.