Spencer

Hi Guys, this week I’ve been continuing work on the Town Event System. To enable us to test each town event quickly without needing a fully spun up level and full server, I spent some time fixing up our deathmatch game mode and extended it to allow us to load a single town and continuously run the town event like a call of duty server. Once the event finishes, everyone respawns and the event starts again. Earlier in the week we spent some time doing a 3 team, deathmatch in the event Splatt designed without the custom event logic and it is playing really well. I will release these mini maps with town event test game mode to the workshop as we build them so anyone can start a server and give them a run.

Weapon Balance

Our TDM playtesting gave me a good chance to revisit weapon balance. At some point the shotgun became stupidly powerful, this will get a slight nerf in the next patch.

Farewell Cow_Trix

This week our homie Cow_Trix is leaving us to travel the world after giving his absolute all to Hurtworld for the last 4 years. He was the first programmer I ever hired, has surpassed every expectation I had of him. I only hope that he finds happiness in his travels until he gets kidnapped and needs us to pay his ransom, forcing him to return to the team.

Mils

I’ve got the normal baking done on the Mozzy this week. This was a pretty straightforwared task and it all came out fairly easily give or take a couple of mishaps. I’m now doing the Alpha and Normal map detail pass that I do when I feel it’s necessary to add details at this stage. Some Normal map details are best added now because they can more easily be included in the Occlusion Map bake and Curvature Map. The curvature map and the Occlusion map control some aspects of the Smart Materials within 3DCoat and so am going to include these normal details so the Smart Mat’s produce the best results. Some of these shapes are better done in Illustrator too, which I have been using for a long time and can get very precise results with. Things like repeated lines and very specific shapes like those you can see on the back of the pilots chairs are some examples. I also got the cockpit instruments halfway done at this point so I could see what they would look like. These will be dissected a little more and then filled with the correct PBR materials once I start working in 3DCoat. It’s all looking good and how I envisaged it.

Also I would like to say Ciao Bello to CowTrix, who is off the get kidnapped in Bolovia or adjacent countries. Cow was the second hire after me and we’ve been in the trenches for years now. Will miss your face amigo. xx

Cow_Trix

Hiya folks! Not a lot to report from me, as I try to pack everything up in my final week. I’ve been trying to clean up my code base, get the map pipeline as clean and easy as I can in preparation for Luka and others to take over, and generally tie up loose ends. Had a great time playtesting Splatt’s town battle zone on Monday, some really fun stuff there.

This will be about my hundredth dev blog, not counting ones I’ve been on holiday for. It’s been a hell of a journey, so I thought I’d put together a little collage of the highlights.

Tom

Hey Hurtworldians, over the last week I’ve been tracking down a bug where the first item icon rendered wouldn’t receive any custom colors and also looking into allowing creatures to damage vehicles and vise versa.

The way our item icons work is that we render them on demand at runtime, this allows us to ensure the icon is always accurate to the item (ie. shows correct attachments, colors, etc.).

Currently the first icon created doesn’t receive custom colors, this can be tricky to notice as often the first icon won’t have any custom colors or the icon will be for the bottom right alert panel so it is only seen temporarily. It’s also difficult to notice as a single item usually has a few icons for different contexts (ie. inspection window, hotbar, backpack, alert panel) and only one of them would ever be broken.

The issue ended up occuring in our icon renderer initialization step, we have a component that passes the custom colors to the shader after receiving the OnWillRenderObject callback, the problem was this component was using its first OnWillRenderObject call to initialize itself instead meaning that first icon wouldn’t receive its colors and then that incorrect icon would be saved into the icon cache and reused whenever the icon was used in that same context again.

This was hard to track down as I was trying to debug it through the Unity editor which was redrawing frames when paused, triggering another OnWillRenderObject making everything appear normal when trying to inspect the rendering setup after the event has occurred.

Lesson learned to be careful about how Unity editor updates when trying to debug rendering issues.

As well as bug fixing I spent some time digging into our AI system to see how tricky it would be to get creatures to start attacking vehicles and allow vehicles to run over creatures.

Now that vehicles are destructible it feels stranger than in legacy to be safe inside a vehicle around creatures, we also thought we could allow vehicles to run over creatures if we damage the vehicle for every creature hit so it doesn’t become an overpowered farming method.

I got as far as having creatures target, chase and attack vehicles but quickly found out taking it to the next stage of having creatures choose between vehicle/player targets, making sure they only target occupied vehicles and tracking the player as they enter and exit vehicles would require some significant refactoring.

Another concern we had is the time desync between AI and vehicles on the client, basically our AI is deterministic and is predicted on the client, this means the AI positions you see on your client match the server positions at the same time. Vehicles on the other hand are simulated server side only and aren’t being predicted on the client, this means the vehicle positions you see are from an older server time. The desync between the two times means these systems could look strange interacting together and would potentially need some extra work to hide these inconsistencies.

Because of these issues I’ll be moving onto other things for the immediate future but hope to revisit it somewhat soon as we’ll need to work out some solutions to the vehicle time desync problem to allow shooting out of vehicles.

This coming week I’ll be setting up a basic Mozzy skeleton prefab, working on separating vehicles into grounded and air vehicles giving us a basic prototype to start playing around with the controls and flying physics.

TEHSPLATT

Hello, this week we’ve been testing the little town event battle zone I made, although it wasn’t designed for a typical deathmatch style game mode, deathmatch is a great way to test the actual playability of the area and make sure all the different areas of cover work well and the map flows nicely. All in all I think it went well, there were a couple things that I needed to fix up but they were very minor. Now that the map has proven itself in deathmatch we need to come up with a good gamemode/objective for it that ties into the natural feel of the world, this is a lot harder than it seems with all the different variables in Hurtworld like group size, player gear, stuff like that. Now that I’ve got the little battle zone done as a sort of proof of concept I’ve moved back to polishing the main map, so far I’ve put my time into the forest biome and cleaned up the overall scattering of grass and a some patches of trees a long with adding in some new rocks that will be scattered throughout to give good cover and some interest, on top of this I still have to add in the terrain chunks I’ve been working on but this is more of a hand polish thing as trying to place them via MapMagic seems like a nightmare. Part of the polish process is adding in lots of towns and interesting areas specifically for the events, however if we want to make sure the the events are genuinely fun and balanced we need to design and test the areas properly, which is a time consuming process, so I think we might have to have smaller, less important zones that don’t need so much planning and then some larger more thought out areas.