Project Evaluation

As my project is finishing this week I've decided to go back over all the work I have done on the project to evaluate myself looking at what I have done and what I would have done differently knowing how the project turned out. I think this is an important to do to help me improve in the future.


What did I want to achieve?

When starting this project I wanted to create an artificial character inside of the Unity3D game engine using the JavaScript programming language. The AI was meant to be able to react to see the player if you moved into its line of site as well as hearing footsteps made by the player. Once detected the AI would begin to path towards the player. The code should be kept neatly with key elements commented and be efficient where possible so that anyone viewing the code would be able to know what is going on.



What changed with my project?

Over the course of my project not too much had changed from what I originally planned to do. The biggest things that I changed on my project was that instead of using JavaScript to program the AI I changed to using C#. I did this after having a meeting with Chris and we spoke about how my project will look from an employers perspective. He mentioned that a lot of employers would rather see my ability to program in C# and that it would greatly benefit my project to change languages. The only other things that I did change was that I added additional work to my project as I was ahead of my milestones. I decided to create the attacking mechanics for the AI and creating my own pathfinding algorithm. I created my own pathfinding algorithm after having a meeting with Chris and we discussed how showing that I have an understanding of algorithms like A* will have a positive effect on my portfolio. The attacking mechanics that I planned to add changed how they worked quite a bit throughout the project as porting my project to C# and creating my algorithm took up the time that I initially planned on working on the attacking mechanics.



What went well?

The main thing that I think we well on my project was that I worked consistently on it every week (Except from the 2 weeks over Christmas break). Putting this much time into the project meant that not only did I achieve everything that I originally planned to do but I was also able to create new features that I had not planned to do. I think that if I had done less work on my project it would have had a big impact on the quality of my work as well. Another thing that I liked about my project was that it gave me a good opportunity to show my programming ability as well as learn new techniques which I will be able to use on different projects that I work on after University.



What didn't go well?

I think the biggest problem with my project was that I had under-scoped what I was going to do. This was because when I originally created my project proposal I had never created an AI character like this for a game. As I was also using a lot of new skills and techniques I didn't think I would learn them as quickly as I did and surprised myself with what I could do. If I was to start my project again I would defiantly push myself more at the start to learn even more advanced tools (For example using a more advanced state machine) as I think that if I put the time into learning these harder tools I would be able to.


Summary
Overall I think my project went really well and I am happy with the final product that I have created. I will be looking to take this AI character that I have created and will be using it in projects that I plan on doing once I finish University. I think the final product shows my ability to program as well as working in an efficient and tidy manager which is something that I had originally set out to do.

Final bug fixing

For this weeks work I went though the feedback that I received from my play testing last week and tried to improve and fix as many of the problems that was mentioned by my play testers.

The fixes that I made were:

• The AI can now wait before transitioning between waypoints.
• Player no longer colliders with the AIs ragdoll body.
• Recreated the test scenes and added a menu. This allows for easier testing of the AI.
• Added controls to the menu.
• Player is now able to crouch when pushing left control. This makes no noise and allows them to sneak up very close to the AI.
• Hearing is now less sensitive so you need to be closer to alert the AI.
• AI raycast for sight has been adjusted. Previously it aimed down slightly. This meant the AI was unable to see the player when it should be in sight.
• AI loses alert status quicker.
• Fixed another bug with the AI sight. AIs position variable wasn't setting correctly causing the raycast to sometimes shoot from several meters below the AI.
• Changed AI viewcone sizes. (Previously was a bit too small).

All of these adjustments have been made to further polish the AIs mechanics and to create a better experience when playing in a scene with it. Something that I have tried to keep in mind this week was something a play tester said about how would to AI feel if it was to be used in an actual game. This is something I originally mentioned when I started this project was that I would like to be to use the AI in a game if I wanted.

After doing all of these adjustments I have gone back over my code making sure that it is as efficient as I can make it, my code has been commented and is easy to read. This was one of the main reasons that I decided to undertake AI as my project as I wanted to show to a potential employer that I can work in a neat and efficient manor.

Something that I have tried to fix but was unable to get working was having the AI rotate faster. The AI currently can be led round in a circle with it unable to turn as quick as the player. I tired increasing the speed on the navMeshAgent component however this did not fix it. I have looked through the code as well but was unable to find anything that is effecting this.

My next blog post will most likely be my final blog post on this project. I will be evaluating my project looking at what I have created, what I think went well, what I think could have been improved and discussing the changes that I made throughout the course of my project. I think that it is import for me to evaluate myself like this to help find areas that I can improve on when working on other projects.

I have uploaded the last changes to my GitHub page which can be found here: https://github.com/ABurton96/GameAI

Playtesting

For this weeks work I looked at getting external feedback on my project to help me find any problems and improvements that I can make before the end of my project. I got these play testers to try out my the test scene that I created last week.

From my play testers the feedback I received was:

• AI reacted too quickly when they see me. Short delay would be better.
• You collide with the ragdoll body when its on the floor.
• Smaller test scenes would be nicer to show off how the AI works. e.g. One AI facing away showing how the hearing works.
• AI turns too slowly.
• A* algorithm works well. When running at an angle you can see the AI stutter when moving between the centre of nodes. 
• The AI is very responsive and can be hard to sneak by at times. 
• How would the AI work in a complete game? AI is very difficult to lose if it finds you.
• No ability to crouch with player. As you always make noise you can't get behind the AI.
• No way to add a delay when transitioning between waypoints.
• Sight doesn't take into count scene lighting.

After reading all this feedback I will spend my final week working on fixing and improving some of the things mentioned above. I will be changing the AIs turning speed, creating different test scenes, removing collision with AI ragdoll, adding ability to delay when moving between waypoints and will also look into trying to make the AI react a little slower than he currently does.

After getting play testing I think this has been important to improving my AI and making the AI as good as I can. This is something that I wish I was able to do earlier as it wold have given me more time to improve more mechanics and would have allowed for me to gain even more feedback.

Polish and preparing for play testing

For this weeks work I looked at polishing some of the AI's mechanics and building a scene so that I can gain feedback on the AI from play testers.

I started by changing how the ragdoll system works when the AI is killed. Previously the AI had all the ragdoll elements on the different body parts while also having all the other AI scripts and animations on the same game objects. This system was causing a few problems where when the AI died he would be thrown backwards and up into the sky. I changed this so that the ragdoll elements were on a different game object and are instantiated when the AI runs out of health. This system looks and works much better than the previous system while not causing any problems performance wise.

Next I added a small health bar to the top of the AIs head so you are able to tell how much health it has. After adding this I noticed that some attacks were unintentionally doing extra damage. After a little bit of bug testing I realised that this was being caused by the different colliders that were on the AI's different game objects that were previously being used by the ragdoll. Removing these fixed this problem.

After this I then added the ability to "back stab" the AI. This means that stabbing the AI in the back will instantly kill them whereas hitting them in the front will only damage them. I also added a very basic death screen to the player. I have done this to help when I give the project out to play testers so they could restart the scene if they die.

Finally I built a scene that I am going to be sending out to play testers next week. I have tried to create a scene that shows off all the different things the AI can do while also giving the player a bit of choice as to how they want to go about killing/moving past the AI characters.

From now on I will no longer be working on my A* algorithm and will just be using Unity's navMesh. This is because my algorithm has a lot less functionality than Unity's and it will take a lot of time for my algorithm to get to the standard of Unity's. I am happy that I have put the time I have into creating the algorithm as I feel that I have learned a lot from it.

Next week I will be collecting all the information from the play testers and seeing what problems and improvements are suggested. As I only have a couple of weeks left on the project I will be looking at what small problems I can fix and improving the AI where I can before handing my project in.

Re-adding attacking mechanics and small bug fixes

For this weeks work I looked at re-doing the attacking system for the AI and I also had a little look at changing the way nodes are handled to make my pathfinding algorithm more efficient.

I started by looking at changing the nodes so that the script only generates one set of nodes per scene compared to a set of nodes per AI which is what currently happens. After spending around an hour working on this I realised that this was going to take quite a bit of work to change how things are handled and that it was not worth my time to continue changing it. This was because I feel that it was more important to finish other key features as I only have a few weeks left of the project.

After working on the algorithm I then went onto working on the AIs attack. I started by creating a basic attacking animation using a sword model that I found online (mmarti, 2002) and created attacking animations for the AI and player. I added a basic combat and health system so that both could take damage. Something that I realised after testing was that nothing happened when either the AI or player ran out of health. For the AI I have set the the AI so that it enables a ragdoll effect. By using a ragdoll character instead of creating a death animation would allow me to add specific forces to each part of the body when attacked. This gives the effect that the AI has actually taken damage in the specific parts of the body. I have yet to add anything for the player dying however I will likely just have the scene restart as my main focus is on the AI.

After I had done the attacking mechanics and was testing them in the scene I noticed a strange bug where the AI would only attack once and would just stand in front of the player. After a few seconds the AI would then begin to run in circles around the player and then after several more seconds it would go back to its patrolling state. I found that this was being caused by how I was calling the AIs attacking function and has now been fixed.

Next week I will be adding the final touches to the AIs attacking mechanics and doing some further play testing. I will be trying the AI in several more advanced scenes and will be putting together a scene so that I can get external play-testers to try the AI out and gain feedback from them. This should give me time to make any final adjustments to the AI ready for the end of my project.


References
mmarti (2002) Sword Model. Available at: https://www.turbosquid.com/3d-models/medieval-sword-3d-model/168366. Accessed on: 12-04-2017.

Testing AI

For this weeks work I looked at testing my AI in more advanced scenes to see how it managed with pathing and reacting to the player in these more complex scenes. I started by creating a scene with a maze along with stairs at different heights. The AI managed to path between all the objects and handle the different heights fine. Having moved the sight raycast from feet height to eyeline has greatly improved the AIs sight. I decided to remove the code that handle the AIs attack for now. This was because it was causing a few problems and was making it hard for me to test some of the other AIs features. I've changed it so that the AI will now run and stand next to the player instead of attempting to shoot him. I may look at adding the ability to attack back depending on time over the next few weeks.

After I had tested the scene I then tried adding multiple different AI into the scene to see how they work together and how it impacts performance. The AI worked well together however something that I overlooked when creating my A* algorithm is that the node grid is generated in the same script that generates the path. This means that each AI needs the script attached to it so a node grid is being generated for each AI in the scene. Although this didn't cause too many performance issues with only a handful of AI this is still something I want to change as I do want the AI to be as efficient as I can make it.

Next week I will look into changing my algorithm so that it is more efficient with multiple AI in the scene. I will also be doing additional playtesting to see if I can find any other problems with my code. Depending on how long these previous tasks take I might look at redoing the AIs attacking mechanics.

More A* Adjustments

For this weeks work I looked at making some small adjustments to my path-finding algorithm. The things I looked at changing were adding the ability for me to check how long the AI path is, fixing node generation around raised platforms, fixing raycast height for AI sight and looking into the AI running awkwardly between nodes when moving.

 I started by adding the ability to check the path distance. This allows me to use my algorithm to calculate the sound for the AI as previously I was still using Unity's navMesh to calculate this. After changing this I then fixed the bug where some nodes generate strangely around raised platforms. This was causing a few problems where the AI would try to take a path that it couldn't reach so would get stuck. Next I looked at changing the movement between nodes. I started by looking at changing how the AI rotates when moving. Doing this helped when moving where there were no obstacles around the AI however when needing to path up stairs or around and object the AI would get stuck then glitch through walls. I changed this back to the previous system and will look at fixing this again later. Finally I looked at fixing the height the AI sight raycast was being shot from. Previously it was from the AIs feet and when moving it up to eye level I either got errors or the raycast wouldn't hit the player. After a little bit of bug testing I noticed that the raycast was being shot at a slight angle upwards causing it to go over the player. This has now been fixed so the AI will see from eye level.

Next week I will be bug testing all components of the AI and will be testing the AI out in different situations to see how it can handle them. Some example of things I will be trying are adding multiple AI to the scene and more advanced scene layouts with multiple different heights and complex mazes.

A * improvements

For this weeks work I looked into improving my A* path-finding algorithm. I did this by adding the ability for the algorithm to generate nodes on different Y values so that the AI could path on stairs and platforms at different heights. I also looked into getting the AI to rotate towards where he is walking.

When working on changing on how the nodes generate the first thing I had to look at was how I was going to generate the nodes without adding too much of an impact on the performance of the algorithm. The next thing I did when adding the nodes was set the code to only check nodes that are possible for the AI to get to. This was to stop the AI trying to move to a node that is floating in the scene without a platform below it and stops unnecessary calculations being made. I got this working by checking the location around the node when it is generated to see if it is colliding with it an object. If the node is touching an object it then looks at if that object is possible to be walked on. After implementing this system the AI was still unable to path up or down stairs due to how the nodes were being generated on them. This was being caused by the algorithm picking nodes generated inside the stairs that it couldn't reach. I had a look online and in several books however I couldn't find anything mentioning how I could handle this. I eventually fixed this by adding a unique tag to stair objects so nodes that were touching the stairs had additional checks before they are set active. Once a stair is found it checks the nodes above to see if it is also generating within a step. If the node is touching a stair then the node is disabled as the current node is inside the stairs and if the node above isn't touching the stairs then it should be at the top of a step. After testing this the AI managed to manoeuvre around my scene without having any problems on the stairs/obstacles placed in it.

Next I looked at changing the rotation of the AI. After getting the AIs rotation to translate towards the player the AI worked fine with only a few small problems. These problems happened when walking up stairs and trying to move to nodes at different Y values. I tried stopping the AI from rotating on its Y axis however it continued to do this.

For next week I will be looking to improve the AIs movement so it walks in a smoother path when transitioning between nodes. I will be doing research into some different approaches that I could handle this and deciding on the best approach. I will also look into fixing the bug mentioned earlier with the AI rotating when walking up and down stairs.

Adding A* to AI and meeting

For this weeks work I started by adding in my A* algorithm in place of the Unity navMesh on the AI script. I did this so I could test and see how well it works and see what changes I would need to make to get it to a usable state. After implementing the algorithm there were a few key things that I noticed that I needed to implement. These were the ability to move up/down stairs, generate nodes at different heights, rotate the AI to face where its walking and to smooth the path the AI takes when walking to each node. These are some additions that would greatly improve my algorithm.

After adding my algorithm to the AI script I decided to quickly tidy up the code for the AIs attacking mechanics. I decided to do this as it was half finished and was causing me a few small problems when working on the AI script. The code for this doesn't work perfectly but no longer causes me any problems when working on anything else now. I may come back at a later date to see what additional improvements I can make to this however it is not a priority.

After planning what I wanted to add I had a meeting with Chris to discuss my project. I had this meeting to decided if it was worth making these changes to my algorithm as even with these changes it is likely that Unity's built in navMesh will still be better than my version. We decided that I should continue to work on it and after making the small changes that I mentioned previously compare the two again. Even if the changes do not improve it to a stage that is as good as Unity's navMesh I will have a lot more experience and work to add to my CV. This is important as this was a key reason as to why I decided to do this project in the first place. We also discussed a few different ways that I could go about implementing these changes.

For next week I will be researching into how I can make the algorithm work for stairs, platforms at a different heights, having the AI rotate towards where it is walking and to smooth the path that the AI walks across. Once I have researched this I will begin adding these changes into my project.

More A*

For this weeks work I continued to work on my A* path-finding algorithm. I started by reviewing my work from last week to make sure I understood where I was and what I needed to do next. For this week I needed to have the algorithm check what the quickest path was and then have the AI element move across that path. When I began adding the code to check the path I realised that how I was handling the nodes didn't actually work due to the amount of information each node needed to store. I though about different ways I could handle this but couldn't think of any good way of handling this that wouldn't cause me more problems later. After having a look at some resource materials I went back to a YouTube tutorial I looked at when starting my algorithm showing a way to program your own version of A* inside of Unity (Lague, S. 2014). After watching the first 3 videos in this series I noticed the mistake I was making was that I could be storing all the information in a class and then store that into an array. Watching these videos helped give me a much better understanding on what I needed to do next and how I could go about handling it. I went on to use this to help direct me whenever I had a problem while implementing the algorithm.

Once I had the algorithm calculate the path I noticed that the path that was being calculated was very inefficient and instead of going directly to the target position it would go around almost all the other nodes before reaching the target. After a while of debugging and looking back over my research materials I noticed I had mistakenly placed a > instead of a < sign. This meant that the algorithm would pick the least efficient node to move to instead of the most efficient.

Next week I plan to start implementing this into the main AI script and seeing how this compares to using Unity's built in navMesh. Although Unity's navMesh has more features (such as allowing the navMesh agent to jump between navMesh paths) I would like to see how much my own version of A* works. I will also look to see what other things I can add to the algorithm to improve it. Some things that I will be trying to add is support for stairs and generating the node on platforms that are not at the same starting height as the target/player at the start of the game.

References
Lague, S (2014) A* Pathfinding. Available at: https://www.youtube.com/watch?v=-L-WgKMFuhE

A* Star

For this week I started with implementing my own version of the A* pathfinding algorithm.I began with going back to the resources that I looked at last week to make sure I knew what I was doing. I did this because I have no previous experience in programming my own pathfinding algorithm so wanted to make sure that I knew what I needed to do. Once I re-read my research material I began programming it into Unity. I started by programming the code that generates the different nodes. The algorithm will use these nodes to calculate the distance between the AI's current locations and their destination. I spent a little bit of time planning the best way of handling the different nodes. This was because I wanted an efficient method but still keep it easy to customise if I needed to at a later date. I first looked at using a 2-dimensional array however I realised this would stop me having holding different variable types. I then looked at using a list however I couldn't hold both the position of the node and whether the node position was/wan't being blocked by any other obstacles. I then decided to go with a dictionary. This was because I could add nodes at run time like a list but was also able to store both node variables together.

The only big problem I had with trying to implement was trying to figure out where the AI was on the node grid. This was because checking the node positions again the players position would never match as the player position would be several decimal places out from being exactly on a nodes centre. I tried rounding the node position and AI position but this caused the AI to be on multiple different nodes at the same time. I finally decide to run through a for each loop which checked the distance from the AI and the node finding the closes one. Having tested this in game it didn't cause  negative impact on performance so I will keep using this method.

For next week I will be trying to implement the rest of the algorithm and begin testing it in the scene. To complete the algorithm I need to start calculating the path the AI needs to take and start moving the AI according to the path generated.

Picture of the the node grid that is generated showing walk-able areas, un-walk-able areas and where the AI is positioned. 

JavaScript to C# and A*

For this weeks work I decided to port my project from JavaScript over to C#. I made this decision after meeting with Chris for my presentation last week. Originally I decided to program the whole AI in JavaScript as I was more comfortable with JavaScript in inside of Unity as I haven't used C# too much in Unity. As I also had never programmed any AI I decided that using a language which I was more comfortable with was a sensible choice. However one thing that I overlooked when making this choice was that I didn't take into account what languages employers would like you to know. This is because I want this project to be a good piece for my portfolio once leaving University and to help with getting a job. After looking into jobs as both Unity developers and programmers outside of Unity I found that many jobs wanted knowledge of C# with very few mentioning JavaScript. Because of this I felt that it was worth spending the time to port the project to C#.

After porting my project I decided to look into creating my own version of the A* path-finding algorithm as suggested by Chris at my presentation. I started by going back to my research materials to get an understanding of how A* works and the benefits of using this instead of a different algorithm. Ian Millington in the book Artificial Intelligence For Games (Millington, I and J.D.Funge, 2009) mentions that A* (Or a version of A*) is used in many projects due to the efficiency and easy implementation of it. Another resource that I looked at was a YouTube video created by Sebastian Lague (Lague, S. 2014). In this video (and the following videos in the series) look into how A* works and how you would go about implementing this into Unity. After looking at these resources I feel that I would be able to create a version of this so will be spending my next few weeks implementing it into my project.

References
Lague, S (2014) A* Pathfinding. Available at: https://www.youtube.com/watch?v=-L-WgKMFuhE

Millington, I. and Funge, J.D. (2009) Artificial intelligence for games. San Francisco, Calif, Oxford: Morgan Kaufmann; Elsevier Science.

Attacking, presentation and the future

For this weeks work I planned on starting to implement attacking mechanics and having my presentation at University. I started by adding the ability for the AI to shoot once he gets within a certain range of the player. I had several problems where I couldn't get the AI to stop running towards the player when he was shooting. The current version still doesn't have this working properly. There was also a bug where the sight was raycasting from the AI start position and not updating when he moves. This hasn't been 100% fix but I will be looking back into sorting this at a later date.

My presentation went well with me presenting my progress on my project to Chris (My project supervisor), discussing my project milestones and what I wish I had done differently knowing how my project has gone. After having this discussion with Chris I have decided to port my project from JavaScript over to C#. I've made this decision as C# is a very in-demand language to know for programming jobs. As I want this project to be used in my portfolio and to help me get a job when I leave I feel that it will be worth my time to port my project over now. We also discussed the idea of me programming my own path-finding algorithm as showing I can program my own algorithms is something else that would be useful to show on my portfolio. This is something else I am going to consider doing depending on how much time I have once I have ported over to C#.

For my next weeks work I will be porting the current version over to C#. I am planning for this to take me around 1 or 2 weeks and will be moving any other milestones this effects back until this is done. Once this is completed I will be creating an updated table of my milestones to show what I will be doing next.

Linking mechanics and creating presentations

For this weeks work I linked together the AI mechanics together (Sight, hearing and pathfinding). This means that he will now path to the player depending on how much he can hear or see (Whereas previously it only went to what it could see). Most of my work this week has been on creating my presentation ready for next week. The presentation is to show my lecturers how my work is going and to get feedback from them on what I'm doing. I will be covering why I decided to create AI for my final project, how each part of the AI works and what I will be doing next. I will also be talking about my project milestones discussing how I've met/not met them and what I have done to deal with meeting/not meeting them.

As well as presenting my presentation to my lecturers I will also be working on creating the attacking mechanics for the AI. This will be having the AI decided when he should attack and also adding the attacking mechanics. How close the AI will get to the player will  be decided on what kind of weapon the AI is using.

Pathfinding adjustments and Chris meeting

For this weeks work I looked into improving the pathfinding system and also had a quick meeting with Chris to discuss the bug stopping the AI sight raycast from begin at eye level. Firstly I changed the AI way-point system to be more user friendly so instead of having to assign all the way-point markers individually, it now will automatically find the way-points and assign them to an array when found. This makes it much easier to add way-points for the AI characters and saves a lot of time when trying to put loads of AI into the scene at once. A bug was fixed where the game would crash if no way-points were put into the scene as well. If no way-points are selected he will now use his start position as a way-point. One thing I looked into adding was using Gizmos to draw out the path that the AI will take by connecting lines between the calculated path. I decided not to do this as the amount of work that it would have taken wouldn't have been worth it as you could only see this in the scene view. It would also be quite costly as it would be calculating the path between way-points often and having a lot of AI in the scene at once could lead to a significant drop in frames.

AI Pathing

After working on the pathfinding elements I decided to use the animations from the Unity standard assets to set up a basic animation controller. This was so that I could have the character walk, run and idle deepening on what he is doing. I also fixed a bug where running into the character would cause him to spin around while still trying to path towards you. This would cause the AI to break (As he never stopped spinning) and would need you to restart the game to fix it. I also had a meeting with Chris and fixed the raycast so it is now shot from the AIs eye line and not from his feet.

Before bug was patched

For my next weeks work I will be working on creating my presentation which I will be presenting to my lecturers. I will also be linking the sight, hearing and pathing mechanics together so that the AI can react to everything that is happening properly.

Pathfinding

For this weeks work I started on adding the pathfinding for the AI so that he can patrol around the map. The pathing system works by using the navMesh to create pathable areas of the map and then I tell the navMeshAgent to move around to specific way-point markers positioned around the scene. I contemplated just writing the Vector3 coordinates into the inspector however this was awkward for trying to get the exact positioning that you want. However as I want the AI to be as easy as possible to set up I am still looking at different ways that could improve it and make it more user friendly. Currently when the AI sees the player he will run towards him (Nothing will happen when the AI touches the player) and when he loses sight of the player will go back to patrolling. If he becomes suspicious and thinks he saw the player he will move towards where he though the player was. This will work for sound as well but I will change this to work with both once I link the 2 mechanics together at a later date.

So far I haven't encountered too many problems when creating the AI. However one problem that I did encounter this week was that I couldn't get the AI to move to any position when calling SetDestination(). I went onto the Unity scripting reference (Unity, 2017) to see if there was a different function that might work but nothing that I found on there worked either. I create a new script and a game object with just the necessary code to move it and it worked. I tried debugging my script to see what was stopping it from working but nothing seemed to work. I then removed the navMeshAgent from the AI game object and placed a new navMeshAgent and things started to work. The only other problem I have noticed so far is that the sight  raycast is shot from the players foot which I have mentioned before.

For next week I will be finishing the pathing system and looking into ways that I can alter the current way-point system to be more user friendly and make it easier to set up patrol paths for your AIs.

References
Unity (2017) navMesh documentation. Available at: https://docs.unity3d.com/ScriptReference/AI.NavMesh.html.

New Milestones

After going back to my old project milestones I have updated it to accurately show what I will be working on going forward. After updating it I had several weeks worth of time where I had no work planned so I decided to look at some new features that I could add to improve the AI. I started by looking at some of my original resources that I used when creating my brief to see what features people spoke about. I also went onto some games which I think have good AI such as Dishonored, Far Cry and Borderlands. One thing that I noticed when doing this was that I ignored what the AI will do once it is in its alert state and reaches the player. I've decided that I will be adding the option to select what type of weapon the AI has which will alter how close it will try to get to the player and when it will try to attack you. This means I will have to create the shooting system as well.

Currently I plan to add these different weapon selections:

Sniper:
Long range
Low attack speed
High damage
High accuracy

Rifle:
Medium range
Medium attack speed
Medium damage
Medium accuracy

Shotgun:
Close range
Low attack speed
High damage
High accuracy

Melee:
Very close range (Touching distance)
Low attack speed
High damage
High accuracy

I have yet to plan what distances count as 'long', 'medium' and 'short' (This also hasn't been done for the attack speed, damage or accuracy)  as I will be doing this once the mechanic has been programmed in. I will program a system that will allow me to quickly iterate and make changes to the variables and figure out what is the best for each weapon type.


Updated milestones:

Finished hearing

After finishing this weeks work I have completed the hearing system for the AI character. This means that the character now can hear how much noise the player is making and depending on how far the player is from the AI he will be able to react to it when his reaction has been programmed in. I will be play testing at a latter date to figure out how far the AI should be able to hear. I have continued to comment my code and have tried to make it all efficient and easy to read.

Now that I have completed the hearing this week it leaves me 3 weeks ahead of my original project milestones. As I am very far ahead of my milestones I plan to look through and review all of my future milestones next week so that I can accurately view where I am in my project. I will also look at how much time I have left over once I have adjusted my milestones to see if there are any additional mechanics that I can add in the time that I have spare.