top of page

Logic Breakdown - Zoo Life

On this page I will be looking at one of the major problems I faced during this project, I will look at how I handled it, my thought process and how I came to a solution.

Example Problem Breakdown: AI priority & location tracking

Throughout this project I faced an untold amount of problems that required research, fixes and workarounds. In this section I will be breaking down one of the larger issues I faced to give an idea as to the mentality and how I solve complex problems.

 

Aim: Have AI animals make decisions based on real time needs. The AI should be able to determine which need statistic is lowest, prioritise this statistic and find a player placed solution.

​

Example (fig 1): Polar Bear 1 has the current real time statistics:​

  • Water = 30%

  • Food = 60%

  • Sleep = 40%

  • Enrichment = 50% 

Polar Bear 1 is thirsty and will seek out the nearest reachable water source to drink.

​

Breakdown

After putting together a fairly simple AI I ensured the AI would prioritise whatever statistic is lowest.

 

In the early demo build video example below (fig 2) water is the lowest stat. The AI prioritises this and moves towards the nearest water source to drink which replenishes the AIs stat to 100% over a couple seconds (dependant on how thirsty the animal is)

​

​

​

​

​

 

 

 

​

 

 

 

​

 

 

 

 

​

            (fig 2)

 

Problem: What if there is not a lowest stat?

​

This is a fairly simple problem to fix, add a "comfortable" state so if the animals stats are above 70% then the animal will wander around its enclosure.

​

Problem: What if there is no need satisfier (water source/food bowl/shelter/enrichment toy) available or placed?

​

If there is no water available it is logical that the animal would try and prioritise the next lowest statistic. Implementing this caused quite the hiccup with the behaviour tree layout. No problem, just need to add the same logic checks for the other statistics after the AI determines there is no water shown. This led to the  branch get longer allow the AI to determine the 2nd and 3rd lowest stats if the 1st priority stat is unavailable. The video below shows this (fig 3)

​

​

​

​

​

​

​

 

 

 

 

 

 

 

 

 

 

​

​

​

                            (fig 3)

​

Problem: This is hard to read and not scalable 

 

As can be seen this somewhat worked but quickly got out of hand in both readability and scalability. The method used here meant that it would get infinitely larger which meant if this project was to ever be scaled up it would need totally redoing. This meant I had to revise my strategy for tackling the previous problem.
 

Often with behaviour trees it is easy to fall into the idea of "if AI can't do X, do Y" in a single branch. However I decided against this and had an enum that was set and updated dynamically alongside a current priority level integer communicated throughout the different branches. So for example if the polar bear (fig 1) has no access to water it will search for somewhere to sleep, if this can't be found it will  find a toy to play with, then if this can't be found it will search for food.

​

Problem: So say Polar Bear 1 had 5% enrichment and 10% food. Would it really prioritise playtime over starvation?

​

No, logically it wouldn't. Therefore I changed the enrichment statistic to be more of a secondary statistic, where if the animal is comfortable then it will decide to play, this will keep the animal happy (and stop it from running away from the zoo).

​

The behaviour tree now looks like this (fig 4). It's more readable than before (I would do this differently in the future through separate nested behaviour trees and compartmentalising them) but most importantly it's more scalable in the event I need to change anything or add a new statistic, etc.

​

​

​

​

​

​

​

​

​

​

​

​

​

​

 

 

 

 

​

​

                           (fig 4)

​

Problem: Since the fences keep the animals in, it also stops them from roaming to whatever need satisfier they want. Meaning they will walk into the fence forever.

​

I tried to fix this in multiple different ways. My initial thought was to ensure that the animal could navigate to the satisfier, otherwise they would ignore it. However this often was temperamental and didn't always work, sometimes it caused the animal to ignore something it could reach. This also meant that there was a lot of code running constantly for the AI to decide if it could reach it or not. Especially if all the AI performed this all at once across every single water source/shelter, etc. on the map. It very quickly can get out of hand. This meant that the issue was more with the potential satisfier sources the AI was being fed rather than the navigation. The AI was attempting to cycle through every single source. Yet the only sources that were relevant to that particular animal are those within the creatures enclosure.

 

The fix to all of this was the development of a completely new system, I won't go overly into this system as it had arguably as many or more of it's own obstacles to overcome. The system allows for:

​

  • Tiles to be set to an enclosure within the build menu

  • The tiles have different "fence type" enums which changes the aesthetic style of the enclosures outskirts.

  • Once exiting the build menu all tiles set to enclosure finds neighbouring tiles, also with the enclosure type, through a search an  be grouped by a overarching enclosure manager and set to be "Enclosure X". 

  • Enclosure X has it's own sub manager spawned to then take track of all water sources, shelters, enrichment toys and food bowls within it.

  • The overarching enclosure manager then proceed to find other enclosure tiles that are not attached to Enclosure X and repeat the process until no more enclosures are found.

  • When building any sort of water sources, shelters, enrichment toys and food bowls within an enclosure the sub manager will update.

  • If a new enclosure is built next to a pre-existing enclosure these will merge due to how the mechanics work. This means the overarching enclosure manager will decide whether to create, update or merge then destroy a sub manager dependant on the situation. This ensures the information is kept up to date.

  • Animals can only be spawned within an enclosure and are added to the sub enclosure manager upon spawning.

  • All enclosure information will be passed to the relevant creature from the sub manager therefore allowing the creature to find what they need.

​

The result:

​

​

​

​

2024

Thomas Wilkinson - Technical Designer

bottom of page