Because it's still using the standard PBR shader we can still have a fair level of detail using normal maps and can simulate a variety of materials using the shader's shininess and emmissive properties. This is done by quantising the light reflected off a surface to two flat steps. It took us quite a few iterations before we came up with a solution that really captured the look of the game we wanted but in the end I followed this blog post and modified the Unity standard deferred shader to have a more cel-shaded look. The outlines they include don't really work on any objects with sharp edges, they don't allow any control over the material properties of the object like you get with Unity's standard PBR shader, and they only work in forward rendering mode. Unity's Standard Assets package inclues some "toon" shaders but we quickly found those limiting so didn't end up using them. Achieving the look of the game - custom shadersįrom the beginning of the project we wanted it to have a light, friendly look, reminiscent of children's cartoons. You can read more about that library and behaviour trees in general in that article, but for us it ended up being quite useful for modelling complex behaviours and decision trees.
More complex AI for parts of the game like the two bosses was built using behaviour trees using the fluent behaviour tree library. stopping running will always go back to idle), but if running is just a child state of idle you can pop the top state off the stack to go back to its parent implicitly. With a traditional approach you would always have to remember which state to go back to (i.e. Hierarchical state machines have a big advantage over traditional "flat" state machines where each state is on the same level, because they allow you to create a stack of states. The system used for managing player state uses Fluent State Machine, a hierarchical finite state machine system I wrote at Real Serious Games. This was great for rapid greyboxing and helped us build the large areas of the game relatively quickly, without having to use any external tools.
Unity's API for writing custom editor extensions was also invaluable as it enabled us to write a full hex-based tile editor that ran within the Unity scene editor. This was good because it meant we didn't have to rely on a single prefab to contain everything, and we didn't need to remember to add the same objects to every single scene over and over again (which was a big deal because we ended up with a total of about 34 scenes in the project). This way, the other scenes only needed to contain objects specific to that level. In particular, the additive scene loading feature introduced in 5.3 was invaluable to us as it allowed us to take elements that were in every scene such as the player and the UI and put them in a separate "Shared" scene. While I've found Unity to be limiting for some certain kinds of projects it was definitely a good fit for Bees Won't Exist. We did consider Unreal 4 and I'd still like to use that some time, but in the end we settled on Unity mostly because I was more familiar with it.
Tech used Unity 5.4Įarly on we decided we wanted to make the game 3d so Unity was the obvious choice for an easy to use, full featured and affordable (free) 3d game engine. Bees Won't Exist is our final year project at Queensland University of Technology and I'm posting to share some insight into the kinds of tech we used, what worked well, and what didn't. We are a team of 5 my role consists of Lead Programmer and Senior Exotic Tea Provider. I'll meet you by the hive!īees Won't Exist is a fast-paced hack 'n' slash adventure game that I have been working on over the past year at Honeyvale games. Can you hear it?ĭon't worry! It's time for some pest control. GIANT BEES HAVE DECIMATED HUMANITY! Every day, the low buzz of death approaches further. Guest post: The tech behind Bees Won''t Exist