Spencer

This week I’ve been working towards an ItemV2 deathmatch build so we can iterate over the updated gunplay changes. And reparing systems broken in the mass content migration to the SDK. I’ve also been working on designing how our item progression will work in the upcoming months.

Experimental Weapon Changes

Something we’ve been toying with the idea of for a while, is splitting our gear into 2 streams so we can better isolate PVP and PVE balance. We want PVE progression to have uncapped depth while putting a low damage ceiling on PVP weapons / armor. This is so we don’t end up feeling like an MMO where a player with far better gear/level has no danger of being killed by a lesser geared player. We have already setup our gear in this way currently by making most projectile weapons ineffective against creatures, and removing any PVP protection for any gear.

This works to a point, but is a bit confusing when it comes to the strength of an item. Why does my assault rifle feel like a pea shooter against a yeti, yet a bow and arrow does heaps of damage?

What we are going to try in the upcoming patch, is having 2 different types of gear, easily distinguishable from each other, where one has no effect on PVP and one has no effect on PVE. If you shoot a bor with a PVP weapon, it will do nothing. We are going to explain this with the age old video game trope of “just because”.

The current working idea is the PVE weapons / gear with be made up of salvaged technology, that looks a little more scifi, while PVP gear will be more realistic existing weapons.

Our next step with the PVE weapons, is to try a massively deep stat progression on what can be crafted as you move through the world. Think Diablo style, you start doing 5-10 damage and end up doing 1 million+ damage.

On the gear side, we will have separate item slots for PVP and PVE gear, focusing on keeping your external appearance fairly tied to your PVP gear so potential victims can get a good idea of who is coming to kill them.

This will let us easily gate areas with gear checks, making creating new deep content not a balancing nightmare for us. For those not familiar with game mechanic speak, a gear check is where an encounter in a video game is designed to be unbeatable without powerful enough gear. An example of this is enrage timers in WoW, where if your DPS isn’t high enough to kill a raid boss in under X seconds, their damage increases massively making it impossible to win.

That said, there is no place for grind based gear checks in a game like Hurtworld. I will initially be using the gear checks as a geographical restriction like we do currently. Without a winter jacket or a movable campfire, heading to the snow is very hard (atleast the first time you try it).

There will still be scenarios where you need sufficient damage to survive a creature encounter, but I will try to ensure that there is still a 50%/50% split between gear and skill on something needed to progress.

This might all suck, but once we are out of ItemV2 hell, we will be iterating much faster.

Mils has some concepts for the PVE weapons below.

Mils

These 3 new weapon designs are for a new category of weapons. To fit with the idea of procedural generated weapon components, I’ve been trying to design these weapons with modularity in mind. As you can see in the first image, the design is broken up into separate areas that do not overlap. This will be our guide to achieving vastly different visual combinations that all fit together for each weapon chassis. This is very similar to the way that the body kits fit onto the vehicles.

Each component will have randomly generated statistical benefits. Our goal here is to make the weapons more interesting and to avoid what we like to call ‘Ronald McDonald Syndrome’ or RMS. By RMS I refer to the way all players nearing end game all end up wearing the same red winter jacket and yellow Chem-suit pants and generally looking like they would like to sell you bulk amounts of burgers a.s.a.p.

This was caused by one set, coloured item, being the most beneficial item above all others for it’s category (ie Red Winter Jacket). To avoid this we will be mixing random stats with paintable, customisable components.

Gavku

So I wrapped up the textures/material for the Bomber Jacket, as well as test skinning it and tweaking it to make sure it sat well over some of the other gear.

Next up for me is a Combat style jacket. Something that has a bit more going on than some of the previous gear, with pouches, strapps, buckles etc to help break it up and differentiate it from the other jacketets. I built the base of the jacket in Marvelous Designer and marked on it where I wanted attachments to sit.

I then built pouches and clips in max and have been combining them all in Mudbox to get the sculpt for the high poly.

Cow_Trix

This week I finished up with entity stats for now, and got back into the map. The last thing that needed to be done on stats was binary effects, which are still a little strange in where the responsibilities for doing stuff are, but should be working fine now, and be moddable.

With map stuff, now that the MapMagic tools and extensions have matured, I’ve been looking back at city stuff and getting all that integrated.

The CBD of the city is pretty much done, which you’ve all seen loads of screenshots of. However, it still needs to be integrated into a surrounding map, which means linking up the designed grid roads that Mils put together with my road tool. This lead into some improvements to the road tool which have been a long time coming.

The first improvement was with intersections, which are much more intuitive to place and move. You can see an example below. A future improvement which I’d like to put in sometime is intersections knowing how to look when only some of the nodes are linked up – so if only two intersections are hooked up, the curb will change to reflect that. Intersections also have to change the terrain height below them, which is still a work in progress.

Another significant improvement is mesh tiling along a road. Previously a mesh would just be stretched out along a spline, which didn’t really work when the the nodes weren’t a uniform distance. Now a mesh will be tiled, which also solves for the most part the UVs. Also, the road terrain integration can now handle roads banking, whereas before it required that they be flat. I basically just had to add the tangent to the height that was already calculated.

Finally, I added support for scattering objects to the side of roads. This includes things like streetlights, bus stops, post boxes, and more. This week will be more map stuff, and working towards a playable build.

Spencer

This week has been getting everything up and running again after migrating everything to the SDK in preparation for ItemV2. We now have the game running with every piece of Hurtworld content loading from the SDK. We should soon be able to start throwing out ItemV2 experimental builds to a new steam branch. Initially in a very broken state, we are keen to get you guys in on the process as soon as possible.

Kanga release

We will be releasing an update with the Kanga included on Monday the 3rd. This will include a wipe of all official servers. At this point the wipe is optional and shouldn’t cause issues on community servers should they want to keep their savegame.

Mils

So the Kanga is now finished on my end. The pics below show some of the colour variation on the 5 Skins. I also designed the icon sets for the body kits, skins, wheels, engine and gearbox. This came out great and fits well with the other vehicles.

This brings me to my new shiny project, GUNS! This is something that I think a lot of kids have enjoyed drawing over the years including me (the big kid). I have been tasked with coming up with some new weapons. These guns will have to take into account the many attachments they will have while fitting into a few set character animations. It is very important that the detail be focused on areas that the player will see the most. The sight area, the left side of the gun and the silhouette when viewed from both third and first person must be interesting. I am designing the gun body first. From here I will design add on parts much like the vehicle system has a core chassis and then components can be added on or switched out. This should make for some very different looking guns, and I am already scheming up some beauties. 😀

Gavku

OK so I am back from a couple of weeks off and straight on to more character gear! Initially I was exploring how to try and do hard surfaced armour type pieces in Marvelous Designer, but was unable to find any workflow that ended with a result I was happy with. So next item up was to be a bomber jacket, which will hopefully read quite different from some of the other clothing pieces. After this I will be moving on to some jackets with more of a combat feel. Adding a bunch of  attachments like pouches and straps to try and break up the shape and give t shape and style that reads nicely.

Sketch over a Marvelous Designer base.

In game Bomber Jacket mesh.

Bomber Jacket sculpt.

Initial textures in unity.

Cow_Trix

It’s been a busy week, fixing up a lot of broken parts of the game as well as continuing with getting a macro outline of the map going.

Entity stats are coming together now in an ItemV2 architecture. We’ve got the basic stats working again, with effects, modifiers, all the good stuff. Players can get hungry, cold, hot, and take damage again. Now I’m looking at binary effects – things like hyperthermia, or irradiation, or broken legs. As with the old stat effects like health, binary effects were defined in scripts rather than as moddable objects. Now this has changed, and binary effects are coming across to a completely moddable, extensible way of doing things. There’s still a few places where responsibilities aren’t really clear, and the entity stats system will need a bit of a restructure later on I think to make the structure of it a bit neater and clearer, we are one more significant step closer to getting back to baseline with the ItemV2 branch.

I definitely want to do more with stats and binary effects with the ItemV2 redesign. We haven’t really pushed the limits at all of what this system can do. Items that give you temporary buffs, debuff weapons, potion-like items, diseases – all very cool things that we are wanting to play around with and try out!

The map tools have definitely matured. I’ve been playing around with workflows to mash the different terrain biomes together. Check out the screenshot above! This won’t be the layout of the map, but it’s a proof of concept for the tools. We can easily change the shape and location of these zones just by altering a single mask texture and regenerating. Hopefully this will make it both trivial for mod makers to make their own maps, and super fast and easy for us to iterate over map layouts and designs.

Tom

This week I’ve been working on the release candidate for the Kanga patch and we’re super close!
I managed to get through a few builds this week and the other guys have been helping me give them a good thrashing. After each test I end up with a list of bugs and change requests to work on and round and round we go until we are all happy.

Right now I think I’ve finally gotten rid of all the regression bugs we could find (although our players will no doubt find a few more) and what we’ve got left to do is some fine tuning (tweaking things like spawn rates, handling stats, crash parameters etc.) as well as getting the final crash animations sorted.
Speaking of balance, the Kanga fits into the vehicle line up as the fastest vehicle and also the most agile (it’s a complete mountain goat) but it won’t be the best outright for everything.
It can’t take any passengers so the Roach is a better choice when travelling with mates. The Kanga also leaves you very exposed making you a much easier target in pvp situations. Speaking of pvp, we imagine the Roach will still be the ‘weapon’ of choice here for the above reason plus the bigger hitbox makes it a lot easier to run your enemies down.
You also run the risk of crashing while on the Kanga which can give your opponents the window they need to easily kill you or even just quickly pinch your bike.

The Roach also comes with storage slots whereas the Kanga only gets storage through the Raider rear panel.
The Goat is now essentially an easier to obtain cross between the Kanga and Roach. It isn’t as volatile as the Kanga as it’s much harder to crash but at the same time it’s still an exposed riding position and it’s also slower than the other two vehicles although it is lighter, smaller and more agile than the Roach.

We’ve still got some tweaking and testing to do and still need to put the latest build through its paces but I’m hopeful of getting it signed off on this week.

Mils

I have designed 5 new graphics for the fairings of the Kanga this week. They are all pretty varied and should be fun to customise. It is difficult to come up with different ideas that look significantly different and also look good on the bike at the same time. I designed 8-10 variations and they were all reasonable ideas, some just didn’t lend well to being placed on a bike. Only these 5 made the final cut. They are only skinned on the ‘Crow’ body kit currently.

I’ll proceed to enhance these a little more next week and get them onto the other body kits. After that the Kanga is ready to be passed to Tom to finish off his end of things on it too. This has come out nicely and after testing the actual ride that Tom has put together so well, this thing is going to be a favourite I think.

Tom

This week I’ve been working on getting the Kanga ready for release. We’ve now got all the kanga items up and running including all the variants and paint masks (although these still need to be applied to the Raider and Earwig variants), Diemensland has been updated with Kanga spawners and the loot tables have been updated to include the new Kanga items.

One of the hardest parts of developing the Kanga has been making the crash system safe so it never places you inside rocks or other peoples bases. After a lot of iteration we’ve settled on attaching an invisible capsule to the vehicle via a joint that can be broken by force, if broken then a crash is triggered. This allows you to bump into and drag across rocks and walls at slow speeds without crashing which is a whole lot less frustrating plus it doubles as excellent validation for the crash vehicle spawn location as we can replace the capsule with the crash vehicle. As well as watching for the joint to break we also check for any large changes in velocity over a small period of time and also test the pitch of the bike relative to the angle of the ground (if we just tested the pitch of the bike against the ‘up’ direction of the world then crashes would be thrown when riding upside down through a loop). Unfortunately early in the week I encountered a bug where If I crashed and the bike landed perfectly upside down I could then re-enter the bike which would instantly cause a crash and the crash vehicle would spawn in the rider position which would be under the ground at that instant meaning you could use this to glitch into rocks.
To fix this up I created a new type of vehicle entry that does some physics checks to make sure the rider has room to enter the vehicle, if this check fails the vehicle gets briefly put into a lift mode where it will try and turn itself upright, giving room to enter.

As well as this fix I’ve also discovered a reliable way to check if a point is inside a collider or not which I’ve added to the ownership stake validation, this should finally put an end to invulnerable rock bases even if players manage to glitch themselves into the rocks.
After reviewing the destruction changes we decided they still have a ways to go as we need to develop good ways to give feedback on the health of the vehicle and its attachments plus feedback on your actions to damage/repair them. In the interest of getting the Kanga update out sooner and not having to redo a lot of work as our whole item system gets overhauled we’ve decided to push the vehicle destruction changes back to itemv2.
I’ve put together our work in progress changelist so you can get an idea of what will be in the update

• Kanga added.
• Crash system added
• Bail crashes (crashing from exiting a high speed vehicle) added to all vehicles
• Goat has had orientation crashes and rider capsule crashes and velocity delta crashes added.
• Goat cannot be entered unless room for the rider is clear
• Player weight is now added to vehicles on entry and more vehicle handling attributes are affected by weight.
• Camera fixed so orientation is maintained on vehicle enter and exit
• Ownership stakes can no longer be placed inside of rocks or other geometry.
• Vehicle brake lights now brighten when braking
• DynamicLOD system added for vehicles, LOD budget and High LOD bias can be set in the graphics options menu.
• Vehicle scales fixed, removes physics rebaking step on spawn which will help considerably when loading many vehicles at once.
• Goat texture resolution increased to match Roach.
• The small 2m square foundation construction piece has had its volume scale corrected, making it take the correct amount of damage (was previously taking too much damage because volume scale was too small)
• Fixed bug where the player’s position in the physics system was not being updated whilst in a vehicle.
• Vehicle wheels now spin correctly in the air maintaining take-off RPM
• Vehicle reversing is now much slower than accelerating forward.
• Vehicle steering assist is now a twisting force rather than a pushing force
• Using the reverse key to slow a vehicle down will no longer reverse its steering direction.
• SDK update with all kanga and crash components added.

Cow_Trix

Not a tonne of pretty pictures from me this week. I’ve been putting the pieces back together after our significant project restructure, and the rabbit hole has taken me into bringing entity stats into ItemV2. The project restructure has felt a little like an open heart surgery. We’ve made the big cuts, and moved around the internal organs we needed to (note – do not do real surgery like this). Now we’re just stitching up everything and getting the heart beating again.

As I mentioned last week, I’ve been taking a look at the Biome and environmental effects system. As is the pattern, this has evolved into a refactor of a base underlying system, the entity stat system. We’ve talked about this a lot before, but as a refresher, this is the system that handles the interactions between all the different stats in the game, like health, nutrition, damage, speed, and more. It’s an incredibly complex system, that does a million different things. One of the fundamental parts of the system is the process of building an entity stats object, like for a player, which contains all stats that entity uses. We need to specify somewhere what all these data and relationships are. Previously, we did this in code, which was easy but not extensible. It wasn’t a thing that could be modded easily, or at all really. So I’ve been porting the entity stats building code over to a format that can be defined in the SDK. The challenge in this has been the huge complexity possible with entity stats, but it’s mostly been moving things around rather than having to come up with entirely new logic.

The map is also coming along. I now have the tools in place to start actually making macro builds of the map, which is a big step. Builds are on the horizon – when things aren’t so broken.

Spencer

Continuing on from last week, I’ve been putting the structures in place so that our asset database can import and export asset manifests as needed. One requirement of this, is that we migrate all our content assets into the map SDK project so we have a clean separation of core logic and configuration. To make this possible, I had to migrate over 1000 code files stripping them of their dependencies on the core project.

Doing this manually would have taken me weeks… instead I utilized the AOT code generation framework I wrote a few weeks back and used it to dynamically rewrite almost all of our code in a form that can be used by the SDK. Long story short, this mostly involves reflectively finding all fields that Unity can serialize on an object, and emitting C# code so that the SDK can construct objects our main project can read, without all of the run time functionality included. We then mark all editor time scripts that need to be fully included and manually flag pieces of code not to be included using compile time #ifdefs.

This means we no longer need to doubly manage 2 code bases, and removes any overhead created by our expanding sdk.

As Cow_Trix described, we are now getting the heart beating again after the enormous restructure. Just to be clear, Cow_Trix and I are working in a different branch to the motorbike progress. The motorbike will be released before the work we are doing towards ItemV2.