Table of Contents

...................................................................................................................................................................... 1 Evil Resident: Student Edition ....................................................................................................................... 3 How Closely the Game Meets the Original Specification ............................................................................. 3 Challenges in Development .......................................................................................................................... 5 Aspects of the Game that went well............................................................................................................. 7 Aspects of the Game that didn't go well....................................................................................................... 7 Testing Strategies .......................................................................................................................................... 8 Black Box Testing ...................................................................................................................................... 8 White Box Testing ..................................................................................................................................... 8 Beta Testing .................................................................................................................................................. 8 Overall view of the game from testing ......................................................................................................... 9 Changes made after Testing ....................................................................................................................... 14 Camera .................................................................................................................................................... 14 Targeting System..................................................................................................................................... 14 Health packs ............................................................................................................................................ 14 Attack speed ........................................................................................................................................... 14 Appendix ..................................................................................................................................................... 15 Raw result data ....................................................................................................................................... 15

Evil Resident: Student Edition

Evil Resident is set in a 3D environment platform, where the player can navigate through the environment and control the characters actions in order to complete the objectives set out in the start of each level in order to complete the games objectives. The game is a 3D short role playing styled game. The game has been designed in a way that allows the user to complete short levels that are easy to navigate and pick up the use of the controls easily. Players that have not played this type of game before will not have a problem playing the game as it is selfexplanatory; the full controls are listed when loading the game. When the game is first loaded you will see the title screen which will allow you to start the gameplay. Also listed on the main page is a full list of all usable controls that the player will need to navigate through the environment and complete the game. When the game initially starts the Laura character will realize what has happened to you and inform you that you are now a member of the undead and run away from you leading you to enter the University. Once inside the real fun starts, you must make your way through the levels ensuring to kill as many human students still surviving, regaining small amounts of health from your attacks and larger amounts from eating the brains left lying around the building. With the end aim of getting to Gerry's room on the last level and starting the boss fight to complete the game. After the user has completed the game it is a simple case of restarting the game to try and beat your previous times that it took you to complete.

How Closely the Game Meets the Original Specification

The original story of Evil Resident begins with the main character Ali waking up outside the University campus having being bitten which results in him being transformed from human to zombie. Ali then meets companion Laura and bites her. She then runs away and comes back into the game at a later stage to accompany Ali through his game. In the final version of the game, our team decided that we would start the game with Ali standing at the entrance to the University and walks up to greet him, discovers he is a zombie and then runs away. Laura has been changed from Ali's companion throughout the game to a character that has a small appearance at the beginning. In the original storyline, Ali enters the UWS building via the main entrance which takes him to the reception area. He would then follow a trail of blood which would lead him to the zombie form of Laura. Ali then attacks human non-playable characters that attack him back. If Ali succeeds, he gains a new ability. In the final version of the game, Ali enters the building as originally planned but does not follow a trail to find Laura. Ali attacks the human non-playable character that attacks him back. The original plan was to have the generic characters being killed and changed to zombie form and helping Ali infect other generic students. In the final version on the game Ali has to attack eight generic students to complete Level 1. Once Ali has beaten the generic student, they fall to the ground and die, not returning in zombie form. The character of Ali gains no new abilities after killing a generic student but can replenish his health by touching a brain which can be found randomly throughout the game.

In the original plan there was stairwells in the building to indicate the movement of the character moving from one level of the game to another. In the final version of the game, a quest system is used to indicate that the character has successfully completed all aspects of a level to proceed to the next one. In the final version of the game the levels have stayed more or less the same as the original plan, the levels consist of the main character killing a required number of generic students to achieve access to the next level. In the original plan, the character has to find a key to access the room where the final battle will commence, featuring the boss Gerry. In the final version of the game, the character has to locate the key, which is the very back of one of the lab rooms, and is made noticeable with the help of a golden flare. In this level, the character not only has to find the key but has to kill a required number of generic students to proceed to the next level of the game which is the final boss. In the original plan, the character opens the door to the lab room where Gerry is. There is a battle and Gerry transforms into zombie form. Gerry then escapes the room and runs upstairs to where he finds access to the roof using a set of ladders. The character then follows Gerry onto to the roof where the final battle would take place. Zombie Gerry then begins to hover above the roof where the aim of the game is for the character to use the projectile vomit ability to blind Gerry. The character can then use his fork-like tongue ability which has just been gained to finish Gerry off and win the game. Losing the game would result in Gerry defeating Ali and being redirected back to the start of the final level. In the final version of the game, the character gains access to the room where Gerry is waiting, a battle takes place and depending on which stage of the battle the player is at, the character can replenish his health by touching the brains which will appear. Once Gerry has been defeated, the player will be informed that they have completed the game and the game will end with the closing credits. If the player is unsuccessful in completing the game, they will be redirected back to the very beginning of the game to try again. The final version of the game is somewhat shorted that we originally planned. However, we think our team kept the story of the game as originally planned.

Challenges in Development
By the end of last trimester we had a sandbox game, a sandbox game is where there is an environment where the user can walk about and view the background models. An example of this would be a game called mine craft which can be viewed at www.minecraft.net. Myself, Alistair and Mohammad were appointed the role of developing the game. We started off by created a camera and movement control for the main model. This entailed a controlling system which the user would use to move the character and a camera control that would follow the controlling system. We went for the basic keyboard and mouse layout because it would be released on PC only. Once the controllers were added we created a collider so that objects such as walls and other npc (non-player able characters) would stop the user walking through them and causing issues. The next step was modeling some enemies. Our first idea would be to use the existing model and change the UV mapping and the animation rig. We had some issues with this. The new UV map was slightly transparent where you could see through them. We later found out that the shader used was a default one which allows transparent features; we changed this to a diffuse state which fixed this issue. The next step was to fix the animation, the animations seem to make the model 3 times larger and look like a large thin stick figure. This wasn't what we intended. A whole new model had to be created with new animations which didnt take long with the knowledge that we gained from making the last model. At this stage we had 2 working models with multiple UV maps for both. The next stage in development was to create a combat system. The combat system entailed of 6 main scripts which included User Health, Enemy Health, Enemy AI (movement system for enemy), User Attack, Enemy Attack and a Targeting System. Each script tied itself together with each other. The first issue we had was with the Targeting System. The idea was to push a button and the game would select the nearest enemy and allow the user to attack this target. The selection of the enemy was only visible by a health bar that would appear below the players health which wasnt noticeable. We also had an issue with all the health bars of all the enemy's within the array of the targeting system showing. This was soon fixed by only showing the health bar of the selected target. The enemy AI system was found to be an issue, with the enemy's all targeting the main character and walking through walls and objects event though we had applied d a mesh collider. This was amended by putting event colliders in each hallway which triggered the Enemy AI from an OFF state to an ON state which seem to resolve this issue but after some testing the results changed once the player left the room. The Dead body would get up and walk towards the player. This was fixed by a destroy command on the trigger which removed the trigger event from the game. The next issue was getting the health sorted. This entailed how much damage the player and enemies would apply. We first set them both to 10 from attack of the enemy's and attack of the player but found this very hard and each battle would be close, so we reduced the enemy's attack to 5. This seem to make it a bit easier but found out later that we had to add health boosts to sustain the game play. The health boosts were creatively disguised as human brains which returned 25 health. This allowed the player the complete the level with only a little bit of trouble. Once we had a few enemies to kill we added in a death result from both enemies and player. When enemy dies we created a quest system which counts the amount of enemy deaths and once it reached a pre-set limit it will allow the user to continue to the next stage. When the player dies we created a splash screen image that will display that the player has died and return them to the start of that level.

Once the first and second level were completed we done some black box testing and found that the game had a graphic leak. This resulted in 1.2 frames per second on a high end gaming system. The graphics card was receiving over 1500 draw calls per second. A draw call is how many objects the graphics card must render for each model. This seem to occur from 3 main models. The computer screens, mouse and keyboards. Each model would reduce the frame rate by 20 frames per second and we had 7 per room and 8 rooms in total so this became a very large issue. After about 4 days of testing it was down to lights and camera within the model. A reimport was needed. Removed some polygons, lights and camera from all models and exported them back into unity. This resulting in a nice 80 frames per second with a total of just over 100 draw calls. Once the inner rooms where done we added in a mission complete system. This system would detect if the objectives are complete and if this is true it will allow the player to access the next level. Each mission is different. The first mission is to follow Laura into the building which can completed by entering the building. On the next stage the mission is to kill 8 humans, after killing 8 humans it will allow the player to continue to the next level by entering the door at the end of the hall. On stage 3 the player must kill 8 humans and collect a key which will allow access to the final room. Stage 4 will ask the player to kill 5 humans and then use the key to enter the final room. All this information will be displayed at the right hand side of the screen. Within the final room the player will face themselves with a boss. The boss will be based on a real life human called Gerry. The boss will have 200 health and hit harder to make it more of a challenge. We increased the boss attack damage to 10 and his attack speed to 1.7 attacks per second. We found this very hard for the player to kill the boss so we decided to add in health boosts. The best way to do this would be to make him drop or spawn health boosts at certain health. We created 5 health boosts and the idea was to have one of the spawn once the boss reached a certain limit of health. We had issues with this were all the 5 health boosts would spawn once the boss reached that limit of health. By placing this code into the attack function and not in the update function it fixed the issue. The next issue was setting the health limits and the spawn rate times. The health gained from the health boosts were increased to 30 from 25 and spawned at the following boss's health limits: 170, 140, 100, 70 and 40. This allowed the player to seem like it was very hard but the outcome would be rather easy as long as the player collects the health boosts. The final part of the game was to add sound. The sound files were already selected all that was left was to edit them and code them into the right place. We added sounds to buttons, opening screen, background music, opening doors, collecting health boosts, enemy's dying and player death. We asked Gerry to create some sound samples of attacks and general battle noises. Gerry got back to us within 2 days of this request with some excellent sounds. We created a random sound generator which would randomly play 1 of the 11 sound files during combat with the boss. Once this was completed we created a website with help of a free hosting company which allowed us to upload our game onto a unity web plugin. We also added in a file download so that if the plugin didn't work the user could download the executable file to the PC or MAC and play the demo.

Aspects of the Game that went well

Parts that where worked on individually the team needed next to no alteration to get it working together. This saved us a lot of time and a lot of problem solving but obviously it needed small modifications to make it all work. The models where all created and textured using Blender. The characters models are consistent in styling and appearance because we decided we wanted them to look more like funny than scary. Creating them was difficult as we were learning as we went along but got to grips with it fairly quickly and began creating models on a daily basis and then began texturing them making sure that they were all consistent with the rest of the art work in the game. The sounds we used where all covers from artists on YouTube and had allowed us to use them. We managed to find a lot of open source sound files that we used in the game like the creepy music in the background of the game. The attack system that we have created ran nicer than we had initially expected and smoother than we were hoping for. The animation was also very smooth and ran just the way we wanted them to. Milestones that we had set when developing the game where met by all members of the team apart from the testing. Although we missed the testing we managed to organize and set up other ways of getting the game tested within a few days.

Aspects of the Game that didn't go well

There was a few things that didnt go as planned but we managed to address these issues. The animation had a few major problems. One of the problems was when attaching the animation to the model it would not move correctly. It would warp any move the sections of the model that should not have been moving . Unfortunately everything that we tried did not work and as a final resort we created the model and only after doing that it worked as it should have. We were planning to have different animations for the main character including a breathing animation when standing still, projectile vomit, the tongue lash animation. The breathing animation was scrapped because it was interfering with the attack animation that was used. Unfortunately the animations for the projectile vomit and the tongue lashing were not added due to time restrictions but are in the to-do list for future plans of the game. We were also planning to randomize animation sequences for the nonplayable characters so they are not just standing waiting for the main character. Again this is in the to-do list for future development of the game. We had initially planned to create a few different styles of rooms like we have in the university. We were planning on have a lecture hall style room without any computers but were forced to use the same room layout for all levels due to the time that we had available. We wanted to randomize the textures of the non-playable characters by creating different tops, bottoms, shoes and faces and randomize how the non-playable characters looked but again due to time restrictions we were unable to work on getting the characters to randomize.

We had some issues with the camera. It became glitchy when walking into a room if the camera was past a certain distance from the character. We also wanted to address the issue that people were having when playing on laptops. We received feedback that it was difficult to scroll out and adjust the camera due to the scroll on the track pad of a laptop. We wanted to also be able to adjust the camera using the two customizable keys (e.g. 9 and 0). This was one of the issues that we will be addressing in the near future. Throughout the coding phase of the game the only main problem that we encountered was with the targeting system. Initially we had it able to tab through all the enemy mobs and attack with no problems. The issue we had was when an enemy mob died and tried to de-spawn it would crash the game. We eventually had to change how we handled death in the game and instead of allowing the enemy mob to de-spawn we changed it so that death would initiate a death animation and leave the mob on the ground still targetable which solved the problem.

Testing Strategies
On testing this game we used both Black box and white box testing methods to ensure the game was working properly and efficiently.

Black Box Testing

Black-box testing is a testing method used on software to test the functionality of the application as oppose to the internal structures or workings of the program. Black-box testing does not require any knowledge of the programs coding or internal structure or even any programming knowledge. It uses test-cases built around specific requirements to determent if the application does what it is supposed to. Both valid and invalid inputs are entered into the program to determine if the program works correctly judging by if the program produces the correct output.

White Box Testing

White-box testing is a testing method used on software to test that the internal structures or workings of the program as oppose to testing the functionality. White-box testing requires an internal perspective of the program as well as knowledge of programming in order to design test cases. The tester selects inputs into the program in order to exercise paths through the programs code in order to determine appropriate outputs.

Beta Testing
Our target audience originally was aimed at students at the University of the West of Scotland and we planned a demo with the second years of Game Development. We spoke with Chris who lecturers this class on Fridays, we agreed with him to allow us entry after 10:30 on the 26th of March. Richie spoke with the class and they all agreed to beta test our game. Unfortunately the night before we had issues with the targeting system and without that it felt that the game was unplayable. We spoke with Gerry and Chris and resulted in canceling the beta test and aiming to release this to friends and family the next week over the internet. We received positive feedback mostly this way, but we all think it could have been totally different results if aimed at strangers.

Overall view of the game from testing

We created a Google document with allowed users to leave feedback on our game. We asked the following questions: Name

We choose this so that we could ask the person in question a bit more about their feedback if they were vague Age

We decided to get a age limit for the game, we created this with a aim for students ages between 16 to 30 which is aimed towards a more mature gamer.

Age of Players
9 8 7 6 5 4 3 2 1 0 16-24 25-34 Age of Players

How often do you play games per week?

This question was to see what the players knowledge of games such as controls, how games interact and such.
9 8 7 6 5 4 3 2 1 0 1 to 5 hours 6 to 10 hours 11 to 14 hours 15 to 20 hours 20+ hours Series1

What type of games do you play?

We tried to gather information about what types of games that the player plays to see if they match our type of game.

Players
12 10 8 6 4 2 0 Players

What platforms do you usually play?

This question is also related to the previous question, trying to gather information about the player to see if there sets of skills could be applied to this game.

Platforms
12 10 8 6 4 2 0 pc ps3 xbox 360 mobile previous gen Other Platforms

How would you rate this game [Theme of game]? This question was aimed at the general idea of the game, whether or not if it was a good idea, if it was a common practice to run this theme or if it was unique and something new.

Ratings of Theme of Game

10 9 8 7 6 5 4 3 2 1 0 Excellect Well Done Average

Ratings of Theme of Game

How would you rate the Design of the game?

We tried to ask the player how the design was of the game, the graphics, in the input and the output of the game, it was entertaining or not.

Rating on Design
10 9 8 7 6 5 4 3 2 1 0 Exellent Well Done Average Could do better

Rating on Design

How would you rate the speed of the game?

This question was asked due to black box testing results, some of the developers found that the speed of the game could be improved but wanted to keep the feel of the zombie motion still there.

How could we improve aspects mentioned above?

This question was asked to allow the player to explain in a bit more depth about the rating of the theme, design and speed. What part did you enjoy most?

This Question was asked to see how much the player enjoyed playing the game. As this project was created for enjoyment, this question will affect how much we will have to change in the final modifications. Was there anything that annoyed you or forced you to rage quit?

This question was very similar to the last question but pointed in the opposite direction. This was to see if the player did have any problems or hates about the game and what we could do to improve the enjoyment of the game. What would you add, remove or change to improve this game?

This was asked to gather information about exactly the player didn't like or anything that the player might find more enjoyable and bring them back to play again.

How many error or bugs did you find?

This was for the players to identify any bugs within the game and help us fix them. From the results there was a few but only ones that we were aware of which was a great result. can you specify what kind of error/errors you encountered

This question was to expand on the previous question, asking the player to give information about the bugs/errors that were found gave us more in-depth information about problems. How much fun did you have?

This question was very much like "what part did you enjoy most", asking the player how much fun on a rating from 1 to 5 provided us with a good result between 3 to 4. With a no budget we managed to create fun for the player

Rating of Fun
7 6 5 4 3 2 1 0 I loved plaing it more than I expected So so Not Much Rating of Fun

Anything else you would like to mention?

This question was added so that the player could add in more information about any other question, sum up what they have said and provide extra information for us to evaluate.

From the testing and the data provided by the players, I think we gave a good impression to the small market that we have hit what Team-Ignition can provide and have set up a small friendly community which will play our games again.

Changes made after Testing

Camera
When we read over the surveys of the beta-test we found that a lot of the players had issues with the camera. At some points the camera was glitchy going into rooms and at some points the camera zoom was not working. We resolved this problem by changing the depth of the camera to 0.

Targeting System
We noticed that from players involvement of the game they found difficulty understanding what enemy was selected. We decided to add a highlighting effect on the selected target enemy which allowed the player to understand what enemy was selected and able to control the game a little better.

Health packs
People testing the game had indicated in the survey that they felt that more health packs should be made available as they found that the game was difficult to play as health rapidly deteriorated and no health was available until further in the game which made it difficult to proceed. We resolved this problem by adding extra brain health at more regular points of the game.

Attack speed
Some people, who tested the game, indicated in the survey that they felt the attack speed was far too slow. Although zombies are supposed to move slow they felt that the attack speed could be improved as the length of time taken to kill a non-playing character was taking far longer than they would like. We resolved this problem by reducing the attack speed to 1.7 which speeded it up efficiently

Appendix
Raw result data
http://www.sendspace.com/file/phg2h2

Or Check attachment at bottom of page.