Godly is a top down action shooter, where you can pick up new items and customize your character with abilities. Find different projectiles and armor and use them to help you explore a world full of surprises. For you to be able to go back enjoying your vacation, Hades needs to be sent packing back to the underworld!
This project started out with three keywords of focus. Audience Awareness, Customization, and Sandbox. And we were running SCRUM after having a workshop in it’s usage. For this project I was assigned the role of scrum master, so I tried my best keeping our meetings short and meaningful. The areas I chose to work with mostly was character set-up and animation, shaders, and making the game run smoothly.
The group seemed happy to get a rigger in the team, and started bouncing ideas of having a multitude of characters rigged. Being a somewhat short project this sounded a bit daunting – so I set the limit that they all had to be humanoid and started looking for solutions to help reduce time spent setting up each character. A quick test of Unity’s Animation Retargeting had the block out character rigged and in game in less than an hour.
The Motion Capture we got from the asset store proved to be enough for what we needed starting out, so after having the blending going, we made some quick animations for enemy taking a swipe at the player. Some poses that could be added on top of the enemy animation to give each character a different weight.
Some time later into the project we decided to make the cyclops be a ranged enemy. So animated a throw and tweaked the spawn position of the projectile particle.
For the final boss, we wanted Hades to strike at the player. So to solve this we looked into adding IK in Unity which proved to be easier than estimated. We then blended in the weight of the IK to not be fully 100% until the strike animation had reached a point and it worked out good enough.
Starting out I had minimal experience with writing shaders, having only written a Windwaker-esque ocean back in 2014. So for our foliage I dusted of that shader and tried do something similar to achieve the feel of leaves moving to the wind.
I managed to get the displacement to work as intended (code), but the “addshadow” wasn’t the simple solution to not having to write a shadowcaster pass I had hoped for. So I reworked the thing using Amplify Shaders.
Image showing the method used for displacing the vertices, only a diffuse and normal texture was used and nothing odd happening there.
We experimented a lot on how to allow the players to see what’s going on when the character became obscured. From making anything obscuring vision transparent, to having it clip worldspace.y. Finally we landed on having a glowing outline around the characters and items of importance. Starting out we used the simple method of scaling vertices – drawing everything in flat color, then cutting this image with the regular render of characters. This works well for any mesh with smooth edges. But will get artifacts wherever there is a hard edge.
I Googled about and found a good looking solution that we ended up implementing. It didn’t work out of the box so took some tinkering to understand it.
Gist of it
Often close to reviews we would have materials on some recently updated assets go AWOL. So artists and designers alike would waste time to manually go through each of our tile prefabs to replace the assets and using different methods to try retain the work of our level designer. I asked permission from the group to create a band-aid solution over lunch, and started out by making a regular C# script that had a checkbox I could toggle. The first iteration worked, it iterated over each item in the hierarchy, replaced them with their original asset and solved the problem. Great. However – it being a regular script, lead to other problems of having to exclude it from builds and without any interface to speak of left most people scratching their heads.
Then I remembered having seen Brackeys do a video on creating custom editor scripts, so took a quick view of that one again. Then reworked the checkbox hack with an actual editor script with clear instructions so there would be less head scratching.
At these projects we’re told to only bother with optimization if and when it becomes a problems. There were times it did feel slugish so I started looking over the levels with Unity’s Profiles running. Also ran on the final build with deep profiling active. The two major thing we could find was firstly overdraw (didn’t need a profiler to tell us that) and secondly there was a script running that rotated the main directional light – which caused the lighting to be baked every frame! Once we deactivated this feature frame rate kept solid above 60fps and we couldn’t find any major lag spikes in any other play test.