Wiley.Games.on.Symbian.OS.A.Handbook.for.Mobile.Development.Apr.2008 (779888), страница 60
Текст из файла (страница 60)
However, as we mentioned in section 8.3.1 it is possiblethat many of the libraries found in the N-Gage SDK will become morewidely available for developers outside the N-Gage program.8.6 SummaryThe evolution of the N-Gage game decks into the N-Gage platform oftoday shows what is possible for native mobile games on Symbian OS.For developers, the N-Gage platform offers a way to write a gamethat runs across a range of S60 smartphones that offer the capabilitiesto run rich-content games. Device differences are abstracted, so a gameis portable across the range of N-Gage compatible phones, and theidioms of C++ on Symbian OS are hidden behind a layer that providesprofessional-quality APIs for game development.
Furthermore, the SDKfeatures tools and APIs to hook the game to the end-to-end deliverysystem as well as the community provided by the N-Gage applicationand N-Gage Arena.For users, through the N-Gage platform, Nokia aims to provide an easy,reliable service for users to discover, try, buy, play, share and managemobile games. The next generation of mobile games is here. Get outand play!Part FourJava ME, DoJa and Flash Liteon Symbian OS9MIDP Games on Symbian OSSam Mason(Mobile Intelligence)9.1 IntroductionIn this chapter, we explore the mainstay technology of mobilegames – Java ME (the ME stands for micro edition). Java ME has ledthe way in mobile application and game development from its inceptionand has been the success story of mobile game development to date.We will start with a very brief Java ME history and discuss some of thefeatures that differentiate the Symbian OS Java ME implementation frommainstream devices.We’ll then have a quick look at why you might use Java insteadof Symbian C++ for game development, some architectural designscommonly used and then walk through a complete game example.
We’llthen wrap up with a look at the new SNAP framework from Nokia,that provides an infrastructure to support, standardize and streamlinemultiplayer games for MIDP.Space is really tight, so we’re only going to lightly touch on a numberof areas of the technology.
If you’re not familiar with Java ME, the JavaCommunity Process (JCP) and Java Specification Requests (JSRs), checkout en.wikipedia.org/wiki/JSR and java.sun.com/javame/index.jsp for agood introduction. In addition, there is a ton of books written aboutJava ME development, which I’ve listed in the Further Reading sectionat the end of this chapter, so we aren’t going to discuss high level GUIapplication development here. Instead we’re going to focus on using theJava ME platform for game development.Let’s start with a quick history lesson. .
.9.2 Java ME 101You’re probably wondering just why we have a whole chapter devotedto Java ME in this book. The answer is threefold – mobile games are266MIDP GAMES ON SYMBIAN OSthe killer applications of the wireless industry and have been for almosta decade, almost all of them were written in Java and there are over1 billion Java-enabled handsets in the world.
It’s a great technology inall its forms, it’s secure, mature, and even the name of the language iscool – ‘Java’ (just say it out loud). Over 5 million developers just can’t bewrong.Not only is it the best cross-platform mobile development technologyin the universe, it’s also really easy to write mobile games using it. Prettymuch every mobile phone handset sold anywhere over the last four years(including every Symbian smartphone) has had built-in support for gamedevelopment using the Java ME platform in the form of the MIDP 2.0Game API.
Check out a series of papers on runtime environments byRoy Ben Hayun, published in 2007 on the Symbian Developer Network(developer.symbian.com) if you need more information.Devices sold prior to 2003 generally don’t have this support (so ifyou have one of these, it’s time to upgrade your hardware), althoughthat didn’t prevent a huge number of titles being developed as the earlypioneers of constrained device development came up with a multitude ofworkarounds and de facto standards. This led directly to the widespreadacceptance, market penetration and overall success of Java ME (or J2MEas it was known at that time) and the ongoing viability of using it as thegame development platform of choice.Sun Microsystems recognized back in the early 1990s that Java wouldbe a major player in the resource-constrained market and subsequentlylaunched an R&D project called Spotless to address this. The result was asmall Java virtual machine (JVM) that used less than 10 % of the standarddesktop version (160 KB to 512 KB) and was called the Kauai virtualmachine (KVM – note that the ‘K’ does not, as is commonly held, standfor ‘Kilobyte’).Since there’s such a diversity of electronic devices with limited capabilities, Sun wasn’t just thinking about mobile phones.
Their vision includedelectronic toys, household appliances (like kettles), pagers, set-top boxes,digital TVs, personal organizers, and PDAs. Consequently, Java ME wasdivided into three main building blocks to address this diversity.9.2.1 ConfigurationsA configuration represents a particular horizontal category of devicesthat share similarities in terms of memory budgets, processor power, andnetwork connectivity, and can be thought of as defining their lowestcommon denominator. Configurations have a virtual machine and a setof classes for basic functionality only.There are currently two configurations, the Connected Limited DeviceConfiguration (CLDC), which was aimed specifically at mobile phones,two-way pagers and low-level PDAs, and the Connected Device Configuration (CDC) which was aimed at devices with more memory,JAVA ME 101267better network connectivity, and faster processors, such as set-top boxes,high-end PDAs and communicator-type phones such as the Nokia 9300and 9500.As we are focusing on mobile phone game development, we won’tsay anything more about the CDC in this book.
The CLDC, which is whatmost concerns us, is the configuration found on most mobile phonestoday. Most of the handsets sold in the last 3–4 years support the secondincarnation of the CLDC, which is version 1.1. It can be regarded asan incremental update and simply added some new features to theconfiguration, including (but not limited to) thread naming and interruptsupport, weak references and support for floating point operations (theFloat and Double classes).
As a result of the last addition, the minimumtotal memory requirement was also lifted from 160 KB to 192 KB.9.2.2 ProfilesProfiles sit on top of a configuration and allow it to be adapted andspecialized for a particular class of devices in a vertical market such asmobile phones. They also generally map to consumer expectations ofportability – you may expect a mobile game to be portable across a setof mobile phones, but you wouldn’t (necessarily) expect it to run on, say,your kettle.A profile effectively defines a contract between an application and aset of similar devices. So if there was a Kettle Profile (KP), then coffeemaking applications written using it would be expected to work on all KPcompliant kettles – and not on mobile phones.There are currently only two profiles that use a CLDC as a foundation – the mobile information device profile (MIDP) for mobile phonesand the Information Module Profile (IMP) targeted at hardware withoutrich graphical displays, such as parking meters, home alarm systems andvending machines.
CLDC is also used by the proprietary DoJa profile fori-mode devices from NTT DoCoMo (the subject of Chapter 10, whichdiscusses writing games for the Japanese market). There are also a numberof profiles built upon the CDC, but we won’t cover them here, becausein this chapter, we’re only interested in MIDP.The MIDP defines the core functionality that mobile applications canleverage – the UI, local storage, network connectivity, and applicationlife cycle management. The original version 1.0 was started in November1999, and, even though it did not actively provide game support, literallyhundreds of games were written for it nevertheless.
It was so successfulthat, almost immediately, work began on defining MIDP 2.0.The MIDP 2.0 GUI library consists of a high level API with support forstandard widgets (textboxes, check boxes, buttons, etc.) and a low levelAPI supporting graphics contexts aimed mainly at game development. Thelow level API includes standard routines for creating graphics primitives268MIDP GAMES ON SYMBIAN OS(lines, polygons, arcs, etc.) as well as supporting clipping, full-screencanvases, regions, image manipulation, fonts, brushes, colors, and offscreen buffers.Crucially, MIDP 2.0 also introduced timers and the Media API (a subsetof the optional Mobile Multimedia API or JSR135) which are obviouslyrelevant to our game focus, as well as the Game API. We’ll talk moreabout that in just a bit.9.2.3 Optional PackagesThese are general purpose APIs in the sense that, while they providea specific set of functionality, they do so for a potentially wide rangeof devices.
Good examples of this include the Mobile 3D Graphics forJ2ME (JSR184) and the Location API (JSR 179) both of which providefunctionality that is not specific to a family of devices such as mobilephones. Optional packages effectively add functionality to a profileand may even end up incorporated into one as time goes on and thetechnology matures.Java’s cross-platform ideal has always been the ability to ‘write once,run anywhere’ and the language was specifically designed with that endin mind. Unfortunately, optional packages have often turned out to bea double-edged sword. While allowing relatively fast dispersion of newtechnologies into the marketplace, they have resulted in what is generallyknown as ‘fragmentation.’ This is a nice word for it – and for a long timewhat it really meant was that you could write a Java ME application onlyonce as long as you only wanted it to run on one type of handset.In reality then, people often had to re-write or re-design many times toaccommodate missing APIs, implementation variations, and workaroundsto address known issues.
Sometimes API implementation details vary evenwithin the same family of devices (or in the worst case, each device).Sadly the phrase ‘write once, debug everywhere’ was really a lot moreapt. In general, this had the effect of greatly hampering the time to marketof Java ME applications and games.9.2.4 FragmentationThere have been two efforts to address fragmentation in the past.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
