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