KIT507 Zombie Maze Week 12


KIT507 - Game Design and Production - Master of Information Technology Systems - University of Tasmania

Zombie Maze Main PageZombie Maze MTP Main

Developers:

                           - CHENGRUI ZHAO (MARK) 459793                            

                           - HOANG THONG PHAM (THOMAS) 487032                           

                            - XIANGNING YAN (PEARL) 226805

WEEK 12 - Beta Stage Update

Welcome to our Zombie Maze made by MTP!

We are MTP (Mark, Thomas and Pearl) who made a video game for teenager audience to enjoy. 

In this dev post, we will talk about how we were busy as we released a beta version of the game to testers to test bugs, receive testers' feedback and acquired helps and knowledge from the testers as well as from Mr.Wells. We worked together like what we did in week 11.


Clip of the beta version game:


This week was the busy one. The team participated a testing section which not only the team recorded feedback from each tester who tested the group's game but also acted as the testers for other group. Recalling, the group prepared a testing form for the testers to fill feedback after they finished testing the game


HOW THE TESTS WAS DONE:

Test by our group team members, classmates and the teacher
               - The tester started playing the game
               - The developer recorded feedback from the tester during the test
               - After the test, the testers completed a questionnaire


The testers were from a different group of classmates in the same tutorial class who had the same game design knowledge as mentioned above. The playtesters were optimistic with the gameplay experience as well as provided useful feedback during they play the game and after they finish the game. In the group, Thomas and Pearl took places to record the bugs and errors during the playtesting, while Mark was responsible to feed the players with information that they asked. At the time, Thomas recorded the bug when the players interact with the environment while Pearl recorded the bugs and the problems that players found and felt by themselves; Mark explained the goal of the game and provide further instruction for testers. Later on, when two members tested other group’s game, one would stay to record and let the tester know what they wanted to hear and record further bugs and errors. After the testers played the game, they were asked to fill out a form so the developers could record the information and remind them of the errors and bugs found from each participator.


Additionally, Mark, Pearl and Thomas were responsible to test other games from other groups to provide them feedback. Often Pearl would test the game while Thomas noted down what necessary problems and errors were to let the developers know after Pearl expressed her idea about the gameplay experience. On occasion, Pearl, Mark or Thomas took place to one person returning to their place to record the feedback of the testers while the other two tried out the gameplay in the whole room.

TRACKING BUGS:

Here are the lists of bugs recorded that both seen from the testers and the team:

  1. Fly up to the sky for a short distance when walking near the zombie
  2. Light condition is worse as the whole scene is very dark
  3. Framerate is decreasing from 60 fps to 15 fps after 5 mins initiating the game 
  4. Shotgun change cannot be used with number pad 3
  5.  Slow weapon switching when the player presses the number pads or scroll the middle mouse to change weapons
  6. Tree stuck glitch when players interact with a tree in the game level
  7.  Stuck at the door when the player triggered the door open
  8.  Zombie is spinning around after he dies when the player goes around them and shoot them at blank range
  9.  Map lighting becomes worse when the player goes in a room

Video Clips of bugs seen during development:



FEEDBACK RESULTS:

What testers Like:

  1. FPS game
  2. Good gameplay
  3. Shooting zombies
  4. The weapons variety
  5. Crosshair
  6. When the player shoots, there will be a spark (gun’s muzzle flash)
  7. When Zombie is hit, his body will bleed

What Problems to be fixed:

  1. The lighting, it was hard to see objects and paths
  2. How to win 
  3. the size of Bench and the size of Zombie (the height of the user feels like the player is a bit short)
  4. Map bleeding
  5. Gun Damage is lower (shooting too many times)
  6. The text of collecting key is oblique
  7.  Introduction of the aim of the game like grab the  key and get away from the maze
  8. the speed of switching weapons is slow
  9. map Gap
  10. The speed when Zombie is  dead and disappear
  11. Introduction in black background with white text as the text is not clear in red
  12. Add menu  to start the game
  13. minimap (the player, zombies or the important things are not clear on the minimap)

The suggestion from Lindsay Wells - tutor of KIT507 on Tuesday at 12 pm

  1. Give the greeting and instruction UI has a white background with black text or background with white text instead of red text
  2. Menu UI may be required according to KIT507’s criteria
  3. Mouse sensitivity: too fast and the gun follow a direction even after the mouse stopped moving
  4. Create a readme file where it put a credit of the developers who are responsible for the specific task in the game design
  5. Improve the interaction with the game world


HOW IMPORTANT BUGS AND PROBLEMS WILL BE ADDRESSED? 

Bugs:
1. Fly up to the sky for a short distance when walking near the zombie
Solution: the group will check the components on both the zombies and the players, research on the
mechanism of the unity physical engine and figure out why the bug happens. Maybe the group can
disable the rigidbody on the zombies.
2. Shotgun change cannot be used with number pad 3
Solution: Add the gun switch logic for the shotgun into the gun script and ensure it works.
3. Tree stuck the player
Solution: the group will adjust the colliders on the trees and player so that reduce the conflict better
group these components.
4. Player stuck at the door
Solution: the group may try to adjust the colliders on the doors and player. Also, the group may try
to expand the available space around the door to avoid this problem.
5. Zombie is spinning around after it dies
Solution: the group will test on both the rigid body and capsule collider components on the zombie
to fix this problem.
6. Map Bleeding
Solution: Try to adjust the NavMesh to stop zombies from walking closely to the barrier. Also, put
suitable collider on the zombies and gun models.
7. Map Gaps
Solution: ensure the components of the map are seamlessly connected together. Also, add the
invisible barriers (using collider) to avoid the player getting to an unreachable place.


Game improvement:
1. Map lighting problem
Solution: the group will add a dark skybox as background and put some suitable light sources on the
map, such as the lamp, fire and spotlights. Also, the group will ensure each fire particle effect has a
light source component.
2. Size of object
Solution: Try to adjust the size to a reasonable scope.
3. Useful Minimap
Solution: Create a minimap which shows the roads in white and rooms in grey. Also to include some
icons representing different ingame entities. Add arrow signs on the minimap to guide the players.
Set the background to black colour for clear viewing.
4. Other settings
Solution: Adjust the gun damage and switching speed; Write a clear guide for the gameplay; Reduce
the disappearing delay after zombie died; Recreate the texts on the keys; Create the main menu.  

--------------------------------------------------------------------------------------------------

Using the feedback information collected from the testers, the team continued to complete the game with improving the mechanism as well as fixing bugs and errors.

PEARL UPDATE:

- Looking for a new zombie look

- Update the minimap and fix bugs (eg. gaps in the map). Originally the minimap had been developed by Mr.Wells in the week before. Then Peal seek the knowledge to improve this minimap to be more. Reference  to new minimap making:


MARK UPDATE:

Zombie Deal damage to player

At first, we created a player manager script storing the data relevant to the player, such as health and number of keys. Although it is easy to create the script controlling the player’s health, the problem raised up when we tried to pass the damage to the player. The desired outcome is the damage only cause once per hit, so the attacking animation needs to align with the damage passing mechanism. We tried to achieve this by setting a trigger on the zombie’s claws, but it didn’t work perfectly to pass the damage. Then after searched the solution online, we found that it is possible to call specific function when the animation is playing. This solution can accurately and easily fulfill our need and we wrote a logic which measures the distance between player and zombie, once the zombie comes closely to player, the damage passes to player along the animation playing. To fit the collider on player, offset distance is added to the script (See image below). Besides, when the player’s health reduces to 0, the game ends.


Image. The EndAttack function called in the animation


Image. Setting of the animation for calling the EndAttack function

Also, the zombie shouldn’t keep clawing the air when it is still far away from the player. Thus, the distance calculation method helps manage the animator and play the right animations in specific distance.


Image. Zombie moving AI

 


Gif. Zombie hits the player

Player Deal damage to Zombie

The script on the bullet defines the damage of specific gun and the raycast method helps detect if the bullet hit the zombie. Once the zombie is hit, the damage parameter is passed to the zombie health script by the bullet script to change the zombie's health (See image below).


Image. The script passes damage from bullet to zombie


Image. The zombie health script

We created a health bar above the zombie so that directly show the current health of zombie. Once the zombie’s health reduced to 0, it dies and script invokes suitable dying audio and animation. Since we found the dead body will still follow the player before it is destroyed, Mark sets the navigation function to the current transform of the zombie when it died and the bug has fixed.


Gif. Dealing damage to zombie and kill it


Bug Fixing

  • Zombie push player/ Flying bug
  • Optimize Nav Mesh/ zombie across or stuck
  • Advanced mini map
  • Adjust the scope of the map/ map gap
  • Adjust gun damage, key text, gun3 switch, object size

Mark found the player movement is based on the Unity physical engine and there were rigidbody both on player and zombie prefab, so the zombie will add force to player and kick the player to sky. This bug was fixed by disabling the rigidbody component on zombie and use the distance method to keep zombie from walking to close to player (See image below). For example, the Navigation AI only will lead the zombie to player when the distance between two entities is far enough.


Image. Scripts for fixing the pushing bug

 

The bug caused by the problematic Nav Mesh generation. Strangely, some rooms have complex structure failed to generate the right walkable area, so we manually added some Nav Mesh obstacle on some barriers, such as internal walls, furniture and trees (See image below).


Image. Manually added some Nav Mesh Obstacle to the scene


Image. Setting of Nav Mesh Obstacle component


Image. Nav Mesh Baking round the trees


Image. Nav Mesh Baking round the boxes

 

We added more details on the mini map and set the darker background which improves the looking experience.


Image. First version mini map


Image. Latest version mini map

 

We added some invisible collider to keep player from walking out of the map (See image below).


Image. Map gap fixing by extending the existing collider


Image. Map gap fixing by adding new collider

THOMAS UPDATE:

Loading scenes fixed by Wells


Loading scenes fixed thanks to Mr.Wells. One of critical things why the loading scenes were not worked because Thomas didn't build the application which made the script not worked. 

Then Thomas recorded what he could fix so he could do in the next week where Mark and Pearl finished their parts.

Leave a comment

Log in with itch.io to leave a comment.