 |
 |
|
|
While mobile phones offer us a very compelling platform for educational game development, there are some unique characteristics for these devices that need to be addressed. Phones are designed to be used primarily for voice communication. All of the other functions that we find in the current generation of phones, such as games, camera, radio, and even GPS are all secondary to the phone’s primary purpose.
Limited Screen Resolution
Mobile phones have very small screen resolution in comparison to PCs and gaming consoles. Even phones that have relatively large screens pale in comparison to the high-definition resolution of contemporary consoles. Large phones such as the Sony-Ericsson W900 or Nokia N93 have a screen resolution of 240×320 (see Figure 1). A resolution of 176×220 is much more common.
Figure 1. Screen for Nokia N93
We should avoid games that require the player to get information from lots of places in a large image over a short amount of time. Consider a game that requires the player to make a decision based on the number of carbon dioxide and methane emissions in each continent. The white dots represent carbon dioxide and the black dots the methane emissions. One method that could be used to implement this feature would be to allow the player to have a small window into a large scrollable map, as shown in Figure 2.
Figure 2. Dots for emissions.
Another method that we might consider would be to shrink the entire map to fit into the screen as shown in Figure 3.
Figure 3. Large image on scaled on phone
As we can see, neither of these options would make for a fun and pleasurable experience. The scrollable map would not be a good mechanism if we wanted the player to make fast decisions. He would most likely get agitated at having to constantly scroll over the map to find the needed information. The large graphic shrunken to mobile phone resolution would also fail because the limited resolution of the phone would make it impossible for the player to get the necessary information. It is not possible to discern the color of the dots on the map at this resolution.
We could redesign our game to make it more playable and fun on a mobile phone. Our problem, in this case, is that we need to inform the player about the number of emissions in each of the continents so that he can decide on his next move. One option would be to change the orientation of the phone and use text. (see Figure 4).
Figure 4. Possible mobile phone solution.
Variable Input Controllers
Another issue that we need to consider is the input interface on the actual phones. Some phones such as the Sony-Ericsson W800 have a small joystick that we can use for input. Other phones do not have small joystick and instead have directional keypads. Regardless of the input device, the physical dimensions of these input devices and placement on the phone makes it difficult for players to perform extremely quick input responses. This would make it difficult to implement a game that required blinding fast user input for example a hand to hand combat fighter such as Mortal Kombat™.
Variable Processing Power
While a large percentage of phones support the Java Mobile Platform, there is very little uniformity in the processing capabilities of mobile phones. Even phones in the same model line will sometimes show drastically different performances. So the problem is not getting games to run on different phones. In fact, most phones will run Java Mobile Games with no modification to our code. The problem is that games will run differently on different models of phones.
From a game developer’s perspective, we need to handle this by making different builds of our game that target specific phones and by allotting more time to testing than is typical. Not only do we need to make sure that our games function properly, but also that they work on each of the specific phones that we would like to target.
The Player’s Surroundings
The majority of mobile gamers play while away from their homes, when they find themselves in scenarios where they are bored. People play mobile games while waiting for buses, sitting in their doctor's office, or maybe even in their cars.
As game designers we need to design games that, while fun and challenging, do not require the player’s exclusive attention and can be played in short sessions. We also need to make sure that our games do not rely heavily on sound because the player will be using his phone in public situations most of the time.
Phones are Networked
Today’s mobile phones are small networked devices with the ability to exchange data readily. This makes it possible for us to consider multiplayer games. However, we need to be careful before considering multiplayer capabilities in our game design because of the relatively high level of latency of cellular based network technology. Over the last few years the bandwidth of mobiles phones has increased, but the latency has remained fairly high. In other words, we can move our data faster than before but the amount of time that it takes to get the data ready to send is still relatively slow. On a busy cellular network latency can be as high as 1 second. From a game designer’s perspective this influences the types of gaming challenges that we can reasonably expect to work on mobile phones.
Designing our games to be a multiplayer game can have some positive repercussions for both the developers and the players. In designing a single player game, lots of attention is placed on making sure that our challenges are neither too easy nor too difficult for our player. In a multiplayer game, the challenge often comes from the opposing players. This lessens some of our responsibilities as game designers. It also makes the AI in the game easier to implement. Multiplayer games also tend to have a high degree of replayability because the game is always different.
Because mobile game players typically play for only shorts amount of time, it is almost guaranteed that some of the players in our multiplayer game will leave the game unexpectedly. When a player drops out, we can either have an AI entity take over or introduce a replacement human player. In both of these scenarios the game would continue.
We also need to consider the high degree of latency inherent in mobile phone networks. Our goal is to hide this latency from the player by presenting them with a fun and enjoyable experience. We can accomplish that by using one of the following designs in our multiplayer games:
Round robin: In this design, player 1 takes their turn, then player 2, then player 3, etc. After each player takes a turn the game updates. This works for a relatively low number of players and for games that are not designed to have a lot of action.
Act whenever: With this design, the game is persistent and is always on. Thus, the player is able to log in anytime and send his orders to the game for execution.
Shared solitaire games: Here each player is given an identical game experience. At the beginning of the game, the players are matched to start from the same place or difficulty level. The players play the game by themselves and when the game is over the server compares the scores of the players. The player with the highest score wins.
As we design our multiplayer game, we should strive to ensure that all players have the potential for a fun game experience. We should try to create a scenario in which like skilled players are encouraged to play against each other. It is not fun for beginners to enter a multiplayer and be obliterated by experienced players. One way that we can do this is by keeping track of experience points and rewarding the players with more points when they win against a more experienced player. This approach will help alleviate some of the problems in this area, but will not stop some experienced players from creating newbie profiles and starting the game again.