Week 1 - 04/03/24 - Proposal
This was the first week of my Final Major Project (FMP), a period I dedicated to starting and completing my project proposal. Using a structure provided by my tutors and a clear idea of what I wanted to create, I persevered and managed to complete it within the week. I had a rough timeline to follow, which required me to finish my proposal in this first week. However, possibly due to a waning idea as the writing progressed or a lack of focus, I found myself rushing on Sunday to complete it.
​
I managed to finish the majority of my proposal during the weekdays, and I believe the rationale is of the highest quality. It thoroughly justifies each aspect of the project and provides strong reasoning for learning these skills. The evaluation is also a high point, offering numerous examples of how I will assess the project and the benefits of these methods. However, when writing the project concept and timeline, I began to notice problems with my idea. While I knew I wanted to create believable NPCs, I was uncertain about the specific details required to make them convincing.
​
Initially, my plan included both friendly and hostile NPCs. However, as I delved into planning the mechanics and timeline, I realised that focusing on hostile NPCs offered a much deeper and more compelling avenue for development. Consequently, I have decided to shift my focus solely to the creation of hostile NPCs. While this necessitates revising parts of my project proposal, it will ultimately save time and result in a more focused and informative project. This revision will commence next week.
Week 2 - 11/03/24 - Proposal & Research
I started this week in the same manner as the previous one, revising my proposal to streamline my ideas. I managed to complete this revised proposal within the day, adhering to the concept I mentioned last week. The focus is now solely on creating hostile NPCs. Due to the similarity of this revised idea to my original plan, I was able to reword rather than rewrite much of my proposal, which saved a significant amount of time. The only section requiring a complete rewrite was the timeline, but this was necessary regardless, so not much time was lost. My new research question, "How can I create believable hostile NPCs that respond appropriately to a given situation?" should provide a deeper understanding of NPCs as a whole and prevent me from becoming overwhelmed with too much study.
​
In addition to finalising my proposal, I began research and planning, which took me to the end of the week. Although research and planning are intended to span two weeks, there is still research from this week that remains incomplete (based on my initial planning). The research yet to be conducted involves examining existing game examples of advanced NPCs. This area remains unfinished primarily because it proved to be more extensive than anticipated. I initially took a brief look at potential candidates for this research (for my timeline), which gave me the impression that few resources were available on the subject. However, once I began this research, I found an abundance of resources to explore. While it's unfortunate that this task wasn't completed within the week, the new areas to investigate should ultimately enhance my project. I had initially planned to dedicate part of my weekend to completing this research, but personal matters distracted me. Consequently, instead of moving on with my research and planning, I will continue focusing on this area, as I believe it is vital to the project's success. I aim to complete this research by next Tuesday, working on Monday and during my personal time on Tuesday. This should provide ample time to plan for these explored mechanics for the remainder of the week.
​
Specifically regarding this week's research, I began by exploring AI pathfinding and how to create it. I deemed it important to start here because pathfinding is essential for all NPCs, regardless of their complexity, forming a solid baseline.
Using a Unity-endorsed series of tutorials, I now have a strong understanding of AI pathfinding. Although these tutorials were well-presented and comprehensive, they were designed for an older version of Unity, which required some intuition and additional research to fully comprehend—inevitably taking extra time. I was also unaware for a considerable period that many of the pathfinding tools demonstrated in the tutorials needed to be downloaded externally. This oversight further complicated my understanding of the tutorials, but once I realised this, I had no difficulty following along.
​
A practical issue I encountered with the AI agents was that they would slide to their destination and around corners as if they were on ice. Fortunately, this problem did not persist for long.
By consulting a Unity discussion, I discovered the solution: simply increasing their acceleration. Interestingly, I had already attempted this solution, but I had not increased the acceleration sufficiently for it to be effective.
From this point, I commenced the previously mentioned study of advanced game NPCs. Based on feedback on my proposal (from my assigned tutor Robert), I was introduced to the game F.E.A.R and its NPCs. This wasn't the only instance where this game's name appeared; while researching example NPCs, F.E.A.R frequently surfaced on almost every list. I conducted an in-depth study of this game using numerous sources, exploring how the AI was developed and identifying specific mechanics that contribute to its advanced nature. This research will be a significant asset to my project.
​
Two other games that appeared almost as frequently were Alien: Isolation and Left 4 Dead. I subjected these games to the same detailed analysis, focusing on the mechanics that render them advanced. Both games offer interesting perspectives on how AI can be sophisticated in unique ways. However, when examining Left 4 Dead, I noted that while its AI is complex, it is done in a way that prioritises gameplay over realism. Consequently, the insights gained from Left 4 Dead may not be as directly applicable to this project, although the knowledge acquired could prove beneficial in future endeavours.
​
This is where I concluded my work, leaving myself with two more games to explore (Halo 2 and Half Life) and some additional tutorials to further my understanding of pathfinding.
Week 3 - 18/03/24 - Research
Starting where I left off the previous week, I delved into the research of the two remaining games: Halo 2 and Half-Life. Halo 2 came first, marking an important step not only in my research but also in gaming history. This game popularised behaviour trees, now one of the most prominent methods for programming AIs.
Halo 2 NPC Analysis
By following an in-depth video that thoroughly explained its mechanics, I gained a comprehensive understanding of the advantages of behaviour trees over FSMs and how Halo specifically utilises them. Using systems such as priority and extensive pools of information, I believe I can effectively create NPCs inspired by Halo.
​
However, behaviour trees are not the only method for programming AI. To make an informed decision on my approach, I needed to research other methods. This led me to explore the original Half-Life, which is an exemplary case of using FSMs to create complex NPC systems.
Half Life NPC Analysis
By following another detailed video, I developed a robust understanding of the unique characteristics of Half-Life enemies and FSMs. I learned that FSMs are typically more code-based, which aligns with my preferred working style. However, they are also more complex to understand, scale, and program, presenting a significant drawback. If I were to use behaviour trees, I would need either an external tool or a different game engine. Further research into these methods was necessary to reach a conclusion, and this became my next focus.
​
I have started following a tutorial series that covers the creation of FSMs within Unity. Although I have not yet reached the point of having a functional FSM, the process of learning to create one has been informative and enjoyable. This does not negate the complexity of the system; there have been numerous moments of confusion, with more likely to come. To enhance my understanding, I have been using ChatGPT to test myself on specific lines of code. I input my interpretation and ask for confirmation, ensuring that I am not simply given the answers. This method allows me to grasp the concepts and progress through the tutorial at a satisfactory pace.
My primary concern at this stage is the time it is taking to progress. I am still following the FSM tutorials and have yet to delve into exploring behaviour trees. For the upcoming week, my goal is to complete the FSM tutorials. Subsequently, I plan on dedicating a significant portion of the Easter Holidays to exploring behaviour trees. Although this adjusted timeline sets me back from my initial plans, I had always intended to utilize the Easter Holidays as catch-up time.
Week 4 - 25/03/24 - Research
Continuing with the FSM tutorials, I successfully completed both the third and the fourth. These two tutorials demanded significantly more time compared to the previous ones, owing to their complexity and extended duration. However, upon reaching the final tutorial, I encountered a setback: missing script segments in the video. As these sections were not fully demonstrated, I was unable to replicate them for testing purposes, which hindered my progress. Despite this challenge, I persisted through the week, albeit with considerable struggle. Although I could not complete the series as intended, I still gained a robust understanding of FSMs, positioning them as a viable option for programming my AIs. While it is regrettable that I did not thoroughly check the tutorial series for such issues before investing significant time, this minor setback should not significantly impede my progress.
Easter Holidays - Week 1 & 2 - 01/04/24 - Research & Planning
During the Easter Holidays, I dedicated a portion of my time to the project to ensure I stayed on track for the upcoming production phase. One of the key areas I focused on was researching how to program my NPCs, a task I initially thought would be straightforward but turned out to be more complex than anticipated. As I had already completed exploring FSMs before the break, I shifted my attention to exploring behaviour trees, particularly focusing on coding them.
Coding Behaviour Trees Tutorial
Following a tutorial video, I aimed to gain a comprehensive understanding to form a strong opinion. However, attempting to replicate the publisher's code while following the video live left me feeling confused and overwhelmed. Many concepts introduced were unfamiliar and poorly explained, which was concerning as a beginner. Nevertheless, the experience was not entirely futile. As I delved into commenting the code, I started to grasp the underlying logic behind the structure of the behaviour tree. While the initial logic of how the behaviour tree functions remains somewhat perplexing, I realized that having the knowledge to adapt and create my own tree for my NPCs was paramount. As long as I could utilize the provided code as a foundation to develop my own, it would suffice for my needs.
​​
Fortunately, the tutorial managed to strike a balance between brevity and informativeness, allowing me to explore visual scripting options as well. However, when it came to capturing screenshots of my code for presentation purposes, I found the quality to be unsatisfactory. Consequently, I researched various tools and websites to find a more stylish way to present my code.
After experimenting with different options, I ultimately discovered "carbon", a tool that perfectly suited my needs and enabled me to showcase my scripts effectively.
Whilst exploring visual scripting options, I discovered that most tools for Unity are external and come at a cost. The price for these tools can be quite substantial, with the most viable option I found priced at €89.82 (Behaviour Designer - Behaviour Trees for Everyone). While the features offered by this tool seemed attractive, I also considered the free alternatives, such as coding FSMs and behaviour trees myself. Given the constraints of time, I prioritized coming to a decision sooner rather than later, which led me to focus less on exploring additional visual scripting options.
​
After thorough analysis, I believe my decision was well justified. Initially, I leaned towards using FSMs, but upon exploring behaviour trees, I found them to be a more viable option. This finalized my research phase and allowed me to transition into the planning stage.
​
With research concluded, I began planning by reviewing my findings from the study of advanced AI examples. I selected mechanics that I believed would enhance realism and were within my skill set to implement. This exercise helped me gauge the scope of my project, and documenting all planned mechanics made it easier to create timelines. While I did not provide extensive detail for each proposed mechanic in my planning, I deemed it sufficient as I had already explained them adequately in my initial research. Consequently, I focused on creating a Gantt chart to outline the project timeline.
This tool enables me to effectively monitor both time and progress throughout the project, covering all necessary areas. While I have created Gantt charts in the past, I had not used the website before. Initially, I found it challenging to become accustomed to the interface, but once I familiarized myself with it, I found it to be highly effective.
Week 5 - 15/04/24 - Practical
This week marked the first week of production. As it was the first week, there was a significant amount that needed to be accomplished, and indeed, much was achieved. I began with the core mechanics, focusing on those that would form a foundation upon which other mechanics could be built.
​
Pathfinding was the first priority. Thanks to my prior research, this was completed efficiently and without difficulty. This was not only a fundamental mechanic but also a prerequisite for testing patrol points.
Coding Behaviour Trees Tutorial
While I did refer to a video tutorial briefly, implementing patrol points only took about 10 minutes and presented no problems. However, the majority of Monday was spent on reflections, meaning that the patrol points mechanic was only fully implemented by Tuesday, a day later than planned. Provided I can make up this time, this delay should not pose a significant issue.
NPC Patrol Showcase
The project continued to progress smoothly. Next on the agenda was the vision system. Initially, I was uncertain about how to create such a system and thought using a cone-shaped object with a trigger would be the best approach. However, I encountered issues with this method, particularly in preventing the detection of the player through walls. Upon realising this flaw, raycasts became an obvious alternative.
​
Despite identifying raycasts as a solution, I was unsure how to implement them for my specific requirements. Thus, I began searching the internet for potential methods and eventually found an effective video tutorial.
FOV Tutorial
This tutorial provided a clear guide to creating the system I needed. By following it, I was able to complete the vision system by Wednesday, only a day behind my planned schedule. This slight delay is acceptable within my overall timeline. In hindsight, more thorough research into creating this mechanic beforehand might have saved time. However, given the project's tight schedule, prioritising immediate production seemed necessary.
NPC Chase Showcase
To further develop the vision system, I began working on a last known position system. This addition introduced some significant challenges. Although I managed to implement and get the system working by Thursday, issues arose with the behaviour tree’s logic. When I integrated the last known position system with the patrol system, the patrol system entirely overrode the last known position system. If I removed the patrol system, the last known position system functioned correctly.
​
I dedicated the whole of Friday to resolving this issue, but by the end of the day, I had made no progress. While I believe I identified the root of the problem, I remain stumped on finding a solution. Despite these challenges, I am proud of the last known position system. Ignoring the conflict with the patrol system, it works beautifully. The NPC seamlessly moves to the location where it last saw the player, creating a very believable sequence of events. If I can get this to function alongside the patrol system, I am confident in the success of this project.
Next week, I will focus on resolving the issue with the last known position and patrol systems. Should I manage to fix this problem, I will proceed according to my Gantt chart, moving on to the implementation of the combat positioning system. I anticipate this to be one of the most challenging systems to implement.
Week 6 - 22/04/24 - Practical
The second week of production, while not particularly productive in terms of the total number of mechanics created, was nevertheless filled with countless hours of scripting. I continued from where I left off with the last known position system. Regrettably, I spent the entire week and the weekend on this single issue. The problem from the previous week persisted: the last known position system and the patrolling system continued to overwrite each other. I attempted multiple solutions to fix this, and I will outline them in chronological order.
​
Initially, I believed the problem was related to the structure of my behaviour tree. My logic was structured as follows: check for the player → if detected, chase the player → if the player is lost, go to the last known position. If the player was never detected, or if the last known position was reached, the NPC should resume patrolling.
I initially thought the issue was due to a lack of a proper check for whether the player had been lost. To address this, I tried incorporating this logic directly within the last known position script. It is worth mentioning that the "lastKnownPosition" was consistently retrieved from the "chasePlayer" script, a strategy that proved valuable.
The issue with my initial implementation was that the logic to check whether the player was not seen would only be executed if the player had been seen previously. If the player was never seen, the logic simply wouldn’t be reached. Through extensive debugging, I realised the "lastKnownPosition" script was always resulting in "NodeState.RUNNING" or "FAILURE". Although I didn’t initially recognise this as the problem, I knew I had to explore other solutions. To address this, I tried placing the logic in a separate script positioned before the "lastKnownPosition" script. This was a step in the right direction, although I didn't realise it immediately and ended up commenting out this node from my tree for most of my testing.
​
While experimenting with these solutions, I encountered another fundamental problem with my implementation. I was attempting to move the player to the last known position by simply setting the destination of the navMesh agent. Although the destination would be set, the player would immediately switch to the patrol script once the destination was achieved. This meant the script didn’t have time to wait until the destination was actually reached. Realising this became my core focus, as it was a fundamental issue with the script rather than with the logic of the behaviour tree.
I felt that using a timer could allow the NPC enough time to reach its destination. However, this approach had significant drawbacks: how would I determine the required duration for each destination? The timer would need to be different for each case, risking either falling short or resulting in the NPC waiting too long at their destination. These were issues I couldn’t effectively resolve with this method, so I ultimately decided against it.
In seeking a solution, I also consulted ChatGPT, but unfortunately, it did not provide a satisfactory answer.
Another possible solution was to detect whether the NPC was still in motion and on its way to the destination. Unsure of how to implement this mechanic myself, I decided to seek assistance from AI chatbots. I continued consulting ChatGPT, which provided a few different methods to help me implement this feature. I tried these methods, but unfortunately, they didn’t work, and I continued facing the same problem.
I was sceptical about this implementation, wondering what would happen if the NPC’s patrol point fell in a similar direction to the last known position. This could confuse the script, resulting in the NPC staying in the last known position script even if it was just heading in a similar direction.
​
Continuing my debugging efforts with AI assistance, I turned to Copilot, Microsoft's AI chatbot, as recommended by my tutor Robert. Despite Copilot’s focus on programming, it struggled to understand my requests and, as a result, did not provide valuable solutions.
At this point, despite being well into the week, progress remained elusive. I contemplated a solution involving creating a point in the scene for the player to reach, serving as the last known position. However, this approach presented a challenge: once the player was directed to this location, they still lacked sufficient time to reach it.
​
Realizing I needed assistance, I humbly sought help from two tutors. The first, Matthew, provided valuable insight into the script's logic, though a solution remained elusive. However, Matthew emphasized the significance of the order of my behaviour tree. With this guidance, I uncovered the current order, which served as a crucial piece of the puzzle leading to my solution.
.png)
It wasn’t solely through my tutors' guidance that I found a solution. I also took the initiative to enhance my understanding of the different nodes within behaviour trees by referring to external resources.
Behaviour Tree Node Explanation - https://www.gamedeveloper.com/programming/behavior-trees-for-ai-how-they-work
Experimenting with various node configurations through trial and error, I placed my lastKnownPosition node within a sequence node. Initially, I believed that placing it within a selector node would yield the desired outcome, but this led to an endless loop due to the failure of the encompassing selector node. I also explored placing the patrol node before and after the lastKnownPosition script, but encountered issues with the script continuously patrolling.
​
However, after numerous attempts, I eventually discovered a working configuration. Seeking further assistance, I consulted another tutor, Joshua, who delved deeper into my script and collaborated on finding a solution. Joshua revisited a previous idea involving creating an object at the last known position, which I initially doubted. His approach entailed integrating this object into the patrol script's patrol point array. Although this solution proved challenging to implement, by the end of Friday, we had devised a viable approach. Implementing this solution would require working over the weekend, but it seemed promising for resolving the issue.
After implementing the solution suggested by Joshua, I encountered initial challenges. Originally, I planned to delete the last known position point within the chasePlayer script. However, this approach prevented the NPC from reaching the point before transitioning to patrolling. To address this, I relocated the deletion process to the lastKnownPosition script. Meanwhile, the creation and updating of the last known position point remained within the chasePlayer script.
​
In adapting my patrol points to accommodate the lastKnownPosition point, I transitioned from using an array to a list. This adjustment was necessary to allow for dynamic resizing and ensure flexibility in adding new points. While the transition to lists was relatively straightforward, I had to refresh my memory on the syntax for working with lists in Unity. I encountered a minor issue where the point was repeatedly added to the list, but this was swiftly resolved by implementing a simple check to verify if it was already present.
At this stage, the NPC successfully navigated to the last known position, but encountered an issue of becoming stuck at that location. To address this, I introduced another script responsible for monitoring the NPC's arrival at the last known position and transitioning them back to patrolling. This role was assumed by the lastKnownPosition script, which underwent modification to facilitate this functionality. Originally, I attempted to incorporate the distance check within the Destroy Patrol Point function. However, this approach posed challenges, particularly if the player's position wasn't known at the time of distance calculation, leading to erroneous failures.
​
Recognizing this limitation, I relocated the distance check to the beginning of the node. Despite this adjustment, I encountered an unexpected problem concerning the positioning of the last known position point. Debug statements revealed that the point was being created at a higher elevation than anticipated, causing discrepancies in distance calculations. After thorough investigation, I identified and resolved the issue by adjusting the distance threshold from "> 0.01f" to "> 0.1f", effectively compensating for the height difference.
​
However, an additional complication arose when attempting to delete the last known position point within the Destroy Patrol Point function. Despite its deletion, the point persisted in the list, resulting in an empty position that disrupted both the list index and the flow of patrol points. To rectify this issue, I implemented a solution to remove the item from the list before deletion, ensuring the proper maintenance of list integrity and script functionality.
Another issue surfaced when encountering a null patrol point, causing the tree to become stuck within the script and preventing the NPC from resuming patrolling. To address this, I incorporated a straightforward else statement that triggered a failure, effectively resolving the problem and allowing the script to proceed as intended.
Achieving success with this mechanic after a prolonged and arduous week brought a sense of euphoria unlike any other. However, despite this triumph, I remain apprehensive about the remaining tasks in my project. What was initially anticipated to be a straightforward feature, slated for completion in just two days, ultimately consumed a staggering 13 days. This significant delay prompts me to consider scaling back my project scope. Nonetheless, in an effort to maintain progress and accomplish as much of my planned objectives as possible, I am committed to dedicating extra time to work on my project during my days off and over the weekend.
NPC Last Known Position Showcase
I received valuable feedback from a peer (Tegan) on the current state of my AI, which proved instrumental in ensuring the believability of the NPCs. My peer suggested that it would enhance realism if the NPC waited at the last known position for a few seconds. Although this feature wasn't implemented during their review, it was slated as my next task. Additionally, they noted that the NPC's field of view (FOV) seemed too restricted, though this adjustment was made temporarily to aid in debugging the lastKnownPosition functionality.
​
All this feedback was based from a mere video, however, when my peer tested the game firsthand, they encountered additional issues. They found it possible to evade detection by standing directly behind the NPC or circling around them. While I plan to address this with a sound system, time constraints raise concerns about its timely completion. It's worth noting that once the NPC investigates the last known position by rotating left and right, circumventing detection by circling should no longer be viable. Another issue involved the player's jump height, which caused the lastKnownPosition point to be misplaced in mid-air upon detection. To remedy this, I may consider disabling player jumping, although I'll explore the possibility of disregarding the y-axis when checking distance if time permits.
​
In addition to practical feedback, my assigned tutor, Robert, reviewed all my written documents. While he commended the quality of my proposal and reflective process, he identified shortcomings in my theoretical research and planning. To enhance clarity, he suggested incorporating more visuals and delving deeper into theoretical research on why certain features contribute to NPC realism and how I can achieve this in my project. He also recommended employing picture-based methods such as mood boards and SWOT analyses. While these suggestions are valuable, I intend to prioritize refining my practical product in the upcoming week before addressing these gaps.
Week 7 - 29/04/24 - Practical
1/05/24
Riding the euphoria from last week's success, I commenced this week with determination.
​
On Monday, I resumed work on implementing the investigation behavior for the NPCs. However, achieving smooth rotation proved more challenging than anticipated, leading to some initial struggles.
Facing this hurdle, I decided to pivot to a seemingly simpler task: the cover system. My initial approach involved modifying the existing FOV script to detect objects tagged as "cover." Unfortunately, I soon discovered that this approach was not feasible, necessitating the development of an entirely new method for object detection. While there are numerous tutorials available for creating such a system from scratch, they are lengthy and involve significant time investment.
NPC Cover System Tutorial
Despite theorising many potential solutions, such as utilizing colliders or pre-storing cover object data and casting rays from the NPC to determine proximity, I recognized that these methods would consume valuable time already constrained by deadlines.
​
Realizing the impact of time lost last week, I acknowledged the need to recalibrate my project schedule. Recognizing the urgency, I planned to revise my Gantt chart to accommodate the new time constraints. Although I intended to complete this task during lesson time, I realized that my previous Gantt chart, which I intended to modify, was created at home. Consequently, I deferred this task until I could access the necessary resources at home. Upon returning home, I promptly revised the Gantt chart to reflect the updated timeline.
The restructuring of my project schedule prioritizes smaller, more manageable tasks, such as implementing the hearing system, over more complex mechanics like the cover system and combat positioning. While these latter mechanics would enhance the sophistication of the AI, their complexity poses challenges given the limited time available for practical work. With only four days remaining before the conclusion of practical tasks, focusing on smaller features is the pragmatic choice. Although I aspire to progress to the cover system after completing the hearing system, I am cautious about overestimating what can be achieved within the allotted time frame.
​
While the project has been scaled back, I aim to demonstrate an advanced AI that exhibits logical responses to stimuli. The actions currently implemented and planned align with this objective and are logically grounded. Although the exclusion of certain features may limit the AI's complexity, I remain optimistic that it will not compromise the NPCs' logical decision-making processes. Reflecting on received feedback, while I initially intended to implement the investigation feature, time and knowledge constraints make its feasibility uncertain. As a result, the hearing system will be the next focus of development.
​
Upon reflection, I realize a shortcoming in my initial research and planning efforts. While I devoted significant time to exploring various methods and examples of advanced AI, I neglected to adequately research how to actually implement the planned features. This oversight was compounded by time constraints and increasing stress as the deadline approached. In hindsight, allowing more time for research and planning before commencing production may have preempted some of the challenges encountered during development.
03/05/24
By Friday, I successfully completed the sound/hearing system for my NPC. However, achieving this milestone was not without its challenges. Initially, my approach to implementing this mechanic mirrored the structure of my last known position script.
Upon closer examination, I identified a flaw in this approach. The current formula relies on the creation of a patrol point, but it poses a problem for this specific task. The NPC can only proceed to the patrol node if no other nodes are active, necessitating that the variable "heardSomethingCheck" be false. However, if this variable is indeed false, the "taskHearSomethingCheck" node is skipped entirely, resulting in the NPC solely patrolling without addressing the source of the sound or being able to remove it from consideration.
​
Realizing this limitation, I revisited my previous scripts and recognized that the logic required for this task closely resembled that of the "taskEnemyDetection" script - and how it required heardSomethingCheck to be true. Drawing inspiration from this, I decided to adopt a similar approach, akin to the structure of the "taskChasePlayer" script. Implementing this adjustment yielded the following solution:
(EnemyBT script went unchanged)
Indeed, the revised scripts demonstrate a streamlined approach, focusing directly on the task at hand. It seems that I had been unnecessarily complicating the issue for myself. With this adjustment in place and thoroughly tested, I proceeded to address the next, albeit shorter, challenge: devising a method to prompt the player to produce these sounds.
The solution I ultimately arrived at for producing footfall sound effects involved checking the player's movement and instantiating the corresponding sound effect accordingly. Initially, I explored various approaches, considering options such as checking the player's speed. However, I soon realized the limitations of this method due to how speed is stored. Fortunately, I devised a more effective solution by leveraging the base input checks. This script efficiently generates footfall sounds and ensures their spatial accuracy at the player's feet. When integrated with the NPC's sound checks, this mechanism enables them to react to the player's movements by heading towards the sound source.
This implementation addresses one of the criticisms raised by my peer regarding the player's ability to evade detection by standing directly behind the NPC. While I acknowledge that some criticisms remain unresolved, I believe the mechanics I have developed uphold a standard of quality and align with the objectives of my project. Collectively, these mechanics exemplify the sophistication of advanced NPCs in games, capturing elements of human-like behaviour.
NPC Final Showcase
Despite the disparity between my progress and the initial plan outlined, I have taken proactive steps to adjust my timeline to ensure the delivery of a valuable outcome. Instead of fixating on incomplete features, my focus for the upcoming week will be directed towards addressing weaknesses identified within my current documentation. While my planning originally designated this period for transitioning to the final evaluation phase, I had anticipated allocating additional time for catching up due to the accelerated pace of progress. Once I have addressed all outstanding tasks, I will seamlessly transition into the evaluation phase as originally intended.
Week 8 - 06/05/24 - Planning & Complete Practical Evaluation
Dedicating this week entirely to reflection and evaluation, I embarked on addressing feedback received during week six. Initially, I revisited my research to fill in any perceived gaps, particularly in theoretical exploration. While I had initially believed my research to be comprehensive, feedback from my tutor suggested otherwise. Consequently, I revisited my existing research materials, augmenting them with additional explanations and examples of human-like behaviour manifested in advanced AI examples. While I believe this augmentation should suffice for theoretical research, I intend to seek validation from my tutor during our next interaction. Should further exploration be deemed necessary, I plan to delve into real-life examples, such as military footage, to enhance my understanding.
​
Following this, I proceeded to update my planning documents. Reflecting on feedback provided by my assigned tutor, I identified a need for a SWOT analysis and a moodboard. To facilitate this task, I discovered Canva, a versatile and free software tool equipped with prebuilt formats suitable for creating a SWOT analysisies and moodboards.
As demonstrated in the provided infographic, I have meticulously outlined the strengths, weaknesses, opportunities, and threats relevant to my project. While I acknowledge that the infographic may appear somewhat sparse due to the abundance of white space, I have ensured that all pertinent information has been included. For the presentation on my website, I am considering adjusting the bar size to optimize visual appeal as well as removing colour - to better align with my preferred style.
​
Subsequently, I proceeded to create the moodboard. Historically, I have encountered challenges in formatting and presenting moodboards, and this project presented an even greater hurdle due to the complexity of the content I needed to convey. Attempting to encapsulate NPC interactions within a single photo proved daunting, as there are limited images available depicting such actions. Consequently, I opted to utilize the game logos from the titles featuring advanced AI, accompanied by explanatory text. This approach effectively communicates the essence of the moodboard despite the absence of specific images of NPC actions.
Indeed, my moodboard intentionally features significant whitespace to facilitate clear associations between each block of text and its corresponding image. Despite receiving feedback from a peer, Tegan, who noted that the spacious layout deviates from the typical appearance of a moodboard, I believe its effectiveness in aiding comprehension outweighs any stylistic considerations. Tegan's observation likening it to a motherboard, albeit unintentional, intriguingly aligns with the essence of my project.
​
Now that I have addressed any outstanding tasks and brought my documentation up to date, I am prepared to commence my comprehensive practical evaluation. Beginning with an analysis of the first week and proceeding chronologically through to the final week, I will provide insights into each stage of the project. Ultimately, upon reaching the conclusion of this evaluation, I will offer my overall assessment of the project's success and effectiveness.
Weekly Analysis
Week 1
In my first week, I made substantial progress by implementing several key features. Beginning with pathfinding, I found this task straightforward due to thorough prior research. I opted not to prototype this mechanic independently, confident in its success based on my preparation. Moving on to the behaviour tree, I relied on tutorials sourced during my research phase, ensuring a smooth implementation despite occasional confusion with the logic. With pathfinding established and the behaviour tree functioning, I proceeded to implement NPC behaviours. However, the absence of logic to detect destinations rendered this initial movement futile. Introducing patrol points posed no significant challenge, allowing me to advance to more complex features, such as NPC vision.
​
My initial approach to NPC vision, involving a cone-shaped object with a trigger, encountered a significant obstacle: the cone's inability to detect obstacles, potentially allowing NPCs to see through walls. To address this, I turned to Unity's raycast feature, leveraging a tutorial to seamlessly integrate vision detection with player detection and pathfinding, enabling effective NPC pursuit. Despite encountering challenges when implementing the last known position system, primarily stemming from a nuanced understanding of behaviour tree logic, I managed to isolate and test this node successfully by temporarily removing conflicting elements.
​
Throughout this week, I remained confident and enthusiastic, buoyed by the culmination of seven weeks of intensive research and planning. Each mechanic I introduced was tailored to address my core inquiry: "How can I create believable hostile NPCs, which respond appropriately to a given situation?" By simulating player interactions and NPC responses, I established a dynamic framework wherein NPCs pursue players upon detection and revert to patrolling upon losing sight. Although the AI's complexity may seem limited, it nevertheless delivers appropriate responses to variable scenarios. Despite encountering setbacks with the last known position system, my overall enthusiasm remained undiminished, fueled by the successes achieved during this productive week.
NPC Detection & Chase Showcase
Week 2
This week unfolded amidst persistent challenges stemming from unresolved issues from the previous week. Originally designated for combat positioning and the cover system, the entirety of the week was consumed by addressing lingering issues with the last known position system. Despite the considerable time investment, resolving this problem was deemed crucial to the project's overall success, even if it meant sacrificing other planned features.
​
Reflecting on the origins of this setback, I discerned how it could have been preempted and potentially avoided. Had I conducted thorough research on creating this mechanic before its implementation phase, I might have arrived at a working solution prior to encountering the hurdle. However, the constraint of a tight timeline posed a dilemma: by the time I was ready to commence feature implementation research, I was also scheduled to begin the creation process. Thus, I opted to allocate all available production time to actual development, rather than dedicating more time to research.
​
In hindsight, the crux of the issue lay in the allocation of research time. A significant portion of the twelve-week project timeline was spent researching NPC logic creation—nearly one-third of the total duration. This approach, while intended to ensure a comprehensive understanding of AI principles, resulted in an overemphasis on holistic logic creation rather than individual mechanics. Consequently, half of the research conducted became redundant post-decision-making.
​
To address the challenge once it emerged, enlisting the timely assistance of my tutor, Joshua, could have expedited problem resolution and potentially enabled the addition of more features. However, personal inclinations towards independent problem-solving and the desire for solitary project ownership delayed this decision. As time elapsed and dead ends persisted, seeking Joshua's guidance became an inevitable necessity, ultimately leading to a breakthrough.
​
While this week tested my resolve with its relentless pursuit of solutions, the eventual resolution of these challenges served as a revitalizing force, reigniting my enthusiasm for the final week of production.
NPC Last Known Position Showcase
Week 3
Despite my high spirits, the final week of production was not devoid of challenges. I persisted in refining the last known position system, particularly focusing on enabling the NPC to investigate once it reached the designated position. However, difficulties arose in rotating the enemy character, and as the pressure to conclude production intensified, I redirected my efforts towards developing a more substantial feature.
​
Initially, I attempted to tackle the cover detection system, leveraging the pre-existing FOV mechanic designed for player detection. However, this approach proved too intricate, and despite diligent efforts, a viable solution eluded me. Consequently, I narrowed my focus to implementing the hearing system, despite initial doubts about its feasibility. Surmounting various hurdles along the way, I ultimately succeeded in overcoming the challenges and completing the mechanic by the end of the week.
​
The journey towards implementing the hearing system was fraught with trials and tribulations, mirroring the struggles encountered during the previous week with the last known position system. Initially, I attempted to adapt a similar approach used for the last known position system, which only compounded the challenges. However, upon heeding advice to step back and re-evaluate the problem, I managed to identify a solution. This marked a pivotal moment in the project, as I embraced a more strategic problem-solving approach, which proved effective in overcoming obstacles.
​
Despite the time constraints limiting the implementation of additional features, completing the hearing system represented a significant milestone, elevating the NPC's realism and enhancing its ability to respond appropriately to various situations. With the implementation of the hearing system, the player's ability to evade detection by simply staying out of the NPC's line of sight or hiding behind obstacles was effectively curtailed. In hindsight, prioritizing the completion of this feature over others was a prudent decision, aligning with the project's overarching goal of creating believable hostile NPCs.
NPC Final Showcase
Conclusion
Having thoroughly reviewed all aspects of my project, both the achievements and the unfulfilled aspirations, I can now assess its overall success.
​
Firstly, it's essential to acknowledge the notable features that were not implemented due to time constraints. These include mechanics such as NPC-NPC interaction, enemies reacting to low health or solitude, and hierarchical enemy responses akin to those observed in games like Halo 2. While the absence of these mechanics may appear to detract from the project's comprehensiveness, their inclusion would have undoubtedly enhanced the depth and personality of the NPCs. However, given the prioritization of combat-related features and the solo nature of the project, their omission was ultimately deemed acceptable, albeit regrettable.
​
Turning to the accomplishments, I can confidently list the implemented mechanics in chronological order: pathfinding, vision system, player detection and chasing, last known position, and the hearing system. Each of these mechanics contributes significantly to the NPC's realism and responsiveness, aligning closely with the project's overarching goal.
​
The pathfinding system stands out as particularly vital, as it forms the foundation for the NPC's navigational abilities. Despite its simplicity, it effectively enables the NPC to traverse the game environment logically, representing a crucial aspect of believable NPC behaviour. While there is room for improvement, such as introducing occasional navigational errors, the system currently functions effectively in achieving its intended purpose.
​
Similarly, the vision system successfully simulates realistic sight capabilities for the NPC, accounting for obstacles and employing a field of view comparable to that of a human eye. This attention to detail, informed by thorough research, peer feedback and trial-and-error, ensures that the NPC's vision behaves logically and contributes significantly to its believability.
The player detection and chasing mechanics seamlessly integrate with the pathfinding system, allowing the NPC to pursue the player effectively upon detection. While additional combat-related behaviours, such as attacking or combat positioning, were initially planned, the implemented chase mechanic adequately fulfills the project's requirements, given the time constraints.
​
The last known position system emerges as a standout achievement, overcoming significant implementation challenges to provide the NPC with a logical response to losing sight of the player. Without this mechanic, the NPC's behaviour would lack depth and realism, highlighting its critical role in enhancing the overall quality of the project.
​
Lastly, the hearing system, though initially underestimated in importance, proved to be a valuable addition, addressing a crucial gameplay issue identified through peer feedback. Its implementation significantly enhances the NPC's environmental awareness and adds depth to its interactions, further solidifying its believability. If it wasn't for the narrowing deadline, and this mechanic's smaller size this mechanic would've likely went unimplemented. And that would've been most regrettable.
​
In conclusion, while certain planned mechanics remained unrealized, the implemented features collectively contribute to the project's success in achieving its goal of creating believable hostile NPCs. Each mechanic demonstrates thoughtful consideration, informed decision-making, and a commitment to realism, ultimately resulting in a project of considerable quality and merit.
Reflection
Reflecting on my evaluation of the practical work completed, I do have one concern; regarding potential repetition in certain areas. However, I maintain confidence in the overall quality of the content presented, notwithstanding any instances of repetition. Each aspect was addressed comprehensively, ensuring a thorough evaluation of the achieved outcomes. Despite potential repetition, I believe all essential points were effectively covered, demonstrating clarity and coherence in the analysis. To enhance the presentation further, I am considering incorporating edited videos to complement the evaluation, providing visual aids to illustrate key points and concepts.
Week 9 13/05/24 - Presentation
This week was solely dedicated to presentation, involving the organisation of my collective documents and placing them onto my website. Initially, I assumed this would be a rather quick task. Although I allocated a week for this, I did not expect it to actually take that long.
​
Before placing my documents onto the website, I decided to create a simple showcase page. This page was dedicated to presenting my final product and included a brief introduction. This task was straightforward, likely due to my experience with a similar project last year. I already had the video saved, so uploading it was easy. Ideally, I would like to enhance this video and others with editing, which would significantly improve the aesthetics of my site.
To create this site, I used one of the formats provided by Wix and then edited it to suit my preferred layout. This approach was chosen to save time and due to my history of poor design choices. With the layout already provided, I began placing my information in, starting with the proposal. To ensure quality and accuracy, I meticulously checked each section word by word. Additionally, I enlisted the help of ChatGPT. Aware of its potential drawbacks, such as fabricating information or making mistakes, I thoroughly compared its output to my original work to ensure it contained all I wanted and was simply improved.
​
One area I couldn't check with ChatGPT was my sources. I struggled with how to present these on my website. Ultimately, I decided to list them, ensuring there was enough spacing to differentiate each source. Next was the timeline, which presented a similar challenge. Wix doesn’t include a table function, so to present my timeline, which was created in a table format, I had to research the best solutions. I eventually found a plug-in called Table Master, which allowed the creation of tables. It took quite a while to manually input each timeline cell into the table, but I eventually completed this task.
(Original Timeline)
(New Timeline)
However, there was a key problem with my timeline in its new format: it didn't allow for paragraphs, causing all text to blur together. While the information remained the same, the aesthetic quality suffered somewhat. Despite this issue, I am confident in the quality of my work and pleased that the process was relatively straightforward.
Next, I started work on my research and planning sections. This process involved manually checking each part, supplemented by the assistance of ChatGPT. Consequently, this phase was relatively easy and quick. The only notable difference was in handling the inclusion of sources and their presentation. This involved incorporating a significant number of images, such as screenshots of code or planning documents, that needed to be included.
​
Ensuring that these images were well-integrated and clearly referenced required additional attention. Despite these minor complexities, I managed to maintain a consistent quality across the sections, presenting my research and planning comprehensively and effectively.
Typical Halo 2 behaviour tree, demonstrating their ease to read and program.
I believe the way I chose to display my sources effectively presents their contents, ensuring all necessary information is clearly shown. The borders around each source effectively link them together under a cohesive aesthetic. However, there is an issue with some images appearing blurry, which is unfortunately unavoidable as they were sourced from a YouTube video. Despite this, the overall presentation remains clear and informative.
Halo 2 NPC Analysis
As mentioned earlier, I found a site that allows for a clean presentation of code. This has significantly enhanced the clarity and professionalism of my project's documentation.
This has been used for all code within my research, necessitating occasional rescreenshots to maintain this quality.
For some aspects of my research, I did some restructuring. I determined it was best to consolidate my explanations of FSMs and behaviour trees with my collective research into these topics, rather than where they were first introduced: my Half-Life and Halo 2 research, respectively. I believe my research is of high quality and presented in a refined manner.
​
With my research concluded, I began work on planning. As my planning section was shorter, it mainly involved adding images: SWOT analysis, mood board, and Gantt charts. My only concern with the planning section is the presentation of my SWOT analysis, which appears quite colourful compared to my otherwise monochromatic website. If time allows, I may attempt to adjust this; however, I currently prioritise more pressing matters. Despite this, my planning is effectively presented, clearly conveying my intentions. Feedback from a peer (Tegan) confirmed the effectiveness of my planning and research presentation.
​
Following this, I moved on to the most arduous task, the reflective log. The challenge stemmed from the extensive amount of writing that required meticulous checking. Additionally, I needed to insert screenshots of my code. My assigned tutor (Robert) advised me to add comments to my code, which required going through all screenshots and annotating them. This involved rewriting certain scripts I no longer had access to, consuming my entire weekend. However, I am pleased with the final appearance. One minor concern is the inconsistency in comment formatting, but addressing this would be excessively time-consuming. Therefore, I believe it is best to overlook this, as the information remains clearly conveyed.
​
The remaining tasks for my website include adding more in-depth descriptions to my scripts and creating edited videos to better showcase my product. However, I am concerned about the time required for these tasks given the impending deadline. Additionally, I lack experience in video editing, which further complicates the matter. Both of these additions were recommended by my assigned tutor, so I feel it is important to attempt incorporating them.
Week 10 - 20/05/24 - Final Evaluation
My tenth and final week of this project was dedicated to my final evaluation. Although this evaluation consumed the entire week, as outlined in my Gantt chart, I had initially anticipated it would only take a couple of days. This would have allowed me ample time to review my project one last time or catch up in areas that were lacking. Regrettably, this was not the case.
​
Nonetheless, I am impressed with the quality of the evaluation I conducted. I believe I addressed all pertinent areas, providing thorough opinions on my project's success, explaining my decision-making process, and outlining what I would change if given the opportunity to undertake this project again.
​
Some of the areas I would have liked to have addressed include adding detailed descriptions to all my scripts, creating edited videos to better showcase my work, and completing a questionnaire to gather feedback. Unfortunately, the limited time available did not permit these tasks. However, I did manage to put together an itch.io page to download my project. This was done to showcase my project to the evaluators, and I believe it was a worthy decision.