tamagossowdev-blog

[tamagossowdev-blog]

Week 12

QA Testing V1.0 - 5 Hours

QA Testing V1.1 - 0.5 Hours

QA Testing V1.2 - 1 Hour

QA  Testing V1.3 - 6 Hours

Bug Fixes - 2.5 Hours

Mailing List - 4 Hours

19 Hours

Mailing List - 

I spent some time trying to find some suitable people to email for the game review. I found a Reddit post with a list of Youtubers who review Indie Games. https://www.reddit.com/r/IndieGaming/comments/14nv98/mega_list_of_youtubers_who_review_indie_games/. However the post was from 4 years ago so I spent some time going through each person and seeing if, they are still active, still doing game reviews, have not become too popular in that time frame. The list became much shorter but the people I found had a good chance of responding and following up. I also found 8 other websites that are open to submissions for reviews. I emailed a few of the websites and some of the Youtubers. 

QA Testing V1.0

Testing the First version was simple however some issues were found almost immediately. The spacebar would break the “Press Any Key to Continue”. I found that the falling platforms animations dont pause with the Pause Menu. I found a few areas near the logs and the campfire where the player can get stuck.

I also found a way by using the nearby hills to jump into the shop wagon. 

The boss fight however was broken. Part way through the QA testing I discovered the boss was waiting at the door puzzle before i had even collected any of the pieces. It was also able to attack the player through the wall. I made all my findings known and a new build was available. 

QA Testing - 

I tested the issues I found in the first test and they were all mostly resolved. However when entering the Main Level Scene, the camera was extremely far away from the player and under the map. Nothing the players could do in game could fix it. This issue was quickly resolved.

After this issue was resolved I continued the QA session however I discovered the boss was still broken. I spent some time trying to fix it and finally did. Some other issues were fixed by other members and so I started another QA session. 

The last QA testing session I did was a full one from start to finish as I wanted to make sure that nothing else had broke. I discovered almost all of the issues I had found have been resolved, the ones where I got stuck in the tent and fire were still prevalent however. Nothing more had broken and I was finally able to test the boss area which worked. There are still a few issues left but nothing to outstanding. 

Bug fixes - 

When the scene is started the Boss Enemy starts moving towards the player. It should only start moving after the player is in its area. However nothing in the code set the ai.tartget before this point. After some debugging it seemed the Boss target was Boss Bar, its health bar. It seemed like the boss was trying to get to the player but instead it was getting to the GUI. Someone had manually set the target in the scene to the Boss Bar. Changing this to none fixed the problem. 

To prevent something like this from happening again, I also added some code to the boss script. This will prevent any targets other than Player and Null. 

[tamagossowdev-blog]

Week 11

Debugging/Testing Build - 1 hour

Ranged Enemy - 15 hours

Implementing Ranged Enemy - 

The ranged enemy model was finished. The model was made intentionally to reuse the other goblin model only with slight changes, as the Grunt model was used to initially test the scripts. Prior to the Ranged Enemy model being done, all the scripts were made and tested using another model, so that the scripts could just be dragged onto the new model and they instantly work. However there were some problems.

Projectile - The projectile script that was used for the cannons did not work with the ranged enemys, as stated in a previous post. This would have been an easy fix except everyone decided it would be better to keep the cannons in the tutorial. This meant I had to make a new Projectile script and Prefab so that both could be used. I also had to change the ObjectPooler in the Level scene but not the Tutorial scene. 

Agent Moving - The script that was made worked perfectly with the other grunt models. The model, animations and everything was the same for both the Grunt and Ranged enemys except for weapons. However the script did not work on the ranged enemy. The ranged enemy will not move with the RunFrom() function. There were few occasions where i could get it to work.

At the shadow puzzle it could move along the edge but never onto the actual navmesh. 

At the fountain it could move along the Navmesh but only move to this point without a navmesh. I even tested in one of the open areas of the terrain, thinking maybe the Navmesh was being blocked by something. But it did not work either. 

The agent has a location but will not move to it. I rewrote the script to look cleaner and remove any extra things that I thought were unnecessary.  

I tested to see if it was the model or whether something had changed with the navmesh over the past few weeks. So I dropped the Ranged enemy script onto on of the Grunt Prefabs however it still worked, which stumped me. There was no discernible difference that would have changed the outcome. 

 I tested to see if SetDestination was the problem so I replaced it with Destination. This didnt work. I added to the script for ai.SetTarget(player). This proved to work as long as the player was more the 15f away, which means that none of the IF statements were being called. This means it probably was a problem with SetDestination. I thought it may be a problem with Update. So I added an if statement to check if the path is complete before generating a new path. 

This didnt seem to do anything. But I noticed that it was still creating a new path whether the other one was complete or not. I then tried changing the Stopping distance within the script to 1f and it worked. Curious, i removed the Path Complete check and it still worked. Turns out because the script was a carbon copy of a much older version of the Grunt Enemy script. In the Awake() it was setting the stopping distance to 15f. This might show why they path around the fountain may have worked as it may have been longer than 15f. But not why the path on the shadow puzzle would have worked. The fact that it still worked with the other models still confounds me aswell.

Other Bugs - The model would wig out whenever it would attack and run away, as it would look back and forth multiple times. I had to delete some code from the RunFrom(). The agent would also keep moving towards the Path when turning around and attacking so I added a agent.IsStopped to stop it when it attacks. 

[tamagossowdev-blog]

Week 10

Dev Day - 7.5 Hours

Nav Mesh Fixes - 0.5 Hours

UI Scaling - 2 Hours

AI Fixes - 1 Hour

AI Blocking - 7 Hours

Issue Fixes - 3 Hours 

Internal Playing - 2 Hours

Total Time - 22.5

Unforunetly, Unity has not been behaving well with my main computer of the past 2 weeks, so any work that was done, was done on my laptop. This meant that I couldnt play the game within the Unity editor itself, but I had to build the game everytime I wanted to test something. 

Dev Day - 

Spent a day from 10 - 5:30 at uni doing dev work together with other team members. 

Nav Mesh - 

During internal testing, the navmesh that was built last week created other problems elsewhere across the map, and so it had to be tweaked further to get it to work both in the Jump Puzzle and in other sections of the map. 

UI Scaling - 

With the introduction of new UI elements the scaling had to be fixed again to ensure it worked well with multiple resolutions. This meant tweaking settings, building the game and then testing the builds UI across multiple resolutions. 

AI Fixes - 

During my own playthrough of the game, I noticed the AI wasnt behaving exactly as intended. This was the Spacing method I developed to improve combat. The value that was there to instuct the enemy on how far away from the player before they started spacing away from each other was still set on a extremely low value, back before the scaling of the level was strange. The value was changed and developed and had to be tested to match how it worked before. 

AI Blocking - 

With the introduction of Stagger animations to the enemies, it completely changed how the enemies behaved in combat. When the blocking was removed from the enemies, the combat was extremely easy. This was because hitting the enemy while its attacking will negate the attack and play the stagger animation. I tested the game by removing the stagger animation but keeping the Block Stagger animation. I also reduced the value of how long after the enemy has been attacked for it to block to the length of the Block Stagger animation. This meant that when the Enemy is blocking and is then attacked, they will be staggered and then continue attacking. However this also removed one of the factors of the Stagger animation, and that was to give the player a visual indicator that they were hitting the enemy. 

Issue Fixes - 

 The issue list is down to 17 issues, however only 3 of these are bugs, a majority are enhancements or features. Most of these have also been marked as “wontfix” meaning it is something we decided to not be important enough to fix now. Some of these issue may also be able to be close however confirmation from other members is needed.

[tamagossowdev-blog]

Week 9

Sliding – 2 hours

Issue 109 – 5 hours

Ranged Enemy fixes – 4 hours

Cannon Fixes – 2 hours

Small fixes – 2 hours

Testing Game/Bug Finding - 2 Hours

Enemy/Player Sliding Issue

RigiBody Constraints – Using the code to lock the position and rotation of the enemies rigidbody’s after they died I could achieve the desired effect. Except they would continually look at the player and when the player died when jumping they would get stuck.

A reliable method for recreating the player sliding issue was found by running and jumping into the Shadow Puzzle pit and while in the air strafing left or right then waking forward (pressing A or D then W). This recreated the issue 100% of the time. Player issue seemed to be resolved easily making the rigidbody velocity == 0. Doesn’t work for enemies. Without the (velocity == 0) line in the code the velocity is never 0 on death. After adding the (velocity == 0) code back in and using the exploit above the sliding issue seemed to be resolved.

Issue 109 – Grunts falling into lava. There is a tiny triangle of the navmesh that leads close to the edge allowing the enemies to possibly fall off. After watching for multiple minutes over multiple instances of the game, I couldn’t find any evidence of it happening. It wasn’t until, while doing other issues, I went to the Jump Puzzle and found only 1 enemy. I changed the navmesh settings to remove the extra part. I was playing it again and watching them when I noticed the fir that was there had a bit of Navmesh going up it. When an enemy tried to walk up, the geometry of the rocks seemed to push the enemy back and it seemed it was possible it would go in the lava. Fiddling with the slope and step NAvMesh settings until it was gone and the ramp in hub still was there.

Ranged Enemy Fixes – Enemy looks in the wrong direction, projectiles fly in the wrong direction. Try changing the forward of the projectile manually in the Ranged Enemy, but to no avail. Looked at the Projectile script and saw it used Lerp. One of the vectors being called in the script was forward, except it hadn’t been set to I changed it.

However if the player changes direction the ball will follow them like a homing missile. Tired putting a refernce in the Start()

However because the projectiles are clones in the object pooler, some of the objects are from the Cannons and will have their transform.forward. Instead put the code in the OnEnable()

This worked for the ranged enemy however it broke the cannons. This is because whoever put the objects doesn’t know that the blue axis always needs to be the forward rotation. Fixing the cannons would not be easy, as it would either mean changing the code and finding another solution for the enemies, or moving all the rigidbodies, scripts etc to another parent node of the cannons. The easiest solution would be to remove the cannons completely from the game and replace them all with ranged enemies. With some testing, we can make the ranged enemy behave similarly to a cannon (except for looking at the target) by putting them on an area without a NavMesh. This is good for the shadow puzzle as I can place the enemy on the pillars as another obstacle.  

The Ranged Enemy looking in the wrong direction was more difficult. This required changing the enemy rotation based around the WalkAway function as the function made the enemy look away from the player. However for some reason the enemy kept looking to the left and right. By moving the “look at player” code to the RunAway function I made it so the projectile will still be fired at the player.

Extra Fixes – While testing the jump puzzle I started to get errors during one part of the puzzle. There I noticed one of the falling platforms did not have a rigidbody attached to it. The script was trying to call for the rigidbody causing errors. Added a rigidbody and checked to see if all other falling platforms also had a rigidbody attached.

Changing more decorations and other objects such as the cannons to static and rebaking the NavMesh.

During testing I noticed not many people ventured out into the red circled area of the jump puzzle, they would just jump to the green circled platform then jump to safety. This can be fixed by adding a coin to the yellow circled platform, giving incentive to players for going out there. It is also possible to completely remove all of the platforms in the red area, make the two platforms below the green one not fall and add a coin to the bottom one.

[tamagossowdev-blog]

Week 8

Times - 17.5 Hours

Ranged Enemy - 12 Hours

Projectile Fixing - 2 Hours

Issue 21 - 2 Hours

Internal testing - 1 Hour

Other Bug Fixes - 0.5

Working on improving the combat i started to implement the Ranged Enemy AI I designed last week. Some of the functionality was already implemented with the Turret and Projectile Scripts. The biggest problem was getting the Enemy to retreat and behave like designed. My first attempt to get the Enemy to flee from the player was by using the Random Nav Sphere used for the Wandering States of the Grunts.

It was slightly edited to ensure that the Position chosen was behind the Enemy and away from the player. This however didn't work. And so I re-adapted it using a method found online. 

Next was to get the enemy to behave correctly. 

This seems to work however there is a small chance that when the Enemy is running away it will ignore the first chunk of the if statement and just continue to walk. However the enemy now behaves as it is supposed to. The next issue encountered was that the projectiles fire in the wrong direction. At first I thought it had something to do with the rotation of the enemy but no matter which way it is facing it will shoot in the same direction. 

Issue #21 - 

From the previous week I was working on a solution on the stuck on walls issue. While I was working on it a few fixes were added to the branch. I pulled these which was the scaling issues fixed. With this new patch I noticed someone had added a Physics Material to Morpheus’ collider, which fixed the issue. I had tried a similar solution earlier but added the Physics Material to the terrain and not the player. However with this it also created a few extra issues, such as the Platforms for the Jump Puzzles edges are curved like a ramp meaning if the player lands on the edge of the platform they slide off the platform, which may seem unfair to a new player. Another issue is if the player stops while walking on the bridges at spawn they will slide back. The bridge issue was easily resolved by adding a new Physics Material with a high friction to the Bridge which will stop the sliding.

However this does not work with the Jumping puzzle as it will undo the fix and make it so the Player sticks to the edges of the Platforms again.

Other Fixes - While testing the game and new movement systems myself, I noticed the cannons at the jumping puzzle were flying away when starting the level. I originally tried removing the rigidbody however the heirarchy required it. I settled on Freezing the Rigidbody’s position and rotation. 

[tamagossowdev-blog]

Week 7

Times - 

Issues #3 #4 - 10 Hours

Issue #21 - 5

 Hours 

Issue #63 - 2.5 Hours

Design for Ranged Enemy - 1.5 Hours

Total - 19 Hours

Continue work on Issue #4 and Issue #3 - 

Spent more time deciphering the code to figure out what every single piece of it does. I messed with some of the values to no avail. I then tried debugging. I noticed the code was creating a Sphere collider to test for collisions. I thought maybe it was not detecting the Terrain collisions. After extensive testing all different areas of the terrain I discovered the Camera Collision would only work if the Player was pressed up right against the Terrain. I believed this was the code colliding with some part of the Player. I decided to test it further by adding a Sphere Collider to the Camera, there I discovered the actual position of the FreeLookCameraRig and also the Pivot was on top of the player. Considering the code for the Collisions was being based on the Camera Pivot I did some testing. 

Using Gizmo.DrawSphere I was able to see exactly where the Sphere Collider was being drawn. As I suspected it was being drawn right next to the player. 

I changed the position of the Collider by reversing the m_Pivot.forward (making the collider appear behind the player) and increasing the distance. With this the Camera now collided with the terrain. HOWEVER, the camera would move unnecessarily close to the player AND if the camera kept moving towards the wall It would still go behind the wall as the Collider didnt move.

The code was changed so that the Collider would continuously be on top of the Cameras position, so it will move with the camera away from the wall. It is still possible for the camera to go behind the walls however it is much harder for it to happen. There is still the problem of the camera moving too close to the player. ATM this causes the camera to move uncontrollably backwards and forwards. 

I tried to fix this by moving the camera forward slightly until it is no longer colliding with anything however it did the same thing but worse.

Issue #21

Continuing from last week, I added a condition to the if Statement that tests the downward velocity. 

However this immediately stops the player upon spawning in. This means that the Grounded RayCast does not work properly. After way too much time figuring out the different values I realised the Grounded RayCast was testing to see if it hit the ground not if it isn't hitting the ground. However this also meant that the player would  randomly stop while jumping. I then added another RayCast to test if there was any terrain in front of the Player. 

This however made the code not work with the Jumping puzzle or if the player got stuck on any other object. This can be fixed if we just test for anything in front of the player by removing the check for the tag “Decor”.

Another solution thought of would be checking if the Players Rigidbody is colliding with anything instead of the testing forward RayCast as it is rather buggy at the moment. 

Issue #63 - Scaling of the UI

This seemed to be any easy fix that took too much time than necessary. This required changing a script on the Canvas for Canvas Scaling. However I was unfamiliar with each of the options. This meant each time I wanted to test each of the options at different resolutions I had to build the game and play it for each of the resolutions and options to see which was the best for scaling. This took alot of time but I found the best option was the following 

Ranged Enemy - 

Ranged

Damage Type: Primarily Ranged [Long Distance] (High Damage)

Attack Speed: Ranged [Medium/Fast]

Speed: When Not Shooting [Medium], When Shooting [Slow]

Health: Low

AI Behaviour States:

WAIT = The Ranger will remain in place while in the WAIT STATE. When the player is spotted by themselves or when in the alert radius of another goblin in the COMBAT STATE or PURSUIT STAGE they will switch to the PURSUIT STAGE. When the player is inside of the Rangers combat radius, they will switch to the COMBAT STATE. No Movement.

COMBAT [RANGED] = The Ranger will remain at a distance while continually firing projectiles at the player. When the player moves towards the player, the Ranged Enemy will move away from the player while still firing projectiles. If the Player gets close enough the attack the Ranged Enemy it will stop Retreating and start firing arrows as fast as it can. If the player leaves the enemy’s combat radius the Ranger will move into the PURSUIT STATE.

PURSUIT = The Ranger will follow the player but will also remain at its maximum range to be at a safe distance. When it gets close enough to the player in which it enters its combat radius, the grunt will change to its COMBAT STATE.

New Animations Needed for the Attack. Most of the code reusable from the grunt. Some of the code can also be reused from the Turrets. 

[tamagossowdev-blog]

Week 6

Time Total  - 17.5 Hours

Issue #47 - 2 Hours

Issue #21 - 8 Hours

Issue #4 - 2 Hours

Pressure Plate/NavMesh - 0.5 Hours

Issue #27 - 0.5 Hours

Issue #23 - 0.5 Hours

Team Meeting - 3 Hours

Boss rotation temporarily breaks if player jumps at it. #47 - 

changed from lookat() to Quaternion.LookRotation(); this made it only change its rotation in the x and z rotation but not the y.

However new glitch appeared, causing the boss model freak out and push the player around. 

Next tried using Quaternion.AngleAxis.

This caused the boss to rotate uncontrollably. 

However after removing all forms of rotating the boss, I noticed the same bug of pushing the player around was still happening. I concluded that this was always a problem with the collisions but wasnt noticed before hand because the Enemies would “get out of the way” when the player jumped at them. 

After a while doing other things I realised the solution. I made the bossEnemy’s RigidBody kinematic, meaning that only code would be able to affect it, not collisions. This fixed the problem. 

The player can get stuck along the side of platforms and walls #21 -

When the player would run into an object while jumping or falling the player will be stuck and wont fall until the player lets go. This was mainly a problem in the jumping puzzle where if the player falls it can latch onto the other platform. 

Another possible fix was creating a Physics Material and changing the Friction to 0 then adding it to the Terrain. Unfortunately this just made it so the player was able to run up sheer cliffs. I scrapped this and moved back to a programming method. 

I used RayCasts to check if the player was grounded and if the object in front of them was tagged as “Decor” as that was what the terrain was tagged as. With some debugging and testing I discovered the trees were part of the terrain and were also tagged as “Decor”.

However If I do use the above code to stop the player from moving anyway it partly works.

The problem is if the player jumps while traversing the forest they will stop abruptly. It will also prevent the player from doing the jumping puzzle.

Fixing the Pressure Plate and Navmesh

During the remodelling of the the pressure plate puzzle it was discovered that the Enemy wasnt capable of walking ontop of the Pressure plate. It was thought to be an AI problem so I was called into fix it.

I looked at what was happening myself and immediately knew how to fix it. I changed the Pressure Plate to be Static in the inspector and Baked the NavMesh, fixing the problem. 

I then realised that none of the decorations or other objects that should have been static were. And so I had to make them all static and bake the navmesh again. 

Camera moves through trees and assets. #4

At one point during the development process the Camera Controller we were using broke so it doesnt collide with the objects. This is particularly difficult in the maze as the areas are very enclosed and the camera continually going through objects makes it difficult to see. I first spent time decoding the original code to figure out what was happening, I then tried different methods to get it to work but could not. I thought it was maybe a problem with the scale but after much testing to didnt seem to work. 

Landing on terrain sometimes leads to "super jumps" #27

A lot of testing with the Animator and boolean values lead nowhere. I then realised if I noticed the rigidBody mass was set to 80 which seemed high. I changed it to 1 which somewhat fixed this issue. It is still slightly floaty but isnt as bad as it was before. Lowering it even further to 0.5 made it look much better. Im not sure what other problems this may cause at this moment. 

While testing the level further, the reproducible area was fixed but I found another place where, even with the 0.5 Mass it still performed a super Jump. It is very difficult to reproduce. 

Time power can be activated again while active #23 

This was easy. Added a boolean to the TimeFreeze script and added it to the KeyDown if statement.

[tamagossowdev-blog]

Week 5

Times

Refining AI: 2 Hours

Team Meeting: 3 Hours

Designing Boss AI: 2 Hours

Implementing Boss AI: 6.5 Hours

Total Hours: 13.5 Hours

An amount of time this week was spent finishing and refining the AI of the enemy. Getting the values correct and smooth. These values are still not 100% as they will most likely be changed to improve upon the combat of the game during testing, but for they know they are good enough for a complete build. 

During the team meeting we talked about what are the final parts of the game needed for the final build. One of the ideas we decided upon was a boss fight. Using the ideas we came up with in the group I was able to design what the boss would do each stage.

Normal (Not Empowered - Stunned) –

-          Small size

-          Normal Speed

-          Can be hurt

-          Stunned

Stage 1 –

-          Medium Size

-          Slow Speed

-          Cannot be hurt

-          Powered by 1 Pylon

-          Single Sweeping Sword Attack

Stage 2 –

-          Large Size

-          Very Slow Speed

-          Cannot be hurt

-          Powered by 2 Pylons

-          Area of Effect Stomp Attack

After this I was able to decide on a FSM suitable for the boss.

MOVEMENT STATE

-          The Boss will move continually move towards to attack the player

-          Will switch to Normal State if Pylon is turned off

-          Will switch to Attack State if close to player

ATTACK STATE

-          If [Stage 1] Swing with sword when player is within close range

-          If [Stage 2] Stomp with Area of Effect attack when player is in medium range

IDLE STATE

-          Used for when the player hasn’t reached the boss yet

STUNNED STATE

-          The Boss will remain still until empowered again

-          The boss can be hit during this state

-          Will switch to this state when all pylons are turned off

-          The boss cannot attack in this state

Using these designs i was able to implement the script for the boss enemy AI. The first thing I did was implement the states of the State Machine. 

I wanted the Update() to be nice and clean unlike the current implementation of the current GurntEnemy scripts. During the implementation I decided it would be easier for their to be 2 Combat States, one for each Stage in the boss fight. 

The movement state is very bare at the moment as it currently just adds the player as the Target. In a later edition, I would like to make it so the Boss predicts the players movement and moves to cut off the player. This means while the player is moving towards the pylons the boss is also moving towards the pylons, ready to attack the player. 

The Idle state is very similar as it is just meant to be used before the player is present, however I added code that removes the player as the target in anticipation of using it as a reset in the case the player dies during the fight. 

The Stunned State was easier than expected. I was anticpating needing to create more booleans to know if the the boss was attackable. Instead I realised the only time the boss was attackable was when they werent empowered so I decided to use that boolean. I thought what else does the enemy need to do when stunned, just stop and maybe play a stunned animation. So at the moment the the Stunned State is also very bare. 

I noticed the boss wouldnt have an ability to block attacks and therefore didnt require a shield. So I changed the MeleeWeapon Script to cater for if the Entity doesnt have a shield, otherwise I would have gotten Null Exception Errors. 

Some quick code to add damage dependent on the empowered state in MeleeWeapon. 

[tamagossowdev-blog]

Week 5 Team Meeting

Topics Discussed:

Merging new level design into the main branch so everyone can get a copy to add their elements.

Getting the rest of the puzzles in place.

Door Puzzle pieces - five in total, two already in place, player needs to collect 3 from the other puzzle areas, then place them in the right order.  No block pushing this time, as it’s not perfect and takes too long to complete.

Populating the enemies.

Ensuring the items and decoration are in place.

Finishing the music.

Finish designing the boss room.

Finish adding the shop model (and shopkeeper model).

Shop UI is done.

Animations are pretty much there.  Some polish remains.

Boss needs to be modeled - Either scale up a goblin, or make a new one.

Boss needs two specific animations created - Sweep Attack and Stomp.

Boss A.I. needs to be programmed once the plan for the Boss Fight has been worked out.

New boss fight has now been worked out.

[tamagossowdev-blog]

Week 4

Times

Testing AI: 1 Hour

“Fixing” Attack Spam: 1 Hour

Improving Enemies Block: 5 Hours

Block Testing: 30 minutes

AI Spacing: 8 hours

Team Meeting: 2.5 hours

Total Time - 18 Hours

I started by testing the AI to see if any major changes needed to be implemented other than the Spacing and Blocking. While I was testing the Enemies Blocking I noticed the player could spam the Mouse 1 button to attack and the attack sound would spam as well and be very annoying. I realise this was probably polish but I tried to fix the problem by editing the script to include the late addition of the 3 hit combo. 

However this just broke the 3 hit combo system. In the end, I added an Event to the attack animation that plays the sound. 

After this I improved the Enemies ability to block. To do this I made the timeSinceDamageTaken in the Health script public and made it so that the when the enemy is attacked they block. After 2 seconds of not being attacked the enemy will stop blocking and start attacking. This means that if the player attacks the Enemy constantly by spamming the Enemy will keep blocking. 

In theory, this would mean that if the player keeps hitting the enemy then the enemy can never attack the player. This could be fixed by making the enemy block absorb all damage meaning the player would have to wait to attack again. However it has “kind of” been fixed if there is more than one enemy. Also, there is a small glitch in the timings, I’m not sure what exactly what causes it but the timings are slightly off where even after the player attacks the player its possible the enemy still attacks the player and then starts blocking. The timings don’t happen every time so it is sort of random. This is something that can be changed and edited during the testing phase.

Next was, again, trying to implement the a suitable spacing method for the enemies. After a bit of research I had an idea to use the RandomNavSphere function currently being used for the Random Enemy Roaming. This required a lot of toying with but ultimately didnt work as the enemies were stopping before the player most of the time, or just running into the player continuously.

This was scrapped for another method which involved creating a list of Attackers that is limited.The first enemies to approach the player would be added to the AttackerList. Other enemies that get close would be pushed away from the Attackers until they are far enough away. There were a few problems with the Array at this point. However at this point I noticed my code was very similar to my original implementation from my original AI code that was scrapped for not working. 

[1st being new Implementation, 2nd being old implementation]

Due to the errors given with the array I removed it and tried to re-implement my old Spacing code but ran into the original problem with the Enemy being pushed away from the enemy. However this time I noticed I forgot to add the “hit.transform.tag == Enemy” if statement. Once this was added the enemy wasnt propelled away from the player instead only from other enemies. I then changed the “step” value from the MoveTowards to a much lower value and it worked almost perfectly. 

[You can skip to 30 seconds]

I realised that pretty much everything from my previous AI system actually worked and it was the scaling that messed it up to begin with. At this point I wanted to shoot myself so I gave up.

[tamagossowdev-blog]

Week 3

Times

Wed - 2 Hours (Debugging Current Block Fix) Sat - 2 Hours (Blocking Failed Implemented and Research to Fix Bugs) Mon - 6 Hours (Blocking Failed Implemented, AI Research and Planning) Tues - 11 Hours (Blocking Successfully Implemented, AI Research and Partial Implementation)

Total Hours - 21 hours

The Blocking was fixed early Wednesday before the Crit. After returning to the PC and doing some testing I realised it wasn't quite fixed. It was not doing the half damage like it should and the damage was still being blocked if the player was attacked from behind. Ultimately I decided the problem was the collisions not detecting the shield. 

Wednesday and Saturday was mostly spent coming up with solutions and debugging this problem. Due to no time with my computer most of this was just brainstorming ideas. 

Monday was spent implementing the brainstormed ideas. The first of which was a RayCast in front of the Entity being attacked to detect if the Attacker is in front the Defender.  

This did not work. It was detecting Hits but from my testing I believe the Attacker was too close for the RayCast to work as it was detecting things behind the Attacker. 

The next solution I tried was creating a Box Collider in front of the Defender. Again I could not quite get this to work properly.

The final solution was to use Vector3.Angle which worked. It will require some minor testing to get the angle working the best. 

While testing the blocking there a few things I want to tweak to make things more fluid. This includes not being able to press the arrow keys while blocking. However, I also want to make it so the W key is automatically pressed while blocking as it means the players model is moved with the mouse and camera rather than separately. 

After the blocking was implemented, some of Tuesday was spent researching and implementing new AI for the enemies. 

http://www.gamasutra.com/blogs/BartVossen/20150504/242543/Enemy_design_and_enemy_AI_for_melee_combat_systems.php

https://forum.unity3d.com/threads/simple-methods-for-achieving-fun-interactive-enemy-behavior.279319/

A good part of it is researching what makes good AI and what would be the best for this project. The first thing I wanted to implement was a timing system for attacking the player because at the moment they just attacked straight away. At the moment the player will attack every 2.5 seconds. 

The next thing I wanted to implement was Spacing mechanic when the Enemies is attacking so they flank around the player. I first used a Boid Behaciour code from a previous project. This however didnt work well. I then tried to implement the AI spacing from my previous GruntAI. Again this didnt work. I tried using the internet to find an answer. 

https://gamedevelopment.tutsplus.com/tutorials/3-simple-rules-of-flocking-behaviors-alignment-cohesion-and-separation--gamedev-3444

[tamagossowdev-blog]

Week 1-2

Times - 

3.5 - Team meeting #1 1.0 - Team meeting #2

6.5 - Goblin AI (Patrolling, Blocking, Alert, Detection) 5.5 - Player Blocking 0.5 - Blocking Redesign

Total Time = 17 Hours

Most of the time this week was spent on updating the Enemy AI. From the last time this was attempted, it would work until implemented into the project. With no easy fix we were forced to use a default AI controller. With this as a base, I was able to reconfigure my already existing code into the project.

The AI movement already worked. It followed the player and attacked them, this didnt need to be changed yet. Using the RandomNavSphere function created last semester, the enemies where able to be given a sense of patrolling. 

Using the AlertOthers code from last semester I was able to allow one enemy to alert multiple enemies to the players location within a certain radius. This did not work immediately and required some tweaking. Such as it was alerting enemies through walls. To fix this, I implemented another feature I already planned on. By using a simple raycast I made it so if the player was no longer in line of sight of the enemy, it would no longer follow them. This meant if an enemy was alerted through a wall but the raycast didnt hit the player, it wouldnt actually be alerted. 

Next was enemy blocking. Adding the block animation to the Grunt Animator Controller was easy, however the block animation was being played automatically after each Idle cycle. Eventually a team mates help was required to rectify this problem. 

However figuring out a suitable system for blocking and attacking has been difficult. A few different health/damage changes were tested however the actual blocking of the shield is not working yet [explained later].

Player Detection was the last to be implemented as it was the least important. A 10 unit distance around enemies worked however adding a field of view to the enemies may allow for more combat mechanics down the road such as stealth attacks. This was the most difficult to fix and still isnt quite complete. this will continue to be worked on throughout the next weeks. 

Because the blocking mechanic wasnt working, i decided to implement the blocking to the player and try to fix it. The animation was successfully added to the controller and works with the code when holding down “Mouse 1″ or the right mouse button. However, with the position of the ThirdPersonCamera it looks weird and is strange to control.

View from back

View from Side

This was removed so that the players camera isnt changed when blocking so it is easier to see and control. This can be changed later but for now it works.

View from Back

View from Side

The most difficult part was actually getting the code to work. It took a while to completely understand how it worked and how each script interacted with each other. After a mass amount of debugging the problem can be seen as the shield = collision.gameObject.GetComponent<Shield>(); returning a null value.

After getting acquainted with the blocking system and testing the Enemy AI I realised that the goal of fleshing out the combat and making it more interesting wasnt exactly achieved yet. This gave me and idea of updating the blocking mechanics. Adding events to the animations of the blocking can allow for timing for extra bonus’s. For example, if the player blocks, within the first section of the animation, if the player is hit they take double damage. In the next section if the player is hit they take no damage and the enemy is stunned. In the last section the player will take half damage. Adding timings to block can add incentive to the players to risk blocking early or late to get an advantage over the enemy. This is a system similar to the Gears of War reloading, in which timing it right can result in an instant reload and extra damage. 

[tamagossowdev-blog]

Semester Divider

Semester 1 has ended. Semester 2 has begun

[tamagossowdev-blog]

Times

Team Meeting: 1 hour 30 Minutes

Bug Squashing: 3 hours

Playtest Plan: 1 Hour

Playtest Report: 2 hours 30 Minutes

Overall: 8 hours

[tamagossowdev-blog]

Playtest Report

Tester 1

Before Questions

Familiarity with Video Games(1-5): 5

Hours Played Per Week: 50

3 Fav Game Genres: FPS, Driving, Fighting

Least Fav Game Genre: Dance    

How familiar are you with Puzzle Games(1-5): 5

How familiar are you with Adventure Games(1-5): 5

Notes

Time Stamp

Die the first time

00:39

Collected First Coin

00:55

Defeat first lot of  goblins

1:01

Died in Lava

1:38

Died in Lava

1:42

Got past jumping  puzzle

1:52

Die in Inventory  trying to use potion

2:14

Die in Lava “Im not  good at jumping puzzle”

2:40

Defeated Second wave  of Goblins

3:07

“Can I block?”

3:30

Arrive at the  perspective puzzle

3:40

Understands how to do  puzzle

4:21

Dies again

8:26

Lost in the maze

9:06

Beat 6 goblins at once

10:02

Gives Up

10:40

 After Questions

Easy to Learn(1-5): 5

Fun to Play(1-5): 5

Challenges had variety(1-5): 4

Combat was easy to understand(1-5): 4

Combat was enjoyable(1-5): 3

Puzzles were easy to understand(1-5): 4

Puzzles were enjoyable(1-5): 5

 Tester 2

Before Questions

Familiarity with Video Games(1-5): 4

Hours Played Per Week: 100+

3 Fav Game Genres: FPS, MMO, RPG

Least Fav Game Genre: Puzzles  

How familiar are you with Puzzle Games(1-5): 3

How familiar are you with Adventure Games(1-5): 5

Notes

Time Stamp

Very Confused

00:12

Died in lava

00:34

Died in lava

00:46

Died in lava

00:56

Died in lava (Wanted  to get all the coins)

1:20

(Called the Goblins  gremlins)

1:40

(Called the health  potion mana potions)

1:50

Reached the  perspective puzzle

2:00

Died to goblins

2:30

(Clipped on wall near  lava)

3:15

(Clipped on wall near  centre)

3:30

“Is there a shield”

4:25

Surrounded by 7  goblins and killed

4:37

Killed all of the  goblins

6:10

“This is so dumb”  (Perspective Puzzle)

7:35

“The voice line gets  annoying after a while”

7:55

Frustrated with  sluggish unresponsive movement

9:54

*Starts mimicking voice  line sarcastically”

14:34

“You fat f**k lose  some weight”

15:14

Zooms in while  standing on blue block causing a strange camera glitch

16:00

“If you run into the  corner of the blocks you glitch a bit”

20:50

“F**KING HELL”  frustrated at the sluggish movement

23:30

Puzzle gets stuck,  hits R button on accident

25:00

Died in lava

25:10

Presses P to reset  puzzle. Stands there for a minute hoping it will randomise into the correct  position

26:00

Pieces stuck again,  resets puzzle

27:42

“Whoever made this  dumb puzzle can suck a chode”

36:44

Taken headphones off

42:00

Completely turned  sound off

42:15

Completed Puzzle

50:30

 After Questions

Easy to Learn(1-5): 4

Fun to Play(1-5): 4 until perspective puzzle then 1

Challenges had variety(1-5): 3

Combat was easy to understand(1-5): 3

Combat was enjoyable(1-5): 2

Puzzles were easy to understand(1-5): 4

Puzzles were enjoyable(1-5): 2

The second playtester mentioned that we should include a second door earlier in the level that the player can use as a reference for the perspective puzzle, as it did take him some time to realise that he was trying to make a door. He also mentioned that the models for the Doorknobs in the perspective puzzle should be moved up slightly as throughout the puzzle they never looked like they were in the right position. Even after he had solved it, he said the doorknobs looked like they were in the wrong position. Both playtesters mentioned the ability to block and spent some time looking for a block button. For the jumping puzzle, the playtesters did not know what they were doing, and would just jump from platform to platform as fast as possible. 

[tamagossowdev-blog]

Playtest Plan

Date: Thursday 01-June-2017

Participants –

               Number: 4

               Who:

Overall Approach: Interview Questions before and After playing the game. Playing the game with Visual Recording.  Notes will be made during the session with timestamps of when it occurred. The Tester will play through the level once until completed.

Session Goals –

               Goal 1: Finding Bugs

               Goal 2: Overall Playability and Fun Factor

               Goal 3: Puzzles Playability and Fun Factor

               Goal 4: Combat and Enemies

Method –

What to Measure –

               Self-reported amount of fun and enjoyment in the game

               Ability to complete the level/puzzle

               Amount of fun and understanding of the combat and enemies

How to Test –

               Before and After testing the game, the player will be interviewed with a serious of questions.

               Observations made throughout the session, comments and remarks made by the player

How to Analyse –

Interview, reviewing game footage, reviewing notes taken

 Before Questions

Age:

Familiarity with Video Games(1-5):

Hours Played Per Week:

3 Fav Game Genres:

Least Fav Game Genre:              

How familiar are you with Puzzle Games(1-5):

How familiar are you with Adventure Games(1-5):

 After Questions

Easy to Learn(1-5):

Fun to Play(1-5):

Challenges had variety(1-5):

Combat was easy to understand(1-5):

Combat was enjoyable(1-5):

Puzzles were easy to understand(1-5):

Puzzles were enjoyable(1-5):

[tamagossowdev-blog]

Final Bug Squashing

·         Edited the Wall Colliders with the new walls

·         Navmesh was broken, enemies wouldn’t move. Made the walls Navigation Static and rebaked the NavMesh

·         Lava Shader was not working. Reimported the Lava Texture from a previous version.

·         Death reset in Jumping Puzzle did not cover the entire pit. Resized and moved to be inline with the lava terrain

·         Changed the Hurt sounds for Morpheus and the Goblins to a pre-recorded dialogue

·         Final puzzle can be reset if the player gets the pieces stuck

·         Reduced Enemy Count to reduce difficulty

·         Increased the potion healing amount from 10% to 25%