Mobile Games - PowerPoint PPT Presentation

Loading...

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



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Mobile Games

Description:

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: http://sweb.cityu.edu.hk
Category:
Tags: games | mobile

less

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

Title: Mobile Games


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

2
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

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

4
Basic Approach
  • Start by looking at the basic design approach or
    theory
  • 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

5
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

6
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

7
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

8
Background
9
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

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

11
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

12
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

13
Details
  • 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
    format
  • The lack of transparency is a major hassle for
    MIDP 1 game development

14
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

15
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

16
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

17
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

18
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

19
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

20
Character Sprites
21
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

22
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

23
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

24
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

25
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

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

27
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

28
Sprites
  • 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
    character
  • We will also need to keep track of its inventory,
    health and a few other things

29
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

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

31
Details
  • 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
    slow
  • Need to be careful with sprite design

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

33
Details
  • 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
    images

34
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

35
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

36
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
    process
  • Easier to update the program code or art
  • Easier to add new levels, just download the art
    from a server

37
Separation of Concerns
  • The Nokia game example doesnt do a good job of
    this
  • 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
  • If we change the sprite or the background we need
    to change the program

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

39
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

40
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

41
Nokia Image Tiles
42
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

43
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

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

45
Nokia Sprite File
46
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

47
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

48
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

49
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

50
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

51
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

52
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

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

54
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 characters properties strength, speed, etc

55
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

56
The Art Package
57
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

58
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

59
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!

60
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

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

62
Program Code
  • So what does the program need to do?
  • Intro screen
  • Help screen
  • Preferences?
  • Load game data
  • Manage background
  • Manage sprites
  • Game loop

63
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

64
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

65
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

66
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

67
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

68
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

69
Game Loop
  • If the player collides with the background, he
    cant 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

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

71
Marks 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

72
Marks 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

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

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

75
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
76
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

77
Player File
  • There remainder of the file is the characters
    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

78
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

79
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

80
Background
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
81
Background
/images/example_tile_palette.png
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
82
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

83
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

84
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

85
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

86
Packaging
87
Packaging
88
Example
89
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

90
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)
  • Cant predict what a particular phone will be
    able to handle, need to check at run-time

91
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

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

93
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

94
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

95
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

96
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

97
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

98
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

99
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

100
MIDI
  • In the case of pitch and rate control, cant
    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

101
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

102
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

103
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

104
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

105
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!

106
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

107
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

108
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

109
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

110
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
    game
  • Send captured sound to other players in a
    networked game

111
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

112
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

113
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

114
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

115
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

116
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

117
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

118
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

119
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
    years
  • Will be common within 5 years, maybe sooner

120
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

121
OpenGL ES
  • 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

122
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

123
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

124
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

125
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

126
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

127
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

128
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

129
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
    quality

130
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

131
Mobile 3D Graphics
  • I dont 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

132
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

133
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

134
Location Based Services
  • A J2ME API for determining location has been
    proposed
  • Based on CLDC 1.1, so wont 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

135
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

136
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

137
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

138
Location Based Services
  • Other players locations is important in the
    game
  • 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

139
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

140
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

141
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

142
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
About PowerShow.com