Spencer
This week has been fixing all the broken stuff that would block progressing in ItemV2 survival. The map and initial progression is now in a playable state as we close towards an initial ItemV2 release.
Cow_trix and Tom have both finished their respective projects which were the final feature blockers for a releasable ItemV2, and I’ve now put the entire team on Release mode. We will be all hands on deck fixing regressions, testing and getting the game back to a decent state instead of adding new features and breaking more stuff đ
Unity Upgrade
The only major blocker left is getting AI working again. The way we generate maps right now is causing havok with our old pathfinding system, which has been a pain in the ass for most of development, but has also been the only good solution. The good news is Unity 5.6 is out, and with it a heaps better Navmesh system so I’ve bit the bullet and am attempting an upgrade tonight.
With everyone in release mode, I hope to get something out to the experimental branch in 2 weeks time.
TEHSPLATT
This week I got started on getting some of the non-equippable items into Unity. Doing simple items comes with a lot of challenges as they don’t need to have over the top detail but they can’t just be flat boring models, they need to be somewhere in the middle. Another challenge with smaller more background items is their triangle count has to be lower, this is fine for things like clay and bricks but requires a decent amount of thought when it comes to small items with lots of detail. Probably the biggest hurdle to overcome with these non-equippable items is making sure they don’t just turn into a blob of noisy colour when they get scaled down to icon size. Zbrush definitely makes life easier when it comes to these sorts of items though (and most others) as it allows me to concept them quickly using pre-built materials already in Zbrush, this is a life saver as it stops me from having to go back and fourth through the entire pipeline making changes, instead I can get it close to perfect before getting it in Unity.
I also tested out some new patterns for the pants, I think they look pretty good, having such quick and easy control over color schemes using the color masking shader is extremely helpful. The mix of objects with different specular values stand out nicely across most color schemes and will most likely be something we try to do to all upcoming models as breaks up the monotony of items with a mostly flat specular, this is something that’s pretty important for bigger items.
Cow_Trix
Hey folks. This week Iâve been doing a bit more work on the UI, integrating Tomâs threading mesh baking into the icon system, fixing a few bugs in the SDK for Spencer and figuring out the best way to set up collider data on world items.
I spent a fair bit of time on item dragging to make it feel intuitive and spatial. It turned out to be pretty tricky, as icons can change contexts pretty massively as you drag them around. An icon can change both aspect and display size as you drag over a slot, and that needs to feel like the actual item drag isnât jumping around the screen – i.e. there needs to be a feeling of continuity. To achieve this I had to put in a few offsets that play off each other, so the internal sprite is offset from the drag raycast point, which is in turn offset again from the actual mouse cursor position. As usual with UI work, a lot of this was just testing and going off what feels good.
The hotbar has seen a few changes. Items in your hotbar are somewhat âfocusedâ or important to you, so we thought they should probably show larger icons. Iâve been playing around with this idea, stretching the hotbar up so it can display different aspect icons to a pretty nice resolution. Check out two prototypes of how this might look below!
Finally, Iâve been looking into more explicit mesh generation for the colliders of world-items. Mesh colliders are just not performant enough to run large amounts of rigidbodies, but they were very easy to configure! Iâve been working out a good way for a world item to figure out what physical volumes it takes up in the world and the best way it can create primitive colliders to fill that volume. Currently weâre just slapping cubes on everything, although Iâve set things up so that hopefully when we find objects where that really doesnât work, we can extend the system to create more complex collider structures.
Mils
A new Stock and a new Muzzle Brake are now good to go. This completes my run on the current components for the AR15. There are now 2 options for all the component slots.
2 x Iron Sights, Red Dots, Magazines, Stocks, Suppressors, Muzzle Brakes, Barrel Guards. That’s 14 component items and 15 with the Receiver. Actually this is a lot more items than I thought after doing a recount.
I really like how this stock came out. Was interesting to model.
I’m now working on 2 skin designs for the AR15. These like the car skins will be unique to the gun type but will be available across all the AR15 components. I already have 1 design which was seen previously on this gun. I’ll be adding that design onto the rest of the components and then making a new one and applying that also. Below are some new designs that are just painted over a screenshot of the AR.
Tom
This week I finished up converting our mesh combiner into a threaded system. First up was implementing a system to pick level of detail for a combined mesh, you can now set the distances for medium, low and culled (high is picked when closer than medium distance) and CowTrix has added a way to override the distance behaviour and allow another component to control and set the detail level (distance doesnât make much sense for things like the new icon renderers).
I also ran into some complexity around cleanly serializing the configurations. The mesh data from the configurations isnât calculated until building a mod out of the SDK (or if previewing in the SDK the data is built temporarily as you need it), this data and a reference to it needs to be built into the asset bundle.
To achieve this I added pre and post build steps to our mod build pipeline, during the prebuild all mesh attachment configurations build their mesh data and save them into a temp folder. The postbuild step deletes the temporary folder then iterates through the attachment configurations setting all buildstep object references to null. Without explicitly nulling the references Unity keeps the old reference around even though it doesnât point to anything so it can generate extra information for errors. In our case though we know we only need these references while the game is running so we donât need the extra error info plus when using a version control system the changing reference will be marked dirty after every build which is a real pain.
Iâve also started working on the next bugfix patch, which we will get out as soon as possible! Thanks to everyone helping me out by reporting bugs!
I donât want to spill the beans on all the changes just yet and spread the bugs before they are fixed but as a quick idea weâll be fixing some remaining crouch state desync bugs, some construction bugs, fixing a few issues with the Diemensland map and adding a short temporary no build zone to c4 explosions to prevent bases being immediately rebuilt.