Wiley.Games.on.Symbian.OS.A.Handbook.for.Mobile.Development.Apr.2008 (779888), страница 11
Текст из файла (страница 11)
Java ME devices implementa profile – for mobile phones this is called the Mobile Information DeviceProfile (MIDP). Applications written for this profile are called MIDlets.Java ME was not originally designed as a games platform, and it initiallylacked some of the functionality needed by games, such as graphics effectslike layering, transparencies and sprite rotation. Some handset manufacturers added their own interfaces to supply this and other ‘improvements’and, combined with some loose, or optional, specifications, the JavaME platform became somewhat fragmented.
In effect, games were notportable between phones from different manufacturers and required effortfrom developers who found themselves producing multiple different versions for different phones (sometimes over 500 versions for a populartitle!). This was a long way from the ‘write once, run anywhere’ modelfor Java, and caused many problems, although the handset manufacturersquickly realized that it was hindering development for their devices, andthey are now moving to standardize their implementations.Working groups, called Java Specification Request (JSR) Expert Groups,design new APIs for mobile devices – to allow the Java ME platform toevolve and adopt new technologies. As the number of JSRs increases,the platform is becoming increasingly capable of providing support forhigh-quality games.Each proposed API is described, discussed and eventually approved, atwhich point, it can be implemented by any mobile handset manufacturerwishing to do so. Each implementation of an API must be carefully testedagainst the JSR for compliancy, and a game that exploits a particularAPI should then be portable across devices which offer the same JSR.In spite of conformance tests, implementations of some features maystill differ according to the handset or manufacturer in question.
Subtledifferences can creep in, because of the implementation differences ondifferent hardware, in some cases, even across device families from theMOBILE GAME PLATFORMS29same manufacturer. However, despite some remaining fragmentation,and with some limitations, Java ME code is mostly portable across variousoperating systems and processor types.Most mobile phones – Screen Digest estimates the figure to be over90 % – support the installation of Java ME games. For a number of lowerend phones, and for Symbian smartphones in Japan, it is indeed the onlyroute to use to deliver games to the phone after it has left the factory.Because of its ubiquity, Java ME is the largest technology platform formobile game development.
One of the advantages of developing in JavaME is that Java is a popular programming language and has good toolchain support and documentation. Developers have access to multiplewell-established programming resources, and companies have a largebody of skilled developers to recruit from.Chapter 9 discusses the creation of Java ME games on Symbiansmartphones in detail, and Chapter 10 describes the DoJa standards fordeveloping games in Java for the Japanese market.1.10.2 BREWBREW (which is an acronym for Binary Runtime Environment for Wireless)is a proprietary runtime platform created by Qualcomm Inc.
BREW can besupported by handsets built for GSM/GPRS, UMTS or CDMA. However,when BREW was first introduced it was solely developed for CDMAhandsets.While Java ME games are delivered as bytecode that is interpreted bythe VM rather than associated with a particular processor, BREW applications are compiled into ARM machine code. The compiled code is said tobe native and, as such, BREW offers an improvement in performance. TheBREW runs between the application and the phone’s operating system, soapplications do not need to use system APIs directly. BREW developerswrite their code in C or C++ using the SDK provided by Qualcomm.The BREW SDK is free, but developers must pay for support if theyneed it.
Unlike Java ME games, BREW applications have greater directaccess to the hardware so they must be digitally signed before they can bedeployed to a phone, to ensure that they do not compromise its behavior,either maliciously or accidentally. Once an application has been createdand tested internally by a game developer, it must be submitted forindependent testing (known as ‘TRUE BREW’) to ensure a defined level ofquality. Only then can it be distributed commercially. This process canincrease a game’s time-to-market and the testing and certification processis an additional development expense. However, it is also true that manynetwork operators insist that a Java ME game be tested and certifiedbefore they will allow it to be distributed via their portals.
So, althoughthe requirement for TRUE BREW testing may put hobbyists off workingon the platform, it does not usually deter professional game developers,30INTRODUCTIONwho find that rigorous certification, while time-consuming, is a de factopart of any game development process.Qualcomm collects royalties from the developers who deploy codeon the BREW platform.
In return, it provides a set of consistent and richAPIs for BREW that includes those for distribution of the applicationbinary to the end user. The provisioning system integrates with networkoperators’ billing systems to make it easy for users to make purchases,and easy for network operators to track purchases.
The model also allowsvariation from one-off payments for a game, and provides, for example, asubscription model for regular revenue generation.BREW is considered to be an excellent platform for game development,particularly BREW 2.0 which has good support for 3D graphics, and canbe used with powerful handsets to create high-quality games. The endto-end system is considered consistent and attractive to many gamesdevelopers, and because of the power of compiling to native code, it is avery popular choice of platform.BREW is mostly used in North America, China, Taiwan and SouthKorea; globally, Screen Digest estimates the install base of BREW phonesto be approximately 6 % of the total market. Even in the markets whereBREW is available, evidence suggests that the majority of mobile gamespurchased are Java ME.We won’t discuss BREW any further in this book, because it is not aplatform offered by Symbian smartphones.1.10.3 Native PlatformsThe term native in this context refers to games written in C or C++ fora particular mobile operating system, such as Symbian OS, WindowsMobile or Palm OS.
The games are programmed against software APIsthat are provided in libraries found in software development kits releasedby the phone manufacturer or platform vendor, many of which originatedirectly from Symbian. Alternatively, they can be written to use a layerbetween the game and the OS, such as 3D graphics middleware, theN-Gage platform or the standard C libraries, provided by Symbian, Nokiaand other partner companies.The benefits of writing native games are that more direct access isgranted to the hardware of the phone, which improves runtime performance and flexibility to manipulate the phone hardware.
For example, anative graphics library is significantly more capable and efficient than itsequivalent in Java ME.In consequence, native games are typically more sophisticated thanJava ME games, with better visual and audio quality, and often moreinnovative use of the phone, because access to certain features, such asmotion detection, vibra and camera may otherwise be limited by the JSRsa phone supports, and the scope of the JSRs themselves.MOBILE GAME PLATFORMS31Some game developers prefer to work in C or C++ rather than in JavaME, even when creating basic, so-called casual, games that do not needaccess to the ‘bare metal’ of the hardware or high performance graphics.One reason is that they can license a particular library to use in theirgame that was created in C or C++ or they may have their own legacygame engines and wish to re-use that code.However, commercial developers often find themselves competingwith hobby developers who are writing similar games in Java ME andgiving them away free or selling them very cheaply.
Unless you are anexperienced C++ developer with an established game engine, architectureand test regime in place, the effort involved to create and deploy anative casual game is usually higher than to create a rough equivalentof the game in Java ME. Many professional developers will not findthe additional effort worthwhile when competing for sales of cheapergames.Portability is an issue for games that compile to native code, becausethe games will only run on particular handsets.
The code must becompiled for the instruction set according to the processor in the phoneand against the set of software APIs that a particular operating systemprovides to interact with the hardware. For example, a C++ game writtenfor a Windows Mobile smartphone will not run on an S60 smartphonebuilt upon Symbian OS, much as an application for a Mac will not runon a PC. The game’s source code must be re-compiled and, before thisis possible, it usually requires significant code changes because of thedifferences between the operating systems.Experienced game developers design their games to separate sourcecode that is generic and can be re-used on each platform from the codethat is specific to a particular operating system. This makes porting a gamewhich compiles natively as easy as possible, although it still requires codedevelopment, integration, recompilation and testing for each additionalplatform.Says John Holloway of ZingMagic, ‘‘We have as much shared codeas possible, even at the UI level.
Drawing the correct chess pieceson a chess board in pseudo Z order to achieve a 3D type effect hasnothing to do with Palm OS, Windows Mobile, Symbian OS or anyother GUI specifics. We can build a generic logical model of whatwe need to do then map that into real platform function calls foreach. That way we can write much of our code for multiple platformssimultaneously.’’There are also a number of standard APIs that abstract API differencesand allow mobile game developers to re-use the source code for a gamewithout making any, or significant amounts, of changes.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
