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 Up
The 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.