NekoPapa

Introduction

NekoPaPa is a Casual & Role-Playing game for Android devices which allows users to feed their own cats, trade with other players, and breed the best cat ever. The target market of this game is north America. The U.S. families love feeding pets, hence probably many Americans like playing video games involving contents of dogs and cats. And since a lot of people are busy with their work every day, they have little time bring their pets together to play frisbees with their friends. Additionally, according to statistics provided by Entertainment Software Association(ESA) in 2017 Sales, Demographic, and Usage Data: Essential Facts About the Computer and Video Game Industry, smartphones are owned by 81% of the US households, and role-playing game is the 3rd game genre among all best selling video games. Consequently, NekoPaPa will probably be an easy-access game as well as a good social platform for Americans who like cats.

We designed our application for the purpose of providing players with a real sense of feeding pets. Specifically, users can feed their cats and sell their cats for gold. With the gold, they could increase the investigations on their favorite cat. Players can also mate their cats with random wild cats. By such process, they could have a great chance to acquire a new cat and would achieve a sense of accomplishment if they could acquire a cat that has some uncommon peculiarities.

Design Process And Intended Goals

During our design process, we first came up with some fundamental elements in our game. These elements include the account management, cats’ attributes management, trade mechanism, mating mechanism as well as map mechanism. With account management, we can have an efficient way to manage all of logins. Users can login to the game only if they register legal accounts. Cats’ attributes management defines different genes of cats, which causes different characters and states of different cats. Trade mechanism is responsible for managing all of the trades in the game. Operations such as gold change, selling cats for gold, and spending gold in improving cat’s state are managed by the trade mechanism. Mating mechanism controls another important part of our game. Players can acquire cats with better genes by mating their cats with wild cats that have much greater genes. The entire mating process including the result of mating (whether it is successful or not), the creation of new cats and genes assigned to new cats is what mating mechanism should think about. Finally, the map mechanism is responsible for using Google map as an external service to find users’ instant position as well as randomly-distributed wild cats’ location.

To implement those necessary elements above, we designed different views in our games. These views are displayed through different pages including login page, account page, game session/home page and also map page. The login and account page often function together to be used for registering an account and loginning to the game. Game Session/Home page is the main page in our game. Basically most of the game is displayed here. Map page is used to get external service of Google map, and Players can switch between different pages by clicking specific buttons.

In order to efficiently develop our design, we chose to implement the project by using The Model-View-Control Design Pattern (The MVC Design Pattern). On the Model layer, we built classes named Account, Cat, CatFurniture, CatItem, WildCat. The Account class is responsible for managing account database for users. Cat class is responsible for managing all kinds of cats’ information. CatFurniture class and CatItem class defines all of the relevant objects that cat might use in the game. A WildCat class is built in order to separate domestic cats from wild cats, and it also controls the refresh of wild cats on the map. On the View layer., we built classes named AccountFragment, LoginActivity/LoginFragment, MapsActivity, WildCatDialogFragment and GameSessionActivity/GameSessionFragment. The AccountFragment class implements the account registration page. The LoginActivity and LoginFragment function together to implement the login page. MapsActivity is responsible for generating a map centered in user’s instant position. And several wild cats that are randomly distributed around user should be shown on map. WildCatDialogFragment is used to generate a message dialog when user clicks one of the wild cats on the map. GameSessionFragment implements the home page, which should have all cats’ information, gold information and buttons that can lead users to other pages. On the Control layer, there are classes called AccountDbSchema, CatFornitureDbSchema, CatDbSchema, CatItemDbSchema, InventoryDbSchema. All of these classes are implemented to control the query and update in relevant database relations. Also, we built another class called GPSTracker, which is responsible for acquiring user’s instant location by using GPS.

We built our database locally and in our database, there are a relation table for user accounts, a relation table for cats and also a relation table for cat items. In the accounts table, there are attributes called name which stores user name, password which stores user password, gold of each account, and last_login of each account. In the cats table, there are attributes called name which stores cat name, energy which stores each cat’s energy, mood of each cat, stemina of each cat, charateristic of each cat, stripe_type of each cat, fur_color of each cat, last_time_energy_consume of each cat, user_id of each cat. In the catItem table, there are attributes called name of each item, energy_effect of each item, price of each item, description of each item and icon of each item.

In the login page, for new players, you need to register an account. Click on the button called ‘Sign up’. After that there will be a Register page that lets you decide your username and password. If you get yourself a duplicated name, system will print an error message saying that: “The username already exists.” After you give yourself a proper name and confirm your password, you can click on “Create” button to finish registration and go back to the login page. For those who have already had their accounts, you can enter the game by typing your username and password and then clicking the “Sign in” button. If the password entered does not match our record, system will print error message:”Wrong password! Please try again.” If the username entered is not stored in the database, an error message that “The record does not exist” will appear.

In the home page, for new players, our system will provide them with 2 low-level cats. On the bottom of your screen, there are 2 attributes of the cat currently shown, including its energy and mood. The energy of the cat is shown as a blue bar. It will decrease automatically every single hour. On the top right side of screen, there are Sell button, Map button and Buy button. On the top left of the screen, there is a HUD to show your gold. Initially system will give you 500 gold. The gold can be used to increase the energy of cats by clicking the Buy button. You can make money by selling your cats. Moreover, system will give you 30 gold everyday you login.

Once you click on the Map option, you will be led to the map page, where google map will be invoked. You can see your current position and the environment around you. 20 wild cats that will randomly appear around your position can be caught to mate with your cat by clicking on the wild cat first and then clicking on the “Ok” button inside the newly appeared dialog box.

Translating Design To Implementation

The first step of this project was to become familiar with the Android development environment. Since no one in the group had experience in Android application development, the group needed to start from scratch. Although the Android Studio was handy to download and install, it took a long time to update and set up the Android SDK. Additionally, the team discovered that Android Studio consumes a big chunk of memory, meanwhile, the hard drive is heavily used in Android programming. Therefore, the team members decided to add memory to their laptops and desktops and move the entire Android Studio to the solid state drive, which dramatically improved its performance. After setting up the whole environment, the team begin playing with the TicTacToe project and doing research with respect to the tools introduced in Android Studio. In order to take advantage of github to share the work with each other, a member of the team created a new project and uploaded it to his github repo. However, another member was not able to download the project through the version control system. At the beginning, the team believed this must be an issue when importing github application. After a series of tests, the team believed the github had been set up correctly. And one of the members found that the access permission was not granted to the member who could not edit the repo and the one who uploaded the project must invite him. On top of that, sending the invitation link manually was necessary. After ensuring all members had access to the repo, the team started learning how to use the fundamental debugging and profiling tools. As the team members are experts in Eclipse, setting up breakpoints and tracing the errors were effortless. However, when testing with the emulator, the team perceived two major problems. First, everytime the team members set up and new emulator in AVD manager, a large amount of data must be downloaded to support the new virtual device. The process of setting up new virtual devices was prolonged. Besides, the emulator is pretty slow as it is a virtual machine based on java. After a long time of using, it becomes even slower due to the background applications and services. In that case, the laptop OS stops responding when closing the emulator. And after a large amount of tests, the team became aware that periodically cold booting the emulator is an essential step to clean up the virtual machine memory. When testing the profiling tools, the team found no record button in memory profiler. The team then consulted the documentations in developers.android.com and discovered that this button was cancelled after Android 7.1, and for higher versions the users can simply set start and end points and read the memory allocation[1]. After learning basic knowledge concerning Android development environment, the team started learning the lifecycle of activities and fragments.

The following step was to implement login and sign up pages. After surveying the login and registration processes of TicTacToe project, the team perceived 2 major issues. First, the team could not open the design page of xml layout files of TicTacToe, they could only try to understand the pages through the xml code. However, in their own project, this was not a problem. The second issues was about the account creation and login process. The team found that the account registration of TicTacToe was not well designed. For instance, the user can create 2 accounts with exactly the same username. On top of that, the approach of accessing the database in TicTacToe does not allow the developer to know whether an operation is successful or not. The solution to these problem is to add statements to check the username and password strings and change the way of accessing the database. Consequently, the DbManagerSingleton was reconstructed to achieve those goals. The team members decided to use methods such as rawQuery(), insert(), update() and delete() to operate database, because those methods will return the results. For instance, rawQuery() returns a cursor which contains all rows of data retrieved from database, and insert() returns the id of the new row and if the insertion failed, it returns -1.

The next step was to implement GameSessionActivity and GameSessionFragment. The first challenge of this part was to create the user interface. The team members had no experience in designing pages through visualized tools. At the beginning, the members simply added buttons, textViews, editTexts and imageView to the page. And after a series of testing, the team discovered that there was no constraint to those widgets, as a consequence, when running on devices of different screen sizes, the relative locations of those widgets will be distorted and it will be inconvenient for players to use. Therefore, the team consulted the documentations[2] about layout design and added constraints to all the widgets. Apart from the page design, the second challenge of this part was the implementation of energy bar. Here were two major problems when designing the energy bar. First, there must be some timer to decide when to decrease the energy. The solution was to create a timer in GameSessionActivity, and put it in another thread. When the time is up, the timer calls updateGauge() in GameSessionFragment to modify the energy data and update the UI. However, there was another problem. The system rejected the request to change the views from outside due to security problems. Hence, the UI update must be done in a method called runOnUiThread(). The second problem was with respect to the energy bar image. There are many kinds of scale types in imageView. Most of them are not suitable for this case because their paddings are hard to control and the image positions sometimes are “unpredictable” for team members since they do not have an intact understanding about those types. Therefore, the team decided to adopt the the matrix scale type. The matrix scale type simply renders the image from left top and it is not affected by the borders of the view. As a consequence, the team simply needed to calculate the new width of the energy bar according to the width of the imageView and set the generated bitmap to the imageView.

The last part of the implementation was unit testing. Again, like the issue in design page, when the team tried to run the unit tests provided in TicTacToe, the Android Studio rejected the request because of lack of certain components. The team tried to update the studio and install these unknown components, but they failed. Fortunately, when the team constructed their own tests in NekoPaPa project, the Android Studio accepted the request and no component was missing. However, when trying to set up the testing environment(i.e. creating new LoginActivity and attaching a LoginFragment to it), the JUnit tool indicated that the activity was null. In the end, the team found that there was somehow an @interface annotation just before the definition of the test class, the test run pretty well with the removal of the annotation.

Design Process Improvement Suggestions

Since we built our database locally, players may not be able to play this game with their friends. Therefore, we could improve our game by building a server and allows a lot of players to play this game at the same time. Also, in order to increase the functionality of our game, we could improve the practicality of the communication system. For example, we can develop a trade system that allows users to trade with their online friends. As a result, they could be able to choose one of their friends and sell cats to or buy cats from him/her. Moreover, we can develop a competetion system or rank system for users’ cats. By taking part in competitions on their cats, players can be distributed into different ranks, for example, from Bronze to Challenger. The higher quality the cat has, the higher rank the player achieves. We could also add more cat items and furnitures to improve the playability of this game. For instance, different cat items have different functionalities on improving cat’s characteristics.

Reference

[1] developers.android.com. (n.d.). View Java Heap and Memory Allocations with Memory Profiler . Retrieved from: https://developer.android.com/studio/profile/memory-profiler

[2] developers.android.com. (n.d.). Build a Responsive UI with ConstaintLayout. Retrieved from: https://developer.android.com/training/constraint-layout/

[3] Entertainment Software Association. (2017). 2017 Sales, Demographic, and Usage Data: Essential Facts About the Computer and Video Game Industry. Retrieved from: http://www.theesa.com/wp-content/uploads/2017/09/EF2017_Design_FinalDigital.pdf