Posts

Showing posts from 2019

Project Evaluation

Image
The goal of my project was to investigate the use of behaviour trees (BT) in a stealth based environment.  I do believe that I have achieved this by researching into various different aspects of artificial intelligence (AI) used within games, the various AI used by different games, especially the BTs used within Alien: Isolation and Halo 2.  At the end of my deadline I have implemented a BT that my agents use in a stealth based environment where the player will need to get from the start location to the objective.  If the player is spotted the AI will converge on their location, once close enough the AI will kill the player forcing them to try again from the start location. I believe that the project has been a success and I have made good progress despite having various personal issues that restricted my availability to work on the project, as well as having commitments to other modules.  I was able to complete all my milestones and create a few extra simple behaviours, such as th

CCTV Implementation

Image
As stated in my project proposal I have worked on implementing CCTV into the scene.  The cameras have a trigger attached that works like a frustum, once the player is within this trigger, the camera notifies the global blackboard that the player has been spotted, the global blackboard then alerts the guards of the player's last known location and sets them into the alerted state. The camera is able to check if the player is in view of the camera by sending out a raycast and returning the item that has been hit.  This is similar to the line of sight (LoS) method that the guards use.  This stops the camera from spotting players through walls.  The cameras perform a sweeping animation as shown in the video below. I have also created a user interface (UI) that prints out the guards states, this helps the user see what the guards are up to and shows the transition between states when reacting to the player.

New Engage, Wander and patrol Behaviours

Image
In addition to the patrol branch of my behaviour tree (BT) I have created another branch that handles the the control of flow once the player has been spotted. At the root node I have added another child selector which will select a behaviour based on if that current guard can see the player, or if the player has been seen by another guard.  If the player has been sighted by this guard, the tree will check the state of the player, if they are in combat (can see the player) they will update their speed and enter another selector. The Shoot or Move selector will decide if the player is within a certain range, if the player is within this range, the guard will "shoot" and kill the player, causing them to respawn back at the start location and the global blackboard will reset the guards states back to idle.  Although once the player is respawned two guards remain in the alerted state.  This is something I will look into and hope to resolve before the project deadline. If the

Adjusting Behaviours at Run Time

Image
I have been looking into way I could have improved my AI and my approach to my Final Project (Dissertation equivalent) and I have found a few methods, and tips that I could implement to make the AI feel less "rigid" to the player and become more "believable" by reacting to situations differently depending on various factors, for example if the player fires at the AI, how should they react?  Should they take cover, return fire or flee?  Should this always be the same and hand coded in?  I have found two methods from Steve Rabin's Game AI Pro 2 which look at ways to make the AI less predictable building upon the illusion of intelligence. Dual-Utility Reasoning Where there are multiple decisions an agent is able to make they will usually pick the first available option, especially in a BT which worked through its children based on positioning priority (unless a random composite node is used).  However, utility-based AI is able to make better decisions and “will

The Illusion of Intelligence - A Talk by Halo's Chris Butcher and Jaime Griesmer

Image
AI is broken down into multiple subsections, some of the responsibilities are down to the designers, such as mission objectives, scripting and object placement, while other tasks are the responsibilities of programmers such as firing patterns, path-finding etc.  However, some parts overlap, such as combat behaviours which is what this talk is mostly about. (Nanopdf.com, 2018) When designing AI the player should be taken into consideration and what they can do as "the first design goal was to make the AI intelligible to the player, so the player can understand what they're doing".   (Butcher and Griesemer, 2002) This means that when designing the AI they had to work within limited capabilities because if the player is unable to understand what or why the AI is doing a certain action, it might as well not be in the game.  So the player will assume that the AI is able to do what they can do such as; see what they can see, do what they can do and know what they can kn

White boxing a test environment with ProBuilder

Image
As I stated in my proposal, to white box out a test environment I was going to use ProBuilder as it is a quick and built-in way to model geometry.  I had tested some environments in scenes  Although this came with some issues as I do not have any prior modelling experience I had a few issues while making the initial rooms, the more I used the software and read up information the quicker I was able to complete the models, however I did vastly underestimate the time it would take me to white box a rough test environment. Another issue I had with ProBuilder is that while building my models, especially the first couple I was having issues connecting pieces together in the way I wanted and it appears I was unable to remove the faces and vertices correctly as once I got round to putting colliders on the environment, some of the models where I had placed doorways in had a very messy collider around those locations which could affect the performance of the test level. At present it has n

Redesigning the Behaviour Tree and Blackboard Implementation

Image
My original Behaviour Tree (BT) was not executing correctly with the agents getting stuck within certain states, or unexpectantly skipping over behaviours altogether. This was not ideal, so I set up a meeting with Chris Janes to discuss the issues I was having. After stepping through the code, Chris pointed out that the tree was not resetting the child lists and some other issues. Due to these problems I elected to redesign how the BT is implemented making sure that everything is reset when a node begins and terminates. With the redesign of the BT I was able to spot some design flaws in how the tree was executing the child nodes and priorities of some of the behaviours were incorrect. To rectify this issue, I created a generic conditional check node that can check the states that the guards are currently in and ensure that the flow of control is sent down the correct branch of the tree for the current situation. For example, if a guard is patrolling but the player has been spott

Researching Blackboards

Image
"a[ sic ] blackboard system is composed of three main components: the blackboard, a set of knowledge sources (KSs), and a control mechanism" (Carver and Lesser, 1994) although over the years the blackboard system has evolved and "many times no arbiter is used" (Isla and Bumberg, 1980) where the arbiter is the control system, that (Carver and Lesser, 1994) describes. The blackboard model has proven to be popular for AI problems outside of games artificial intelligence (AI) and within, however, within games AI "blackboards are commonly used with behavior[ sic ] trees"   (Broder, 2014) although they can be used without a behaviour tree.  Blackboards are a place where data can be stored and read by agents within a game world.  Agents can have their own independent blackboard, a global blackboard can be used or both. As mentioned above, blackboards can be used to store data after a calculation.  This can help with performance as it will not need to be calcu

Presentation Feedback

Image
Recently I had to perform a presentation to two of my tutors at the University of Suffolk to give them a progress update on my final project.  To begin the presentation, I spoke about some of the milestones stated in my project proposal that I had completed which was mainly about researching into the various AI techniques, Line of Sight (LoS) and beginning to implement a Behaviour Tree (BT) and some behaviours for my Guard AI. I then gave a rough breakdown into how a BT functions before discussing some issues that I have been having with the project and in my personal life, and how they have affected the timeline of the project leaving the project around two weeks behind the intended schedule.  I then went on to explain the future of the project speaking of what I intend to have implemented by the deadline and what stretch goals I plan on implementing should there be enough time. After the presentation tutors were then given a chance to ask questions around the project, I didn'

Conversations

Image
To make the guards more believable, as they are patrolling around the scene, should they cross paths with another guard, they will stop to have a conversation with them.  This helps break up the predictability of the guard's patrol, as once they have finished with their conversation they may end up travelling in a different direction to what they had originally started upon finding a new patrol destination.  It will also start to lock off paths that the player can travel down as there will be at least two guards standing in their way. The converse path in the tree is part of the IDLE  SelectorNode and takes priority over the patrol nodes.  shouldConverse is a SequenceNode that has three children; Attempt Conversation This node is used as a conditional check that ensures that the agent hasn't recently had a conversation.  This stops the guards from being in constant conversations either with another guard that walks past or reenters conversation with the previous guard. 

Creating a realistic NPC search

The way NPCs search in games helps create believably and makes the NPCs seem more human, as they go about searching for stimuli that they are reacting to.  There are different types of searching an NPC can, and should perform depending on the situation and the stimuli, (Welsh, 2015) breaks these types of searches down. When an NPC is performing a cautious search, this should be because "the NPC has been alerted, but does not know whether their target is hostile." (Welsh, 2015).  This can be caused by sounds using techniques different games employ, such as in Metal Gear Solid, the player can knock on a wall, or in other games the player can make a verbal noise such as the whistle in Assassin's Creed. Another type of search that (Welsh, 2015) talks about is an aggressive search, this is where the NPC knows that what they are searching for is hostile, some stimuli to this could be spotting the player or hearing a hostile sound such as a gunshot. It is important to tele

Changing Patrol Logic

Image
Originally guards would have an array of way points individual to each guard.  Whenever a guard reached their destination, that guard would select another way point at random and begin moving to that position. However this method makes the guards move in a very predictable way, as once they player figures out the way points, they'll know where the guards are going to move to.  I wanted to make this more believable, so I changed their behaviour from a straight " seek " to a " wander " behaviour.  This was an attempt to make the guards move around in a more sporadic way and be harder for the player to predict their movement. To achieve this I created a wanderRadius around each of the guards and used a method to return a random point from within that radius This method would create a random point in the scene and test that it is accessible on the NavMesh to allow the agent to move there, if the point was unsuccessful it would call the function again un

First Design Iteration of the Guard Behaviour Tree

I have been working on designing how the behaviour tree will be implemented, focusing on the "idle"  states, I wanted to do this now before I get too far into development with the nodes only to have to change the layout of how certain nodes works.  Initially I tried to show the design as a visual representation by creating nodes within Microsoft Paint, however this didn't work very well as I kept deciding to change different parts of how the tree works. For now I have decided I will build the foundations of the tree using a Microsoft Word document  using bullet points and indentation to visualise the tree, priority of nodes working from the top down and will look to creating a more visually appealing document further into development. As stated above so far I have been focusing on the guards idle states, which will control what the agents will do when they have not been alerted to the players presence.  I have placed some basic behaviours which I believe will make the