Since Necropolis is such a procedural game, it presented some unique technical challenges in terms of authoring VFX. I worked with several designers and engineers to make systems that allowed us to procedurally apply VFX, so that I could author one VFX package and it would apply to a whole class of assets, reshaping itself to fit within the context that the designer had chosen. The project taught me a lot about the intricacies Unity’s rendering and VFX pipeline and what things are necessary to create optimized particle effects and shaders. 

When I arrived at Harebrained we didn’t have an established pipeline for environmental asset creation. During my time on Necropolis I worked with several artists to identify time consuming problems and create tools to solve them, whether it was an issue with Maya or Unity or both. This involved creating several Maya and Unity tools for automating tasks and improving workflows, and managing the Unity asset pipeline. Additionally I worked with several engineers and artists to get around issues with Unity’s prefab system – If you’ve ever worked in Unity and tried to put a prefab in a prefab you know what i mean. 

On the Maya side  some highlights include a material converter that can convert all our unity materials into Maya materials and hook up all the textures/settings, an automatic texel based UV unwrapper, a mass FBX exporter, custom decimation and LOD tools, and an automatic fracturing tool for creating detructible objects. On the Unity side I wrote several post processors to take handle imported assets and automatically create colliders, set up LODs, attach components, assign materials and layers, and automatically create prefabs. I also wrote a custom batching script to combine static meshes. Since Necropolis is procedural, we couldn’t use the Static Batching that comes with Unity. To solve this I wrote a tool that could not only combine multiple assets with different LODs into a single draw call, but could also convert them back to individual prefabs, allowing us to iterate on kit pieces and layout and still bake everything down for maximum efficiency. 

One of my favorite tools I worked on was the test automation suite I created. Since we had such a small team on such a large game, it became necessary to create several tools to automate our testing process. This took the form of automated testing of scenes every time someone saved and of all scenes and prefabs at build time. It would generate error / warning files for engineers and populate windows for artists, increasing visibility and dramatically decreasing common errors like missing LODs, broken script connections, incorrect layers, etc. It also generated estimates of performance for each scene, estimating draw call counts, light and VFX usage, static batches, etc. This gave us a much better sense of what scenes were over budget and how to optimize them for ship. 

The procedural nature of the environment made creating interactable and scripted assets a unique challenge. Not only did everything have to work in a variety of scenarios, they also had to make sense when placed procedurally. I created the initial implementations of several traps and interactable objects and assisted artists in creating new ones. This included everything from switches and moving platforms to traps and teleporters. Identifying, solving, and anticipating the many edge cases created by the procedural placements of these assets was a constant learning process, and taught me a lot about procedural asset design in general.