from single to multiplayer mobile bluetooth gaming

Download PDF
5 downloads 547 Views 855KB Size Report
Comment
game, along with a game engine that can be used for the development of the graphical elements .... As with any J2ME application the MIDlet is the essential ...
FROM SINGLE TO MULTIPLAYER MOBILE BLUETOOTH GAMING

Daniel C. Doolan Department of Computer Science, University College Cork College Road, Cork, Ireland Email: [email protected] Phone: +353 21 490 3164 Fax: +353 21 4274390

Kevin Duggan Department of Computer Science, University College Cork College Road, Cork, Ireland Email: [email protected] Phone: +353 21 490 3164 Fax: +353 21 4274390

Sabin Tabirca Department of Computer Science, University College Cork College Road, Cork, Ireland Email: [email protected] Phone: +353 21 490 3662 Fax: +353 21 4274390

Laurence T. Yang Department of Computer Science, St. Francis Xavier University Antigonish, NS, B2G 2W5, Canada Email: [email protected] Phone: +1 902 8675546 Fax: +1 902 8673302 Corresponding Author: Daniel C. Doolan, [email protected]

From Single to Multiplayer Mobile Bluetooth Gaming ABSTRACT The growth of mobile phone sales is phenomenal with estimated sales for 2007 / 2008 expected to be approximately one billion. The majority of these devices are Java enabled, giving rise to a huge market within the realm of computer games. Most of today’s mobile games are designed to execute on as many phones as possible. Thereby they focus on MIDP 1.0 technology; such devices have very limited resources compared to the top of the line phones of today. The primary reason for this is to maximise profits, by having the game reach as wide a potential market as possible.

Mobile technology is ever advancing, and the

capabilities of the lower end devices will continue to improve. Perhaps in the not too distant future we will see all of the lower end mobiles Bluetooth enabled and supporting more advanced Java implementations. This chapter examines the world of mobile gaming. In particular it looks at what is needed to produce a single player game, and what elements are necessary to modify it to allow for multiplayer gaming over a Bluetooth network. A framework is presented to allow for the rapid transformation of a single player to multiplayer game, along with a game engine that can be used for the development of the graphical elements, such as the background and sprites. The multiplayer framework makes use of the Mobile Message Passing Interface (MMPI) to simplify the creation of the network connections, and inter-device communication.

Index Key Words Multiplayer games, Bluetooth, mobile message passing interface, MIDlet, Canvas, Sprite, single player game, Client, Server, Avatar, Player, broadcast.

INTRODUCTION The area of computer gaming is a huge multi-billion dollar industry. One of the first computer games developed was called Spacewar for the PDP-1 computer in 1961. The game consisted of two player controlled spaceships, flying about a central star, each trying to destroy the other. The first generation of PC based games were generally text adventures or interactive fiction. This was due to the early computers having very limited resources and graphic capabilities. The Commodore 64 personal computer was introduced in 1982 and stayed on the market until it was discontinued in 1994. During that period thousands of titles were developed for it many of which included games such as Platoon, Ghostbusters and Commando. The Commodore 64 had a processor of approximately 1Mhz and 64KB of memory. This is in stark contrast to many of the fairly standard smartphones of today such as the Nokia 6630 and 6680 which feature a 220Mhz processor and several megabytes of system memory. Other machines of the 1980’s included such systems as the Apple II, Sinclair ZX Spectrum, Amstrad CPC 464, Atari and the IBM PC. All the games of this era were 2D type games with limited bit depth. In 1991 id Software produced one of the first first-person shooter games called Hovertank 3D (Hovertank, 1991), this represented a breakthrough in gaming featuring the first use of real-time software-rendered 3D graphics. The following year Wolfenstein 3D (Wolfenstein, 1992) became the first commercially successful first-person shooter game (originally released May 5, 1992). Just fifteen years ago saw the release of Doom on the PC in 1993, which was hailed as a breakthrough in 3D computer graphics and also supported networked multiplayer gaming. In the intervening years the quality of level of realism of computer games has increased dramatically with releases of such games as: Duke Nukem 3D, Quake, Half-Life, Halo, Age of Empires, and Settlers. 3D graphics libraries such as DirectX and OpenGL have also matured and are used in a substantial number of modern day games. Just three years ago in 2005 saw the release of the AGEIA PhysX (AGEIA, 2006) hardware based physics engine, removing the need for complex physics based calculations to be carried out it software. That and the advancement of graphics cards capable of carrying out many of the expensive operations in hardware as meant that the games of today have a very high level of realism.

Such is the demand for mobile computing products that the European Union market penetration averaged at 111% for the year ending 2006, while only four years before it stood

at 80%. Clearly no longer are we happy owning just one mobile phone. Luxembourg recorded a record high penetration rate of 156% in 2005, although this dropped to 138% in 2006.

All modern mobile phones are capable of running games, that are usually Java or BREW based. A typical example of this is the game DOOM RPG (Doom, 2005) which is available in both formats (released September 19, 2005). The primary focus of this chapter is with regard to the development of Java based games (MIDlets). Specifically how one can develop a single player game and rapidly transform it into a multi-player game with the minimal of changes.

BACKGROUND

Games, games, games, just about everybody love to play games, each having their own particular preference of game genre. Games are usually classified into a selection of genres that reflect the type of game play. There is a general lack of commonly agreed criteria for defining particular genres. This is further complicated as many games may overlap particular classifications, for example a game could have elements of action, strategy and role-playing. Many of the main game classifications include: Strategy, Role-playing, Adventure, Platform, Simulation, and Sports. The majority of games available for mobile phones, are single player. Multiplayer mobile games are usually limited to turn based games, such as chess, and poker. Multiplayer games are generally more entertaining as you the player are competing against other like players and not computer based AI’s.

An alternative means of classifying mobile multi-player games was devised by Wang et. Al (Wang 2006) based on two main classifications: the data transmission requirements and the modes of user interaction. The data requirements called the “updating dimension” is sub classified into three categories: U1 Asynchronous, U2 Synchronous and U3 Real-time. Games that feature the Asynchronous mode of updating are not time critical, with the updates occurring whenever possible. The Synchronous division requires a more frequent updating of inter-device state. The amount of data to be transmitted is quite small, limited to general information such as game scores, rankings and simple player states. The final sub-category U3 Real-time requires the largest amount of data exchange between participating nodes. This would include information such as the location of avatars, the firing of weapons and so forth. Therefore to ensure that all devices participating in the game are displaying consistent scenes

to the players the refresh rate for inter-node state would have to be quite high. From the User Interaction perspective the games may be divided into four categories: I1 Controlled, I2 User Interaction, I3 Automatic triggered and I4 Automatic. The Controlled category is suited for turn based games, or games that follow a specific pattern or sequence. In the User Interaction category, user interaction will in-turn trigger data exchange. Games that may search for other players and cause an action to occur when found fall into the Automatic triggered category. The final category Automatic require no user interaction, and can often be found in roleplaying games, where the players create characters, and once create they can fight automatically with the other characters existing within the gaming universe.

The Mobile Message Passing Interface (MMPI) (Doolan, 2006) provides the developer with a simple to use MPI type interface to carry out inter-device communication, abstracting from the need to write any Bluetooth specific code. By using this library one can achieve communications between two or more devices with about half a dozen lines of code. This is in stark contrast to the several hundred lines of code a developer would have to write just to achieve the same end result. Thus by providing the developer with a simple set of methods to achieve communication, the entire process of creating Bluetooth applications can be greatly simplified. Not only that but development time, costs, and errors can be reduced.

The Bluetooth Multiplayer Games Framework (BlueMGF) is a project available from sourceforge that provides a framework to create both multiplayer games and applications running over a Bluetooth network. A two player tank combat game is included within the package as an example of the frameworks usage. The project is quite recent being registered in January 2007. At present four developers are involved in the development of the system of which the current release is version 1.7. A little over 2,000 downloads of the framework and associated files have occurred prior to August 2007. The framework consists of a set of nine Java classes within the package panic.bluemgf. To create a Bluetooth application using the package one must extend the BlueMIDlet class. This performs the initialisation of the system and displays the game mode configuration form. The configuration form allows the user to choose between the options: Stand Alone, Server, Client and Configuration. The configuration option allows for the user to select the level of logging feedback to report (which is makes use of another sourceforge project called log4j2me) and the type of connection protocol to use (L2CAP or SPP).

If the user chooses the option of “Stand Alone” then the role of the framework is concluded as no inter-device communications are required. Choosing the “Server” or “Client” options will instigate use of the framework for the carrying out of communications in a Client / Server, star network topographic manner. When creating a MIDlet to use the framework one needs to call two methods in the constructor setNumberOfPlayers(…) passing a parameter for the number of players to partake in the game, and setServiceUUIDAsString(…). The second method requires the developer to specify the Universally Unique Identifier (UUID) for the game.

The last section to develop for is to implement the handleEvent(…) method which is in turn called by the framework. Two parameters are passed to it from the framework, the first being a string representing if the application has been started as a stand alone application, a Client or a Server. The second parameter returns a Vector of Connections if the application has been started as a Server, or just a single instance of a Connection object in the case of a Client. The disadvantage of this is that when a developer starts to code for a multiplayer game they must deal with Connection objects, data streams and communications error handling. Another disadvantage is due to the star network configuration as if a message was intended to be passed between Clients it would have to be routed through the Server, requiring both extra communications and code development time. The framework provides resources only for the communications element, and provides no aid to speed up the development of the game elements itself such as the management of sprites, and various layers.

THE GAMING FRAMEWORK

A simple architecture is presented that may be used for the creation of both single and multiplayer games (Duggan, 2007). The primary advantage of using the architecture for the development of single player games is that a multiplayer version can be readily created with the minimal of code changes. This is made possible by making use of the MMPI library for abstracting the programmer form the intricacies of inter-device Bluetooth communications.

One can generally go about creating a J2ME game in two different manners, the first is to simply create a Canvas and directly paint on the background scene and character representations using the drawing methods of the Graphics class. This can make the

programming of the game more complex, and one must work at a relatively low level. Another big problem with this style of game programming is that of screen sizes, due to mobiles having a varying selection of screen sizes one would have to carefully develop to factor in this non consistent aspect. The J2ME Game API package simplifies both the development (as elements can be put together as layers), and the resizing of on screen elements of on screen elements in accordance with the devices display size is far less of a problem.

The framework structure makes use of the Game API giving access to such key classes as TiledLayer, Sprite, GameCanvas and the LayoutManager. For the creation of any game with these API classes one must go through the laborious task of creating the background scene, the avatars, layering them together adding them to the LayoutManager and so forth. Much of this must be carried out for every new game one may develop. Therefore there is quite a large amount of repetitive development that can be streamlined to allow these elements of the game to be put in place rapidly, leaving only the essential elements to be developed such as how should on screen characters interact with one another and their environment.

The framework comprises of three main Java classes (Figure 1), namely: the MIDlet, GameManager and the GameCanvas. As with any J2ME application the MIDlet is the essential element that is the starting point for any application. In this architecture it handles user navigation through the various screens of the game, and the creation of the game objects. The GameCanvas is used to display all the onscreen elements of the GameManager class and handle some elements of user interaction such as the pausing and exiting of the game. The essential class within the framework is the GameManager, it includes several key elements for the creation of the game elements as well as user input and management of the game loop.

Figure 1. The Framework Structure

The GameManager (Figure 2) handles the creation of the background scene via the method createLevelMaps(), it allows for the creation and maintenance of Sprites the handling of player movement and the game loop itself. The Sprites include both the player’s avatar and other essential Sprites such as enemy characters, these elements are maintained by an array of such Sprites.

Figure 2. Elements of the GameManager Class

Single Player Game

In the case of a single player game just three lines are essential to get the games setup. This involves creating the Sprites (Listing 1), rendering the world and displaying the canvas onto which all the gaming elements are placed. The rendering of the world constitutes the creation of the background scene and the addition of the Sprites to the LayerManager. The createSprites(…) method takes as a parameter the number of Sprites to create. In the case of a single player just one avatar is required. In the case of a multiplayer game then the number of devices that are participating in the game is passed.

Listing 1. Setup and Display of a Single Player Game createSprites(1); renderWorld(); midlet.displayGame(canvas);

For a Single player game, while under execution (not in a paused state) one need only acquire the user input gained from the canvas object and pass it to the movePlayer(…) method to update the on screen avatar (Listing 2). This needs to be carried out during every game loop. The second parameter to the movePlayer(…) method takes a zero as an index into the array of player sprites. In the case of a multiplayer game this index value would have to reflect the sprite that corresponds to the relevant device initiating the user based movement.

Listing 2. Game Loop Code for a Single Player Game while(gameRunning){ this.movePlayer(canvas.getKeyStates(), 0); }

Multiplayer Game

The essential changes between a single player and multiplayer game is the inclusions of interdevice communications. The first priority with a multiplayer game is to establish the communications infrastructure, once created the other elements of the game can be created and the game may then presented on screen to the user for play. This additional step is achieved by the inclusion of a method called setUpMMPI(…) (Listing 3). In comparison to the single player example Listing 1 the setup of the multiplayer system requires only a few extra method calls and a slight modification to the parameter of the createSprites(…) method. Setting up the communications infrastructure requires the creation of an MMPI object, this takes as parameters the type of node it should create (Client / Server) and an object for the logging of the status of the Bluetooth system. The selection of the node type requires the inclusion of an additional form to be displayed to the user to select the appropriate mode. This is included within the MMPI package itself. The creation of the communication streams between the devices can take a considerable amount of time due to device and service discovery. Therefore a Thread is created that creates a splash screen while the system is initialising. Once communications has been established the Sprites can be created based on

the number of players (device) present in the game. The world can be rendered and finally displayed.

Listing 3. Game Setup Code for a Multiplayer Game public void setUpMMPI(){ mmpi= new MMPI(nodeType,new LogScreen(midlet,canvas)); Thread mmpiThread = new Thread(){ public void run(){ midlet.displayWaitingScreen(); while(!mmpi.isComplete()){ try{ Thread.sleep(1000); } catch(Exception e){ } } createSprites(mmpi.getSize()); renderWorld(); midlet.displayGame(canvas); } }; mmpiThread.start(); }

The handling of user based interaction requires some extra minor additions for the multiplayer game so that as a player’s avatar moves or interacts, the state change needs to be transmitted to all the other devices so the on screen graphics remain synchronised across the multiplayer world. The first stage of the communication process (Listing 4) is to generate a packet to be transmitted consisting of the user input key states and the state of the game itself. The game state may contain flags to indicate whether the game has been paused or ended. This packet must then be transmitted. This is done using a global communications method to broadcast this new state information to all the other participating games. The player’s avatar position is then updated according to the input from the user. Finally the broadcasts from other players are received and each character is again moved to reflect the system wide state of all the on screen avatars.

Listing 4. Game Loop Code for a Multiplayer Game while(gameRunning){ userInput = canvas.getKeyStates(); int[] sendPacket = {canvas.getKeyStates, gameState}; mmpi.bcast(sendPacket,0,sendPacket.length,MMPI.INT,mmpi.getRank()); int[] recvPacket = new int[2];

this.movePlayer(recvPacket[0],mmpi.getRank()); for(int i =0;i< mmpi.getSize(); i++){ mmpi.recv(recvPacket,0,recvPacket.length,MMPI.INT,i); this.movePlayer(recvPacket[0],i); } }

The inclusion of random within a game requires such elements to be generated on one device and then broadcast to the others, to ensure those elements appear in the same state across all devices. Therefore the packet structure of input state and game state can be appended to include random element states. In the case of the MMPI based multiplayer game, the root node generates all of the random elements and broadcasts through out the network.

An aircraft based shooter type game (Figure 3) was developed using the framework to examine its effectiveness. The game consists of a number of aircraft that reflect the number of players in the game. To win the game a player must find a glowing sphere and keep it for a specified amount of time. Other players may shoot each other to prevent them from acquiring the sphere first. The sphere moves about at random locations; hence this element is handled by the root node. A player’s aircraft always remains in the centre of the screen; therefore in this case each player may have a slightly different view. Even with several players involved in the game the synchronisation work seamlessly. Therefore the framework not only allows for rapid game development, but also allows for effective real-time multiplayer Bluetooth based games to be achieved. Communication times of 100ms are often quoted as the upper bound acceptable for real-time games. In the case of the aircraft game the communication times for a four player game were little over halve this recommended value.

Figure 3. Screen Captures of an Aircraft based Game with four Players

Simplifying Game Creation CASE is the use of computer-based support in the software development process. CASE tools can be used to support the development cycle of a software application. Most CASE tools such as UML tools give the developer the ability to visually create and represent different aspects of the application they are designing. Another important feature of CASE tools is automated code generation. The visual representation created by the developer is taken and transformed into the application source code, Hence the developer is relieved of this tedious task allowing more time to be spent on the actual design and functionality of the component.

Within the area of game development, a CASE Tool package is more commonly referred to as a Game Engine. A game engine is the major component of any game development project. It provides the developer with a technology base to build upon. Development of a game is therefore simplified. A few mobile game companies have developed their own Game Engines to aid development.

Octopi (Nokia, 2005a) is a company that develops web-based multiplayer mobile games. It has released a suite of casino games featuring Texas Holdem, Texas Holdem Tournament, Five-Card Draw Poker and Blackjack. Their proprietary game-development engine is called Octoplex, which supports multiple platforms, devices, and languages. All of the multiplayer games communicate via HTTP connections; this restricts them to turn-based applications due to the inherent latency. This however is quite acceptable for the domain of Card games which they ostensibly develop for.

The Chinese Mobile games developer Digital Red (Nokia, 2005b) have developed a multimedia engine it calls `Dragon Bone'. This engine contains a development platform for wireless applications and supports a variety of mobile operation systems including Symbian OS. Hence a developer can build an application or game once and easily port it to different mobile platforms.

With the generic game structure defined, a CASE tool to aid developers in game creation was also developed. The case tool is a Java Standard Edition (JSE) application, with a front end built using SWING. CASE is the use of computer-based support in the software development process. The motivation in developing this tool was to allow for ease and speed of development and hence rapid-prototyping of the game. The core of the game is quickly

developed using the CASE tool. This makes the developer's task less tedious as large blocks of the game are generated automatically. These blocks include code to manage multiplayer games, generating level maps, specifying interactions/collisions between game characters and their environment. Defining player states (and the animation associated with those states) for example run, jump and explode. It also allows for the generation of utility screens such as menus, splash screens and alerts.

Figure 4. Game Engine – Map Editor

The tool allows the developer to create the background maps (Figure 4) by simply dragging and dropping a set of small tiles. At the configuration stage it is necessary to specify the number of tiles that will be required for the map. When exported a block of code will be created giving a two dimensional array representing the background. A similar mechanism is also present for manipulating the sprites (Figure 5). One can bring in an image and drag and drop the appropriate tiles that are required for the sprite animation. This again is exported into the source code for the game.

On the right hand side of both the map and sprite editor, one can see displayed the actual image loaded from disk. The left hand side represents the loaded image broken up into its individual tiles, which can be placed in the central area. The content that appears in the central area of the editor is that which will eventually appear in the game itself.

Figure 5. Game Engine Sprite Editor

The tool allows for extra time to be focused on the unique aspects of the game. It provides a set of clear steps to follow for the development of a new game, thus developers with limited experience can easily step onto the rung of the production cycle.

CONCLUSION This chapter has shown that by using a well defined framework one can quickly develop J2ME based games. Moreover by adhering to the framework structure the games can be repurposed into multiplayer games with minimal additional code changes. A J2SE game engine has been also developed that facilitates the creation of background maps and player sprites, resulting in the necessary code being automatically generated and added to the framework structure. Perhaps with the use of distinct frameworks and easy to use libraries for inter-device communications we will see a growth in the development of multiplayer mobile games in the near future. When we look to the near future and see Ultra Wide Band (UWB) Bluetooth coming on stream it will open up a huge area in Bluetooth applications development. In time as our mobile so too advance we will probably see UWB speeds incorporated into our mobiles, thus allowing extremely high end, massive multiplayer mobile games to become commonplace. REFERENCES

AGEIA. (2006). PhysX by ageia, Advanced Gaming Physics Defining the New Reality in PC Hardware,

Retrieved

August

10,

http://www.ageia.com/pdf/wp_advanced_gaming_physics.pdf

2007,

from

BlueMGF. (2007). The Bluetooth Multiplayer Games Framework. Retrieved August 10, 2007, from http://sourceforge.net/projects/bluemgf/ Doolan, D. C., Tabirca, S., & Yang L. T. (2006). Mobile Parallel Computing, In Proceedings of the Fifth International Symposium on Parallel and Distributed Computing (ISPDC 06), (pp. 161-167). Duggan K., Doolan, D. C., Tabirca, S., & Yang L. T. (2006). Single to Multiplayer Bluetooth Gaming Framework, In Proceedings of the Sixth International Symposium on Parallel and Distributed Computing (ISPDC 07), (pp. 343-349). Doom. (2005). Doom Role Playing Game Website, Retrieved August 10, 2007, from http://www.doomrpg.com/ Hovertank 3D. (1991). Hovertank 3D, The first 3D PC game ever. Retrieved August 10, 2007, from http://www.idsoftware.com/games/vintage/hovertank/ Nokia. (2005a).Octopi Brings Multiplayer Games to Nokia Devices Retrieved August 10, 2007,

from

http://www.nokia.com/NOKIA_COM_1/Developers/Success_Stories/Case_Studies/Games/p df_files/successcase_octopi.pdf Nokia. (2005b).Digital-Red Advances China’s Mobile-Game Market, Retrieved August 10, 2007,

from

http://www.nokia.com/NOKIA_COM_1/Developers/Success_Stories/Case_Studies/Games/p df_files/sc_pro_DigiRed_A4.pdf Wang A. I., Norum S. M., and Lund C. W. (2006). Issues related to Development of Wireless Peer-to-Peer Games in J2ME, In Proceedings of the International Conference on Internet and Web Applications and Services (ICIW2006). Wolfenstein

3D.

(1992).

Wolfenstein

3D,

Retrieved

August

10,

2007,

from

http://www.3drealms.com/wolf3d/ KEY TERMS

Bluetooth – Is an RF based, wireless communications technology that has very low power requirements making it a suitable system for energy conscious mobile devices. The JSR-82 Bluetooth API facilitates the development of Java based Bluetooth applications. CASE Tool – A Computer-aided Software Engineering (CASE) Tool is a software tool designed to assist in the development and maintenance of other software products. Such tools include but are not limited to: code generators, Unified Modeling Language (UML) tools, re-

factoring tools and Model transformation tools. In the area of game development they are often referred to as Game Engines. Console Game – This is a type of game that is designed to run on a dedicated gaming system. Examples of such systems include the PlayStation, Nintendo GameCube, Nintendo DS, the Nintendo Wii, and the Xbox to name but a few. Such systems include dedicated graphics hardware for rendering high quality on screen graphics. JVM – Java Virtual Machine’s are now a standard feature of most mobile devices such as phones. They allow for the execution of Java bytecode. Applications designed for these minimal virtual machines are called MIDlets analogous to Applets that are capable of running in a web browser. MMPI – The Mobile Message Passing Interface is a library designed to run on a Bluetooth piconet network. It facilitates application development of parallel programs, parallel graphics applications, multiplayer games and handheld multi-user mLearning applications. Mobile Game – A mobile game is a computer game that can be played on a mobile device. Mobile devices encompass such diverse systems as: mobile phones, PDA’s, ultra mobile PC’s or any other type of handheld device that provides a raster display and facilities for user input. Multiplayer Game – This form of game may involve two or more players that compete with each other, as players are competing with one another it brings an extra level of excitement to the game, that a single player game with some artificial intelligence could not achieve. Such games usually require some form of computer networking to connect the systems together. Single Player Game – This is game that can be played on a single device, be it a powerful desktop computer system or a small resource limited handheld device. Such games typically involve the user playing against the computer which would usually have some AI elements.