Design and Development of 3D Mobile Games - IEEE Xplore

6 downloads 834 Views 499KB Size Report
implementation. Designing mobile games involves many critical issues that must be taken into account such as application size, memory space, processing ...
2010 2010 Third Third International International Conferences Conference on on Advances Advances in in Computer-Human Computer-Human Interactions Interactions

Design and Development of 3D mobile games M. Zameer Jhingut, Ibtihaaj M. Ghoorun, Soulakshmee D. Nagowah, Raj Moloo and Leckraj Nagowah Computer Science & Engineering Department, University of Mauritius, Reduit, Mauritius. [email protected], [email protected], {s.ghurbhurrun, r.moloo, l.nagowah}@uom.ac.mu

the possibilities for building a game which can simulate a virtual reality. However, 3D mobile games require higher performance, resolution and memory on the handset [3]. Development time and number of resources needed can be twice or even thrice more than that needed for a 2D game development project. There are also new required skill-sets, compared to simple 2D mobile games, in terms of graphics design and network communications.

Abstract -A major issue arising nowadays is the lack of entertainment due to up-going level of stress. In this era of technology, where mobile has become more of a necessity than a luxury, a new form of distraction has taken birth, that of mobile games. Mobile games are one of the primary entertainment applications at present. These games provide a means of relaxation and help to draw users’ attention away from routine tensions. However, mobile game development is more difficult than desktop application development because of scarce resources. Performance is one of the critical requirements for mobile games. With the advancement in technology, mobile multiplayer games have started to evolve. This paper discusses about 3D mobile games development for both single player and multiplayer and also evaluates two different APIs namely MIDP 2.0 GAME API and M3G API.

II.

This section gives a brief overview of the mobile game trends during the last decade. Nokia developed the first mobile game, Snake in 1997. The game became surprisingly popular and was permanently installed on the phones [3]. Few years later, mobile phones were equipped with color screens and downloadable Java games. The games started to be more innovative and in 2001 some of the best WAP games such as “Lifestylers”, a casual turn-based WAP game, was developed by Picofun and “Wireless Pets” was published by Digital Bridges [4]. Nokia introduced its N-Gage platform and wireless online gaming with N-Gage Arena in 2003. The first 3D games were being released in Japan, with titles such as “Ridge Racer” mobile game. On the other hand, during the same year JAMDAT released “Bejewelled Multiplayer”, a multiplayer version for the famous popular Bejewelled which was a killer stroke at one time [4]. The “World of Legend” is the first network game embedded on mobile phones released in 2005 by Nokia, which marks the official debut of network games for mobile phones. Other striking popular games such as “Downtown Texas Hold 'Em poker”, one of the first poker game, developed by Downtown Wireless was released in the same year [5]. In 2006, I-Play released “The Fast and the Furious - Tokyo Drift” game which made big hit [6]. In 2007/8, Nokia introduced a new version of N-Gage. It was released with some excellent games such as “Reset Generation”, “Metal Gear Solid Mobile” and “ONE”. With the arrival of Touchscreen iPhone, developers were able to sell their games directly to consumers without having to deal with publishers and operators [7].

Keywords- 3D games, mobile games, MIDP 2.0 game API, M3G API

I.

INTRODUCTION

Modern mobile phones are like small computers, with limited processing power, but are one of the most powerful compact devices available for mobile computing purposes. A recent study carried out by ITU (International Telecommunication Union) shows that by the end of 2008, mobile penetration has almost reached 50 percent; about 4 billion mobile subscribers worldwide while ten years ago it was close to zero and the number is growing annually [1]. This indicates that mobile phone is one of the most widespread devices available today. Mobile games are one of the fastest growing segments of the game industry. Recent advancements in mobile games include single player, multiplayer and 3D graphics. With the advent of new mobile phones with network connectivity capabilities, multiplayer games are quickly finding an audience, taking advantage of the ability to play against other people. Primarily geared for voice data, mobile phones can send and receive other kinds of data as well. This ability to share information offers an opportunity to design games where players can interact with others [2]. Moreover, the introduction of 3D in mobile games development has become a major challenge. 3D development provides a greater means of expression and 978-0-7695-3957-7/10 $26.00 © 2010 IEEE DOI 10.1109/ACHI.2010.24

RELATED WORK

119

III.

Another concern which affects mostly online multiplayer games is mobile network latency. Most of the mobile games are turn-based which further aggravates the problem because players have to wait for the other players involved to make their move. Furthermore, the game cannot be constantly alive due to limited bandwidth [10].

DESIGN ISSUES

This section discusses about some of the design issues related to mobile game development. Mobile devices are quite constrained compared to consoles or PCs especially in terms of screen size, processing power, keypad layout and software implementation. Designing mobile games involves many critical issues that must be taken into account such as application size, memory space, processing power amongst others. The primary issue is the application size where there is an upper limit on how large an application can be and still run. Mobile games have limited memory and if a game is bigger than the allocated working memory on a device then the game simply will not run. Program code, graphics and sounds all take up space and contribute to the application’s compiled size which leads to another major concern which is the application memory space. When an application runs, it consumes more memory than the application file itself. Every device has a limit on the amount of memory usable by applications. Consequently, it must be ensured that, the game designed can run in the available space without ignoring the processing capability of the mobile handset [8]. Moreover, mobile games are the most processor-intensive applications available. Each new generation of games provides better graphics, requiring more processing power. However, for small J2ME games, processing power is not a serious constraint since MIDlet size limits prevent games from containing graphics that require too much processing power [8]. Mobile devices have screens that are much smaller than those on PCs. This is one of the main reasons why mobile games cannot be played for large time periods. The game must be designed in a way to fit in the device’s screen. However, this affects the quality and type of games that can be implemented on mobile phones since it should be made aware of the various resolutions and color ranges available on the different phone models. It is even harder when developing for 3D games since it is more complex to export 3D game objects to different screen sizes than a 2D object [9]. Furthermore, user interface is another issue for mobile game development and this concerns mostly the playability of games on mobile handsets. Mobile phones are designed primarily for voice telephony, as are the controls on most of these devices. These are not optimized for use in games. In J2ME implementations, this can be worked around by using MIDP’s high-level “game actions” (Left, Right, Fire, and so on), which each device will map correctly to appropriate keys. However, MIDP’s high-level actions are limited [9].

IV.

SYSTEM STRUCTURE

This section proposes a system structure for the design of a 3D game along with a description of its different components. Figure 1 shows the system structure components.

Figure 1. System Structure Components

Mobile games can be played in two modes: single or multiplayer mode. Single player is the most common play mode for all mobile games. Depending on the game type, the user can race against time or acquire a maximum number of scores in a given time. On the other hand, multiplayer mode requires two or more players. A. Score and Game Rule One of the major components of the proposed structure consists of the rules and score tracking component. This is a vital component present in all games. This component varies with different games. Depending on the game type, most of them use collision detection techniques to allocate score to a player for 3D mobile games. B. Collision detection Collision detection adds more realism to games. Depending on the game logic, it can restrict the

120

movement of players within a particular region or determine whether an object has been intersected. In 3D applications, the M3G API makes use of the ray intersection class for collision implementation. Rays are casted through groups of objects and intersections with objects are calculated, together with the distance where the collision occurred. For most 3D games, this class is sufficient for collision detection. For MIDP 2.0 GAME API, collision detection is implemented by making use of the sprite collision method -collideWith(). It makes use of pixel based collision and checks whether images/sprites overlap.

F. Position Tracking Position tracking goes in pair with synchronization. It enables the application to keep track of the players’ position. The dead reckoning technique can be used for calculating the players’ present position from a past position and their velocity since, rather than from physical referents such as landmarks. With dead reckoning, clients need to transmit only changes in the velocities of the moving objects. The exact position of each object is then extrapolated from its last known location and velocity. This enables the game to be operated on limited bandwidth.

C. Graphics3D Graphics3D is a class in the M3G API for the rendering of all 3D scenes. To render a scene with Graphics3D, it is necessary to bind the Graphics3D instance to a target object which is generally a Graphics object. Then the rendering of the world is done, and the target is released. Otherwise, the Graphics3D instance cannot be bound to other object again and the buffers are not flushed. On the other hand, MIDP 2.0 GAME API makes use of the Sprite and LayerManager class for the manipulation of graphics images. These images are stored as an ordered list of layers each having an index which indicates their position front to back. The LayerManager is a class in MIDP 2.0 GAME API which manages the display of image/sprite layers and the view window, hence simplifying the game scene rendering process.

V.

ARCHITECTURE DESIGN AND API

This section proposes a generic architectural design for 3D mobile games development. The design illustrates a system structure comprising of the logical layers of the game application along with the core functions associated to each of them. The architecture diagram in Figure 2 can be accustomed to any single player game. Single Player Architecture User Interface Layer

Application Layer Figure 2. Logical Layers of the single player architecture

D. Friction For added realism in motion game, a frictional component is essential for monitoring the acceleration and deceleration of objects. This component can be implemented in various ways depending on the equation being used. A simple example would be the velocity equation v = u + at which is responsible for the linear increase of speed with respect to time until a maximum speed is reached. However for applications such as card or strategy game, this component might not be essential.

A. User Interface Layer The User Interface layer encapsulates user-interactivity functions for the game play. It allows a user to do specific actions according to specified game key states. Table 1 shows the different functions in the User Interface Layer. TABLE 1 Functions processKeys()

E. Synchronization Multiplayer games require a synchronization component to synchronize the game state of two or more players. This enables the same game scene to be viewed by the players. It allows the exchange of the position of players among the different mobile devices. However, a hindrance to proper game synchronization is network latency, which is the time between sending a request and receiving a response and this lag average to several seconds. For proper game play, the synchronization component should be optimized to minimize network latency or even an AI component can be added in case of network disruption to predict players’ positions.

paint() drawWorld ()

USER INTERFACE LAYER FUNCTIONS Description Performs different action according to the specified game key states. For example if the user has pressed the left button, the application will also make the player in the scene move left. Is actually part of the Canvas class, which represents an abstract drawing surface for graphics operation. Displays the current scene to the screen which consists of the group of objects and the camera.

B. Application Layer The application layer consists of game initialization and game playability methods. In the M3G API, it will consist of methods for loading m3g file containing the world and other objects required for the rendering and managing each object in the 3D world. It also has methods that initializes the camera, updates the 3D world to a new state and handles collision. Alternatively, for MIDP 2.0 GAME

121

TABLE 3

API, it will consist of methods used to load the graphics images and detect collision with other Sprites. The different functions in the application layer are shown in the Table 2. TABLE 2 Functions init() getObject()

initWorld() updateWorld() startApp() append() getIntersected() collideWith() winCheck() resume() reset()

APPLICATION LAYER FUNCTIONS

Functions startMultiplayer() serverFound()

APPLICATION LAYER FUNCTIONS Description Loads the m3g file containing the world and other objects required for the rendering of the 3D world. Fetches every individual object from the m3g file according to their object ID so as to be able to differentiate each of them when the 3D world will be rendered. Renders the 3D world by creating the first part of the track using every object that has been fetched previously and it also initializes the camera. Updates the 3D world to a new state. Loads the graphics images such as sprites by passing a newly created Image object into the Sprite constructor Manages graphic elements such as sprites to create a complete scene by combining them together. Inbuilt method for M3G API provided by the ray Intersection library which is used to check for collision. Detects collision with other Sprites, Tiled Layers and Images. Is implemented based on the game rules to determine if the player has won or not Stores the initial state of the game Reinitializes all variables to start a new game

runServer() runClient() serverClient ConnectionEstablished()

Description When a connection with the server has been established, this method initiates the client before starting to communicate together Checks if the server has already been hosted and will return true if it’s the case. Initializes the server. Starts the client and thus establishes a connection between the two devices. Acknowledges if a successful connection has been established between the client and the server and displays the status of the players.

B. Communication Layer The communication layer is crucial for good synchronization in multiplayer games. As the game proceeds, at regular time interval, each player must see the same scene and be at their respective positions on each mobile phone. The game is synchronized by message passing. Table 4 shows the different functions in the Communication Layer. TABLE 4

COMMUNICATION LAYER FUNCTIONS

Functions getLocalDevice() DiscoveryAgent. startInquiry()

Multiplayer Architecture Based on the layers and methods described above, an architectural design is now designed for multiplayer games consisting of some additional methods which are specific for a multiplayer game. The user interface layer for a multiplayer game is similar to that of the single player game.

DiscoveryListener. deviceDiscovered() getDiscoverable()

Connector.open() readData() writeData() closeConnection()

User Interface Layer

VI. Application Layer

Description Retrieves information about local device available Places the device into an inquiry mode and the application should specify an event listener that will respond to inquiry-related events. Is called each time an inquiry finds a device. Gets information about the current discovery mode of the Bluetooth device. It will return an int that is either NOT_DISCOVERABLE, LIAC, or GIAC. Parses the URI and returns a Connection object. Reads from the Input Stream Writes to the Output Stream Closes the Connection when finished

SIMULATIONS AND DISCUSSIONS

To evaluate our proposed architecture, two different games have been implemented. Furthermore, two different API namely MIDP 2.0 GAME API and M3G API have been used and a single player and multiplayer game were implemented respectively.

Communication Layer Figure 3. Logical Layers of multiplayer architecture

Single player game For the single player game, a Snowboard game using M3G API has been developed. The game has a realistic game environment consisting of a snowboarder speeding down a long track, with various flags and obstacles. The snowboarder’s aim is to perform different actions such as turn right, turn left, accelerate and decelerate. On both sides of the track, there are trees that act as barriers to prevent the snowboard from going off-track. The application also keeps track of the user’s score and

A. Application layer This layer consists of the same methods defined for the single play game but with additional methods specific to multiplayer architecture. These include server initialization, server localization, accepting/ acknowledging clients and establishing client connections. Table 3 shows the different functions in the Application Layer.

122

cumulates the points obtained by the latter until the time limit is reached or the required points have been obtained. The game then displays the best time or highest score. Collision detection has also been implemented in the game to prevent players to go beyond the track boundary and to cater for collision with some obstacles. Figure 4 shows the snowboard application which has been developed with J2ME and tested on Sun Wireless Toolkit.

VII.

TESTING AND EVALUATION

This section focuses on the testing and evaluation of the games which is critical to ensure that the applications work fine. The main factors that have been taken into consideration for the testing phase are performance, portability, responsiveness and 3D graphics amongst others. The tests have been carried out for both snowboard and table tennis game. Snowboard game The snowboard application has been tested on several handsets and the result is shown in Table 5. The game was tested for a time period of 20 seconds and the average distance covered on the track is also listed in Table 5. TABLE 5

Figure 4. Overview of Snowboard game

Multiplayer game A multiplayer table tennis game has been implemented using MIDP 2.0 GAME API. The game consists of a table, a ball and two rackets of different colors. The players’ aim is to hit the ball in the direction of their opponents with their respective rackets whilst moving left, right, up and down. Each player has to hit the ball in such a way that it falls in the area of their opponent. If after one bounce the opponent is not able to hit the ball, it is the player who earns one point. Otherwise, if the player has hit the ball and it falls out of the table, it is the opponent who scores one point. The first player who reaches a score of 11 is the winner. Service alternates every two points. Collision detection has also been implemented to allow players to strike ball with their respective bat in direction of their opponent and distinguish which one has earned a point. Moreover it allows for bouncing of the ball when it falls on the table. Proper game synchronization has been implemented so that both player see the same scene and are at their respective positions on both phones at a particular time. Figure 5 shows the table tennis application which has been developed with J2ME and tested on Sun Wireless Toolkit.

SNOWBOARD GAME SPECIFICATION SUPPORT

Make

Model

Nokia Sony Ericson Motorola Nokia

N73 W880i V3i 6600

Average Distance Covered (units) 1330 842 940 -

Comment Game runs smoothly Game runs but stagnates a little Game runs but is slow Game does not run as it requires CLDC 1.1

Table tennis game The discovery time of different Bluetooth devices was measured. When a user launches the game, the application searches for existing servers and if none has been located, it hosts one and waits for a client to connect. The discovery time varied only slightly between the devices and was on average in the order of 15 seconds. A series of tests were carried out to determine the maximum range that the game can be played among the two Sony Ericsson handsets namely W880 and K850. Table 6 shows the results obtained. TABLE 6 Average Distance (m) 1m 5m 7m 9m

RESULTS BETWEEN W880 AND K850 HANDSETS Comment Smooth running between the two handsets and is perfectly synchronized. Game runs fine between the two handsets and is still perfectly synchronized. Game stagnates a little between the devices and synchronization is fair Both devices are still connected but the game is not synchronized

Another series of tests were carried out between Sony Ericsson K850 and Nokia N73 handsets. The results obtained were similar to the two Sony Ericsson handsets in Table 6. Figure 6 shows the feedback obtained out of 25 users for the snowboard 3D and for table tennis 3D. Figure 5. Overview of table tennis game

123



snowboard game M3G API is supported only on handsets which support MIDP 2.0 and CLDC 1.1. Camera View: It is easy to setup different camera positions due to camera class provided by M3G in snowboard game. Alternatively a single position camera has been implemented for the table tennis application.

VIII.

CONCLUSION AND FUTURE WORKS

In this paper, we evaluated two different APIs namely MIDP 2.0 GAME API and M3G API for mobile games development and our approach can be adapted to different mobile games that have similar features or scenarios. We believe that there are still many improvements that can be made to both games. For the snowboard game, one of the major enhancements is allowing players to select different snowboarders with different characters and choose tracks to race. Moreover, the multiplayer version of snowboard can be developed. For the table tennis game, different tables and rackets can be made available to the gamer as a choice before launching the game. The graphics can also be enhanced in order to perceive the player instead of seeing only the rackets. Last but not least, a single player version of table tennis 3D which will include an artificially intelligent player can be implemented.

Figure 6. User Evaluation of snowboard 3D and table tennis 3D

The evaluation of the two games has been done in terms of: • Performance: The snowboard application has a fair performance on mobile devices due to randomization which requires a lot of resources while table tennis application has a good performance on mobile devices. • 3D graphics: The snowboard application has a realistic 3D environment implemented with trees and snow compared to table tennis which uses mostly sprites and quite poor to implement realistic 3D environments. • Collision Detection: Collision detection is quite complex to implement for both application but however, it lacks accuracy when implemented for M3G API which makes use of Ray Intersection class compared to MIDP 2.0 GAME API which uses collideWith() method, used to detect collision with other Sprites, Tiled Layers, and Images. • Randomization: M3G API is very good at randomization as for the snowboard application, obstacles and flags are at random positions while for the table tennis most objects positions are already defined and MIDP 2.0 GAME API does not support randomization. • Interactivity: For both applications, it is easy to interact with the game by using different keypad controls and the latter responds accordingly. • Portability: The table tennis game is supported by nearly all java-enabled handsets while for the

REFERENCES [1]

International Telecommunication Union, “Measuring the Information Society, The ICT Development Index.” pp. 108, 2009. Available at: www.itu.int/ITUD/ict/publications/idi/2009/material/IDI2009_w5. [2] Donald Wisniewski, Derrick Morton, “ Mobile Games White Paper” , In Proc of the Game Developers Conference 2005 by the IGDA Online Games SIG, 21-2. Available at: http://www.igda.org/online [3] Forum Nokia, “Introduction to Mobile Game Development Version 1.1"; January 2003 [4] Tommi Pelkonen, “Mobile Games E-Content Report 3”, Anticipating Content Technology Need, E-Content Report Series, 2004”. Available at http://www.acten.net/cgibin/WebGUI/www/index.pl/mobile_games [5] Levi Buchanan , “Downtown Texas Hold 'Em, Review. The big poker craze sweeps your handset”, May 2004. Available at : http://wireless.ign.com/articles/512/512400p1.html [6] Mike Abolins, “The Fast And The Furious. Tokyo Drift (3D)”, 2006. Available at: www.pocketgamer.co.uk/r/Mobile/The+Fast+and+the+Furious.+Tokyo+Drift+(3D)/review.asp?c=1238 [7] Peter Cohen, “Metal Gear, Silent Hill games for iPhone” ,December 2008. Available at: www.cio.com/article/471479/Konami_announces_Metal_Gear_Silent_Hill_game s_for_iPhone [8] Shwetak N. Patel and Abowd, G.D., “Beyond Mobile Telephony. Exploring Opportunities for Applications on the Mobile Phone Handset”, GVU Tech Report, August 2003. [9] FORUM NOKIA , “Mobile Game Graphics – Overcoming the Small Screen Challenge Version 1.0”; January 16, 2007.pp.5 [10] Gerhard Schwabe, Christoph Goth, “Mobile learning with a mobile game. Design and motivational effects”, Journal of Computer Assisted Learning, Vol. 21, No. 3, June 2005, pp. 204-216.

124