Mobile Games
Mark Green
School of Creative Media
City University of Hong Kong
Introduction
 Mobile
games are played on a phone or a
mobile game console
 These devices have limited processing
power, little to no graphics support
 3D graphics accelerators for mobile
devices are coming, but they are not
widely available yet
 Must design for limited devices
Device
 Since
devices are limited, mainly work with
pre-computed or pre-drawn images
 Devices don’t have the power to compute
images from scratch
 This is different from current PC and
console games, but similar to older
console and PC games
 We can use the same approach as these
older games
Basic Approach
 Start
by looking at the basic design
approach or theory
 Can’t compute images, so start with precomputed images and put them together
 Produce a set of images that can be
combined interactively to produce the
game display
 Simple matter of copying images to the
screen
Basic Approach
 There


are two types of images:
Background – form the background for the
game
Sprite – smaller images that are placed on top
of the background, could be player, enemies
or game items
 These
images are usually hand drawn, but
could be computed from 3D models
Background
 Background
images are usually quite
large, several times larger than the display
screen
 To see how this works look at a side
scrolling game, one where the player
moves left or right through the game level
 The background image is one long strip,
as the player moves the part of the image
displayed changes
Background
 Draw
one image that is the height of the
screen, and as long as the level
 Only display part of this image at a time,
as the player moves right, the displayed
part of the image moves right as well
 The background image only scrolls when
the player gets close to one of the edges
Background
Background
 The
same thing can be done with a maze
or racing game
 In this case the background image is
closer to a square
 A display sized portion of the image is
displayed as the player moves around the
game area
Background
 Simple
games have a single background
image, but multiple images are possible
 Why use multiple layers of background?


 If
Can be used to produce a 3D like effect
Can be used to add details to the background
we have multiple layers can place
objects in different layers based on their
distance
Background
 The
furthest layer will scroll slowly, while
the closest layer will scroll quickly
 This gives a bit of a depth effect, since
objects close to us move more when we
move
 Multiple layers can also be used for
details, easier to reuse the detail images
Background
 Produce
one large background image and
several detail images, the detail images
can be smaller
 For example, the background could have
mountains and lakes, while the detail
images could have roads and houses
 Can use the same detail image at several
places on the background
Details
 How
does this work on different devices?
 MIDP 1 doesn’t have transparent images,
so one layer backgrounds are the best
 The background images can be any size,
as long as the phone can handle it, but
must be in the PNG format
 The lack of transparency is a major hassle
for MIDP 1 game development
Details
 MIDP
2 has transparent images, so it is
easier to do multi layer backgrounds
 Note that MIDP 2 is only available on new
phones
 Some phone manufacturers have game
APIs that remove some of the MIDP 1
restrictions, but this limits your game to
one type of phone
Details
 Gameboy
supports up to 4 layers of
background in hardware
 But, it places limits on the size of images,
depending on format can be 512x512 or
1024x1024
 Usually need to tile the background,
produce multiple background images and
switch between them
Sprites
 Sprites
are smaller images, maybe 16x16
or 32x32 that can move around the screen
 Sprites are used for:





Player character
Enemies
Other characters
Games items
Level details
Sprites
 After
the background is drawn the sprites
are drawn on top of it
 The simplest sprite is just an image that
has a fixed position within the level
 Whenever the sprite is visible it is drawn
on the screen
 Used for game items, such as coins, could
also be used for bricks that make up a
level
Character Sprites
 Character
sprites are more complicated,
since characters can move
 Need to have multiple images:


Character could face different directions or
have different poses
Animation of the character as it moves
 The
sprite needs to know which of these
images to display, and how to cycle
through them
Character Sprites
 Consider
a walking character, need to
have at least 3 images:



 If
Right foot in front of left foot
Both feet together
Left foot in front of right foot
the character can walk in two directions,
need two sets of these images, one for
each direction
Character Sprites
Character Sprites
 To
produce walking animation we cycle
through the images, both forwards and
back
 More images produce better animation,
but take more space and time
 Need to be careful when drawing images
so character doesn’t change size or colour
from one image to the next
Character Sprites
 How
do we organize these images?
 Could use a set of separate images, but
this causes a number of problems
 Need to keep track of all of the images,
and remember to load all of them
 Some formats, such as PNG, have a lot of
overhead for small images, so this will
waste a lot of space
Character Sprites
 Filmstrip
format: use one large image to
store all of the images
 Place them one after another in a
horizontal row, view individual images as
the frames in a movie
 Animations are now represented as the
set of frames to be displayed in a cycle
Character Sprites
 The
data we prepare for each sprite
includes:


The filmstrip image
For each pose and animation, the frame
numbers to be displayed
 This
keeps the art work separate from the
program code, easier to manage and
organize
Sprites
 Some
sprites have behaviour, they do
things in the game
 The simplest behaviour is moving, in most
cases the sprite moves in a straight line
until something interrupts it
 Another simple behaviour is collision,
occurs when two sprites run into each
other
Sprites
 There
are usually only a few types of
sprites in the game:



Static or game objects
Player sprite
Enemy sprite
 The
static sprites are the simplest, they
don’t move and only have a few simple
behaviours
Sprites
 Static
sprites typically have a collision
behaviour, so players and enemies know
when they have run into them
 In response to a collision the sprite may
give the player something, a gold coin,
and they may disappear from the screen
 The player sprite is a bit more
complicated, since it can move
Sprites
 The
motion of the player sprite is
controlled by the player, so we don’t need
to worry about this
 We still need animations and poses for the
character
 We will also need to keep track of its
inventory, health and a few other things
Sprites
 The
enemy sprites are more complex
since they should have reasonable motion
 This will need to be programmed, but in
most cases it will be quite simple
 For simple games there are only a few
types of enemy sprites, the main
differences are in the images used for
them
Details
 How
are sprites implemented on various
platforms
 In the case of MIDP 1 there is no support
for sprites, so we must program it all
ourselves
 MIDP 1 doesn’t have transparent images,
this makes sprites more difficult
 Copy the sprite images to the screen, a
rectangular block of pixels
Details
 If
the character is a rectangle we are okay,
but otherwise the background won’t show
through
 There are some tricks that can be played:


Divide sprite into smaller rectangular images
Draw the sprite one pixel at a time, this is very
slow
 Need
to be careful with sprite design
Details
 MIDP
2 has transparency, so this isn’t a
problem, a much better platform for game
development
 MIDP 2 also has a Sprite class, which
handles some of the sprite details:



Draw sprite
Simple animation sequence
Maintain basic sprite data
Details
 Gameboy
has special hardware for
sprites, don’t need to do as much
programming
 Manages the sprite images and draws
them in the correct place and order
 Special memory for sprites that gives
higher performance, but restricts the
number of sprite images
Details
 For
both MIDP 2 and Gameboy need to
program the sprite behavior
 Need to move the sprite, and advance the
frames in the animation
 Need to program collision responses and
the reaction of the sprite to other objects in
the game
Putting it all Together
 We
now know the basic theory, how do we
put it together to make a game?
 There are two main components:


Program code
Art
 We
are mainly going to concentrate on the
art, but will also discuss the program code
Separation of Concerns
 Would
really like to keep the art and the
program code separate:




Usually done by different people, don’t want
them stepping on each other’s toes
Use different tools, have a different production
process
Easier to update the program code or art
Easier to add new levels, just download the
art from a server
Separation of Concerns
 The
Nokia game example doesn’t do a
good job of this:



 If
The images are separate files – good
The animations are stored in the program
code- bad
The tile positions are stored in the program
code – bad
we change the sprite or the background
we need to change the program
Art
 One
of the main components is the
images, but also need to store how they
are used
 Start by looking at background
 With a single background image this isn’t
much of a problem, we really only have
the image file, but need to know the image
file for each level
Background
 For
a tiled background the situation is
more complicated
 We still need to have the image that has
the tiles, but we need to know how they
are placed
 For each layer need to know the size of
the layer, width and height in tiles, also
need to know this size of the tiles
 For each tile position, the tile to be
displayed there
Background
 In
the case of MIDP 2, the image tiles are
numbered left to right, then top to bottom,
starting at one
 Tile number zero is transparent
 In the Nokia example, this information was
stored in an array in the program
 A better solution is to store this information
in an external text file
Nokia Image Tiles
Background
 For
each level there is a text file, for level
n the file name could be “leveln”
 File contains the following information:





Size of background, in tiles
Number of layers
Image for each layer
The size of the tiles
For each layer the tile displayed in each of its
cells
Background
 If
we use a text file, could use something
simple like notepad to construct it
 Cheap, but not the easiest to use
 A better approach would be to produce a
graphical editor for selecting the tiles for
each layer
 This editor would produce the text file
 Could be used to produce several games
Art
 The
next main art component is sprites
 This isn’t as easy as the background, need
to decide how much to include
 The minimum is the images for the sprite
and the animation sequences
 MIDP 2 organizes sprite images similar to
tile images, viewed as a set of subimages, all the same size
Nokia Sprite File
Sprites
 The
sub-images are numbered left to right
and top to bottom, in this case the first
sub-image is zero
 The animations are given as the sequence
of sub-images to be displayed
 These images will be displayed as a loop
 In the Nokia example the animations are
stored in the program code
Sprites
 One
solution is to use a text file for each
sprite
 An alternative is to have a single file that
contains the information for all of the
sprites
 The minimum information we need is the
name of the image file, the tile size, and
the animation sequence
Sprites
 The
animation sequence has a list of
image numbers, but how do we associate
this with motion in the program?
 One way is to give a name to each
animation sequence, stored as name
followed by image sequence
 Then the program can just gives the name
of the animation it wants
Sprites
 We
usually want to do something with
sprites
 We could leave this up to the program, but
there are a number of things we could do
at the art level
 Example: coins placed in the level, each
coin has a simple animation and when
player collides with it, they get a point
Sprites
 All
the coins have the same animation and
behavior, the only thing that changes is
their position
 Its easier for the artist to place the coins in
the level, since they are designing the rest
of the level
 The programmer can create a coin class
that does the behavior, the artist does the
rest
Sprites
 How
does this change our text file?
 We still need to have the images and the
animation sequences
 We add to this the type of the sprite and
any sprite specific information
 In the case of coins, the only extra
information we need is the position of the
coin within the level
Sprites
 We
can do the same sort of thing with
enemies
 There are only a few types of enemies in
each game, programmer can produce a
class for each of them
 The sprite file entry contains the type of
enemy, its name, its initial position within
the level, its strength, and number of
points for killing it
Art
 The
last thing we need to worry about is
the player character
 The player is a sprite, but it’s special since
it moves from level to level
 The player may have a choice of several
characters when they start the game, so
we may need to design several of them
Player Character
 Each
player character can be stored in a
separate file, player selects the one they
want at the beginning
 Each file contains:




The name of the image file for the sprite
The animations for the sprite
The name of the character
The character’s properties: strength, speed,
etc
The Art Package
 So





what do we end up with?
Tile image file for each background layer
Sprite image file for each sprite
Background text file for each level
Sprite text file for each level
Character text file for each player character
 Note
that background layers and sprites
can share image files
The Art Package
tile1
level1
spriteImage1 sprites1
player1
tile2
level2
spriteImage2 sprites2
player2
tile3
level3
spriteImage3 sprites3
player3
tile4
level4
spriteImage4 sprites4
tile5
spriteImage5
tile6
spriteImage6
tile7
spriteImage7
The Art Package
 These
are the files we would need for a
four level game with three player
characters
 We will still need some way of organizing
these files during production
 Will probably only deliver one or two levels
at a time over the phone, download levels
as they are needed
Program Code
 Take
a quick look at the program code
 The program code divides into two parts:


Generic code used by most games – game
engine
Specific code for the game being developed
 Game
engine used for multiple games,
may be purchased or developed locally,
reduces development time
Game Engine
 The




game engine is responsible for:
Loading game data
Network communications
Background and level management
Basic sprite behavior
 Game
engine doesn’t handle game
details, otherwise everyone’s game would
be the same!
Specifics
 What



does the game programmer do?
Programs the sprites used in the game, the
game specific sprite behavior
Programs the game rules
Handles the specifics of where the game data
is located and networking
 The
programmer makes the game
different, provides those extra little details
that make the difference
Specifics
 It’s
a good idea to separate the game
engine code from the game specific code
 This simplifies program development, less
for the programmer to deal with
 Have a separate file for the game sprites,
programmer responsible for this
 Small number of places in the game
engine that can be customized
Program Code
 So







what does the program need to do?
Intro screen
Help screen
Preferences?
Load game data
Manage background
Manage sprites
Game loop
Utility
 Standard
support stuff needed by all
games
 Intro screen: name of the game, credits,
etc displayed while loading game data
 Character selection screen if there are
multiple characters
 New game / saved game screen if we let
the player save games
Utility
 Will
probably need a help screen, explain
how to play the game and the basic rules
 Help screen should be short, point to web
page where there are more details
 Might also have a preferences screen, not
used by many mobile games, but might be
necessary for more complex ones
Load Game Data
 The
game will load the data it needs,
hopefully from local files
 May also need to read saved game data,
while tell us which level to start at
 May need to load a new level from the
network, or check that the player has paid
monthly subscription fee
Manage Background
 The
game displays the background for the
current level
 May need to scroll the background as the
player moves
 Try to keep the player close to the center
of the screen
 If you wait until the reach the edge the
player will have too many surprises
Manage Sprites
 For
each sprite need to advance its
animation on each move
 In the case of enemies also need to move
the sprite and possibly respond to the
player
 In the case of treasure, the sprite will give
the player points and remove itself from
the game
Game Loop
 This
is where most of the action occurs,
respond to the player’s actions
 Start by reading the keys, determine what
the player wants to do
 Move the player sprite and see what
happens, see if the player collides with the
background or another sprite
Game Loop
 If
the player collides with the background,
he can’t move to this location, and we
move him back
 If the player collides with a treasure sprite
we collect the treasure
 If the player collides with an enemy sprite
we start a fight
 Finally advance the player animation
Mark’s Game Engine
I
have produced a simple mobile game
engine for use in this course
 This will give us the opportunity to see
how a mobile game engine works, and
produce some simple games
 The game engine is based on separating
art from programming, so some games
can be produced with no programming
Mark’s Game Engine
 The
game engine is based on the
following style:



The levels are maze like, think Mario and
similar games
The player moves through the level trying to
find the exit point
Along the way the player collects treasure and
encounters monsters
Mark’s Game Engine
 The
game engine and the art work is a
NetBeans project
 Use NetBeans to package the game,
produce the .jad and .jar files
 NetBeams also provides an emulator for
testing the game
 Can also extend the Java code if you like
Examples
 Now
lets look at how this all works
 We will start by taking the Nokia example
game and putting its art in files instead of
in the program code
 Since this game really doesn’t do anything
this is relatively easy
 We will start by producing the file for the
player character
Player
 We
already have the image file that
contains the individual images for the
character
 We need to construct a text file that
describes the character and its animations
 We will use notepad to construct this file,
since it isn’t very long
Player File
Space Bob
/images/example_sprite.png
24 32
4
left 3 9 10 11
right 3 3 4 5
up 3 0 1 2
down 3 6 7 8
Player File
 The
first line of this file contains the name
of the character
 The next line contains the name of the file
that has the character images
 The third line is the size of each of the
sub-images (in pixels)
 The fourth line is the initial pose, or subimage used to display the character
Player File
 There
remainder of the file is the
character’s animations
 The first item for each animation is the
name of the animation
 This is followed by the number of frames
in the animation
 The rest of the line has the image
numbers for frames in the animation
Player File
 All
player characters are assumed to have
four standard animations:




Left
Right
Up
Down
 These
animations are used when the
player moves, other animations are used
for special effects
Background
 The
background file for the level is similar
to the character file
 It is created using notepad and contains
the information for the two layers of the
background
 This is a larger file, since it also contains
the contents of each cell for both layers
Background
10 10
0 0
216 315
/images/example_tile_palette.png
24 35
0
118 118 117 31 31 31 85 46 46
31 31 103 31 31 134 28 46 46
31 31 103 31 31 31 31 28 46
31 31 103 31 31 31 31 134 28
31 31 103 31 31 31 31 31 134
31 31 103 31 31 31 31 31 31
96 96 101 96 96 96 96 96 96
31 31 103 31 31 133 31 134 31
31 31 104 118 118 118 118 115 130
31 31 31 31 31 31 31 133 31
46
46
46
30
31
31
96
31
31
31
Background
/images/example_tile_palette.png
24 35
1
0
0
0 127
0
0
0
0
0 127
0
0
0
0
0
0
0
0
0 131
0
0 127
0
0 131
0
0 131
0 127
0
0
0
0 127
0 127
0
0
0
0
0 132 127 132
0
0
0
0
0
0
0
0
0
0
124 124
0 112
0
0
0
0
124 124
0
0
0
0
0
0
0 124 112
0
0 124
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Background
 The
first line of the file contains the size of
the background in tiles
 In this case we have a 10 x 10 tile level
 The next line is the start position for the
level, this is the (x, y) position, in pixels
where the player character starts
 The third line contains the end point of the
level, the pixel coordinates of the place the
player is trying to get to
Background
 This
header information is followed by
information for each background layer
 There can be any number of background
layers
 The first set of background lines is for the
bottom layer of the background
 It starts with the name of the image file
followed by the size of the individual tile
images, in this case 24 x 35 pixels
Background
 The
next line contains a collision flag, if
the value of this flag is 0 no collision
detection is done on the layer
 The next 10 lines are the contents of the
layers cells
 Note that there are 10 lines of 10 cells
 the second layer is basically the same,
except its collision flag is 1, so collision
detection will be done on this layer
Packaging
 We
need to put these files together with
the game engine to produce a game
 This is done in NetBeans
 Create a new NetBeans project, make
sure to select CLDC 1 and MIDP 2, using
the game engine source code
 Add your files to the data folder and then
run the project
Packaging
Packaging
Example
Other Media
 So
far life has been easy
 Most modern phones support MIDP 2
graphics, so what we have done so far
should work on most phones
 For other types of media and services the
situation is quite different
 There are no standards and things tend to
vary from one phone to the next
Sound
 Sound
is one area where things can vary a
lot, the possibilities include:




Simple tones
Tone sequences
MIDI
Sampled sounds (WAV or MP3 files)
 Can’t
predict what a particular phone will
be able to handle, need to check at runtime
Sound
 There
are two main solutions to this
problem:


Use the most primitive format, likely available
on all phones
Use the best possible format, produce the
best possible sound on a given phone
 The
first alternative is the easiest choice,
only need to produce one version of the
sound content
Sound
 Unfortunately
we don’t take advantage of
the features of better phones
 Game will not sound better on better
phones
 If we take the second alternative will need
to produce several versions of the sound
content, one for each possible format
 Better sound, but much more work
Simple Tones
 This
should be supported by all phones
 Plays a single note at a time, procedure
must be called for each note
 Somewhat similar to MIDI, give a note
number, length (in milliseconds) and
volume (percentage of full volume)
 Have no control over the sound that is
played, each phone could be different
Simple Tone
 Hard
to play a song, would need to
program each note
 Better for sound effects, play a tone when
something occurs in the game



Collision
Hit by enemy
Hit the enemy
 Could
be specified with player art work
Tone Sequence
 Ability
to play a sequence of tones
 Only one tone at a time, and no control
over the instrument that plays the tone
 For each note can give the pitch and
length, volume events used to set the
volume of following tones
 Can be viewed as a simplified version of
MIDI
Tone Sequence
 Represented
by an array of bytes, a
numerical representation of the tone
sequence
 Array can be stored in program, or it can
be stored in a file
 Don’t know of any programs that can be
used to construct this file format
 Not that easy to work with
Tone Sequence
 Could
be used for background music
 Could be able to play a tone while a tone
sequence is playing, depends on phone
 Could also be used to signal events in a
game
 Tone sequence files could be part of the
art work, attached to levels or possibly the
player character
MIDI
 This
is probably supported by more
expensive phones that already use MIDI
for ring tones
 This gives us more control over the
sounds, can control the instrument
 Can also have multiple notes playing at
the same time
 Possible to mix several MIDI pieces
MIDI
 There
are two ways that MIDI can be
used:


Use a standard MIDI file, of most interest to
us
Send individual MIDI events under program
control
 For
file playback can control the pitch,
volume and rate of playback on some
phones
MIDI
 In
the case of pitch and rate control, can’t
control the absolute pitch or rate
 Instead specify a percentage increase or
decrease
 This can be used to increase the pitch and
tempo as the player moves through the
level, increase the level of excitement
MIDI
 Can
be used for background music and to
signal events
 Can use standard MIDI editors to create
content and then include them in the game
JAR file
 Easier to author than tone sequences, and
produce a much better sound
 Can be attached to any game graphics
Sampled Sounds
 Produces
the best quality sound, but only
supported on more recent high end
phones
 Can be wav or MP3 files
 Could be possible to mix several files to
play at the same time
 Main problem is the size of the files, this
can be very expensive to download
Sampled Sounds
 Can
control the pitch and rate of playback
in the same way as MIDI sounds
 Can also control the volume during
playback
 Can only be stored in a separate file, really
can’t generate in the game engine itself,
not enough processing power
Sample Sounds
 Probably
don’t want to use as background
music, too large
 Can be used to signal events, much
shorter file
 Can use standard sound editing program
to create sound files
 Can attach to player character or possibly
sprites
Game Engine
 How
does the game engine handle
sounds?
 It first needs to determine which sound
formats are supported by the phone
 If the art work has multiple sound formats
it will choose the best sound format that
the phone will support
 Lots of extra program code!
Packaging
 This
is an important consideration
 If our game supports multiple sound
formats do we put all the sound content in
the same JAR file?
 Everything in one file is the easiest to
produce, game engine can determine
format when it runs on the phone
 Will always make the correct sound format
choice
Packaging
 But


this requires extra space:
Costs more to download the game
Needs more room on phone, may prevent
download on some phones
 Since
each phone will only use part of the
content makes sense to only include what
it needs
 Better use of bandwidth and memory
Packaging
 But
how do we know what to include?
 Two possible approaches
 Download the sound content after
determining the formats supported by the
phone
 Small initial download, opportunity for
additional revenue from network usage
Packaging
 Determine
the sound formats supported by
each type of phone
 When JAR file is requested, provide the
one that matches the phone
 Good results with minimal use of
bandwidth
 But, most test each possible phone
 Need a fallback for new or unknown
phones
Sound Capture
 Since
phones have microphones it should
be possible to capture sound
 This is supported on some phones, but
doesn’t appear to be common
 Could be used to capture custom sounds
for a game
 Send captured sound to other players in a
networked game
Video
 Video
playback is supported on some
phones, mainly 3G
 Could be used in games, same way as PC
and platform games
 Main problem is file size, not enough
storage on most phones and cost of
download
 Could use external memory card
Video
 Another
possibility would be to stream the
video to the phone
 3G networks are good at this, so it could
be economically feasible
 Could add extra interest to the game,
videos could change on a daily basis,
feature top players
 Could be location based, videos change
as you move through the city
Video
 Video
and still capture might be more
interesting
 Capture still image of player and put it in
the game
 Capture video clip to send to other players
 Still capture seems to be the most
practical, since it involves less memory
and processing
Video
 Video
could also be used as part of the
interaction
 Use simple image processing to detect
movement or objects in the scene
 Could be used as another form of game
controller, or a way of interacting with the
game
Video and Sound
I
haven’t seen video and sound capture
used in a mobile game
 There might be some interesting things
that could be done with this, a new game
genre
 Could have a video scavenger hunt, take
pictures of target objects, first one to have
a complete set wins
Video and Sound
 Could
have a tag or shooting game
 Take picture of all the members of the
other team before they take pictures of
you
 A lot of possibilities, try to take advantage
of groups of people and short play time
 Could also be used for dating and match
making games
CLDC 1.1
 Most
phones are CLDC 1, defines the
version of Java used on the phone
 CLDC only has integer arithmetic, aimed
at current generation of phones with
limited processors
 CLDC 1.1 supports floating point
arithmetic, aimed at next generation of
phones with better processors
CLDC 1.1
 Some
of the things that we would like to
do are only supported in CLDC 1.1


3D graphics
Location based games
 This
will become more popular in the
future, so worth taking a look at now
3D Graphics
 This
could make mobile games more
interesting, but really isn’t possible on
today’s phones
 Working on mobile graphics chips, some
are available now that support 3D graphics
 Will start appearing in phones over the
next few years
 Will be common within 5 years, maybe
sooner
OpenGL ES
 A version
of OpenGL for mobile devices,
both phones and PDAs
 A subset of OpenGL that is easier to
implement on small devices
 Since many 3D games use OpenGL, this
could open the door to 3D games on
mobile phones
 There is an integer only subset, could be
put on current phones
OpenGL ES
 There
are versions of OpenGL ES for
PDAs, I’ve used one of them
 I haven’t seen it on a production mobile
phone yet, but I’ve seen demos
 Has the advantage of being well known,
large number of programmers know
OpenGL
 Could even port some existing games
3D Graphics
 Two
versions of 3D graphics for Java on
mobile phones
 Version of OpenGL ES for Java, provides
interface to OpenGL ES for Java programs
 Not clear how widely this will be
implemented, since it clashes with other
Java standards
 Could be done on CLDC 1
3D Graphics
 In
the past there has been some conflict
between the Java community and the
OpenGL community
 A pure OpenGL ES implementation in
Java may not be popular
 There are also some performance issues
as well, since Java on phones isn’t fast
Mobile 3D Graphics
 One
of the main problems with Java is
lack of speed
 In C or C++ can use a large number of
calls to graphics package, not a
performance problem
 A call for each vertex of each object is
okay
 Can easily modify geometry from one
frame to the next
Mobile 3D Graphics
 This
is what gives good smooth animation
in most 3D games
 Can tweak the motion frame by frame to
give the best result
 This is hard to do in Java because of its
performance, calls to the graphics
package are much slower
 This would greatly restrict the size of the
models that can be used
Mobile 3D Graphics
 The
proposed solution is to do most of the
graphics underneath Java, can then use
more efficient languages
 Pass the graphical information to this
lower level to manage and display
 The Java program just handles the higher
level details
 This give adequate performance at a price
Mobile 3D Graphics
 The
Java 3D API uses a scene graph, a
high level representation of the graphical
information
 This is a standard graphics technique
 The Java program constructs the scene
graph and then passes it to the lower level
for display
 Tries not to change the scene graph after
it is constructed
Mobile 3D Graphics
 This
results in good performance, scene
graph display handled efficiently at lower
level
 But, if we change the scene graph we are
back to our original problem
 So, if nothing moves we are okay
 This might be okay for some applications,
like eCommerce, but doesn’t work for
games
Mobile 3D Graphics
 One
solution to this problem is to only
change the transformations in the scene
graph
 This is a small amount of data that only
effects a small part of the scene graph
 This gives the ability to do rigid motion
efficiently, but still doesn’t have the best
quality
Mobile 3D Graphics
 There
is also the ability to do skinned
meshes
 This can give better looking animations,
but the Java program needs to do more
work for this
 There is also a special file format for the
mobile 3D graphics package
 I don’t know of any modeling programs
that produces this format
Mobile 3D Graphics
I
don’t know whether this approach will be
successful
 3D graphics on PCs and consoles is quite
good and improving
 3D graphics for phones will not be near as
good, and may not be acceptable to
consumers
 The quality difference might be too large
Mobile 3D Graphics
 In
addition, there are no modeling tools
that support the file format
 Hard to get good content if we must rely
on programmers to produce all the models
and animations
 Might be better to stick to 2D graphics and
do a good job of it, produce better quality
games
Location Based Services
 Mobile
phones know where they are, or at
least the phone company knows where
they are
 Talk of location based services for many
years, but I don’t know of any
 GPS receivers are available for PDAs and
map based services have been developed
for them, becoming a popular addition
Location Based Services
 A J2ME API
for determining location has
been proposed
 Based on CLDC 1.1, so won’t work on
most existing phones
 This API gives the longitude and latitude of
the phone, in some cases it can also give
the altitude
 Need to convert this into something useful
Location Based Services
 Need
to know the latitude and longitude of
interesting places
 One way of doing this is to store the
location information of important
landmarks on the phone
 This could be downloaded from the
service provider
 Could also get this from web sites that
provide a location service
Location Based Services
 Given
the phone’s location, need to search
through the list of known locations to find
where we really are
 The phone’s location can be updated
every few minutes, so this must be
efficient
 Now we need to think about how this
information could be used
Location Based Services
 Suggested
uses include advertising,
locating children, maps
 How could this be used in games?
 Game content or play needs to depend
upon location
 Content is hard to produce, so its unlikely
that content will depend upon location,
need to concentrate on game play
Location Based Services
 Other
player’s locations is important in the
game:





 If
Hide and seek
Tag
Spy games
Assassination, or crime games
Scavenger and treasure hunts
we get close enough to a particular
location we receive some points or awards
Location Based Games
I
have not seen this used in mobile phone
games, but I have seen a tag game for
PDAs
 This could produce a new game genre
 Look for something that can be played
quickly and involves a considerable
amount of action
 Could be good exercise
Summary
 Easy
to develop mobile games with just
2D graphics, will work on most newer
phones
 After that life gets more complicated,
features vary from phone to phone
 Hard to produce a game that will run well
on all phones
 Need to develop different versions, control
how content is delivered
Future
 Things
could get better in the future, more
standardization, easier to produce games
for a wide range of phones
 Some interest in doing this:


Easier for game developers, will produce
more content for phones
Selling point for phones, a new phone will
already have content
Future
 If
games become a major money maker
there may be pressure to develop special
feature for each phone
 Similar to game consoles, want to have
better graphics and sound than the
competitors
 This could make development harder in
the future