Development of a Euchre Application for Android

Transcription

1 Development of a Euchre Application for Android Carleton University COMP4905 Julie Powers Supervised by Professor Dwight Deugo, School of Computer Science April

2 Table of Contents Introduction...4 Motivation... 6 Goals...6 Objectives...7 Outline...9 Background...10 Approach...19 Results...26 Conclusion Future work

3 List of Figures FIGURE 1: Screenshots of the settings screen for Euchre. The figure on the right shows part of the expanded Visuals section...11 FIGURE 2: The Euchre game screen in landscape and portrait...12 FIGURE 3: Dialog prompting the user for their choice during the first round of bidding...13 FIGURE 4: Playing a round after trump has been called...13 FIGURE 5: Round history feature...14 FIGURE 6: Screenshot of the Euchre Master game screen partway through a round...15 FIGURE 7: The settings screen for Euchre Master...15 FIGURE 8: The show last feature. Notice how it covers up the user's and their partner's card...16 FIGURE 9: The statistics screen for Euchre U...17 FIGURE 10: The settings screen for Euchre U...17 FIGURE 11: Screenshots showing the landscape and portrait orientations of Euchre U. Note the size of the text for both the team scores and number of tricks in the upper right hand corner of the game screen...18 Figure 1:...23 Figure 2:...24 Figure 3:...25 Figure 1:...28 Figure 2:...28 Figure 3:...29 Figure 4:

4 Introduction Euchre is a trick taking card game that is traditionally played with four players. Players are divided into teams of two and they play against each other. The deck consists of twenty four cards. These cards are the nine, ten, jack, queen, king, and ace of each suit. For each round of the game, players are dealt five cards. The four remaining cards are placed face down and become the kitty. The topmost card is turned up. This card's suit is offered as trump. It is the only card in the kitty that is shown to the players. The rest are kept hidden until the end of the round. Trump is the suit in which its cards have the highest ranking. There are always seven trump cards. The jack of the trump suit is called the right bower, and it is the highest ranked card in the entire deck. The second-highest card is called the left bower. It is the jack of the other suit of the same colour. For example, if clubs was trump, the right bower would be the jack of clubs, and the left bower would be the jack of spades. The remaining trump cards, as well as the non-trump cards, are ranked based on their face as follows: ace, king, queen, jack, ten, nine [Bicycle, 2013]. Note that a trump card wins over a non-trump card. The first round of bidding begins with the player to the left of the dealer. They have the option of passing or ordering up the card. If the card is ordered up, the dealer has to discard a card in their 4

5 hand. Otherwise, the next player (to their left) has an opportunity to bid. If all of the players pass, the second round of bidding begins. Players have the option of naming the trump suit or to pass. The player is allowed to pick any suit as trump, except for the suit of the card that was turned down. If all of the players pass in the second round of bidding, the cards are thrown in. The next player then becomes the dealer. When a player names trump they may also choose to play alone. In this case, their partner turns their cards face down and does not participate in the hand. Play begins once trump is named. The player to the left of the dealer leads. After, players must follow the suit of the lead card if they are able. If not, they may trump or discard. A trick is won by the highest card of the suit lead or, if trump was played, by the highest trump. The player who won the trick leads next. Once all of the cards have been played, points are awarded to a team. The team who named trump has to win at least three out of five tricks to avoid being euchred. The opposing team scores two points if they are euchred. However, if they win three or four tricks, they score one point. If they manage to win all five tricks, aka a march, they score two points. The scoring for a lone hand is the same for all cases but a march. If the person playing alone wins a march, they score four points instead of two points. A game of Euchre ends once a team wins at least ten points. 5

6 Motivation Mobile devices are a popular platform for games. More and more game companies are releasing on mobile devices than desktop computers. The two predominant mobile operating systems are Android and ios. Android is open source. There are no extra costs to develop and test on Android devices, unlike for ios devices. My specialization is in game development so I thought I should l learn more about Android as a platform. I decided on a Euchre application because I enjoy playing the game. In Ontario, there have been a number of job postings asking for Android development experience. I knew the basics of Android from taking the first year course in the mobile development stream. However, I had not developed a full Android application. I designed this project to gain more experience. Goals The main goal of this project is to finish a Euchre Android application. Another goal is for the application to store statistics about the user's play. The application is to provide various rules that affect how the game is played. Also, the application is to run on different Android devices. Another major goal of this project is to gain Android development experience, specifically in the context of game development. The next goal is to support users playing against each other across the network. Lastly, I wanted to learn how to write AI for imperfect information games such as Euchre. 6

7 Objectives There is much to consider when attempting to make an application that could be deployed on the Google Play store. First of all, your application has be stable. For example, it should not crash if the user answers their phone. To provide this, a developer has to handle activity life-cycle events. There is a wide range of devices running Android. They vary in screen size, pixel density, as well as in their installed platform version. To deal with different screen sizes and densities, an Android developer should define alternative resources, such as layouts and images. The Android training documentation recommends supporting up to 90% of the platforms on active devices [Google, 2014a]. This is more challenging because some features are not available on older platforms. Luckily, Android provides support libraries. Newer features such as fragments and the action bar are supported on older platforms by using these libraries. Details about a Euchre game have to be displayed to the user. They have to know: Who the dealer is Which card was on top of the kitty Team scores What is trump Which team called trump The number of tricks per team Whose turn it is Their cards This information has to be visible no matter which device they are playing on. 7

8 The single player version of the application has to have three AI players. The logic for one AI player could be reused for all of them. Euchre is an imperfect information game. A player does not know which card their opponents (or partner) will play. Each player knows the cards in their hand plus the card on top of the kitty. The application has to have a method for storing statistics in the device's memory. Basic statistics include how many times a user has won or lost a game. As a game progresses, these statistics have to be updated. The application should have an activity where the user can view the statistics and have the option to clear them. To support multiplayer games, a game server is required. The game server has to store and maintain client accounts, possibly in a database. It has to allow the creation of new accounts. The Android application has to connect to this server across the network. To log into the server, the user has to enter their credentials into a form and submit it. The application will send a log in message to the server. There has to be some mechanism on the server to authenticate the connected client based on the contents of this message. If the credentials are valid, the server has to log the client in. Otherwise, it rejects the log in attempt. The user is alerted if they have to re-enter their credentials. The client should have multiple options on the server. They should be able to create a new game and define which rules to play by. Once a new game has been created, other clients have to be invited to join by the game creator. The server keeps a friends list and profile for each client. This is the social networking aspect of the server. The game creator should also be able to invite friends to join their 8

9 game. If four clients join, the game may begin. The server has to maintain all of this game's state. It needs to be able to recreate a game if any clients get disconnected, or if they quit the game. Errors could also occur on the server. For the location services, the server has to temporarily track where clients are located. This is while clients are looking for other nearby people to play against. There has to be a scoring method to rank the players. When a game is completed, all of the user's scores have to be updated. The server has a leader board. It can be accessed by users to see the top scores. Outline This report begins with a description of four free Euchre games on the Google Play store. I review the positives and negatives of each game. Then there is a section detailing the approaches I took and discarded while developing the application. The next section discusses the issues I encountered, as well as which features work and which do not. Finally, I offer some concluding remarks and suggest future work to be completed. 9

10 Background On the Google Play store there are approximately seventeen free Euchre games. As part of my play testing, I studied four of these games. Note that the following scores were recorded on April 16 th The screens were captured from my Samsung Note II. The top two Euchre applications are Euchre by KARMAN Games and Euchre (free) by Jeffreys Software. Euchre by KARMAN Games has received a score of 4.3 stars (out of 5), from over 10, 000 reviewers. There have between 100, 000 to 500, 000 installations of the application. Out of all of the ones I played, it was the most polished. Their application has many configurable settings, which can be viewed in Fig. 1. These settings range from the game's rules to the difficulty of the AI players. It is one of the few applications to not restrict the game's screen orientation to portrait (see Fig. 2). Earlier this year KARMAN Games added multiplayer. According to their website [KARMAN Games, 2014], they are utilizing Google technology for this feature. This implies that it might be Google Play game services. The Google Play game services SDK offers APIs for adding features such achievements, leader boards and, as of January 2014 [Google, 201b], turn-based multiplayer to developer's applications. Unfortunately, as of update 1.3, ads were included into the application. The user has to pay to remove them. KARMAN Games also does not clearly advertise which versions of Android and screen sizes their application will run on. They state that it varies with device. 10

11 FIGURE 1: Screenshots of the settings screen for Euchre. The figure on the right shows part of the expanded Visuals section. 11

12 FIGURE 2: The Euchre game screen in landscape and portrait. Euchre (free) by Jeffreys Software has a score of 4.1 stars from 5, 876 reviewers. It has been installed around 500, 000 to 1, 000, 000 times. The developer claims that it runs on devices with Android 2.1 and up. This would encompass all the versions that are currently in use. It has a clean interface as seen in Fig. 3 and Fig. 4. Everything that you need to view as you are playing is clearly visible. Fig. 5 presents the application's hand history feature. It is unique to this application. Details about the hand are recorded as the user plays and they are appended to this screen once the hand is over. Therefore it does not give the user an unfair advantage of knowing which cards have been played. It is a handy feature if you wish to analyze the hand. The number of customizable settings is comparable to Euchre by KARMAN Games. There are settings to change the game rules, the look and feel of the interface, and the difficulty of the AI players. There is a difference in terms of the menu compared to Euchre. The main activity in Euchre (free) displays where you left off in a game when 12

13 you start the application. Euchre has a menu screen. Euchre (free) instead places the menu in the action bar of the main activity. For Euchre (free), placing the menu in the action bar is the most appropriate. There is single player mode. Euchre has both single and multiplayer game mode, so it has to prompt the user which type of game they want to play. FIGURE 3: Dialog prompting the user for their choice during the first round of bidding. FIGURE 4: Playing a round after trump has been called. 13

14 FIGURE 5: Round history feature. Euchre Master is made by Rencelaw Computing. There has not been any updates from this developer since April 2012, and their website link is broken. They says that it runs on Android 1.6 and up. It did not require any permissions to install, which is preferable for a simple game. The rest of the applications I tested required multiple permissions. The interface is basic, but functional (as shown in Fig. 6). The application restricts the orientation to portrait like Euchre (free). There are some settings (Fig. 7) and the cards are animated. The single complaint I had about the application was in regards to its show last feature. If the show last button is clicked, it shows the cards played in the last round. I 14

15 do not understand why someone would want this feature. Its dismissal behaviour is also unexpected. It fades away after a certain amount of time. The user cannot dismiss it manually and it covers the played cards. Fig. 8 illustrates this. FIGURE 6: Screenshot of the Euchre Master game screen partway through a round. FIGURE 7: The settings screen for Euchre Master. 15

16 FIGURE 8: The show last feature. Notice how it covers up the user's and their partner's card. Euchre U is developed by Gidilevich Software. Based on 47 reviews, the score of the application is 2.5 stars. The developer claims that it will run on Android 2.1 and up. 10, 000 to 50, 000 copies of the application have been installed. Overall, this application was the least polished out of the ones I played. It saves simple statistics such as the number of games played, game won and games lost (Fig. 9). There are only three settings (Fig. 10). These are the game speed, stick the dealer and landscape mode. The landscape mode has bugs. While playing the game in landscape, if you use the options menu to go back to the main menu, the setting for landscape mode becomes unselected. On 16

17 occasion, if I navigated back to the game screen after this, the application would unexpectedly crash. How the application draws the user's card during play is different from the other application. Whenever the user has a card in the lead suit, it draws them larger than the rest of their cards (Fig. 11). I found that the cards were small, but legible, on my device. In comparison, the score and number of tricks were very small and hard to read. FIGURE 9: The statistics screen for Euchre U. FIGURE 10: The settings screen for Euchre U. 17

18 FIGURE 11: Screenshots showing the landscape and portrait orientations of Euchre U. Note the size of the text for both the team scores and number of tricks in the upper right hand corner of the game screen. 18

19 Approach I first broke down the game of Euchre into a requirements list. That way I would have an idea of what I needed to do to get a basic game running. I began implementing items on the list in a simple Java program. The program initialized the cards and dealt them to an array of players. It was supposed to loop until a team had won at least ten points. I thought that if I had a Java version, I could convert it to Android. Early on I researched into developing for Android. This was done using books accessible through the Carleton library. I thought I should obtain more knowledge on the subject due to my limited development experience with the platform. I wanted to avoid beginner mistakes. I fully read through a few of the books. While reading, I tried to simultaneously search for useful information, in regards to my project, such as the activity lifecycle and drawing bitmaps. Most of these books discussed topics that I would never use in my project. Overall, this was not the best approach. I was attempting to learn too much at once. I also kept reading without testing out some of the code in the books. I should have looked into topics that were the most relevant to my project and wrote small demos to apply what I had learned. I wrote small demos to understand parts of the SDK. This way I could test out a feature without affecting my main project. I used this approach for the GPS, a database, the ConnectivityManager and the networking code. I thought I could utilize the location services for the game server. Using a device's GPS, the API provides the fine or coarse location of the user. This location could be sent to the server in order to find 19

20 nearby users to play against. The server would have to calculate the approximate distance between users for this information to be useful. I became sidetracked while reading. I began developing extra features, especially ones related to customizable application settings. I realized I was wasting time and quit. The game had to be functional before I could even consider developing extra features. I compiled a to-do list based on my project proposal. This list helped me to stay focused on my goals, but I felt I should have done it much sooner in the project. I returned to my idea of writing a rough version of Euchre in Java. I implemented two AI players, random and high, to simulate a game against the user. The random player behaves according to its name. It plays a random card in its hand while following the lead suit. High always plays the highest card in its hand with the same restrictions as the random player. I finished the program in stages. First, I kept it to one hand. I hard-coded trump and the player's cards for testability because a game of Euchre has many test cases. There are multiple hands per game, trump influences the value of a card, players have to follow the lead suit, and so on. Once I was able to play a full hand I added the logic for a full game. I used the game rules that I normally play with, meaning that a game ends when a team wins at least ten points, and a hand is thrown if no one calls trump. This was an effective approach because it gave me a basic program for which I could improve upon. The rough version's classes were not well designed. I should have planned them out more carefully before writing them. Players should control their own deck, and I felt there should be a common interface for all the players. The control flow for AI players differs from the user of application. An AI player acts immediately on their turn. For comparison, the game has to wait for 20

21 input from the user when it is their turn. While writing my proposal, I conducted play tests of the free Euchre applications on the Google Play store. They tended to restrict the orientation of the device. Most of the games only supported a portrait orientation. This is understandable because, on smaller devices, it is challenging to show the played cards along with any other information. Cards are taller rather than they are wide. This means that the user's hand will cover a fair portion of the display. If you create any dialogs, there also has to be space for the user to see their cards. One option I had seen while play testing was the option to see the previous hands. This would be useful if the user was learning the game or trying to improve their game skills. I found a paper that briefly documented the development of the game Tichu [Foril et al., 2013]. It was similar to what I was trying to develop, including networking. They did not write their own server. The networking was handled using Bluetooth. I decided to include basic statistics. These were the number of games won and lost, and the number of euchred calls. I saved them using shared preferences. There are other ways to save data such as external storage, an SQLite database or through web-based services. For a few statistics, shared preferences was sufficient. I had read that there are variations of Euchre for different number of players. I thought about changing to the two-handed variation to make the gameplay logic easier. I also thought it would simplify the server version because I would not need as many devices or emulators to test with. 21

22 However, there are no standard rules for this variation of the game. The rules I read were confusing, so I decided to stay with the traditional four player game. I started looking at examples of open-source servers and Android card games. One of the most completed games I found was Yaniv for Android [Katz, 2012]. It has not been modified since October I wanted to use it to learn how games are structured for Android and how they handle the application life-cycle. Yaniv for Android stores the game state by having serializable classes. It saves the instances to a file. I thought that this would be a good way to quickly save the game state. How it handled turns was not useful for my project. It waited until the user clicked on a next button to progress the game, rather than automatically starting the AI player's turn. 22

23 23

24 Figure 2: 24

25 25

26 Results My project proposal was lacking in details. It was written to give me the flexibility on which game rules and statistics I wanted to implement. I was unsure which project goals were achievable when I wrote it. The issue was that it might have been too flexible. I became distracted on implementing customizations for the user rather than working on the game. Working with images was initially problematic. The archives of card images I downloaded contained both SVG and PNG files [Bellot, 2004] [Knoll, 2011]. Android does not have any classes for loading SVG files. The API guides mentioned that PNG files are the preferred format for images [Google, 2014c]. I therefore utilized the PNG files for my cards. I wrote a demo application to load and draw the cards. When it ran on the emulator, it threw an out of memory exception. The emulator's memory ran out because the bitmaps were too large. I temporarily resized the images to half their size using the SVG files. After that all of the images loaded without any issues. The multiplayer mode and the game server were not finished even though I spent quite a lot of time researching how to implement them. I did not have any experience with networking. This fact greatly hindered this project. At the midterm mark, completing them was not feasible, so I stopped working on them. Converting the rough Java version to Android was more difficult than I planned. Activities have a life-cycle. Applications have to handle life-cycle events in order to be stable, and to behave in way the user expects. Creating classes that during this life-cycle is not the same as developing in a desktop environment. For my game class, I initialized it at the application level so that it would not be recreated 26

27 when oncreate is called. The method oncreate is called in the case where the user rotates their device. Users do not want their game to be discarded and have a new game started if they happen to rotate the screen. I wanted to try and follow the MVC pattern, if possible. That way if the user interface changed it would not affect the underlying game logic. It was not obvious how this should be done in Android. A goal I struggled with was designing a GUI for multiple screen sizes and densities. How you handle this is somewhat based on how you draw the game. The game could be drawn using a Canvas, SurfaceView, OpenGL ES, or views. I had very limited knowledge of OpenGL, so I did not consider it an option. Canvas seemed viable because I had to draw the cards as bitmaps. The game's graphics were fairly static. A canvas is better suited for a game with graphics that change dynamically. My initial Android version would block the main thread. This meant that updates to the display did not occur until the user's turn. I did not know how to deal with this issue. There was not many resources to help. 27

28 Figure 1: Figure 2: 28

29 Figure 3: Figure 4: 29

30 Conclusion In the end I did not achieve as much as I wanted. This was due to not knowing how long it would take to complete my goals. My project was too ambitious from the start, factoring in my Android and networking background. Making the single player version probably would have been sufficient as a project. Future work I have many ideas for future work. I still want to write a game server. A user could be authenticated by logging in with their Google+ or Facebook account, rather than implementing my own authentication method. I might also try out the Google Play services SDK. I would add application settings for users to customize in order to compete against KARMAN Games. They have many settings. There are ones for online play, visuals, sound, card selection and game speed. I would store them using a preference activity. The easiest setting to add would be allowing users to select different card backgrounds. Other possible settings could be sorting the cards in the player's hand by rank, autoplay single cards, dim invalid cards, different ways of selecting cards (e.g., click and drag, or tap), and names for the AI players. It would be simple to sort the cards in the user's hand because each card has a score associated with it. I would like to eventually add animations to the game. Animations for views are supported back to API 11, which is an issue if I plan to support up to 90% of platforms Android. According to the April 1st Android dashboard [Google, 2014d], 17.8% of users still are running API

31 The majority of the free games in the Google Play store maintain a wide range of game statistics. My application only maintains basic statistics. I would like to add more in the future. I might add more game rule variations. I was planning to add the rule going under as it a rule that I frequently saw while play testing. It is a first come first serve type of rule. The first person who calls it is allowed to switch their lowest cards with the three cards hidden in the kitty. I might consider providing users an option to play against nearby people using a peer-to-peer connection. I discounted this option originally because Wi-Fi P2P seemed the most appropriate for this task. It has a faster connection speed over a larger distance than Bluetooth [Google, 2014e]. The problem was it is only available on devices running API 14, or higher. 31

32 References Bellot. (2004) Introduction to SVG-cards Bicycle. (2013) Foril, Gairing, Pfannkuch, Schwarz (2013) Developing an Android app for the card game Tichu Google. (2014a) Supporting Different Platform Versions Google. (2014b) Google Play Services Google. (2014c) Canvas and Drawables Google. (2014d) Dashboards Google. (2014e) Wi-Fi Peer-to-Peer KARMAN Games. (2014) Katz. (2012) bestcardgameever-android Knoll (2011) Vector Playing Cards 32