Wiley.Games.on.Symbian.OS.A.Handbook.for.Mobile.Development.Apr.2008 (779888), страница 13
Текст из файла (страница 13)
As described earlier in the chapter,depending on the handset manufacturer licensing Symbian OS, thesmartphone uses one of the three UI platforms: either Nokia’s S60,NTT DoCoMo’s MOAP user interface for the FOMA 3G network, or UIQ,designed by UIQ Technology.There are significant differences among the three platforms. At a highlevel, these can be characterized in terms of look and feel of the UI, andthe way the user interacts with the phone. For a developer, the distinctionoccurs at an API level – code for one UI platform is incompatible withthe other platform.
Developers using native C++ APIs find there are36INTRODUCTIONsome significant differences between UIQ 3 and S60 3rd Edition, in theUI classes employed, how they are used, and the design philosophyemployed. Code conversion between them can be complex. It can leadto almost two completely different versions of the application, unlessthe application is carefully designed to separate generic code that usesstandard Symbian OS APIs, such as string, event or file handling, fromcode that displays the UI and code that accesses hardware such as thephone’s backlight or the vibra motor that vibrates the phone.Fortunately, games are often some of the easiest C++ applications toconvert between UIQ and S60. Many games do not use the standard UIcontrols (such as dialogs and list boxes) that other applications employ,and thus typically require fewer code changes.
Of course, games often usehardware specific APIs and these need to be ported between platforms.Some may use elements of the UI platform in their menu system, althoughmany define their own. Good game design will separate platform specificcode from agnostic code, making cross-platform conversion relativelystraightforward.Even within a single UI platform, there can be issues of portability. Thehardware characteristics of a range of smartphones can differ significantlyaccording to the target market for a phone. For example, Nokia’s S60range offers fully featured ‘multimedia computers’ which are smartphonesfeaturing, for example, high resolution screens, hardware acceleratedgraphics, high-quality video and WiFi, for downloading mobile TV, musicand video.
Then there are alternative, smaller form factors, and more basicS60 smartphones for those that want the benefits of a smartphone (such asemail, web, and ability to install after-market software) without wantingall the multimedia options available. Variations such as the amount ofmemory available, processor speed, and disk space are also factors thatmay affect some games, for example, if the frame rate is crucial or thereare a lot of game assets to store and load into memory.Many games aren’t significantly affected by variations in the phone’sprocessor, memory, or storage, but variations in the form factors maycause issues. Some phones may not have a camera, for example, or mayhave a lower resolution screen than others. A game must be one of thefollowing:• able to determine the device characteristics and adjust accordingly• optimized for the lowest common denominator hardware it can beinstalled upon• agnostic to any variation in hardware.The N-Gage platform addresses the issue of portability between different S60 smartphones by providing a set of libraries that present aSMARTPHONE CHARACTERISTICS37consistent interface for the games to establish hardware capabilities andmanage differences.
The N-Gage platform approach also divides the S60phones that support the N-Gage platform into ‘device classes’ accordingto capability, so a game developer can guarantee a minimum level offunctionality, for example, a minimum allocatable heap size of 10 MBand a minimum storage capacity (on external memory card or built-inmemory) of 64 MB, and support for standards such as Bluetooth 1.2 andOMA DRM 2.0.The N-Gage platform also allows game developers to write games forSymbian using C++ that is more familiar, using standard interfaces andtypes, rather than relying on knowledge of active objects, descriptorsand Symbian OS-specific types.
This in itself eases portability of gamecode originally written for other platforms, such as Windows Mobile, andeven console or portable game players. Chapter 8 discusses the N-Gageplatform in more detail.Some game developers use middleware solutions to give them portability across platforms and devices. A good example is Ideaworks3D’sAirplay.
The Airplay SDK provides an operating system abstraction layer,‘Airplay System,’ which abstracts all of the major mobile operating systems. This layer not only provides source level compatibility but alsogoes a step further by maintaining binary level compatibility betweenplatforms, which results in major cost benefits (for example, QA time issignificantly reduced, as every platform is running the same game application binary). In addition, the publisher is able to deploy to all platformssimultaneously, which is critical to being able to leverage their marketingexpense for a given title (often tied in to a console game or film release).Some of the middleware solutions available for Symbian smartphones aredescribed in Chapter 7.1.12 Smartphone CharacteristicsThe characteristics of a mobile phone differ from a typical handheld, PCor game console, and this has an effect on the design and implementationof mobile games.
As I’ve already discussed, a Symbian smartphone is abit like a Swiss army knife, and has a number of different roles. A gamedeveloper must take this into account; the code must co-exist with theother applications running on the smartphone and take cues from theoperating system when necessary.For example, a game should be interrupted when there is an incomingcall, and should allow the player to be aware of received messagesand display calendar alarms, if he or she chooses to be notified whileimmersed in the game. The operating system controls much of this andwill, for example, force the game to the background when a phone call is38INTRODUCTIONreceived.
The game is made aware of the change in focus, and the gamedeveloper should write code so the game suspends its activity while itis in the background – we’ll discuss how to do this in the next chapter.Game developers must take measures to prevent the game consumingbattery power and other resources, such as active network connections,while the game is paused, particularly if it is for a lengthy duration.More generally, it is important that a mobile game developer considers the limited resources available on a typical Symbian smartphonecompared to a PC or game console. Good examples are the limitationon memory, disk storage capacity, and download size, and the fact thatit mostly runs on battery rather than on main power.
This last factor,combined with the standard ergonomics of a phone and the context inwhich mobile games are played, typically limits the time for which agame is played. Mobile games have much shorter play times, in general,than their console or PC equivalents, and a game designer must considerhow to grab a player’s attention, and be satisfying, in a short time frame.The need for simple, consistent gameplay and the circumstances underwhich mobile games are often played (in transit, with associated issues ofvisibility, sound constraints and interruptions) are important issues in thedesign of any mobile game.A game designer must also take into account the variety of form factorssuch as input controls, screen sizes and screen orientations available tothe mobile phone platform.
One interesting issue is that of localization,where a game is translated into a number of different languages. The gamemay be designed with artwork and text for one particular language, oftenEnglish, and the layout arranged to fit the small phone screen exactly.Text localization may result in different length strings which are oftensignificantly longer than the English version, but still need to be made tofit in the same screen area.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
