See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/232639663

Design and Development of 3D Mobile Games

Article · January 2010

DOI: 10.1109/ACHI.2010.24 · Source: DBLP

CITATIONS READS
7 1,978

5 authors, including:

Zameer Jhingut Soulakshmee Nagowah

University of Mauritius University of Mauritius
2 PUBLICATIONS   9 CITATIONS    39 PUBLICATIONS   153 CITATIONS   

SEE PROFILE SEE PROFILE

R.K. Moloo Leckraj Nagowah

University of Mauritius University of Mauritius
17 PUBLICATIONS   90 CITATIONS    34 PUBLICATIONS   143 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Mobile View project

Data Analytics for Real-Time Disease Outbreak Management and Surveillance in Mauritius View project

All content following this page was uploaded by Leckraj Nagowah on 08 July 2016.

The user has requested enhancement of the downloaded file.

 2010
2010 Third
Third International
International Conferences
Conference on
on Advances
Advances in
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.
j.zameer@gmail.com, imteeaz@gmail.com, {s.ghurbhurrun, r.moloo, l.nagowah}@uom.ac.mu
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.
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 119
DOI 10.1109/ACHI.2010.24
in Computer-Human
Computer-Human Interactions
Interactions
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.
II. RELATED WORK
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].
 III. DESIGN ISSUES Another concern which affects mostly online multiplayer
This section discusses about some of the design games is mobile network latency. Most of the mobile
issues related to mobile game development. games are turn-based which further aggravates the
problem because players have to wait for the other players
Mobile devices are quite constrained compared to involved to make their move. Furthermore, the game
consoles or PCs especially in terms of screen size, cannot be constantly alive due to limited bandwidth [10].
processing power, keypad layout and software IV. SYSTEM STRUCTURE
implementation. Designing mobile games involves many
critical issues that must be taken into account such as This section proposes a system structure for the
application size, memory space, processing power design of a 3D game along with a description of its
amongst others. different components. Figure 1 shows the system structure
The primary issue is the application size where there is an components.
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 Figure 1. System Structure Components
those on PCs. This is one of the main reasons why mobile
games cannot be played for large time periods. The game Mobile games can be played in two modes: single or
must be designed in a way to fit in the device’s screen. multiplayer mode. Single player is the most common play
However, this affects the quality and type of games that mode for all mobile games. Depending on the game type,
can be implemented on mobile phones since it should be the user can race against time or acquire a maximum
made aware of the various resolutions and color ranges number of scores in a given time. On the other hand,
available on the different phone models. It is even harder multiplayer mode requires two or more players.
when developing for 3D games since it is more complex
to export 3D game objects to different screen sizes than a A. Score and Game Rule
2D object [9].
One of the major components of the proposed structure
Furthermore, user interface is another issue for mobile
consists of the rules and score tracking component. This is
game development and this concerns mostly the
a vital component present in all games. This component
playability of games on mobile handsets. Mobile phones
varies with different games. Depending on the game type,
are designed primarily for voice telephony, as are the
most of them use collision detection techniques to allocate
controls on most of these devices. These are not
score to a player for 3D mobile games.
optimized for use in games. In J2ME implementations,
this can be worked around by using MIDP’s high-level
B. Collision detection
“game actions” (Left, Right, Fire, and so on), which each
device will map correctly to appropriate keys. However, Collision detection adds more realism to games.
MIDP’s high-level actions are limited [9]. 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.
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.
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.
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.
121
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.
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
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 USER INTERFACE LAYER FUNCTIONS
Functions Description
processKeys() 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.
paint() Is actually part of the Canvas class, which represents
an abstract drawing surface for graphics operation.
drawWorld () 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
API, it will consist of methods used to load the graphics TABLE 3 APPLICATION LAYER FUNCTIONS
images and detect collision with other Sprites. Functions Description
The different functions in the application layer are shown startMultiplayer() When a connection with the server has been
in the Table 2. established, this method initiates the client
before starting to communicate together
TABLE 2 APPLICATION LAYER FUNCTIONS serverFound() Checks if the server has already been hosted
and will return true if it’s the case.
Functions Description runServer() Initializes the server.
init() Loads the m3g file containing the world and other runClient() Starts the client and thus establishes a
objects required for the rendering of the 3D world. connection between the two devices.
getObject() Fetches every individual object from the m3g file serverClient Acknowledges if a successful connection
according to their object ID so as to be able to ConnectionEstablished() has been established between the client and
differentiate each of them when the 3D world will be the server and displays the status of the
rendered. players.
initWorld() Renders the 3D world by creating the first part of the
track using every object that has been fetched B. Communication Layer
previously and it also initializes the camera.
updateWorld() Updates the 3D world to a new state. The communication layer is crucial for good
startApp() Loads the graphics images such as sprites by passing synchronization in multiplayer games. As the game
a newly created Image object into the Sprite
proceeds, at regular time interval, each player must see
constructor
append() Manages graphic elements such as sprites to create a the same scene and be at their respective positions on
complete scene by combining them together. each mobile phone. The game is synchronized by
getIntersected() Inbuilt method for M3G API provided by the ray message passing. Table 4 shows the different functions in
Intersection library which is used to check for the Communication Layer.
collision.
collideWith() Detects collision with other Sprites, Tiled Layers TABLE 4 COMMUNICATION LAYER FUNCTIONS
and Images.
winCheck() Is implemented based on the game rules to Functions Description
determine if the player has won or not getLocalDevice() Retrieves information about local device
resume() Stores the initial state of the game available
reset() Reinitializes all variables to start a new game DiscoveryAgent. Places the device into an inquiry mode and the
startInquiry() application should specify an event listener that
will respond to inquiry-related events.
Multiplayer Architecture
DiscoveryListener. Is called each time an inquiry finds a device.
Based on the layers and methods described above, an deviceDiscovered()
architectural design is now designed for multiplayer getDiscoverable() Gets information about the current discovery
games consisting of some additional methods which are mode of the Bluetooth device. It will return an int
specific for a multiplayer game. The user interface layer that is either NOT_DISCOVERABLE, LIAC, or
GIAC.
for a multiplayer game is similar to that of the single Connector.open() Parses the URI and returns a Connection object.
player game. readData() Reads from the Input Stream
writeData() Writes to the Output Stream
User Interface Layer
closeConnection() Closes the Connection when finished

VI. SIMULATIONS AND DISCUSSIONS

Application Layer
To evaluate our proposed architecture, two
different games have been implemented. Furthermore,
two different API namely MIDP 2.0 GAME API and
Communication Layer M3G API have been used and a single player and
multiplayer game were implemented respectively.
Figure 3. Logical Layers of multiplayer architecture
Single player game
A. Application layer For the single player game, a Snowboard game using
M3G API has been developed. The game has a realistic
This layer consists of the same methods defined for the game environment consisting of a snowboarder speeding
single play game but with additional methods specific to down a long track, with various flags and obstacles. The
multiplayer architecture. These include server snowboarder’s aim is to perform different actions such as
initialization, server localization, accepting/ turn right, turn left, accelerate and decelerate. On both
acknowledging clients and establishing client sides of the track, there are trees that act as barriers to
connections. Table 3 shows the different functions in the prevent the snowboard from going off-track. The
Application Layer. application also keeps track of the user’s score and

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 SNOWBOARD GAME SPECIFICATION SUPPORT

Make Model Average Distance Comment

Figure 4. Overview of Snowboard game Covered (units)
Nokia N73 1330 Game runs smoothly
Multiplayer game Sony W880i 842 Game runs but stagnates a
A multiplayer table tennis game has been implemented Ericson little
Motorola V3i 940 Game runs but is slow
using MIDP 2.0 GAME API. The game consists of a
Nokia 6600 - Game does not run as it
table, a ball and two rackets of different colors. The requires CLDC 1.1
players’ aim is to hit the ball in the direction of their
opponents with their respective rackets whilst moving Table tennis game
left, right, up and down. Each player has to hit the ball in The discovery time of different Bluetooth devices was
such a way that it falls in the area of their opponent. If measured. When a user launches the game, the application
after one bounce the opponent is not able to hit the ball, it searches for existing servers and if none has been located,
is the player who earns one point. Otherwise, if the player it hosts one and waits for a client to connect. The
has hit the ball and it falls out of the table, it is the discovery time varied only slightly between the devices
opponent who scores one point. The first player who and was on average in the order of 15 seconds.
reaches a score of 11 is the winner. Service alternates A series of tests were carried out to determine the
every two points. Collision detection has also been maximum range that the game can be played among the
implemented to allow players to strike ball with their two Sony Ericsson handsets namely W880 and K850.
respective bat in direction of their opponent and Table 6 shows the results obtained.
distinguish which one has earned a point. Moreover it
allows for bouncing of the ball when it falls on the table. TABLE 6 RESULTS BETWEEN W880 AND K850 HANDSETS
Proper game synchronization has been implemented so
Average Comment
that both player see the same scene and are at their Distance (m)
respective positions on both phones at a particular time. 1m Smooth running between the two handsets and is
Figure 5 shows the table tennis application which has perfectly synchronized.
been developed with J2ME and tested on Sun Wireless 5m Game runs fine between the two handsets and is
still perfectly synchronized.
Toolkit. 7m Game stagnates a little between the devices and
synchronization is fair
9m 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

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
124
View publication stats
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.
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.