Wiley.Games.on.Symbian.OS.A.Handbook.for.Mobile.Development.Apr.2008 (779888), страница 12
Текст из файла (страница 12)
These includestandards for graphics (such as OpenGL ES which is an API for fullyfunctional 2D and 3D graphics) and for audio (such as OpenSL ES). TheC and C++ standard libraries are also a means to abstract native platform32INTRODUCTIONdifferences, which are may otherwise require source code changes beforerecompilation. These can be particularly useful on Symbian OS, whichhas a set of idioms that are unfamiliar to many experienced developerswho have previously worked on other platforms. Chapter 7 discusses thesupport for various standards that is offered by Symbian OS.Aside from the portability between different native mobile platforms,another drawback is that the installation of native games is often restrictedor prevented. Many network operators do not allow the download andinstallation of native games, and prevent the user’s access to the filesystem of the phone except through specific application managers thatdo not recognize the file types of native installation packages.
Manylower-end, mass-market phones, and Symbian smartphones in Japan, areclosed to after-market installation of applications except those written inJava ME or DoJa, according to region.To conclude this section on technology platforms, let’s set out whereyou can find more information in this book. We discuss the C++ APIssupplied by Symbian OS for creating native games in Part Two of thisbook, standards support for games creation and porting using C/C++in Part Three, and how to write games for Symbian smartphones usingJava ME in Part Four.
On S60 3rd Edition smartphones, mobile gamescan also be written for Adobe Flash Lite, which is discussed further inChapter 11.1.11Portability and CompatibilityPortability and compatibility of mobile games are big issues inherent tothe lifetime of a typical mobile games device, and the number of differentdevices available. Let’s compare the expectations of a console gamedeveloper, a PC game developer, and a mobile game developer.1.11.1 ConsolesThe developer of a console game knows that if he or she tests the codeon a Microsoft Xbox 360 before releasing it, it will run on a customer’sXbox 360 too. It will also run on the customer’s friends’ older Xbox360 consoles, and, in two years time, it will also work on a newerXbox 360.
The only reason that it may stop working is if compatibility isbroken by the hardware manufacturer, for example, if a firmware updateis introduced that has not been tested for backwards compatibility. Thisis likely to be rare because the manufacturer does not want to fragmentthe platform into different firmware versions since this causes anxiety forconsumers who can’t easily tell if a game will work on their particularmachine. Indeed, some of the console manufacturers go to great lengthsto ensure that, not only is a single console compatible throughout itsPORTABILITY AND COMPATIBILITY33lifetime, but that it also plays games from previous consoles in the series.For example, a software emulator can be used on an Xbox 360 to alloworiginal Xbox games to be played on it.
Likewise, the Nintendo Wii isbackward compatible so that all official Nintendo GameCube softwaremay be played (although a GameCube controller is required to playGameCube titles, and online features of those games are unavailable onthe Wii).There is a very limited concept of portability in the console world. Thereis only one model of a console for a developer to worry about – subjectto minor variations such as hard disk space or memory.Of course, between consoles there is a portability issue. A consolegame written for Xbox 360 cannot be run on a Nintendo Wii, because thetwo platforms are not portable, but most users understand that.
A gamemust be ported to run on different consoles, and large game publishersoften do produce ports to allow popular games to be played on multipledifferent console platforms. A good game developer, regardless of whetherthey are working on console, PC or mobile platforms, will usually designa game to make the porting effort between devices as easy as possible.22We’ll also discuss some of the standard and middleware used by gamedevelopers to make their code more portable in Chapter 7.1.11.2 PCsA PC game developer has more issues to consider than a consoledeveloper, since the game must be tested on each of the different versionsof Windows available, to ensure the game’s portability between them.For example, a player may have Windows XP, but then upgrade his orher PC to Windows Vista.
He or she will expect to be able to install andrun the game on the different OS platform if the manufacturer claims it issupported. There may also be issues associated with hardware differencesbetween different PC setups, particularly since PCs can vary significantlyin their capabilities. The PC game developer has to consider these whencreating the game, and list a minimum set of capabilities as part of thegame’s specification.Compatibility is also not a problem, since Microsoft provides a levelof assurance that newer, successive versions of Windows will retaincompatibility with older releases, for a timeframe which is typicallylonger than the lifetime of the game.1.11.3 MobileMobile game developers face the biggest challenges in terms of portabilityand compatibility. There are numerous different phone models in the22For more information about the issues to consider when writing portable games, Irecommend Cross-Platform Game Programming, Steven Goodwin, Charles River Media,2005.34INTRODUCTIONmarket, from different manufacturers, each with varying hardware anddifferent operating systems.
This is typically called fragmentation.I discussed issues of portability for native mobile games in the previoussections. For example, Java ME developers have to be aware of devicefragmentation. Different handsets may support different versions of theJava ME standard and different sets of JSRs. To work around this, the gamedeveloper has to create separate versions of the game for the differentphone types, sometimes numbering into the hundreds for a popular game,and increasing the development expenses caused by testing across therange of handsets supported.Even when a developer manages to resolve the technical issues ofportability between different phone handsets so that the game executes, itdoesn’t necessarily mean that it will be easy to play! Handsets may varysignificantly in terms of screen size and orientation, memory specificationsand input controls.
The difference in the form factors between mobilephones can be significant, compared to that between PCs (where eachis likely to have a mouse, keyboard, and large screen). For example,some phones have keypads with reasonably-sized, well-separated keys,a joystick and high contrast screen. Others may have small, stylizedkeypads, touchpads or small screens.
Some of the current Symbiansmartphones are shown in Figure 1.4.Figure 1.4The diverse range of Symbian smartphonesPORTABILITY AND COMPATIBILITY35A game designer often has to decide on a basic common set ofhardware features, and support those alone, in much the same way that aPC game developer presents a minimum set of hardware specifications.Unlike consoles, which generally have a lifetime of about five years,the typical mobile phone lifetime is a year to eighteen months.
Mobiletechnology evolves rapidly, driven by the dynamics of the mobile communications business and consumer expectations. Network operatorsactually subsidize the purchase of each new generation of phone handsetin order to spur consumer adoption and drive up the use of new networkservices and tariffs.1.11.4 The Symbian OS v9 Binary BreakThe underlying mobile platform changes according to the requirementsplaced on it by operators and consumers, and in doing so compatibilitymay not be retained. A good example of this is the binary break introduced by Symbian OS v9, which is found in UIQ 3 and S60 3rd Edition.Applications for earlier versions of those UI platforms cannot be installedand run on newer Symbian OS v9 phones because of binary incompatibility across the Symbian platform.
The code must be recompiled, andrequires changes in all but very few cases.Symbian and its phone manufacturer licensees do not break compatibility lightly, and do not plan to do so often, but could not avoid doingso in Symbian OS v9. The migration path between the original and newplatform versions has been clearly documented for developers, but it isstill clearly an issue that needs to be highlighted. This book will focuson writing games for Symbian OS v9 only, and will not describe theearlier platform versions. For a detailed discussion of the differences inwriting code pre- and post-Symbian OS v9, please consult the portingdocumentation on each of the main developer support websites listed inthe References and Resources section at the end of the book.1.11.5 Symbian Smartphone UI PlatformsThere is a further issue for developers targeting Symbian smartphones thatshould be discussed at this point.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
