Open Nicky-Jones opened 6 years ago
Currently working on trying to transition through the states properly for Anky, have hit a bit of an issue, i've put in some conditions that are being met to make the anky go into the drinking state but for some reason it's not going into it even when setting the state to be in the drinking state.
just seems to constantly switch back and fore between the grazing and alert state, i think part of the reason for this is because the transition between the both doesn't have a condition set.
[Day - Sunday 18/03/2018] so after figuring out the transition issue, getting the state to go into Drinking and executing the animation was fairly simple.
Then came learning to transition the state into "Alert" this was a little difficult because i had to access the Field of View script, and get access to the array that stores all the creatures that is inside the circle for any specific dino.
once that was done it was fairly simple to define some parameters to put the anky into an Alert state if the raptor was within a range i deemed appropriate.
Fleeing was next on my task, this was a fairly simple implementation too as it was roughly the same as the Alert state except i just made the range that i deemed a anky would flee from a raptor to be much closer than the alert stay.
Fortunately Mike had already created a "flee" script which simple made the gameobject move the opposite direction from a target gameObject, so when the flee state is active, I enable the flee script on the Anky and pass in the GameObject of the Raptor that is closest to the anky in question. I've also temporarily increased the speed of the Anky when running (stamina hasn't been implemented yet and I may give it a crack myself if I have time, but for now seeing as i'm not doing any behaviors for the raptor, the anky will always out run a nonmoving/moving raptor)
priority of the code seems to be key in how the behaviors act, I noticed that if certain behaviors are checked before others, it can mess up how the states get transitioned through.
another thing i'm still struggling with solving is sometimes the state gets thrown back into Grazing when it should still be in Alert, and for that reason when a raptor is to close sometimes its not always in the alert state and as such it doesn't actually go into the Flee'ing state when activating the flee code, fortunately the code still gets executed.
[Day - Monday 19/03/2018]
after a day of helping people in university, I didn't really get much done.
I tried adding some herding code but the attempts i've tried have been unsuccessful. I think the best way to go about it, is by looking for all the ankies in your field of view, store those ankies in a separate list, look through all the ankies positions against yours and find the one that is closest to you, and ideally it has ankies close to it (if you can see them). that way if a ankie is by itself, but there is a group of 3 ankies directly opposite, the ankie looking to herd will ideally chose the one that has more ankies and as such the solo one will then also join the larger group.
once they go to the nearest ankie's position, use that current ankies position but off set the x axis by roughly 5/10 to keep them an even distance from each other, this will essentially create a huge line but it will suffice for now. now I've just got to go about implementing it.
towards the end of the day i realised I wasn't comfortable with the way I was doing my code it didn't feel like i was truly using "FSM" so with the help of a youtube video i have been recreating a new FSM that directly connects to the MyAnky code and moves into separate scripts/States when conditions are being met, its updating everything that was being updated previously when my code was in MyAnky, but I've noticed the code is a lot more cleaner, and the transitions between states in the animator seems to be a lot of more accurate and less buggy which is a good thing.
the only problem i'm having with this at the moment is with the fleeing state, the state works perfectly if i drop a anky next to a raptor, it goes into fleeing mode and runs away until its a safe distance from a raptor and returns to the Alert state, the problem is when the anky goes from the alert state into the fleeing state, it executes its code properly and just as it gets to the distance deemed safe and move back into the Alert state it seems to enter the alertState 1000+ times in a second which lags out the game for a second, it's weird. i'm looking at the code I don't understand why its doing it..
suspicion lies with the code i'm using to exist the fleeing state and entering the alert state but im unsure why i'm suspicious of it, it just feels like a good place to start, but that's tomorrows problem.
[Day - Wednesday 21/03/2018]
after spending all day was finally able to successfully implement a fully working herding system, this will allow the ankies to remain fairly close to each other, so they remain herded instead of separated, as this would be a common thing for ankies to do back when they were alive.
Currently not trying to get access to the layer of each tile on the terrain so when the anky is in a grassy area it can chose to eat to heal if it needs too. seems to be a little complicated.. I think the terrain is broken. during my attempts i accidentally removed all of the additional foliage to the terrain, but when i readded it back manually (aka just put down some grass) the code seemed to respond to the newly placed grass and went into the eat state..
unfortunately when replacing it with a old back up so i have the correct style of map, I tried adding in some grass but the code still didn't work. must investigate why.
[Day - Thursday 22/03/2018]
Started off the day, trying to solve the problem I have been having with accessing the layers on the terrain to determine if I was on a tile that had grass or not to eat it..
after a couple of hours I found out that I was only accessing the GameObject of the terrain, not the terrain component inside the GameObject which holds the correct information about the layers on the terrain. This does come with some draw backs, Ideally I would have liked to have a A path to a specific layer and use the A to find the closest tile that has that specific layer (which would be grass) but due to the limitations of the terrain gameobject itself, I don't believe this is possible, a way around this however would be to make a grass gameobject and place it around the terrain, that would then make it possible to do everything I could dream of doing to grass.
After that I decided to add a hunger and water values to the Anky because as the day goes by they will progressively get hungrier and thirsty, easy to add, Child's stuff.
With the help of @15014576 I was able to get an A* path to the Water so the ankies will seek out water when they are either low on water, or are in need of some health if they have been attacked.
The next thing I added was an attack state, this is obviously self-explanatory the reason I added this code is because a Anky in certain circumstances will stand and defend itself again enemies. I put in some conditions that needs to be met to enter the state and some conditions that may happen to leave the state, for example if an anky gets to low on health it might op to flee from the fight.
The final thing that needed to be added was the death state. which is also self-explanatory and easy to implement.
Fixes left to do: at the moment the only real fix that is left is to get the animationClip.Play function to actually play a animation when its being called. so far it does not.
[Day - Friday 23/03/2018]
Report Summary:
Herding - The reason why I added herding is because It was an essential part of the anky's behavior when they were alive to help deter enemies from attacking them.
Why - why did I focus on on the method that I used: The reason I chose this particular method, was because in essence it very much adheres to what Game AI is, which is fairly stupid AI pretending to be very good AI, its a very simple technique, I look for other ankies, find the one closest to me and if the anky is a distance considered to far away from the next closest anky, move close to it using a script that simple gets the position of the closest anky and moves the current anky forward in that direction until it reaches the position of the closest anky. its a very simple technique yet made to be more complex than it actually is. a more complex approach would be to find the closest Anky, use a path searching AI to find a route to the destination of the closest anky, by creating points that makes up the path for the Anky to follow. an example of this would be to use an A* algorithm.
Evaluation - When testing the method that I decided to use, I found it to work very effectively considering how simplistic it actually was, it found the nearest anky, and moved to a position close by without a lot of complex code, and without performance costing code. making it a very simple and cost effective method to use.
Attacking - Attacking is a self-explanatory behavior to have, all creatures will defend theme selves from enemies under the right conditions.
Why - The method I used for how my ankies and raptors will attack is based off collision detections, the reason why I chose this method is because it is a very good way to get accurate and ideal looking attacking combat between raptors and ankies, or ankies and ankies and raptors and raptors. what the method does is a collision box will be on an anky, when it performs the attack animation the tail of the anky will attack its current target and the collision will happen when the tail hits it's target and it will lose health. the same will happen when taking damage too, if a attack hits the side of the anky, it will detect that and see that when the side is hit by either an anky or raptor in attack state that anky will take damage.
another method that was a possibility was a proximity based where the anky or raptor would simply move to a close position of the target and while it remained in that close proximity it would periodically do damage to that enemy.
Evalution - The colision box method that I used works fairly well, a disadvantage to this method is how the combat system needs to be set up. because the anky will only take damage if it is collided in the side by a GameObject that is in an attacking state means that the attacking enemy always has to move to be on the side of the anky, and because the anky uses its tail in the attacking animation and the damage is based off the collision between the tail and the target, anky vs anky fights would prove to be very difficult to make if a fight happened between the two, Anky vs Raptor wouldn't pose this problem as the anky's animation of the tail moves pretty far up it shouldn't have a problem hitting the raptors collision box and activating the code. this wouldn't be the problem with the proximity method, but the proximity method is very dirty and not very pleasing as a simulation but it effective and very easy to set up, a problem with this is it doesn't give any advantages in the future, setting up the collision box for the fighting system can be then used for other future behaviours that may wanted to be added or could affect already existing behaviours.
Fleeing - This is probably the most used behaviour an anky will use, it would be common practice when the herd is under attack to flee rather than stand and attack the enemies, unless cornered.
Why - The method I used for this is when a raptor is to close for comfort and its not ideal to attack the raptor the anky runs by calling a simple script called "Flee" which takes the target of the enemy you're running from, and runs the direct opposite direction of the enemy. its a very simple script and works very effectively and is cost efficient.
another method you could use is A and change the direction in which you move, because the the current method simply moves the direct opposite direction, so if there was an anky that was in that direction further ahead it would keep fleeing back and fore between raptors but A could alternate the direction away from the closest anky by roughly 90° so you don't run away the same spot every time.
Evaluation - The current method of simply running the opposite direction from the closest enemy threat seems to work relevantly well and would only pose a problem if the above situation happened to develop which would be unlikely as their would be multiple ankies and they would try to herd which would move their direction. it's not the most elegant nor is it completely flawless but considering how cost efficient it is to A its fine to have instead of the A method.
Hunger/Water - stats that gets reduced over time as the game progresses.
Why - because this is a simlulation type game, ankies and raptors will have a hunter and water stat that gets decreased over time as the game continues, the way i've done this is by creating two variables at 100, and have them decrement slowly over time.
Evaluation - this method is an efficient method, and works very effectively, Ideally I would have liked to improve on this and have the value of those stats determine some of the characteristics of the ankies, for example if a anky has a hunger value of over 150, its size would increase and would move slowly in return, also if the hunger or water levels drop to much the ankies or raptors would move more sugglishly and more often to being attacked and killed.
Drinking - another behaviour used by both the anky and the raptor.
Why - the method I used for getting the anky to the water is based on two conditions, one being if the health is low (health is increased when eating or drinking) or if the water stat is to low, and then the anky will use A* to find the closest tile that has water on it and create a path to that tile to follow. this in terms of simulation is a good method to have for this behaviour as it makes it more realistic.
another method that could have been used, is by changing the center of the water GameObject to the middle of the island where the little pond/lake is and when the conditions are met to go to the water, have that be the target for the seek script which would take the position of the anky and just move to the position of the target which would be the center of the water. this would be more cost efficient than the A* method but isn't as nearly as effective or good.
Evaluation - The A* method works very well, its fairly effective in terms of performance compared to the second method. but isn't as simple.
Eating - a behavior used for Anky and Raptor
Why - the method I used was to access the layer level on the tile that the current Anky is on when on the terrain, this is a very efficient and a fairly simple method to implement, another method that was a possibility was to define a specific value on the y axis, where it is more likely to have grass grown when its half way up on the terrain, rather than all the way up which would be stone, or all the way at the bottom which would likely be water or sand.
Evaluation - This method is a very good basic and cost efficient method but the downside to this method is because the terrain is based off an older build on the Unity it doesn't have access to the newer features that the later version of the terrain has. and as such you cannot use A* to check each tile layer on the terrain and find the closer tile to you that has grass on it. so when the anky is low on health or perhaps low on Hunger he has to be near a tile that has some kind of food on the tile to eat, but because they constantly wonder and the vast majority of the island has some sort of grass/plant to eat it shouldn't be to much of an issue, something the other method wouldn't have a problem as you could just simply tell it to go to a specific value on the y axis and eat.
FSM - I created a Finite state machine to better process the different states for the anky and raptor.
why - This method was chosen because it made a lot more sense to have different states/state files to have code being executed from rather than all in one file to keep things neat and better to debug with as problem can only exist in one state.
another method that could have been used was to use the animator alone and make the changes all in one file, which can make it very cluttered.
Evaluation - Using the Finite state machine was definitively the best choice, it was very easy to debug issues and wasn't very complicated to set up, I also noticed that the animator for the anky and raptor seems to be a lot more accurate and less buggy when using the FSM compared to method 2, which i was originally using at the beginning before changing.
References - Finite state machine tutorial - https://www.youtube.com/watch?v=PaLD1t-kIwM
14016036 assignment documentation through github, this will be updated as I go through working on my assignment as another form of documentation to be presented to Mike for my report.