Trout Priest - Navigating Navigation & First Round of Playtests

While it has been spread over a couple of weeks, in terms of time spent, it’s been 5 days on Trout Priest now. I'm quite pleased with what I have managed to achieve in basically a work week. Now definitely feels like the time to lock the project down, fix bugs, polish existing features, and finish the thing!

A big problem I initially ran into was that the original way the enemies move does not seem to behave the same on WebGL builds as it does in the Unity editor. They either moved incredibly slowly, or got stuck on tiny bumps in terrain that were no problem in the Unity editor.

I got very frustrated from trying to blindly bodge the Rigidbody movement, so I thought I would try another approach, and navigate Navigation.

A simple navmesh on the terrain means the enemies will use some basic intelligence to find their way to the Chapel. Obstacles are now avoided rather than walked into. This is going to allow me to make more complex terrain features like cliffs and layered walls, while still allowing the enemies to (eventually) reach you.

I’ve not used Unity’s Navigation system before, and was a bit concerned that I would be overwhelmed with complex systems and AI layers. Turns out, it is incredibly simple! Simply generate a Navmesh for your terrain, give your NPCs a Navmesh Agent component, and that’s it! In the code, give the Navmesh Agent a destination and off it goes! Magic!

A concern I do have, however, is the performance cost of this new Navmesh movement. It is far more complex than a simple LookAt() and AddVelocity() script, and with many of these actors in a single scene, things could get quite heavy quite quickly. To mitigate this, I have made the Navmesh quite coarse, set a fairly low maximum amount of enemies in game at once, and made their pathfinding the lowest quality possible. These are zombie fish, so nobody is expecting high intelligence from them.

After sorting the new navigation, I did some more research and found that the initial issues with the Rigidbody-based movement was that WebGL builds seem to use FixedUpdate - and changing Update functions in c# to FixedUpdate, I got similar results to web builds in editor. Well now I know for next time!

A useful UI update is to show your upgrade materials at all times, rather than just when you are at the chapel. This seems to make players more inclined to collect them, simply because there is better feedback.

This was one of many small Quality Of Life improvements suggested by playtesters. These are usually the last thing you think about when deep in the development mines, focusing on pure Minimum Viable Product and already knowing the game inside out. It’s been really nice watching people play, and noticing things that I have not explicitly mentioned, but managed to hint at from visual and gameplay cues.