|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Designing Mobile Games For WAP Design Limits &
Opportunities
In the area
of game design, you typically get the basic feel by playing games on the
target platform (say, a game console or a WAP phone). As a professional
designer, you constantly enhance and revise this gut feel with input from
programmers (technical L&O), artists
(visual L&O), sound
fx people (audio L&O), and sales
people (business L&O). As
a result, you are able to make informed decisions about specific features
during the design process. When you know your L&O, you have a rough
idea of what kind of designs are and are not possible. For instance, a
puzzle game based on guessing the right color won't work in a medium with
monochrome screens (current WAP phones). Design Limits on
WAP You have
ideas, and you have ambitions. That's probably part of your motivation
to be a game designer in the first place. If necessary, you may be willing
to compromise, but at the same time you try to preserve the main ideas.
To get your WAP game ideas in tune with the real world, you need to consider
the following design limits. Situation:
Idle Moments This is the core of mobile gamer behavior: mobile gaming remedies moments of boredom when there's no access to better gaming devices. The result is a completely different pattern of playing — whereas traditional gaming consists of a few long sessions, mobile gaming is all about multiple short sessions. Charging Per minute for data calls is an additional incentive for the player to keep the game sessions short.
Technological
Limits From a game designer's point of view, this means that both the game content and the game logic must be stored on the server, and only static pre-generated chunks of game content are delivered to the mobile phones. To put it another way, think of a web page with only text, images and hyperlinks. No frame structures, roll-over mouse effects, fancy flash animations, interactive java applets; just text, images and hyperlinks.
Imagine writing a game for this system. Hypertext stories are the first to spring to mind. You get a bunch of images and text with links in it. Clicking on the links takes you forward in the story. If you play the game again and choose the same links as before, everything will be exactly the same. But wait, there's more. Since data is processed on the server, you can deliver different game situations based on the player's actions. For instance, you could attach a random effect to each link. Whenever the player selects a link, the game logic decides whether the following room contains a treasure or a monster before sending the new game situation to the player's phone. As you can see, this mechanism is inherently turn-based. You deliver the player a chunk of static content (text+image(s)+links), she ponders for a while and responds by clicking a link. The game on the server moves on depending on the link the player chose and the system delivers another chunk of static content.
In our tactical naval game Sub Hunter, the player gets an image of the game board. After looking at the board for a while, the player decides on new orders for her fleet and sends them to the server. The server responds by generating a new board image based on the game state after the orders have been carried out. Nothing will happen until the player sends her orders. You might also want to make the links dynamic. For instance, in an adventure game, the player receives the link, "blast lab doors open", only if she has already been to the weapons room. If she hasn't been to the weapons room yet, the blast option is simply not available. From a game mechanics point of view, the most restrictive feature is probably the "fetch a document" nature of WAP technology. Analogous to HTML technology, this forces all WAP games into a turn-based mode. There is no real-time strategy for this platform. In addition, current WAP implementations lack "push" capability. There's no way to inform the player that something's happened in the game world. Currently, you have to resort to short messages (SMS) if you want to alert the player. After getting the message, the player has to go through the trouble of launching the WAP connection and navigating to your game, possibly even logging into the service manually with an id and password. It would be much more convenient to simply push a WAP game screen to the player so that she would be able to respond immediately without any extra effort.
Other WAP technology limits include monochrome displays, small screens (for instance, Nokia 6210 features practical bitmap resolution of 88x39 pixels), slow & unreliable connection, and "device hell" (there are too many WAP phone models with different ways of rendering content to keep up with). On the whole, WAP resembles very clearly the early days of the WWW with multiple browsers and poor media content. The final technological point is that mobile phones are small devices with a cumbersome interface, so be sure to keep the game interface very simple! Instead of adding a multitude of different features, concentrate on making the core game play easier to access. ______________________________________________________ |
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Design
Limits & Opportunities
Resource
Guide 
Whether
you are designing sports cars, furniture, or WAP games, the basic process
is always the same. Besides having great ideas, you have to know what
the fundamental characteristics of your chosen design area are —
what limits and opportunities (let's call them "L&O") exist
in this branch of design. These are the things you need to know to make
a great product. Only after you have a feel for the L&O you are ready
to nurture your ideas into successful designs. 
