University of Manchester School of Computer Science Project Report Universalum the Universal Game. Author: A. Prohhorov

Transcription

1 University of Manchester School of Computer Science Project Report 2016 Universalum the Universal Game Author: A. Prohhorov Supervisor: Dr. V. Pavlidis 1

2 Abstract Author: Andrei Prohhorov The aim of the project is to produce a game for Android that can will have modifiable parameters, such as graphics, difficulty, length etc. These parameters will be selected by players prior to playing to fit the game to their needs and preferences. Unity will be used as the game engine for the project. Supervisor: Vasilis Pavlidis 2

3 Acknowledgements I would like to thank my supervisor Vasilis Pavlidis for all the support provided throughout the making of this project. I would also like to thank friends who provided moral support while making the project. 3

4 Contents Table of Contents 1 Introduction Motivation Aims and Objectives Background Selecting a development platform Selecting game engine Design Requirements gathering Gameplay design Gameplay Customization system design Mini games Platformer mini game design Tower defense mini game design Logical mini game design Methodology Planning UI design Designing the plot Implementation Scenes Customization system Platformer game Player movement Enemy movement Animation controller Tower defense game Turrets

5 4.4.2 Enemies Enemy waves Player health Turret-enemy interaction Testing Unit testing Other testing Results Evaluation Aim evaluation Feature evaluation Future development Conclusion

6 List of figures 2.1 Worldwide Smartphone OS Market Share Preferred graphics Preferred game genres Screen transition chart Initial menu design Method for swiching scenes Example of a scene Updating the graphics value Linecast demonstration Character walk animation Conditions for walking animation Transmissions between animations Main menu Customization screen Story screen Platformer with fancy graphics Platformer with minimalistic graphics Tower defence game Appendix Appendix

7 7

8 Chapter 1 Introduction The following report will describe the process of developing a mobile game application and all the experience related to it. The report shows how the project was designed and implemented together with any research that was done in order to achieve success. The purpose of it is to gain sufficient experience in developing games and in particular mobile games Motivation Most of the smartphone owners nowadays play mobile games to some extent. And the Google Play market is being flooded with tens of thousands of new apps monthly. There are also a big number of clone games on the market, which mimic one another with small differences. With all those games to choose from we sometimes wish to download one game and tell it exactly what you want it to be. That is what I tried to create in this project, a universal game. You tell it what it needs to be, it shapes itself according to your needs. It is quite obvious that it is impossible to satisfy every single user s preferences, but nonetheless it is worth a try Aims and objectives The main aim of the project is to implement a working mobile game with an extensive modification system, consisting of multiple popular mini-games and supporting different playing styles. With that I aim to gain a better understanding of game development process, practice developing a mobile app and to gain experience in working on long-term software development projects. I also aim to get experience in working on a large-scale project using an existing engine, as opposed to spending time on writing a game engine from scratch. Breaking it down into objectives, I can identify three of them: 1. To implement in the most efficient way the customization system that will ask a player for all select an option for each modifiable parameter and combine them all together in a personalized game. 8

9 2. To implement a minimum of three mini-games together with all the possible customization options that can be added to them. 3. Write a plot for a game and put the mini-games and the customization system together into a game. 9

10 Chapter 2 Background Prior to the design and development processes there was a need to perform some research on developing mobile apps and related areas. Some crucial fundamental decisions had to be taken as well. This chapter provides a short summary of that Selecting a development platform As I have decided to make a mobile app and there exist multiple widely used mobile platforms, a decision on what platform to choose had to be done. Figure 2.1: Worldwide Smartphone OS Market Share My preferred phone OS is Android, as I have used it for multiple years now and am quite familiar with it. Android is also the most widely spread phone platform in the world. As shown 10

11 in figure 2.1, Its market share exceeded the 80% mark in 2015, whereas it s next competitor, IOS has less than 20% of market share. Android is also a very convenient OS in terms of development as there are multiple popular engines that support it and the documentation is easily accessible. Testing would also be more easy for me as most of the people that surround me use Android phones, so there is always a wide range of devices to perform tests on. Considering all these factors, I have selected Android as the platform for my game Selecting a game engine Because Universalum is supposed to be a large game consisting of multiple mini game that differ in the implementation and a big number of different customizations it was decided to use an existing game engine, as opposed to writing one. The aim of the project When it comes to choosing a game engine, there are multiple choices available today. A set of criteria needed to be created to select the most suitable one. In order of decreasing importance: 1. Price I needed the engine to be free, because I couldn t afford paying for it. 2. Documentation availability 3. Active community Marmalade a good and widely used game engine with cross platform development and a 2D development kit available. Had a free version with apps showing up on the screen and limited extensions. Construct 2, LibGDX game engines available for free, had a wide selection of tools offered for 2D development with decent amount of documentation and forums available for questions. Unity perhaps, one of the most popular game engines in the world with a big amount of features, very big and active community and 2D development tools available. Used to be proprietary before, but became free some time ago. These are the best options that were considered, but in the end, Unity engine was selected for the project due to the very good 2D development support and big amount of available documentation. 11

12 Chapter 3 Design This chapter describes the process of designing each particular feature of the game. Starting from gathering requirements and preferences from different people to decide on which features to implement and ending with designing the features of mini games and creating a plot for the game Requirements gathering Before starting the design I decided to make a questionnaire to see what different people's perception of a perfect mobile game is. This was needed to identify the possible modification parameters for the game and then split each parameter into a list of different options. The questionnaire was completed in total by 20 people and provided a satisfactory result. The results made it possible to see that it is in principle very hard to satisfy the needs of all people at the same time. This is due to the fact that opinions and preferences split into a wide range of answers for every question. For example, figure 1.1 shows the percentage of people preferring fancy or simplistic graphics in games. In this case we don't have to take a decision on what to implement and what not to implement as there are only two options. If we add these two types of graphics we will already satisfy all the players. 12

13 Figure 3.1: Preferred graphics The situation becomes more complicated in case of a question with a larger number of choices. A good example of that is a question about the preferred game genre. The answers to these questions are shown on the figure 1.2. When it comes to genres, most of the people actually don't have one favorite. And because the number of games I can implement is limited by the time boundaries, I selected three most popular choices. These happened to be strategy (8 votes), logical (8 votes) and action (6 votes). Other popular votes, such as Educational (5 votes) and Puzzle (5 votes) were considered as features that might get added later on. 13

14 Figure 3.2: Preferred game genres 3.2. Game design Gameplay The gameplay consists of playing multiple mini-games that act as tasks or obstacles in a big story. In the beginning the player selects his desired preferences (game length, graphics, setting), after that he is being presented with an introduction to the story, after which the player has to complete a mini-game. After successful completion he is being shown the continuation of the story. After that he needs to complete another mini-game and so on until the end of the game. 14

15 Figure 3.3: Screen transition chart Customization system design Before the actual gameplay starts the user must complete the customization process. It begins immediately after the user presses the start button. First he is being asked to select a setting, which is basically the world or the environment that the game events will be happening in. There are four option provided: Sci-Fi - futuristic world after humanity colonized space Fantasy - an imaginary universe similar to the universe of Hobbit Noir - a world in a style of old detective fiction Historic - medieval world After the selection is done, the user confirms the choice and proceeds to the next screen to select the preferred graphics. The choices are: Minimalistic - Simple 2-color graphics, objects have minimum details and no animation Fancy - multicolor graphics with complex animation, high level of details 16-bit - retro graphics style, similar to Nintendo or Sega Textual - absence of graphics, events happening are described by text The next screen similarly has 4 choices of story length. The length of the story changes depending on how many time will the game cycle through a series of 3 mini games. The options on this screen are: 15

16 Shorter - Each mini game is played once Full - Each mini game is played twice Long - Each mini game is played 3 times No storyline - Mini games come one after another with no story screens in between until the player decides to quit playing After the third screen the story starts and after that the player appears in a world that he has chosen, with his preferred graphics and story length. The customization process is organized in steps to achieve maximum straightforwardness for the user. The initial design of a customization screen is shown below in figure Mini games Platformer mini game design A typical platformer game is a game which involves guiding an avatar to jump between suspended platforms and obstacles to advance the game. The features may change from game to game, but in our case the mini game has elements of stealth game (a game where a player uses different techniques to avoid antagonists), because the player can't destroy the enemies he encounters, so he must avoid them. The objective of the game is to safely reach the end of the level which is indicated by a door, portal or other object, depending on the plot. The platforms that the player moves on are "hanging" in the air, so if he falls off any of them, he will immediately die. Similarly, if the player touches an enemy once he starts flashing. After touching an enemy for the second time he dies and is put at the beginning of the level Tower defense mini game design Tower defense is a type of strategy video games where the goal is to defend a player's territories by obstructing enemy attackers by placing defensive structures on or alongside their path. Universalum utilizes a classical tower defense game, with waves of enemies coming towards player's base. Player has to place turrets along the path that enemies follow.the towers can also be upgraded with the money received from killing enemies. As a tower progresses, it gets longer shooting range, faster and stronger bullets. Player has health points as well and whenever an enemy reaches player's base these points are deducted. When there are no health points left, the player dies and has to redo the level. 16

17 Logical mini game design Sokoban is a logical game, in which the player pushes boxes or crates around in a warehouse, trying to get them to storage locations. The mini game designed for Universalum utilizes the idea of the classical Sokoban game, with the difference in the environment. Instead of the warehouse the action might be happening in open space and there might be satellites instead of boxes. In this game all the marked cells must be occupied by boxes, if they are - the level is completed. The boxes can be pushed around by the avatar controlled by the player. An obstacle in successfully completing the level is the fact that the boxes can get stuck. For example if the player eventually pushes a box into a corner he will not be able to push it out of it. In this case the level must be restarted, which can be done by pushing the provided restart button Methodology To organize the work on design and implementation, an agile practice of whiteboard was used. I have. A whiteboard was created with 5 columns, each representing a current state of a task. The columns are as follows: 1. Backlog general ideas for the projects that might not be implemented. If after evaluation an idea is being approved, it moves to the next column and becomes a standing task. 2. To do the column, containing a list of tasks (usually a task is a feature) that must be implemented in future. If a task is chosen to be implemented next, it moves to the next column. 3. In development tasks that are currently being worked on. When a task is completed it goes to the next column. 4. Testing if a feature is tested and no bugs are found it moves to the next column. If a bug is found it moves back to the development column. 5. Done represents a list of all finished features ready for deployment. A picture of the taskboard is provided in Appendix A. 3.4 Planning 17

18 A Gantt chart provided in appendix B was produced prior to the start of project work. The purpose of this chart is to provide a basic plan for tackling different features of the application. I was expecting to follow it quite closely, however very soon I noticed that it is very hard to follow the plan. This is mostly due to the lack of previous experience in implementing large projects like this. The time constraints for most of the tasks were too small, so in the end I used the chart to see the order in which different parts of the system were to be implemented, without following the time constraints. 3.5 UI design Designing a good and easy to use user interface is very important for user satisfaction. It is very important to be able to navigate through the game and menu screens easily and intuitively. A game can be very interesting to play, but if the controls or navigation in the menu screen is frustrating it can affect the impression from the game in a negative way. For the sake of simplicity it was decided to put minimum buttons on the screen. The size of the buttons also was planned to be variable, so that the most likely inputs stand out from the rest. The main menu is the very first element of the game that players will encounter, so it was important to make it aesthetically pleasing to give a person playing a good first impression of the game. Figure 3.5 demonstrates the initial design of the main menu. Figure 3.4: Initial menu design Another important rule is to keep the UI elements consistent. To achieve that, the elements don t change their position on different screens. For example, the customization screens have the same layout in terms of button placement and actions needed to be performed to proceed to the next screen. 18

19 The consistency can also be noticed in the design of the UI elements, they all have the same appearance throughout the game. 3.6 Designing the plot For many games, the plot is one of the most important parameters. It can keep player motivated to play, immerse a person into the world that the action takes place in and make the gameplay more pleasant in general. However, writing a good plot for a game is not an easy task, especially for a person with no experience in writing. Because of that I stuck with a few popular time-tested ideas. These put the user in a role of a person with all the good qualities, a hero, that has to overcome all the challenges and obstacles that are presented to him to save the people around him. This kind of plot is used very widely in computer games and movie industry. There were four different scenarios designed, one for each setting. These include: Sci-fi: The galaxy is in a state of war. Humanity has expanded its habitat far beyond our Solar system and has eventually encountered different civilizations scattered throughout the galaxy. Then a war struck, humans were fighting for the right to exist for centuries. And in a critical moment a hero appears to change everything and save humanity. Fantasy a concept similar with Sci-fi. An evil and powerful wizard takes over the land of our hero. Everybody lost the hope to ever be free again, the only person who is brave enough to take any action is the player. Noir a detective is trying to catch a leader of a famous gang that has been terrorizing the streets of New York for years. The enemies are strong and deceptive, but the hero is Historic the player takes the role of Julius Caesar, the legendary Roman statesman to lead the Roman army against the galls. 19

20 Chapter 4 Implementation This chapter describes the process of implementing of all the in-game features and explains all the technical decisions made in this process. It also presents all the tools the tools used to create the game. As already mentioned before, the engine chosen for creating this game was Unity, because it featured the widest range of features and tools, a very active community and a big amount of documentation. The programming language used in Unity is C#. Certain technical implementation ideas were taken from online tutorial websites provided in the reference section, but these were added and implemented with understanding of underlying mechanics. 4.1 Scenes It was decided to organize different menu screens and mini game in different scenes. A scene in unity contains a set of game objects. It can be considered a basic building block for the game. Transitioning between scenes is performed by a simple method utilizing the Application class that Unity provides to swap to a specified scene. The method is shown in figure 4.1. usingunityengine; usingsystem.collections; publicclassswaptonextscene:monobehaviour { publicvoidswaptonextscene(inti) { Application.LoadLevel(i); } } Figure 4.1: Method for switching scenes A scene has multiple elements to it. Figure 4.2 demonstrates a typical scene opened in the Unity editor. Every object has 3 coordinates in the world space x, y, z. As the scene is 2-dimensional, 20

21 the z coordinate is used to position the objects in front or behind each other. The x and y coordinates are used to actually position it on the screen. Figure 4.2: Example of a scene The main objects that are present in the scene are: Main camera device that captures and displays the world to the player. Is represented by a white rectangle and decides what part of the world is visible to the viewer. Canvas the area that holds all the UI elements (buttons, labels, etc.) Background The background image. UI elements buttons, labels panels, sliders, etc. Game objects the actual objects that the game revolves around. Usually are sprites. 4.2 Customization system The customization system uses multiple variables and conditions to combine all the playerchosen settings. The variables are initialized in the class Main and can have values from 0 to 3. Each of the numbers corresponds to a setting. For example, for the graphics variable 0 means fancy graphics, 1 means minimalistic graphics, 2 means 16-bit graphics and so on. Figure 4.2 demonstrates the method for changing the graphics. 21

22 usingunityengine; usingsystem.collections; publicclassmainupdate:monobehaviour{ void start(){} // publicvoidmainupdate(inti) { //Updating the value in the Main class Main.graphics=i; } Figure 4.3: Updating the graphics value The proceed buttons in the first two scenes simply load the next scene. However the same button in the last screen calls a different script, which is a modification of the SwapToNextScene script. This script contains if-else statements that load different scenes depending on the values that the variables described previously have. 4.3 Platformer game The platformer game utilizes three scripts that contain all the methods needed for a particular part of the system to work. The movement of the player and the physics related to that is managed by the PlayerController script (testmove), enemies are controlled by the EnemyController script. Animations are handled by the AnimationController script Player movement A player is represented on the screen by an empty object and a character sprite attached to it. The character object is given a Rigidbody2D component, which gives places it under the control of the physics engine. As described in the design chapter, the character can walk and jump around on the platforms, which he should not fall of. Here is a list of properties that the character has. To ensure that the character always stays on top of the platforms, he is assigned a collider element. There is a constant gravity force affecting the character. Because of that the platforms are given colliders as well, so upon touching a platform the character will not fall through. 22

23 For any type of movement, be it going left, right or jumping, vectors are used. There are two buttons on the left of the screen left and right button. Whenever one of them is pressed, the StartMoving method is called. In this method, the input variable (stands for horizontal input) is assigned a value of 1 or -1if one of the buttons was pressed, and of 0 if a button was released. Each frame the FixedUpdate method is called, which calls the Move method. The Move method gets the velocity of the character object, and adds the speed value multiplied by the 1 or 0, depending on the state of the buttons. Jumping is performed in the Jump method, which checks if the character is touching the tag ground element that the character is assigned. If it is touching the ground the character s up vector is summed with the jump velocity and the character moves up Enemy movement The enemy movement is organized in a similar way to the character, but uses a different method to see if it is grounded. The task was to set make the enemies move in one direction until they reach the end, turn around and go into the other end and so on. For that reason a method called linecast was used. Linecast is an imaginary line between two points in world space. Any object making contact with the beam can be detected and reported. The enemy has a constant speed and is moving horizontally in the same way that the player does while casting a linecast, starting from the front of it and going vertically down towards the ground. When a platform edge is reached, the linecast detects no ground and the enemy is rotated 180 around it s y-axis and starts moving in the opposite direction. Figure 4.4 shows an enemy with the linecast detecting the ground. Figure 4.4: Linecast demonstration 23

24 4.3.3 Animation controller Unity provides an animator tool for creating custom animations,setting up the transitions between them, and specifying the conditions under which the animations are running. Figure 4.5 demonstrates the walking animation of the character, figure 4.6 demonstrates the condition that needs to be satisfied to make a transition from idle to walking animation. Figure 4.7 shows the map of all possible transitions. Figure 4.5: Character walk animation Figure 4.6: Conditions for walking animation 24

25 Figure 4.7: Transitions between animations The AnimationController class contains methods for rotating character during the movement as well as triggering the blinking animation when player collides with an enemy. 4.4 Tower defense game Tower defense is a simple game in terms of the playing process, but a more complex game in terms of implementation. I will describe the key points about the game s composition. The concept of prefabs is mentioned below. Prefabs is in an essence a template for adding new objects in a scene. If a prefab is modified, all of it s instances are modified too Turrets The OnMouseUp method provided by Unity is used to check if player has tapped one of the platforms. If so, a new instance of the tower prefab is created at the location of the corresponding platform. 25

26 If a turret is tapped on: 1. Check if there are levels to upgrade to. 2. Check if player has enough gold 3. If so switch to the next tower sprite and upgrade tower s features Enemies The path of enemies consists of multiple waypoints that are set throughout it. Enemy prefabs are spawned on the very first waypoint, after which lerp is used to move them along the path. Lerp is a Unity-provided function which is most commonly used to find a point some fraction of the way along a line between two endpoints. We use it to interpolate the current position of the enemy between the start and the end of the current segment. It is also important to rotate the enemies in such a way that they always face forward the direction that they are moving in. For that we subtract the current waypoint s position from the next waypoint s position. Then we determine the angle that the enemy is pointing towards using the Atan2 function that unity provides. Finally, we rotate the sprite along the z-axis by the required angle Enemy waves Enemies in a tower defense game must be grouped into waves. Here are the steps in which the waves are organized: 1. Check the current wave s index to check if it is not the last one. 2. If so, calculate how long ago was the last enemy spawned. There are two intervals inwave (short) and between waves (long). 3. Spawn a new enemy by instantiating a copy of the enemy prefab and increase the count of enemies spawned. 4. Check if there are enemies on the screen, spawn a new wave if there are none and the last enemy was spawned for the previous wave. Give player 10% of all gold. 5. If the last wave was beaten run the victory animation. 26

27 4.4.4 Player health Player has health, which is shown on the screen alongside the enemy wave number and player s gold amount. If it reaches 0, the game is over and the game over animation is played. Each time the health decreases, which happens when one of the enemies reaches player s base, one of the human sprites on the player s base is destroyed to visualize the loss Turret-enemy interaction The turret prefab has a circle collider assigned to it. Its radius decides the shooting distance Delegates are special kind of classes that Unity provides. These are used when it is needed for a game object to actively notify other game objects of changes. This is used to notify turrets of killed enemies. When an enemy touches a turret s collider, it is added to the enemies in range list. If an enemy is destroyed it is removed from that list. This is achieved with two methods, OntriggerEnter and OnTriggerExit. If there are multiple enemies in the range of a tower, it will shoot the one closest to the player s base. This is achieved by calculating the length of road not yet travelled by the enemy. For turrets shooting the enemies, Lerp is used again. Bullets travel in a straight line between turrets and enemies. A bullet has a set of parameters, which include speed and damage. The rate of fire is also modifiable. So the overall shooting process can be described with these steps: 1. Select the target. Iterate through enemies in range to find one closest to player s base. 2. Call the Shoot method, determines the start and the end position of a bullet and instantiates a new bullet. 3. Calculate the rotation angle between the turret and it s target and set the turret s rotation to this angle so that it always faces the enemy. 27

28 Chapter 5 Testing This chapter describes the testing process what kind of tests were performed, what techniques were used, what results were achieved. 5.1 Unit testing Unit testing was conducted on all of the game s features. Whenever a new feature was implemented in the game it was tested to detect any possible bugs before developing any other features. No specific frameworks were used, the testing was performed manually. That is mostly due to the specificity of the project the game has to be played on a mobile device and interacted with through the touchscreen in order to test most of the functions. The tests were designed and written down in the logbook, the results of each tests and any actions taken related to testing were also described in the logbook. Figure 5.1 shows an example of testing logs from the logbook. Figure 5.1 here 5.2 Other Some evaluation was done as well in an informal fashion. For that the prototypes of mini games were given to different people to get feedback on playability, design and general impression. This helped with refining some in-game features. It is important for a good evaluation to have people who are not biased by relationship with the developer or any other factors. And though not all the people could satisfy these conditions, I believe that most of the evaluation received was reasonable and critical. 28

29 Chapter 6 Results This is a demonstration chapter for the project, containing screenshots of the screenshots of some of the game aspects, such as menu screens and mini games. Figure 6.1: Main menu Figure 6.2: Customization screen 29

30 Figure 6.3: Story screen Figure 6.4: Platformer with fancy graphics 30

31 Figure 6.5: Platformer with minimalistic graphics Figure 6.6: Tower defense game 31

32 Chapter 7 Evaluation This chapter shows the evaluation of all the features that have been implemented. The evaluation is made on the features that were planned to be implemented and the aims that were set. 7.1 Aim evaluation Following the description of aims in the first chapter, following conclusion can be made. 1. Implement a working mobile game with an extensive modification system, consisting of multiple popular mini-games and supporting different playing styles. This aim is partially accomplished: a working mobile game is produced, but there are features missing from it, that limit the gameplay substantially. 2. Gain a better understanding of game development process, practice developing mobile apps. This aim is reached, because considering that before I had almost no experience in game development, I have learned many new concepts. Some of these include physics engine, UI design, game design, sprites etc. 3. Gain experience working on a large-scale project. This aim was reached as well, because the development period lasted for almost half a year, I had to do planning, write tests, make changes to the project and experience other things related with a long-term large scale project. 7.2 Feature evaluation 1. To implement in the most efficient way the customization system. A method was developed to implement the customization system, however not all the customization features were finished (not all graphics sets, settings, game lengths). 32

33 2. Implement a minimum of three mini-games together with all the possible customization options that can be added to them. Out of the three mini-games the two most complicated and time-demanding mini-games were implemented. However the graphics sets and different settings were not fully implemented due to the lack of time. 3. Write a plot for a game and put the mini-games and the customization system together into a game. 4. The plot was designed for the game, however different scenarios for different settings were not added into the game. 7.3 Future development Because I still consider the project idea to be interesting, I will continue the development of Universalism. It requires a substantial amount of implementation and refinement work to be done before deploying it to the market. 7.4 Conclusion In conclusion, The project was semi-successful. This is due to the fact that by far not all the planned features were implemented and added to the game. Mostly, because of the mistakes made in time-management and work organization. But even though the desired result was not fully achieved, a good amount of experience was acquired. 33

34 References 1. IDC: Smartphone OS Market Share. (n.d.). Retrieved April 26, 2016, from 2. Shneiderman's Eight Golden Rules of Interface Design. (n.d.). Retrieved April 26, 2016, from es.html 3. Unity Manual. (n.d.). Retrieved April 26, 2016, from 4. What's the most challenging part of making a successful mobile game? (n.d.). Retrieved April 26, 2016, from 5. How to Create a Tower Defense Game in Unity Part 1. (n.d.). Retrieved May 03, 2016, from 6. Unit Testing. (n.d.). Retrieved April 26, 2016, from 7. Devin Curry - Technical Artist. (n.d.). Retrieved May 03, 2016, from 8. Building a Useful Task Board - Agile For All. (2011). Retrieved April 26, 2016, from 34

35 Appendices Appendix A Appendix B 35

36 36