Developing a bluetooth enabled J2ME game

Developing a Bluetooth-enabled J2ME Game James McHale A dissertation submitted in part fulfilment of the requirement of the Degree of Master of Information Technology at The University of Glasgow September 2007 Abstract This project investigated the design and development of systems programmed using Java Mobile Edition (J2ME). Particular emphasis was placed on the analysis and implementation of Bluetooth-based communications technology. The communications package demonstrates re-usable portions of code that may be used to add Bluetooth functionality to other programs. The project assesses the material in the context of a mobile game, based on the classic “Top Trumps” card game. 0.1 Acknowledgements I would like to acknowledge the help of Dr Simon Gay, my project supervisor, for offering this project, and providing support along the way. I would also like to acknowledge the help of the DCS Computing Support service for installing the required development environments when needed. I would also like to acknowledge Chris Puncher’s Web Trumps,[17] as I adapted their statistical information as test-data for my program. Jamie McHale September 10th 2007, Glasgow i Contents 0.1 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . i Introduction Context Survey 2.1 Mobile Gaming . . . . . . . . . . . . . . . 2.2 Top Trumps . . . . . . . . . . . . . . . . . 2.2.1 Top Trumps Brand Mobile Games . 2.3 Challenges of Designing for Mobile Devices 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bluetooth Review 3.1 Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Device and Service Discovery . . . . . . . . . . . . . . . . . . 11 3.3 Authorisation and Encryption . . . . . . . . . . . . . . . . . . 12 J2ME Review 4.1 CLDC . . . . . . . 4.2 MIDP . . . . . . . 4.3 Generic Connection 4.4 MIDlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 15 16 16 17 J2ME and Bluetooth 5.1 Local Device . . . . . . . . . . . . 5.2 Discovery and Discovery Listeners 5.3 Searching for Services . . . . . . . 5.4 Publishing a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 18 19 19 20 . . . . . . . . . . . . . . Framework . . . . . . . Analysis 22 6.1 Development Process . . . . . . . . . . . . . . . . . . . . . . . 22 6.2 Requirements Capture . . . . . . . . . . . . . . . . . . . . . . 23 6.3 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 ii Design and Implementation 7.1 Development Tools . . . . . . . . . . . . . 7.2 Game Architecture . . . . . . . . . . . . . 7.2.1 Packages . . . . . . . . . . . . . . . 7.2.2 Class Diagrams . . . . . . . . . . . 7.3 Prototypes . . . . . . . . . . . . . . . . . . 7.4 Game Engine . . . . . . . . . . . . . . . . 7.5 Bluetooth . . . . . . . . . . . . . . . . . . 7.5.1 IBM Bluetooth Package . . . . . . 7.5.2 Creating a Game Encoding System 7.6 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 25 25 26 27 32 34 35 37 38 39 Evaluation 43 8.1 Program Testing . . . . . . . . . . . . . . . . . . . . . . . . . 43 8.2 User Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 44 8.3 Device Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 46 Conclusion 49 A Package A.1 Interfaces . . . . . . . . . . . . . . . . . . . . . . A.1.1 Interface Game . . . . . . . . . . . . . A.2 Classes . . . . . . . . . . . . . . . . . . . . . . . . A.2.1 Class Player . . . . . . . . . . . . . . . A.2.2 Class RemoteListener . . . . . . . . . A.2.3 Class RemoteListener.StatusMessage . . . . . . 50 51 51 52 52 54 57 . . . . . . . . . . 60 60 61 61 61 63 64 65 68 68 69 B Original Proposal B.1 Introduction . . . . . . . . . . . . . B.2 Statement of Problem . . . . . . . B.3 Background Survey . . . . . . . . . B.3.1 Top Trumps . . . . . . . . . B.3.2 Current Software Available . B.4 Proposed Approach . . . . . . . . . B.4.1 Technologies and Concerns . B.5 Work Plan . . . . . . . . . . . . . . B.5.1 Deliverables . . . . . . . . . B.5.2 Approximate Timetable . . iii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter Introduction Bluetooth is a popular communications protocol for mobile devices. It can be found on upwards of a billion units throughout the world. It is found on devices such as mobile phones, printers, earphones, and PDAs. Bluetooth is used for short range, wireless, ad-hoc communication. Harnessing the power of Bluetooth can add a great range of additional functionality to existing programs - and opens up new doors of possibility for the future. This project investigates the use of Bluetooth in developing Java Mobile Edition applications. This project uses the context of developing a simple game application to demonstrate the functionality of Bluetooth. The game will be programmed using J2ME, and include wireless multiplayer functions. The game that we have selected is based on the classic “Top Trumps” card game, in which players compete by having a detailed knowledge of a chosen subject area in particular, the statistics associated with the cards they hold. This project is useful for those who are interested in developing applications for mobile devices, and integrating Bluetooth into their systems. It will provide a review of the J2ME language, the Bluetooth APIs available, collection of code for re-use. The deliverable application will form a useful basis for further projects. We show how an existing Bluetooth package can be wrapped and adapted for easy integration into mobile applications. This report starts by reviewing the context of development: a survey of mobile technology, the Top Trumps card game, and a technical look at the Bluetooth specification. An analysis phase is then undertaken, stating goals for the deliverable system, and looking at the development process. The de- sign and implementation of the deliverable is then summarised and evaluated before a conclusion is reached. Chapter Context Survey 2.1 Mobile Gaming The value of this project is linked to the commercial aspects of the mobile phone game market. The market is virtually saturated in the UK. Communications providers are looking to provide additional services, including both music downloads, and mobile games. It is expected that the global market for mobile games, currently at $2.6bn, will rise to $11bn by the end of the decade[13]. Developing mobile games may have a significant commercial payoff, both in terms of the product produced, and in solving common problems in the development process. Although this project will not be sold commercially, the information derived may be beneficial to other game developers. There are many mobile phone games available. Most of the major phone providers offer a download service for games. Many phones also come preloaded with a variety of games. The current mobile phone game market is still developing. In a recent survey it was found that of the top-selling US mobile games in the second half of 2006, none were original ‘straight to mobile’ developments. Three titles were classic games, ported to the new platform, and seven were licensed titles that were either supporting consolegames, films or were marque branded[14]. Simple games, such as classic arcade games have done reasonably well on the mobile platform. But there is a lot of scope for original content to be produced. The main barrier to mobile game development appears to be the cost of development, and the risk of investing in an unknown title. There have been discussions in the media regarding the future of mobile gaming[19]. There are suggestions of a different way of gaming on mobile phones - building up ‘characters’, or interacting with the real world in some way. Mobile games may not be able to compete directly with console games, but they may be able to offer a totally different experience[3]. 2.2 Top Trumps Top Trumps is a classic card game, which rose to popularity during the 1970s and 1980s. It involves both a simple game-play element and a ‘collection’ element. Many sets of Top Trumps cards have been produced. Sets of cards are based around a particular theme. These themes may be as diverse as cars, aircraft, historical figures, or sea-life. Each card is described by a set of statistics, shared by all of the cards in the set. Figure 2.1: New Rockets: 1982 Waddingtons Series For example, the Waddingtons 1982 “New Rockets” set defined the following five statistics for each rocket: • Propulsion; • Range; • Length; • Diameter; • Weight The game-play is centred around choosing a statistic to challenge an opponent - the ’winner’ of the round being the player with the higher value card for the chosen figure. The collection occurs either during the game, winning your opponents cards, or after where the winner collects ‘ante’ cards. A player, through winning or obtaining new cards can build up their deck of cards, collecting each card in that particular set. The strategy in the game play is building up knowledge of the statistics for a set of cards - knowing what constitutes a ‘winnable’ statistic. Top Trumps has a simple transactional game-play structure: • The available cards are dealt among the players equally. • A player starts the game by selecting a category from their ’topmost’ card, reading out the value of that category. • The second player responds with their statistic for the chosen category. • The winner of the round is the person with the highest value for that chosen category. • The winner of the round adds his or her opponents card to the bottom of their playing deck. If a draw occurred then the two cards are held into the next round, increasing the winning stakes. • The winner of the round then chooses the category for the next round • The overall winner is the person who collects all of the cards. There are many variations on the top trumps game: Three Card Pick In this variation when a player only has three cards remaining they get a chance to pick a card to play, rather than it being their top-most card. The main effect of this is to extend the game-time. Super Pick Traditional Top Trumps cards came in decks of 32 cards. They were labelled A1-A4, B1-B4 G1-G4. Per deck there was one “super pick” card that beat all other cards, with the exception of cards labelled with a ‘1’. Methods • assembleGameStatus private synchronized String assembleGameStatus( Game Player rmPlayer ) game, • dessembleGameStatus private synchronized void dessembleGameStatus( java.lang.String m ) • getStatusMessage public String getStatusMessage( ) 59 Appendix B Original Proposal B.1 Introduction This proposal outlines the ideas, issues and development routes for a Javabased card game, Top Trumps, to be deployed on mobile devices. Top Trumps is a simple transaction-based knowledge game. It has many variations that may be implemented. The value of this project is linked to the commercial aspects of the mobile phone game market. The market is virtually saturated in the UK. Communications providers are looking to provide additional services, including both music downloads, and mobile games. It is expected that the global market for mobile games, currently at $2.6bn, will rise to $11bn by the end of the decade[13]. Developing mobile games may have a significant commercial payoff, both in terms of the product produced, and in solving common problems in the development process. Although this project will not be sold commercially, the information derived may be beneficial to other game developers. This report will firstly define the problem which the project will tackle; look at the background to the problem domain: including similar and relevant projects and discussions; then examine a proposed approach to the project - including a discussion of the relevant technology and associated concerns. We will conclude with an approximate project timetable, and the deliverables to be submitted during the course of the work. 60 B.2 Statement of Problem The aim of this project is to develop a Java-based card game for a mobile phone. The game will be based on the classic Top Trumps game. Players will compete with each other over a wireless Bluetooth connection. Collections of cards will be accumulated through the gameplay, and stored in persistent memory. This project will focus on the quality of the final product, rather than an large range of features. The code will be robust: with particular regard to Bluetooth communication problems. The interface will be tested thorougly with user-evaluation as a key metric. Once a core game engine has been developed then the project may be extended. Possible areas for expansion include: a PC-based Java client to generate card-sets; and extensions to various aspects of the gameplay. B.3 Background Survey In order to gain a better understanding of the project we need to investigate the individual components, and relevant background information. We will look at the classic Top Trumps card game, and the current mobile phone software that is available. B.3.1 Top Trumps Top Trumps is a classic card game, which rose to popularity during the 1970s and 1980s. It involves both a simple game-play element and a ‘collection’ element. Many sets of Top Trumps cards have been produced. Sets of cards are based around a particular theme. These themes may be as diverse as cars, aircraft, historical figures, or sea-life. Each card is described by a set of statistics, shared by all of the cards in the set. For example, the Waddingtons 1982 “New Rockets” set defined the following five statistics for each rocket: • Propulsion; • Range; • Length; 61 • Diameter; • Weight The game-play is centered around choosing a statistic to challenge an opponent - the ’winner’ of the round being the player with the higher value card for the chosen figure. The collection occurs either during the game, winning your opponents cards, or after where the winner collects ‘ante’ cards. A player, through winning or obtaining new cards can build up their deck of cards, collecting each card in that particular set. The strategy in the game play is building up knowledge of the statistics for a set of cards - knowing what constitutes a ‘winnable’ statistic. Top Trumps has a simple transactional gameplay structure: • The available cards are dealt among the players equally. • A player starts the game by selecting a category from their ’topmost’ card, reading out the value of that category. • The second player responds with their statistic for the chosen category. • The winner of the round is the person with the highest value for that chosen category. • The winner of the round adds his or her opponents card to the bottom of their playing deck. If a draw occured then the two cards are held into the next round, increasing the winning stakes. • The winner of the round then chooses the category for the next round • The overall winner is the person who collects all of the cards. There are many variations on the top trumps game: Three Card Pick In this variation when a player only has three cards remaining they get a chance to pick a card to play, rather than it being their top-most card. The main effect of this is to extend the game-time. 62 Super Pick Traditional Top Trumps cards came in decks of 32 cards. They were labeled A1-A4, B1-B4 G1-G4. Per deck there was one “super pick” card that beat all other cards, with the exception of cards labelled with a ‘1’. B.3.2 Current Software Available There are many mobile phone games available. Most of the major phone providers offer a download service for games. Many phones also come preloaded with a variety of games. The current mobile phone game market is still developing. In a recent survey it was found that of the top-selling US mobile games in the second half of 2006, none were original ‘straight to mobile’ developments. Three titles were classic games, ported to the new platform, and seven were licensed titles that were either supporting consolegames, films or were marque branded[14]. Simple games, such as classic arcade games have done reasonably well on the mobile platform. But there is a lot of scope for original content to be produced. The main barrier to mobile game development appears to be the cost of development, and the risk of investing in an unknown title. There have been discussions in the media regarding the future of mobile gaming[19]. There are suggestions of a different way of gaming on mobile phones - building up ‘characters’, or interacting with the real world in some way. Mobile games may not be able to compete directly with console games, but they may be able to offer a totally different experience[3]. This project may be able to build in ideas derived from these articles. As Top Trumps may have a “card collection” element, players may be able to build up a profile of cards and other resources. A possible extension to the project may be the generation of a statistics file, which they can share online with their friends. Top Trumps Brand Games There are several “Top Trumps” brand games available, both for the mobile gaming platform, and for others such as Nintendo DS[5]. Top Trumps Gumball 3000 Supercars Mobile is a Java-based game for mobile phones. It has a humans vs. CPU element, and a human vs. human over Bluetooth element. It includes “lifelines”, functions that modify the game-play, extending the game and making the strategy more complex. Top Trumps Live: Sharks Top Trumps offer simple Top Trumps games on their website[20]. The games are graphics-rich, developed using Adobe 63 Flash. There are several sets to play, including sharks, cricket stars and horror. The graphics aid in the game-atmosphere, bringing the cards to life: B.4 Proposed Approach I will need to use a range of technologies to solve problems of the software development process. We can now review the various Java technologies available, and discuss matters arising: How is Java implemented for mobile devices? What technology will we require for the application? Are there issues surrounding the implementation of these technologies? How feasible is it to implement this technology on a mobile phone? Java has three major platforms: • Java Mobile Edition (J2ME) • Java Standard Edition (J2SE) • Java Enterprise Edition (J2EE) The J2ME platform is a collection of Java APIs (Application Programmer Interfaces) for resource-constrained devices. A resource constrained device, such as a mobile phone, or PDA has limits on some or all of its hardware devices. The memory may have a low capacity, the input may be limited, the output screen may be particularly small. J2ME tries to solve each of these problems. J2ME code can be developed using emulators on traditional PCs. These emulators set the Java running environment of the PC to that of the target device. Because of this J2ME is a popular option for mobile game development. The J2ME platform implements the Connected Limited Device Configuration (CLDC) - a strict set of Java libraries that are the mimimum needed for the Java virtual machine to run. On top of CLDC runs the Mobile Information Device Profile (MIDP) is a specification for accessing the functionality of mobile phones. Programs developed for MIDP are known as MIDLets. 64 This project may have to overcome the limitations of specific devices, or reduce the possible deployment platforms. Some implementations of the J2ME platform specify a maximum program size for the device - and some mobile operators specify a maximum file transfer size over WAP - so graphics and game information may have to be stored seperatly from the program files. B.4.1 Technologies and Concerns There are several areas of specific interest when developing a mobile Java game. We should consider implementation, portability and problems with each of these in turn: • User Input • Graphical User Interfaces • Bluetooth, wireless communication • Data storage and transmission User Input Mobile devices often have limited or novel input methods. These need to be taken into account for game portability. There are two main methods of input, key and touchscreen, for which J2ME has in-built facilities. The game that we will implement will not need advanced input. The essence of the game will be menu-based (however we represent this graphically), and therefore we can use the basic functions of any mobile device. No significant problems are anticipated in this area. Graphical User Interface J2ME provides a set of APIs for programming GUIs, more specifically for games. The APIs provide a canvas on which animation can be performed, and selected areas of the screen updated independently. The APIs also provide key-polling functions - that allow you more control than the standard libraries - over the response to certain key presses. Graphics may be ‘layered’ to provide more complex scenes, with the individual sprites allowing transformations such as rotation and mirroring. J2ME provides 3D graphical user interface libraries - however, it is not expected that these will be needed for this particular project. 65 Graphics files may be quite large - so a suitable format has to be chosen. If transparency is required formats such as PNG are used, however, if it is not then smaller compressed JPGs may be better. This project will develop a GUI for the gameplay element. The card images are a core feature of the Top Trumps game. The project will need to balance the requirements of high graphics quality, with those of resource-constrained deveices both in terms of file size, and display resolution. Bluetooth Bluetooth is a short-range wireless specification for creating so-called Personal Area Networks (PANs). It was designed to be a low-cost, small-sized solution, with low power usage[15]. There are two classes of Bluetooth device. Class are higher-powered devices, with a long range, designed for access-point functionality. The most common devices are Class 2, which operate over a range of approximately 10 meters, and are used for a variety of purposes. Networks of several devices can be made, however, the scope of this project is a simple point-to-point two device link. JSR 82 was the first open, non-proprietary standard for developing Bluetooth applications using the Java programming language. It hides the complexity of the Bluetooth protocol stack behind a set of Java APIs that allow you to focus on application development rather than the low-level details of Bluetooth. JSR 82 is based on version 1.1 of the Bluetooth specification. For the purposes of this project, two features of the Bluetooth protocol will be used: service discovery, and object exchange. Service discovery is the ability to scan for other Bluetooth devices, and recognise functions that the device can provide. Object Exchange (OBEX) has been adapted from InfraRed Data Exchange. It allows session-based spontaneous object and data transfer. Implementing games of sufficient quality over Bluetooth is technically feasible[1]. However, there are still problems in doing so: many manufacturers add their own Bluetooth features, or don’t implement the full standard. Devices must meet the Java API’s minimum device specification: • 512k minimum of total memory available (ROM and RAM) (application memory requirements are additional) 66 • Bluetooth wireless network connection • Compliant implementation of the J2ME Connected Limited Device Configuation (CLDC) It is anticipated that the game will run on most modern mobile phone handsets - although portability testing must play a part of the system development. The testing should occur on “real world” devices as well as PC-based emulators to ensure that as many deployment issues are resolved as possible. Data Storage and Transmission Our project will require a mechanism to store data of both the card sets, and associated graphics. This data will have to be encoded/decoded by the program, and transformed into a format suitable for transmission over Bluetooth. There are several possible ways of achieving this: using standard J2ME libraries, a proprietry data format, or with XML documents. XML is an abbreviation of eXtensible Markup Language. It is a metalanguage, derived from Standard Generalised Markup Language (SGML). It is used to describe information, for both storage and transmission. It has widespread use on networks, namely the Internet, and the derived XHTML standard. The advantages of using XML are: ease of use, and portability between systems. As XML is encoded so that it is human-readable the file sizes tend to be larger than if a more simple format is used. Should XML be chosen to represent the card sets then an evaluation of the various XML parsers available must be performed. J2ME does not provide a library for reading/writing files as a default. Many devices not actually have a file system as standard, so the limitation isn’t as strange as it initially sounds. There are optional libraries for the reading/writing of files, and it is up to each device implementation to expose them to applications[4]. As the project must store graphics files alongside card-set information, it may be useful to read/write simple files - as only one file access method would be used, rather than having the additional burden of XML. 67 B.5 Work Plan B.5.1 Deliverables The following deliverables will be submitted over the course of the project: 1. Document: Use-Cases - An outline of the various scenarios that the application will have to deal with. These Use-Cases will be used as a metric of project success. The final application should complete each Use-Case. 2. Document: Class Diagram - An overview of the system model, including attributes and functions for each class. This may be preceeded by simple Class-Responsibility-Collaboration diagrams, that may also be included in the final report. 3. Document: Sequence Diagrams for complex Use-Cases - UseCases that may be interesting or complex from a development perspective should be expanded into sequence diagrams. The sequence diagrams will show interaction between the various classes and the user. 4. Document: Data Structure Definition - The game will require a representation for the card sets, most likely based on XML. This document will outline the standard for communicating these card sets. This may be presented as an XML schema. 5. Java Class: Basic Bluetooth - This class will scan for Bluetooth Connections, broadcast Bluetooth game ‘flag’. 6. Java Class: Basic Data Document - Generate a valid data document, encoding a set of cards. This will be based on the previous Data Structure Definition. Alongside this class will be a series of short tests to ensure valid documents are being produced. 7. Program Milestone: Exchange XML documents via a Bluetooth connection 8. Program Milestone: Basic text-based GUI - This GUI won’t be functional, but will allow the browsing of menus, and other game options, with a pre-programmed functionality. 9. Java Class: Basic game engine - The game engine will provide basic gameplay of standard Top Trumps. 68 10. Program Milestone: Game Engine tied to the GUI and Bluetooth - The GUI will now be functionally coupled to the game engine to provide basic gameplay over Bluetooth. 11. Program Milestone: Graphical User Interface - A Graphical User Interface will be implemented for the game. This represents the basic final deliverable. 12. Beta Version - This version will be a functional game, ready for testing. 13. Document: Test Plan - The test plan will evaluate all functionality of the game. There will also be a usability/heuristic evaluation. Although this test plan is listed as one of the later deliverables, the plan should be developed alongside development of the program to ensure that the testing is complete. 14. Document: Test Results - The test results document will provide the results to the above tests, and document any subsequent improvements made to the game. 15. Final Deliverable. B.5.2 Approximate Timetable The project will take place between June and September 2007. The timetable, as related to the deliverables in the previous section, will be as follows: • June - The first set of documentation will be produced. The problem will be analysed, and the software development process refined. Feasibility studies will be conducted for all the relevant technologies. Deliverables: [ 1, 2, 3, 4]. • July (First Half ) - The basic Java Classes will be started. Objects that communicate wirelessly, encode and finally exchange information will be created. Deliverables: [5, 6, 7] • July (Second Half ) - A second set of Java Classes will be developed that provide a basic interface, and a game engine. These will interact with the classes that have been developed in the first half of July. Deliverables: 8, 69 • August (First Half ) - Once the gaming engine has been constructed, and tied to the object encoding and communication classes then these can be tied to the GUI. The GUI can then be developed with more advanced graphics - a beta version before the final deliverable. Deliverables: [10, 11, 12]. • Auguest (Second Half ) - Once the final deliverable has been produced then the project report can also be finalised. Test plans for refining the deliverable will be implemented at this stage. Deliverables [13, 14]. • September - Finalisation of documentation and write-up. 70 71 Bibliography [1] Peter Andersson. Bluegammon: 3d game code sample. http://developer.sonyericsson.com/site/global/techsupport/ tipstrickscode/mobilejava3d/p java3d bluegammon.jsp The Bluegammon code example demonstrates a simple game working across the Bluetooth protocol. The game includes use of some of the Sony Ericsson 3D graphics API. [2] Anon. Bluetooth, 2007. http://en.wikipedia.org/wiki/Bluetoothw. [3] Daniel Blackburn. Social gaming with bluetooth. http://www.druh.co.uk/base/dan.html This article, written by a managing Director of a games company, outlines various possibilities for mobile game development. It covers Bluetooth, large-scale multiplayer games, social gaming and potential game structures. [4] Eric Giguere. An overview of the file connection optional package. http://developers.sun.com/techtopics/mobility/apis/ttips/fileconnection/ This article provides a short introduction to files on the CLDC with the File Connection Optional Package, defined by JSR 75. It includes short code examples. [5] Jon Jordan. Ds comes up top trumps. http://www.pocketgamer.co.uk/r/DS/Top+Trumps+DS/news.asp?c=1684 A press release, giving details of a Top Trumps game for the Nintendo DS platform. 72 [6] Andre N. Klingsheim. J2ME Bluetooth Programming. V¨ait¨oskirja, University of Bergen, 2004. http://www.nowired.org/Thesis-PDF/AndreK.pdf. [7] Adam Laurie. The bunker - bluetooth security. http://www.thebunker.net/resources/bluetooth. [8] James Lewis. Bluetooth security. http://islab.oregonstate.edu/koc/ece478/05Report/Lewis.pdf. [9] Sing Li. Begining J2ME: From Novice to Professional. Apress, 2005. [10] Sun Microsystems. Cldc jsr 30 jsr 139 overview. [11] Sun Microsystems. Applications for mobile information devices: Helpful hints for application developers and user interface designers using the midp. 901 San Antonio Road, CA 94303, 2000. [12] Oster Miller. String tokenizer. http://ostermiller.org/utils/StringTokenizer.html. [13] Dan Milmo. Mobile phone game sales set to soar. Guardian, July 2005. http://www.guardian.co.uk/computergames/story/0,,1536048,00.html An outline of a report on the mobile gaming industry, including statistics and comments. [14] Richard Mosher. Is creativity dead? licensed vs. original mobile phone games. http://www.w2forum.com/i/Is Creativity Dead Licensed vs Original Mobile Phone Games Outlines the current state of the mobile gaming charts, developing arguments for future game development. [15] Nokia. Bluetooth technology overview. http://sw.nokia.com/id/d42eb404-ccf1-412a-88b7f21cbacf067e/A Brief Introduction to XML Parsing in MIDlets v1 0.pdf An introduction to the parsing of XML documents in MIDlets. [16] Nokia. Nokia n80 developers support forum. http://discussion.forum.nokia.com/forum/showthread.php?t=79256. 73 [17] Chris Puncher. Web trumps. http://www.puncher.co.uk/hum trumps.php. [18] Bluetooth SIG. Bluetooth.org special interest group. http://www.bluetooth.org. [19] Keith Stuart. Mobile gaming exec talks sense shocker. http://blogs.guardian.co.uk/games/archives/2007/01/31/mobile gaming exec talks sense sh Comments on the current state of the mobile gaming industry, including a short review of customer habits, and future releases. [20] Top Trumps. Top trumps live: Sharks. http://www.toptrumpslive.com/sharks/game.asp Play Top Trumps Live online in a Flash-based game. 74 [...]... collaborate with game classes, in order to minimise specific coupling between packages 7.2.2 Class Diagrams A Class Diagram shows the fields and methods of each class in our system We will look at each package in turn, and for reasons of clarity and simplicity, developing the class diagrams in an iterative fashion, adding detail as we go along Firstly, we will examine the basic Class Diagram for the Game. .. 7.2: Class Diagram outline: Game Engine Package These implementations are the RemotePlayer and the LocalPlayer We did not include them on class diagrams on this report for clarity • Game, an interface Defines the basic functions that a game must implement • RemoteGame, implementing the game interface Works as a placeholder, waiting for information from a game on a remote device There is no game logic... The Player Class will interrogate their Game Object (whether Local or Remote) to derive their standing in the current game All of the player methods function as adaptors, allowing access to the game state How do the game engine classes interact with out communications package? We saw on the original package diagram that the communications package interacted with both player objects and concrete game. .. describe the state of the game at the time of examination These variables are: A set of boolean values indicating the basic state: • Is the game running? The game may be awaiting a player, or processing the set-up methods • Has the game finished? The game have run and completed 29 • Is the specified player the “active” player in the current game? When the player is “inactive” they are waiting on their... player • An integer identification number for the last move made, in order to synchronise updates across remote devices The Game interface also provides two methods that modify the game state: • Get a Game Slot - A method that a player object can call (passing itself in the methods parameters) requesting to join the game Should there be an available slot (two slots for a local game, one for a remote game) ... Trumps Brand Mobile Games There are several “Top Trumps” brand games available, both for the mobile gaming platform, and for others such as Nintendo DS[5] Top Trumps Gumball 3000 Supercars Mobile is a Java-based game for mobile phones It has a humans vs CPU element, and a human vs human over Bluetooth element It includes “lifelines”, functions that modify the game- play, extending the game and making the... image, description and statistics 28 Now that we have an understanding of the basic functionality of the game we can add in a set of fields and methods for each class, that will help us understand its role in providing functionality and value in the system Figure 7.3: Game Engine Class Diagram: Detail The Game Engine Class Diagram detail shows the fields and methods we can describe for the player class... game as a whole will be functional There are a subset of requirements that the game- logic dictates, however, they are individual functions and not worthy of examining at Use Case level, e.g each card must have an image associated with it; the card data should be loaded from a text-file 24 Chapter 7 Design and Implementation The focus of this project is on demonstrating a Bluetooth- enabled mobile game. .. the production of detailed Class Diagrams 7.2.1 Packages Figure 7.1: Package Diagram: Overall System Model Our package diagram shows three main constituent components: 26 • Game Engine and Logic • Communications • Graphical User Interface Each of these packages is responsible for a specific group of functional tasks These tasks are dealt with by the classes within these packages The Game Engine implements... implements the rules of the game, contained within the game logic The Game Engine deals with both the core game, and the players that connect to that game Different versions of the classes are shown for implementing the logic of a “hosted/local” and a “remote” game The Communications package sets up and manages Bluetooth connections It will send, receive and interpret all game messages It will respond to . knowing what constitutes a ‘winnable’ statistic. Top Trumps has a simple transactional game- play structure: • The available cards are dealt among the players equally. • A player starts the game by. simple game- play element and a ‘collec- tion’ element. Many sets of Top Trumps cards have been produced. Sets of cards are based around a particular theme. These themes may be as diverse as cars, aircraft,. commer- cially, the information derived may be beneficial to other game developers. There are many mobile phone games available. Most of the major phone providers offer a download service for games. Many