This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Design Limits &
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.
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
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.
The most fundamental differentiating characteristic of mobile gaming is the situation. On a PC or console, you typically play fairly long, continuous sessions. For instance, you may play a couple of hours after work every day. The truth is that mobile phones are not the most hi-tech gaming devices on earth. If you have access to better gaming equipment, you are not likely to play with your phone. However, when you are sitting in a bus or in a downtown cafe waiting for a friend, you can't fire up your PSX. The only device most people carry around is their mobile phone and they will use it when they have nothing else.
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.
Figure 1: Traditional game Sessions (left) versus mobile game sessions (right)
WAP stands for Wireless Application Protocol, a standard for delivering content (text, images & hyperlinks) to wireless devices. Current WAP (1.1) is based on content residing on a server. The WAP enabled mobile phones are small browsers that connect to the server just like Netscape Navigator connects to WWW servers while you are surfing on the Internet. On WAP, the data storage and processing power are completely on the server side, while the WAP phones themselves are dumb terminals.
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.
Figure 2: WAP phones are dumb user interfaces, all game logic resides on the server.
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.
Figure 3: In Sub-Hunter, the game board was rederded as a bitmap for each game turn.
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.
Figure 4: Action games on WAP are really turn-based tactical games.
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.