Mobile Games - PowerPoint PPT Presentation


PPT – Mobile Games PowerPoint presentation | free to download - id: 254a7-NzEwM


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Mobile Games


Mobile Games. Mark Green. School of Creative Media. City University of Hong Kong. Introduction ... I have produced a simple mobile game engine for use in this course ... – PowerPoint PPT presentation

Number of Views:131
Avg rating:3.0/5.0
Slides: 143
Provided by: creativ6
Learn more at:
Tags: games | mobile


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Mobile Games

Mobile Games
  • Mark Green
  • School of Creative Media
  • City University of Hong Kong

  • 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

  • Since devices are limited, mainly work with
    pre-computed or pre-drawn images
  • Devices dont 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
  • Cant compute images, so start with pre-computed
    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
  • These images are usually hand drawn, but could be
    computed from 3D models

  • 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

  • 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

  • The same thing can be done with a maze or racing
  • In this case the background image is closer to a
  • A display sized portion of the image is displayed
    as the player moves around the game area

  • Simple games have a single background image, but
    multiple images are possible
  • Why use multiple layers of background?
  • Can be used to produce a 3D like effect
  • Can be used to add details to the background
  • If we have multiple layers can place objects in
    different layers based on their distance

  • 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

  • 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

  • How does this work on different devices?
  • MIDP 1 doesnt 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
  • The lack of transparency is a major hassle for
    MIDP 1 game development

  • 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

  • Gameboy supports up to 4 layers of background in
  • 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 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

  • 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
  • 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
  • Right foot in front of left foot
  • Both feet together
  • Left foot in front of right foot
  • If 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 doesnt 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

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

  • 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

  • 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 dont
    move and only have a few simple behaviours

  • 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

  • The motion of the player sprite is controlled by
    the player, so we dont need to worry about this
  • We still need animations and poses for the
  • We will also need to keep track of its inventory,
    health and a few other things

  • 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

  • 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 doesnt have transparent images, this
    makes sprites more difficult
  • Copy the sprite images to the screen, a
    rectangular block of pixels

  • If the character is a rectangle we are okay, but
    otherwise the background wont 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
  • Need to be careful with sprite design

  • MIDP 2 has transparency, so this isnt 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

  • Gameboy has special hardware for sprites, dont
    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

  • 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

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, dont want them
    stepping on each others toes
  • Use different tools, have a different production
  • 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 doesnt do a good job of
  • The images are separate files good
  • The animations are stored in the program code-
  • The tile positions are stored in the program code
  • If we change the sprite or the background we need
    to change the program

  • 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 isnt much of
    a problem, we really only have the image file,
    but need to know the image file for each level

  • For a tiled background the situation is more
  • 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

  • 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
  • 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

  • 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

  • The next main art component is sprites
  • This isnt 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 sub-images, all the
    same size

Nokia Sprite File
  • The sub-images are numbered left to right and top
    to bottom, in this case the first sub-image is
  • 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

  • One solution is to use a text file for each
  • 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

  • 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
  • Then the program can just gives the name of the
    animation it wants

  • 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
  • Example coins placed in the level, each coin has
    a simple animation and when player collides with
    it, they get a point

  • All the coins have the same animation and
    behavior, the only thing that changes is their
  • 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

  • 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

  • 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
  • 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

  • The last thing we need to worry about is the
    player character
  • The player is a sprite, but its 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
  • Each file contains
  • The name of the image file for the sprite
  • The animations for the sprite
  • The name of the character
  • The characters 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
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

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 doesnt handle game details,
    otherwise everyones game would be the same!

  • 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

  • Its 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

  • 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
  • New game / saved game screen if we let the player
    save games

  • 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
  • May need to scroll the background as the player
  • Try to keep the player close to the center of the
  • 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 players 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
    cant move to this location, and we move him
  • 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

Marks 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
  • The game engine is based on separating art from
    programming, so some games can be produced with
    no programming

Marks Game Engine
  • The game engine is based on the following style
  • The levels are maze like, think Mario and similar
  • The player moves through the level trying to find
    the exit point
  • Along the way the player collects treasure and
    encounters monsters

Marks Game Engine
  • The game engine and the art work is a NetBeans
  • 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

  • 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 doesnt do anything this
    is relatively easy
  • We will start by producing the file for the
    player character

  • 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 isnt very long

Player File
Space Bob /images/example_sprite.png 24 32 4 l
eft 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 sub-image
    used to display the character

Player File
  • There remainder of the file is the characters
  • The first item for each animation is the name of
    the animation
  • This is followed by the number of frames in the
  • 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

  • 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

10 10 0 0 216 315 /images/example_tile_palette.
png 24 35 0 118 118 117 31 31 31 85 46 46
46 31 31 103 31 31 134 28 46 46 46 31
31 103 31 31 31 31 28 46 46
31 31 103 31 31 31 31 134 28 30
31 31 103 31 31 31 31 31 134 31
31 31 103 31 31 31 31 31 31 31
96 96 101 96 96 96 96 96 96 96
31 31 103 31 31 133 31 134 31 31
31 31 104 118 118 118 118 115 130 31
31 31 31 31 31 31 31 133 31 31
24 35 1 0 0 0 127 0 0 0 0 0 0
0 127 0 0 0 0 0 0 0 0 0 0
0 131 0 0 127 0 0 0
0 131 0 0 131 0 127 0 0 0
0 0 0 127 0 127 0 0 0 0
0 0 0 132 127 132 0 0 0 0
0 0 0 0 0 0 0 0 0 0
124 124 0 112 0 0 0 0 0 0
124 124 0 0 0 0 0 0 0 0
0 124 112 0 0 124 0 0 0 0
  • 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

  • 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

  • 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
  • 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

  • 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

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
  • 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 is one area where things can vary a lot,
    the possibilities include
  • Simple tones
  • Tone sequences
  • MIDI
  • Sampled sounds (WAV or MP3 files)
  • Cant predict what a particular phone will be
    able to handle, need to check at run-time

  • 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

  • Unfortunately we dont 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
  • 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
  • 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
  • Dont 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

  • 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
  • Possible to mix several MIDI pieces

  • 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
  • For file playback can control the pitch, volume
    and rate of playback on some phones

  • In the case of pitch and rate control, cant
    control the absolute pitch or rate
  • Instead specify a percentage increase or
  • This can be used to increase the pitch and tempo
    as the player moves through the level, increase
    the level of excitement

  • Can be used for background music and to signal
  • 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
    cant generate in the game engine itself, not
    enough processing power

Sample Sounds
  • Probably dont 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!

  • 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

  • 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
  • Better use of bandwidth and memory

  • 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

  • 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 doesnt
    appear to be common
  • Could be used to capture custom sounds for a
  • Send captured sound to other players in a
    networked game

  • 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

  • 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
  • Could be location based, videos change as you
    move through the city

  • Video and still capture might be more
  • Capture still image of player and put it in the
  • Capture video clip to send to other players
  • Still capture seems to be the most practical,
    since it involves less memory and processing

  • Video could also be used as part of the
  • 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 havent 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

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
  • CLDC 1.1 supports floating point arithmetic,
    aimed at next generation of phones with better

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 isnt possible on todays phones
  • Working on mobile graphics chips, some are
    available now that support 3D graphics
  • Will start appearing in phones over the next few
  • Will be common within 5 years, maybe sooner

  • 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

  • There are versions of OpenGL ES for PDAs, Ive
    used one of them
  • I havent seen it on a production mobile phone
    yet, but Ive 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
  • 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 isnt fast

Mobile 3D Graphics
  • One of the main problems with Java is lack of
  • 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

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
  • 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

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 doesnt 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 doesnt have the best

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 dont know of any modeling programs that
    produces this format

Mobile 3D Graphics
  • I dont know whether this approach will be
  • 3D graphics on PCs and consoles is quite good and
  • 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
  • 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 dont 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
  • Based on CLDC 1.1, so wont work on most existing
  • This API gives the longitude and latitude of the
    phone, in some cases it can also give the
  • 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
  • Could also get this from web sites that provide a
    location service

Location Based Services
  • Given the phones location, need to search
    through the list of known locations to find where
    we really are
  • The phones 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
  • Content is hard to produce, so its unlikely that
    content will depend upon location, need to
    concentrate on game play

Location Based Services
  • Other players locations is important in the
  • Hide and seek
  • Tag
  • Spy games
  • Assassination, or crime games
  • Scavenger and treasure hunts
  • If 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

  • 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
  • Need to develop different versions, control how
    content is delivered

  • 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

  • If games become a major money maker there may be
    pressure to develop special feature for each
  • Similar to game consoles, want to have better
    graphics and sound than the competitors
  • This could make development harder in the future