Because we've already defined a lot of the basic maneuvers described in Part 1, 2 & 3 as behaviour nodes we can now mix and match them to create new behaviours in our tree. This is where the Behaviour Trees really shine. Simply apply the intentions above to actual movement (modify velocities, update positions, repel from walls, separate from nearby entities etc.) This is WIP, we plan on cleaning up this behaviour during production.ģ. There's some bugs and caveats to this method, one of them is that it's easy for the monsters to chase each other in a loop (or pairs), so there's some failsafe hackery code to stop this from happening. As long as the leader of the pack is alerted and can see the enemy, this state and behaviour is propagated to other mobs down in the chain. Priority B is particularly important - it allows the monsters to follow each other in a chain/queue-like fashion. If this fails also (there are no alerted friends visible), then we fall back to patrol (with best guess). He then proceeds to follow the alerted friend in the same way as in priority A (again line of sight, breadcrumbs, and last recorded location). If his friends are alerted, this state is passed on and the monster becomes alerted also. If these actions fail - the next branch (priority) of the tree is parsed and the monster has a look at what the friendlies are up to. The first one we've already covered in Part 1: monsters chase after players in their line of sight, then breadcrumbs (smell trail), then to the target's last recorded location. So, conceptually speaking, our tree models a list of ordered priorities: A. For an overview of Behaviour Trees, AIGameDev covers this particularly well: We'll not cover the specifics of the Behaviour Tree implementation here - the details are too numerous and will best fit in a future post. This is where the Behaviour Tree comes in handy - to aid in the decision making process. By this point, the monster now has a reasonable view of the world on this exact frame, and we use this information to help the AI determine what to do next.Ģ. In future versions, things like visible furniture, entrances and exit doors, walls etc. In addition to these, breadcrumbs dropped by both threats and friendlies are also recorded. The lists are cleared at the beginning of each iteration. Entities that cannot be seen are not included in this list. For each frame (more specifically each iteration of the Behaviour Tree), the monster maintains 2 lists: threats (you), and friendlies (other skeletons) - based on line of sight. Let's break this group chasing behaviour down:ġ. Combine Archers and Skeletons together and you have quite a challenging group of foes to deal with. Today, I'm going to explain a little bit more about how this group movement actually works - and also introduce a new monster to the pack: The Skeleton Archer, with its Ranged Attacks. In Part 2 (Retreating) we briefly touched on how Fire Imps in each other's line of sight were connected as a group, and that they would share alert levels. Interactive demos for previous parts are at the usual place: Monster AI System Explained (Part 1 of 5)Īll techniques demonstrated are implemented in my game TinyKeep, which is currently Kickstarting (only 2 days of funding left to go!) Monster AI System Explained (Part 2 of 5) Monster AI System Explained (Part 3 of 5) If you haven't already please read those articles to get a context for the AI and game so far: This is a continuation of my previous game development "Explained" posts.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |