Project #1 Report for Color Match Game

Transcription

1 Project #1 Report for Color Match Game Department of Computer Science University of New Hampshire September 16, 2013

2 Table of Contents 1. Introduction Design Specifications Game Instructions Components User Documentation Conclusion References

3 1. Introduction The purpose of this project is to implement a color match game for the Android operating system. The game itself is simple: the user is presented with the name of a color and must determine if this name matches the font color it is displayed in. To make it more difficult, the background behind the word is yet another color. The game ends after a predetermined number of rounds (in this case, 10), and the user is presented with a Results screen displaying statistics about the game they just completed. The Color Match game design is the main focus of this project. The classes and their relationships were deliberated upon much more than the game logic, which is explained in further detail in this document. With the aid of a few key diagrams, the remaining portion of the document is intended to bring a better understanding of the layout of the Color Match game. Portability is the goal with this program and, in my opinion, it was achieved. The initial coding of the application was contained in the main activity, so the final representation is structured with much more forethought. 2. Design Specifications In this section, the instructions for the game and the components of the application are discussed in detail. The game instructions are made to be as concise as possible in section 2.1, and each design choice, class, and class relationship is explained in section Game Instructions The game begins upon loading the application. The player is immediately brought into the game, so this is when the timer begins. On the screen is a text box, which displays the name of a color. The player needs to determine if the name of the color matches the font color that the text is painted in. If the text and color of the text do match, then the player presses the 'Yes' button. Otherwise, the player presses the 'No' button. The player is awarded one point per correct guess and this is added to their score, which is shown in the upper right corner of the screen. If the player guesses incorrectly, no points are awarded or deducted. 2

4 Figure 1: The text color matches the word. Player hits 'Yes'. Figure 2: The text color does not match the word. Player hits 'No'. Once the game is completed (the player has played 10 rounds), the results screen will open. This screen displays the total time taken to finish, as well as the player's total score. The results screen also has a replay button on it, which will allow the player to play again. To exit the application, the user may press the home button or the back button Components The Color Match game was initially very simple to get running. The logic of the game is not complex. However, figuring out how exactly to divide up the classes is more difficult. The first implementation of the game was created using only one class the GameActivity activity. All of the logic for the game was located in the onclick method in the activity. If one encountered code that was structured like this (everything in one method), they would not have a good understanding of how the code works. So, more classes were implemented with the goal is good programming structure in mind. Adding a ResultActivity activity to the project meant that it was now necessary to find a way to invoke this activity from the old one. Remember that the ResultActivity is the screen that displays all relevant information about the game that the player just completed. This is when intents became very important. An intent, which is an abstract description of an operation to be performed, was used to launch the activity, and a helpful method called 'putextra' was used as a means of transferring the time and score to the newly invoked ResultActivity [1]. The method puts the information from the GameActivity into a Bundle so that it can be retrieved while in the ResultActivity. The relationship between the two activities is shown in Figure 3. The ResultActivity has two simple components, the data being displayed and the replay button. The data is passed via a Bundle, but the replay button just begins a new activity of the GameAcitivity type when the onclick method is called. There is no game logic involved in 3

5 either the GameActivity or ResultActivity; the game logic resides in the GameEngineClass. This class is a standalone class. The GameEngineClass extends GameEngine, which is an interface. GameActivity calls every method it needs to call through the GameEngine interface. Thus, it is not aware of what is going on behind the scenes. Similarly, the game engine should need to know even less about the activity that is using it. To help me understand game engines further, I read a thesis involving them and their implementations written by John C. Hammer. Hammer stated, modularity allows the engine to be extensible, so new behavior can be added by another developer without modifying the engine as a whole, which helped paint a picture of where a game engine would fit into my application and how exactly it would be used [2]. Before fixing the GameEngineClass to be a more standalone class, it relied a great amount on the GameActivity activity. The original build of the GameEngineClass had the GameActivity passing itself as an argument in the constructor of the game engine, so that the UI could be updated from within the GameEngineClass itself. The final build of the game engine brought sanity along with it: the engine no longer knew anything about about the activity calling it, and thus could stand on its own. This final change to the GameEngineClass made the project much more modular and fulfilled the criteria that the Color Match game should be made easy to port to any environment. Now that the game engine was acceptable, the project could continue to be restructured. The final step to making the project more portable involved creating one more new class. The code that was previously contained in the 'textandcolorset' method of the GameEngineClass was moved to help create a new class called 'ColorGen'. This new class basically provides a random color generator that returns an array of three ints (colors). It is able to provide the three random colors for the game engine to pass to the UI for the text, text color, and background color. Figure 3 displays the relationships between these classes. ColorGen is in its own class both for readability and portability of the code. 4

6 Figure 3: This UML class diagram depicts the classes and their relationships in the Color Match game. The most useful part of the game engine for Color Match is probably its flexible nature. I decided to plan for as much expandability as possible. In the game engine interface, there is one method, 'restarttimer()', that is not used, but I thought it might be a useful function in the future. Another small example of the game engine's malleability can be seen in its constructor. The constructor for the GameEngineClass accepts two integers one for number of rounds and one for number of colors. This will allow the game to be customized to allow for any number of colors or any number of rounds for the player to play. I am considering eventually creating a start screen where the user can choose these settings. The game begins when the application is opened, so all of the initialization occurs immediately. The game engine and ColorGen are created one time at the start of the program. Figure 4 depicts what methods are called sequentially upon the start of the application. 5

7 Figure 4: This UML sequence diagram shows the events that occur when the game is started and whenever the game needs to update the view to display new colors. Figure 4 shows the game engine being created via the 'oncreate()' method. The game engine then creates a ColorGen object when it is initialized. Right after the game engine is made, its 'textandcolorset()' method is called, which in turn calls the 'updatecolors()' method of ColorGen. The game engine then uses 'getcolors()' to retrieve the array of three colors that will be used to update the view in the activity. This array is what is returned by the 'textandcolorset()' method to the GameActivity. From there, the activity acts like a view class and updates the screen with the information that the game engine returned. It can be noted that if you remove the 'oncreate()' and 'new ColorGen()' calls from the diagram, the resulting diagram would then depict how the view is updated after every round. Figure 5 represents the small use case of the player hitting the 'Yes' button. The high level view of this is quite simple: the activity tells the game engine that the user has pressed the button via the 'matchingcolor()' method, the game engine keeps track of if it was correct or not, and then the return value of 'matchingcolor()' lets the application know if the game is over. Only if the user's answer is right does the game engine call 'updatescore()'. After all of this, 6

8 the rest of the diagram is just the view being updated to display the latest information. Figure 5: This UML sequence diagram models the events that unfold after the player presses the 'Yes' button. Looking at this sequence diagram, I can tell that the setup of my program is decently distributed over the classes that it encapsulates. However, for future remodeling, I am considering splitting up the duties of the GameActivity even more. Right now the activity appears to me to function as some sort of view/controller combination. Maybe if I can separate this functionality and have a separate controller class, then the portability factor of the code might become even greater. To make the controller class, I would try to remove any remaining logic from the GameActivity activity and shift it into the new class. This way the activity would function solely as a view class and the controller would be separate. However, I think where 7

9 the application is now is a big improvement from where it began all code located in the GameActivity. The code is now readable, understandable, and portable. 3. User Documentation The player of the game will be presented with two different kinds of screens when within the Color Match application. These screens are distinguished from each other by their titles. The first is the main game screen where the game actually takes place, and this is called 'Color Match'. The other screen in the application is the results screen, which is titled 'Results'. Figure 6: A screenshot of the game screen. The answer here is 'Yes'. Figure 7: Another screenshot. The answer is 'No'. Figure 8: This is the Results screen. User may hit 'Replay' to play again. In the game playing portion of the application, the user is presented with two options the 'Yes' button and the 'No' button. The player should hit 'Yes' when the text and the text color are the same and 'No' when they are not the same. The score is displayed in the upper right portion of the screen and increases when the player guesses correctly. Once the player has answered, the screen immediately changes to a new color card. For example, imagine the player is shown the color card from Figure 6. After pressing one of the buttons, the player could then be presented with the color card from Figure 7. The cards are randomized. 8

10 Once the game has completed (the 10 rounds are finished), the player is presented with the Results screen. This screen shows the Time that the player took to complete the game (in seconds), as well as the score the player received (how many guesses were correct). The options presented to the user here are hitting the 'Replay' button to play again, or pressing the back or home buttons on the device to exit the game. 4. Conclusion The design and structure of the game was quite imperative to the portability of the game. I believe that anyone familiar with android would easily understand the setup of all classes in my code. Even someone who knew nothing about android, but knew how to program, could probably interpret my layout with just the help of this document. The main idea behind the project was the make the program as modular as possible. This was accomplished by breaking my initial code, which was contained in one class, into multiple classes. However, at a certain point, it is pointless to keep breaking the program down further. I attempted to stop at this point and that is what my final submission for Project #1 is. The idea of structuring programs in the mindset that we did with this program will be very beneficial down the road when we are creating much larger projects. 9

11 5. References [1] Intent Android Developers. (n.d.). Android developers. Retrieved September 14, 2013, from [2] Hammer, J. C. (2012). The design and implementation of a mobile game engine for the android platform (Thesis). Retrieved from /HAMMER-THESIS.pdf?sequence=2 10