Hurtworld Update #117. Hurtworld кофе
Hurtworld - Multiplayer FPS Sandbox Platform
So I finished the Mozzy chassis last week and it’s looking very tasty. The texturing all came out well and fits our style as usual. I really like the instrument panels in the cockpit. The PBR workflow for vehicles changed a bit beginning with the Slug and has continued onto the Mozzy. I will probably go back and make some changes to the texture style on the previous vehicles at some point to bring them in line. I added a bit of base level dirt to the vehicles in this new style, we previously planned to down the track add dirt via a texture that would increase over time, giving a worn look, which may tie into a degradation system. This stuff is all theoretical right now, so I thought to filth them up I would add some toned down dirt to the base textures. I’m onto the first body kit now and hope to have that finished in the next couple of days, end of week the at the latest.
Hey Hurtworldians, this past week I’ve been refactoring our vehicle code to more sanely support air vehicles and other non-car vehicles.Because of the way Hurtworld has evolved most of the vehicle code assumed a 4 wheel car type vehicle as the standard base with other vehicles like the Kanga or the crash vehicle (an invisible cylindrical vehicle you get placed inside during a crash) being specializations of that base with overridden functions to skip over the car specific stuff (such as setting up anti-roll bars to compress wheels on the same axle).Adding the helicopter gives me a good opportunity to go and clean some of this stuff up, creating a simpler vehicle base class just containing shared functionality like physics overrides, vehicles seats, lights, a sleep system so they don’t hog all the resources when not in use, etc.From the base we diverge into vehicles with almost completely custom handling (like the crash vehicle or the new Mozzy) and another path into the standard, powered, grounded, wheeled type of vehicle.Now we have a nice Mozzy skeleton prefab that can be entered, exited, blown up, parts equipped etc, that we need to write the physics simulation for, really looking forward into playing around with that soon.
Hello, this week I’ve been gathering all the knowledge for the final hand over from Cow_Trix, it’s been tough but I think I have a decent understanding of how the stamping system works and have started building mini towns and some polish stamps. I’ve moved on from those to work on the higher priority. The town events. We’ve set up the first town event map I made (Fight Yard Out Post) with the event system on it, it runs a capture the point game mode where you have to hold a designated area for an amount of time we set. It was pretty fun to play, it works well with people turning up at different times and takes skill to stay on the point. I’ve started working on a new town for the event stuff, this one seems a lot bigger and a lot crazier. It will definitely suit bigger groups of players. It’s currently in a grey box state and I’m playing with different ways to make walls without just sticking walls around the whole thing. Looking forward to playing this one. Hopefully I will have 3 towns ready for the next patch, one of them might still be in it’s grey box form though. You can see some progression between the grey box process and replacing the objects with proper assets.
This week I’ve been working on the world event system and fleshing out the game mode wrapper that runs town events continuously. For the initial release there will be two types of town events available.
Control Point EventThis event will require a single player to hold a control point for a period of time by being the only player in range of the control collider. On Completion the winning player will be rewarded with a loot cache that comes with amber insurance and will not drop on first death. Meaning if you die after winning the event, you will keep your loot (provided you don’t open the cache until you get home)
Loot FrenzyThis event will work fairly similar to legacy towns, except on crack for a short period of time. While active, loot caches will spawn around a town containing valuable loot at high frequency. Controlling the town and accumulating loot for the duration of the event will be very profitable, however the longer yous stay, the more people will show up and try to take what you’ve collected. There isn’t a single winner, escape with whatever loot you can or risk it all.
We are starting with some pretty simple events, we plan on introducing more complex events involving creatures and possibly travelling between multiple towns in future. We will see how these go in rotation to begin with.
We will be putting lots of duplicate towns across mangatang for this build that will allow us to test the town running meta before going deeper on town design. In future we expect them to all be unique.
Respawn RefactorThis week I’ve been working on how we can refactor the mechanics of re-spawning slightly. It’s still a bit too easy to throw up a stake and use it to respawn rapidly without cost. This will become worse once the town event system gets up and running. What we are looking at is decoupling spawning from the stake, and requiring that you drop a bed in an owned cell for each person. The first death will be an instant respawn, after that there will be a longer wait time of around a few mins before you can respawn there again. There will be an option to fill your bed with amber and buy back instantly and skip the cooldown similar to the buyback mechanic in DOTA. This won’t be going into this patch, likely the next one.
Hurtworld - Multiplayer FPS Sandbox Platform
I carried on with the Recurve Bow parts again this week. I have a Rest (which is a slightly bent nail) and an arrow to show you. The nail was pretty easy and looks fine. The arrow ended up looking really satisfying with the flint head material contrasting with the wood and feathers. One set is now completed on this one.
I got into the Riser on the next set also. This one is a piece of square pipe that has been scavenged and hammered and bent to fit the use as a Riser. There’s a leather wrap handle that I wanted to try and find an easier and better way to create. I tried using Maya’s nCloth to simulate the strap wrapping around the bar and making the cloth surface really sticky, so that it would cling to the bar and not fall off. This was interesting to learn a bit about nCloth dynamics, but in the end I decided to drop that method as it was taking too much time. I will say that the basics of cloth simming in Maya using nCloth is really easy. I ended up using a bend deformer and rotating it to get a slight offset. This created the layered wrapped effect fairly well. The UV mapping and normal baking are done on this so I will start the texturing this afternoon.
Heya folks! This week I’ve been working through a number of bugs that you guys have raised. I refactored the chat window a bit, so you can more easily read long messages like server announcements. Previously, if the message exceeded the height of the chat window it was actually impossible to read the whole thing. While I was at it I tried to tweak the text display to make it a bit more readable on both a very dark and very light background. I also added some quick native support for one of the most common features server owners ask for, greeting messages, as well as an indicator of when a message is a server announcement.
I also looked into making claiming vehicles have a bit more functionality. Right now it’s pretty easy to quickly strip a car for parts with vehicle attachments being easily take-on and take-off. This means it’s pretty rough to leave your car anywhere, as in just a few seconds it can be completely destroyed and all the loot you were keeping in it stolen. We already had the concept of enabling and disabling inventories, so I extended that to give the owner of a vehicle the ability to lock and unlock the storage of their car so people can’t take parts on and off, or things out of the boot without you around. That being said, they still can drive the car away and they still can wrench the car and get all of it’s parts, though wrenching a claimed car is a pretty slow job. I’ve been thinking about various upgrades that would be easy to make for vehicles to make them less susceptible to these scenarios, such as kill-switches, trackers, and car alarms, which hopefully we will be able to explore in the future.
Aside from those few little projects, I’ve just been working on various bugs. I fixed some scenarios where your construction raycast went through walls, changed a lot of machines and sound-emitting objects over to the new sound system (which will mean that you won’t get random things making noise even when you’ve got the game volume down), fixed some machines continuing to play sounds after they were destroyed, and fixed a few bad areas in Mangatang. All these fixes and more will hopefully be coming to all very soon!
This week I’ve been continuing trying to create an interesting looking resource node for the meteor strikes. Melting lava ball is where I’m at right now, I created this hollow ball with holes in it, then made an inner sphere with an emissive glow that shines through the holes. I wanted to make it stand out from your basic resource nodes so I tried to add some particles, sort of like smoke leaking out of the holes. Originally the smoke looked very obviously fake against the emissive glow due to it not receiving any lighting from the glow. I used the particle system’s colour over lifetime gradient to fake the lighting of the particles, it now gives the impression that the glow from within the node is lighting up the smoke as it leaks out. I also tried a few different smoke variations the second one below is one of the more ridiculous ones.
I also revisited the Amber world item which is honestly a pretty difficult one when using the standard shader, it’s hard to convey a semi transparent rock that catches the sun in interesting way using only an albedo, spec and gloss. So I saw something worth trying out and in my opinion its the best looking version yet, but, possibly a bit too realistic and also might not stand out on the ground among other earthy colours.
This week I’ve been finishing setting up destructible wheels for vehicles, doing some bug fixes and also improving our tools and mod build process.
As part of implementing destructible wheels I needed a way of binding hitboxes to storage slots, we already had a basic implementation of this going on with the way the players armor works but it was all hard coded bindings which wouldn’t work for vehicles as the different vehicle types have different storage configurations. So with this in mind I’ve moved the hitbox bindings into the StorageConfig asset used to setup inventories. Below is the Roach’s StorageConfig (left) paired with its EntityStatsBuilder (right) which is the other half to setting this up. In the StorageConfig you can see RoachWheelFrontLeft is bound to the Wheel FL hitbox. Over in the stat builder you can see DamageProxy WheelFL also has a HitboxMapping for Wheel FL. I’ve also setup a FluidEffectImpactMultiplier of -1 which adds the original damage value * -1, essentially cancelling all damage to the vehicle. Below the hitbox mappings you can also see the RaiseMitigatedEvent flag is checked, this causes a new event to be raised with data about how much damage was prevented by this stat. Finally either a PlayerStatManager or VehicleStatManager will handle these mitigated events by looking for storage slots with a matching hitbox binding and then pass the mitigated damage onto any item in this slot.
I also managed to get through some bugfixes including fixing an issue that would cause rifles and shotguns to become tiny when aimed down sights from third person mode, fixing seed items recolouring your hats again, fixing an issue that allowed the shotgun to fire without a shell loaded, returning ladder climb speed to legacy values and improving vehicle exit behaviour. Unfortunately due to most of the office getting sick we weren’t ready to deploy these fixes in time for last Friday’s wipe but we hope to get them out to you soon.
I also spent some time improving our VehiclePassenger tools. I was struggling with debugging some vehicle exit problems and decided we needed a clearer visualisation of what was happening as it can get very complicated with exits that are defined in the vehicle’s orientation space (so they rotate with the vehicle) but then can also have an additional cast to ground step, then with the position worked out we need to check the whole player’s volume over the exit rather than just a point and if that passes then we do a final raycast from the seat to the exit, if this passes then the player can exit the vehicle. To make this all easier to see I created a debug view that will draw all exits and their current state. I’ve also changed the vehicle exit list to a reorderable list (as exit order defines priority) and created a custom inspector for copying exits from another seat (while shifting them into the new seats orientation space).
I’ve also been working on speeding up our mod build process so we can iterate quicker, first up I added a proxy check (ie. is the object real or is it a placeholder?) that can be run based off an unique id that is generated for all assets by unity. During pre and post build steps (where things like preparing mesh attachments happens) we can use this check to skip over all the proxy assets without having to load them into memory first (because we use the id instead). I also added another early exit check for when the asset is labeled as ‘dontbuild’, these were being correctly ignored from the build but were still running pre and post build steps for no reason.
I haven’t got much done this week due to being knocked out with the flu. I am still working towards a dynamic geography hotspot build which is playable for the first time today. If by some miracle tomorrows playtest goes really well, I might try to push it out to you guys on Friday. I wouldn’t hold your breath though.
Good news is all the features I wanted to get in for dynamic hot spots are working really well. I added some sound effects to the meteor strikes that came together really well. Looking forward to getting them out in the wild!
Hurtworld - Multiplayer FPS Sandbox Platform
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 NamingThe 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 EventsI’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 WipeThe 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.
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).
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.
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.
Hurtworld - Multiplayer FPS Sandbox Platform
I’ve got the main chassis for the Hell-Yeah Copter ready. This is still not the final chassis as I will now concept paint the outer shell to get a nice design. I’ll then go back and model the low poly outer and look at where my poly count is sitting. I plan for this to be around 15,000 – 20,000 poly’s because it is quite large. Once the outer is done I may have to strip some of the detail out to accommodate the body work. The outer body has preference over the details on the inner chassis as they inner will be covered by the body most of the time. I have made the tail removable so that when the outer is added, all those framework bars aren’t just sitting beneath the outer hogging up my poly budget. Most of the chopper chassis will be mirrored down the centre line to save on texture space also. Although this is based on the Huey Design, I will be making it conform to our other vehicles ‘Hurtworlded’ style. The chassis for example is not like the real thing, it is a scrapped together backyard built frame, that holds a similar shape but isn’t true to real engineering standards. It is a ‘ghetto bird’ as Spencer would say. 🙂
Turns out I managed to get the first body concept out also. So here it is. It’s a scrappy type of body kit which gives a serious nod to the shark teeth type paint jobs that used to be on some of the Huey’s. (the teeth were Cowtrix’ idea, thanks matey)
Heya folks! This week I’ve been working on a new map, and further refining the level creation pipeline. As we’re trying to go back a bit more to legacy structures, the new map will have similar structures to Diemensland. You will have the starting desert in one corner, which branches off in one direction to the forest and snow, and in the other direction to the sand dunes and red desert.
One of the big things with putting together a large map is that it is quite difficult to split the work up into manageable, modular chunks. If multiple people want to work on the same level, there’s not real easy way to do this with everything all living in the one Unity scene. How I wanted to structure things was to have individual capture scenes of each biome, that could then be capture as a WorldStamp and stamped onto the big map as a final composite step. A couple of improvements needed to be made to the system before this could be a viable workflow.
Firstly, I created the concept of stamp templates. This means that you can set up a stamp capture in a scene, and save those settings into a gameobject. This object can then be used to set the capture up again in exactly the same way with the same mask, which makes it trivial to recapture stamps again and again. So, for instance, I could paint out the rough biome shapes in the main map and create stamp templates from that. Then, I could bring the templates in to the individual biome scenes. I could then use this template to both see the area I needed to detail and fill in the stamp, and recapture the stamp in such a way that fit perfectly together in the main map. This workflow has been working great!
Secondly, I needed to think about how roads fit into this workflow. I need a way to embed road networks into a stamp. The solution I came up with was to create a stripped down version of the road network (like we do in the build process) that can then be embedded into the WorldStamp prefab. There were two issues to solve to make this possible. Firstly, we need some way to connect these embedded road networks to their surroundings once they are stamped. To do this, I created a concept of a “stamp exit node”, which is a special type of node that sticks around when the network is stripped down. This means you can mark specific nodes, and they will be able to be connected to once the stamp is in the level. Secondly, I need to figure out a way to embed the generated meshes in the prefab. When you generate a dynamic mesh in Unity, the reference is only valid within the scene that mesh was created in. If you naively create a prefab from an object with a reference to a procedural mesh, that reference won’t stick. I didn’t really want to create a bunch of sub-assets every time a created a prefab from a road network, so I created a quick mesh wrapper object to solve this, that stores a serialized version of the mesh and detects when it needs to create a new copy.
The new map is coming along well, and will hopefully be internally playable by the middle of this week, and playable by all of you soon!
Hello Hurtworldians! This week I’ve been continuing working with vehicles mostly, starting with improvements to vehicle spawning. Vehicles now will receive random wheels on initial spawn rather than the same wheels every time and its relatively smart about which wheels get picked, both front wheels must match and both rear wheels must match as well, also, big ‘Sand Hopper’ style wheels will only ever apply to the rear making sure wheel spawns are always balanced.Our basic customisation features have been rolled out to vehicles as well, vehicles now roll their color and paint mask on initial spawn and all their attachments now inherit their appearance from the base vehicle to match how the weapons operate. Currently like in the example below these colors are completely random but we should have them limited to a few good looking color sets in time for release.In the hopefully not too distant future we are really keen to open up the customisation to player choice but that still requires design and UI work and for right now our priority is to get back to a stable experimental release.
Also in vehicles I’ve been implementing a camera perspective cache. Basically what this means is the game will remember which perspective (first or third person) you last used in vehicles and will store this separately to your standard perspective. It will then automatically switch perspectives when entering/exiting vehicles.
I also spent some time extending our ‘uber’ shader that we use to shade almost everything. Previously vehicles were using a very similar shader that was blending its custom colors through saturation rather than a linear blend. When checking through vehicle world items I noticed a few panels needed to have their backfaces drawn so rather than add a backface option to the vehicle shader I decided to add a saturation option to the uber shader. Whilst doing this I also added an emission option (with both color and texture) for self-lit objects and fixed a series of bugs around shader variant creation. As a result of this fix the uber shader is no longer replaceable through modding but you can still use any shader you like by assigning an override material to the mesh attachment.
This week I’ve been continuing work on the set dressing assets I was working on. After changing a few things on the terrain chunk mesh It’s now very easy to swap textures in and out to match them up with all the biomes. At the moment the terrain chunks work better in certain biomes due to the general noise of the terrain which gives me more dips and valleys to fit them into, but that won’t be an issue when I place them in the real map as I can edit the terrain manually to make them fit nicely. I’ve also been looking at creating a few medium sized rocks to be used as hard occlusion, at the moment the only rocks we really have are either massive impassable objects or resource nodes, so having something in between is an easy win from a gameplay aspect. Although rocks are easy to use as hard occlusion they are a bit harder to actually model, there’s a lot of challenges when it comes to size and noise frequency, at the moment I’m putting everything I’ve learnt about them through out the year to use.
This week I finished off the loot, damage, stats, items, crafting sync with legacy as a baseline. I just put the finishing touches on the amber protection system which fits into our item architecture nicely and doesn’t add much complexity to the progression. It currently works by simply right clicking->protect an item which will put a lock icon on it indicating it will stay with you after death, pretty simple.
The biggest work here is now configuring how much amber each item costs to insure, which I think would be better done by a formula based on crafting recipe. Reversing crafting recipe from an item isn’t currently very easy, but is something we had planned for the recycler machine that will be rolling out with this patch so I’ve opted for implementing that first, then I will work backwards to calculate the amber cost of all droppable items and we should get to a decent baseline balance for it.
Schedule Bump UpThe original schedule for our next experimental release was the 26th of Jan, as this is a public holiday for us we will be releasing on Thursday the 25th of Jan at 5pm Melbourne time instead.