Mobile Game Developer

Mobile games tend to be small in scope and often rely on good gameplay over flashy graphics, due to the lack of processing power of the client devices. One major problem for developers and publishers of mobile games is describing a game in such detail that it gives the customer enough information to make a purchasing decision. Currently, Mobile Games are mainly sold through Network Carriers / Operators portals and this means there are only a few lines of text and perhaps a screenshot of the game to excite the customer. Two strategies are followed by developers and publishers to combat this lack of purchasing information, firstly there is a reliance on powerful brands and licences that impart a suggestion of quality to the game such as Tomb Raider or Colin McRae and secondly there is the use of well known and established play patterns (game play mechanics that are instantly recognisable) such as Tetris, Space Invaders or Poker. Both these strategies are used to decrease the perceived level of risk that the customer feels when choosing a game to download from the carrier’s deck.

Recent innovations in mobile games include Singleplayer, Multiplayer and 3D graphics. Virtual love games belong to both of singleplayer and multiplayer games. Multiplayer games are quickly finding an audience, as developers take advantage of the ability to play against other people, a natural extension of the mobile phone’s connectivity.

Java (aka "J2ME" / "Java ME" / "Java 2 Micro Edition") runs atop a Virtual Machine (called the KVM) which allows reasonable, but not complete, access to the functionality of the underlying phone. This extra layer of software provides a solid barrier of protection which seeks to limit damage from erroneous or malicious software. It also allows Java software to move freely between different types of phone (and other mobile device) containing radically different electronic components, without modification. The price that is paid is a modest decrease in the potential speed of the game and the inability to utilise the entire functionality of a phone (as Java software can only do what this middle-man layer supports.)

Java ME devices implement a profile. The most common of these are the Mobile Information Device Profile aimed at mobile devices, such as cell phones, and the Personal Profile aimed at consumer products and embedded devices like Set-top boxes and PDAs.

A profile is a superset of a configuration, of which there are currently two: Connected Limited Device Configuration and Connected Device Configuration.

Connected Limited Device Configuration
The CLDC contains a strict subset of the Java class libraries, and is the minimal needed for a Java virtual machine to operate. CLDC is basically used to classify myriad devices into a fixed configuration.

Mobile Information Device Profile
Designed for cell phones, MIDP boasts an LCD-oriented GUI API, and MIDP 2.0 includes a basic 2D gaming API. Applications written for this profile are called MIDlets. Almost all new cell phones come with a MIDP implementation, and it is now the de facto standard for downloadable cell phone games. However, many cellphones can run only those MIDlets that have been approved by the carrier, especially in North America.

Information Module Profile
The Information Module Profile (IMP) is a Java ME profile for embedded, "headless" devices such as vending machines, industrial embedded applications, security systems, and similar devices with either simple or no display and with some limited network connectivity.

Originally introduced by Siemens Mobile and Nokia as JSR-195, IMP 1.0 is a strict subset of MIDP 1.0 except that it doesn't include user interface APIs — in other words, it doesn't include support for the Java package javax.microedition.lcdui. JSR-228, also known as IMP-NG, is IMP's next generation that is based on MIDP 2.0, leveraging MIDP 2.0's new security and networking types and APIs, and other APIs such as PushRegistry and platformRequest(), but again it doesn't include UI APIs, nor the game API.

IMP applications are called IMlets, but in reality they are MIDlets. They subclass MIDlet, and follow the same packaging, deployment, security and life-cycle as MIDlets.

The Ant team find that most of their support calls related to JAR file creation have two underlying causes.

The first is manifest creation, specifically how long lines in the manifest are wrapped. This is a complex and somewhat ambiguous part of the specification. Ant wraps long lines at 68 characters and continues on the following line with a space at the front to indicate a continuation. This is viewed as erroneous by people that have not read the specification in detail and believe that the classpath should be split at a file boundary, instead of partly across a file name. Unfortunately, if that is done, the Java runtime does not detect a split line as the first line ends before the 68 character boundary.
The second is WinZip converting upper-case files and directories to lower case. If an user views the contents of a JAR file using WinZip, a file such as MANIFEST/MANIFEST.MF is converted to manifest/manifest.mf.
It is unclear what test suite Sun has for JAR tools. If there is one, it is probably in the test suite for the java runtime itself, which is only available to open source projects in strictly controlled circumstances, including the signing of non-disclosure agreements. This makes it hard for the Gnu JAR and Ant teams to be 100% sure that their implementations do match the specification. All they have to work on is the few lines of text in the Java documentation, and experiments with the Sun runtimes.

Some mobile phone Java runtimes appear to parse the manifest in ways that are incompatible with the specification, and require a strict ordering of entries in the manifest. They also get the line wrapping algorithm wrong. This may imply a problem in the test suite for the J2ME mobile java runtime.

If 2005 was the year that mobile gaming went 3D and broadband, 2006 will be the year that mobile gaming gets big. Not in terms of the size of the cell phone screen, of course. But in terms of game capacity, pricing, audience and the size of at least one publisher entering the market.


Next month, the video game industry's 800-lb. gorilla -- Electronic Arts -- will most likely close on its $680-million purchase of Los Angeles-based Jamdat Mobile, the leading mobile games developer said to own about a 30% marketshare. The deal will propel EA way ahead of the competition in the fast-growing cell phone game space, and the combined companies are expected to publish more than 50 titles during their first year together.


While the move will not only make EA No. 1 in mobile gaming overnight as well as instantly bestow upon it all the relationships with phone carriers that traditionally take so long to build, industry insiders see another strategy motivating the giant publisher.


"I think what they're after is what we call cross-platform design -- the ability to integrate games across all the platforms," notes Mike Yuen, senior director of Qualcomm's Gaming Group in San Diego. "That doesn't mean just taking EA's 'Madden NFL 06' and making a mobile version of it. I think there's going to be a much deeper integration ... perhaps giving gamers the ability to transfer a player from 'Madden' on their PC or console to their cell phone, enabling them to do some drills to perhaps improve the player's skills and boost his scoring accuracy by, say, 3%, and then return the player to the PC or console game with better stats. I think that kind of cross-platform interaction is going to be key to videogaming's success in the near future."


Yuen also believes that EA's entry into mobile gaming "validates that industry and, in my opinion, serves as a wake-up call to other video game publishers who haven't really considered becoming mobile developers themselves. Instead of just selling other developers' titles, this almost forces them to consider taking that acquisition path."


EA chose not to comment for this story.


Meanwhile, at GameLoft, the seven-year-old mobile game developer and publisher founded by the Guillemot family (which began Paris-based publisher Ubisoft 13 years earlier), Eric Albert also sees consequences from EA's Jamdat deal.


"There's no question that it's going to be tougher for the smaller guys to make it in the mobile business now that some of the bigger players are starting to make their presence felt," says Albert, who heads up GameLoft's North American operations. "At the same time, I think there's still room for smaller developers to bring innovation to the industry. Not if all they have is another version of solitaire or another bowling game. But if it's really innovative, they will find a publisher to take their product to market."


Innovation in 2006 includes experiments with mobile games that are far heftier than the traditional small-file games that one typically sees on cell phone menus or "decks."


For instance, at year-end, EA came out with "Need For Speed Most Wanted," a mobile car racing game loosely based on the PC and console game of the same name. According to Qualcomm's Yuen, it's roughly 40 megs in size, "which is humongous for a cell phone game which is typically just a meg or two." Because the game can capitalize on the speed of one of the new 3-G ("third-generation") high-bandwidth networks, it downloads to the phone in bite-size chunks -- as you progress in your auto race, new tracks, cutscenes, and an MP3-quality soundtrack pour out of EA's servers. The result, says Yuen, "is a much richer experience than if a gamer can just downloaded a single one-meg game."


None of these larger 3-D games could exist without the high-speed 3-G networks that were launched last year and will become more popular this year, says Qualcomm's Yuen. That's because the 3-G-capable phones, or "handsets," are being priced for the mass-market -- as low as $49 today -- and game developers have learned they can charge more for the games, sometimes twice as much. Smaller 2-D games typically cost between $4.99 and $5.99, but 3-D games go for $8.99 to $12.99, and multiplayer 3-D games can levy an additional recurring monthly subscription fee.


For example, in June, GameLoft released "Asphalt Urban GT," a real-time, multiplayer racing title that enables a gamer with a cell phone to compete head-to-head against up to three other cell phone-wielding gamers anywhere in the country while six other AI-controlled cars go along for the ride. It sells for $9.99 plus a $2.99 per month subscription fee.


"The price points have been moving up but there's been little backlash from consumers," notes Yuen. "They don't seem to think $12.99 is too expensive for a mobile game, and that's the direct result of the kind of quality you get in a 3-D title playing over a high-speed network."


But if cell owners have developed a liking for hi-end mobile games, does that mean they are abandoning the casual games -- like poker and puzzles -- that have been the mainstay of the genre, especially in the older and female demographics?


Not at all, says Yuen.


"Despite advances in the technology, whether it's on the network side or in the actual handsets, casual games won't go away because that's the nature of the two to three billion people carrying phones. They're always going to love playing Texas Hold'em and Tetris. That's never going to change."


What is changing, however, is the growth in the number of young -- really young -- mobile gamers. According to MobileYouth, a London-based firm that tracks technology issues, more than seven million U.S. children between the ages of 10 and 14 had cell phones in 2004, a number that's expected to increase to 11 million this year. Parents simply find it convenient to be able to call their kids any time they want to ask where they are and what they're doing.


And quite often what they're doing is playing games. In fact, last year the Entertainment Software Rating Board, the organization which rates video games in the U.S., added a new rating, "E10+" -- for "Everyone 10 and Older" -- tailor-made for the cash-flush "tween" demographic.


The so-called "tween" audience -- adolescents between the ages of nine and 14 -- is the target demographic of Seattle-based Smashing Ideas, a company that, after nine years of creating over 900 online games for popular tween Web sites like everGirl and Nickelodeon, is preparing to move into mobile games.


Only instead of programming with popular software like Java which is supported by today's cell phones, Smashing Ideas' primary development platform will be "Flash Lite" which is not yet supported on handsets in the U.S.


"We are currently working on several mobile games, including one called 'Clearum,' that will debut in the U.S. once Flash Lite-enabled handsets launch in the market, hopefully in the second or third quarters of this year," notes Brian Burke, the company's managing director of corporate development. According to Burke, programming a game in Flash Lite takes one third the time of programming in Java and costs considerably less, a savings for the developer that could potentially be passed on to consumers.


The new Smashing Ideas games will all be designed for the tween demographic, an age group that Steve Jackson, the company's CEO, describes as an "always-connected audience."


"They are always on the go. And, to them, the cell phone is just another entertainment device, an extension of the experience they have on their TVs, their PCs, and their game consoles," he says. "There are over 73 million kids in the U.S. and, on average, they're spending multiple hours a day interacting with mobile devices, text messaging and listening to their MP3 players. Cell phones allow them to communicate with friends, to share high scores, to have fun. As multiplayer games start to penetrate the market more, tweens will be the demographic that will really thrive on that type of stuff. The tweens are the growth market -- a market we understand very well -- and we're making sure we're connecting with those people at an early stage."


While 2006 will see changes in terms of the mobile sector's audience and the hi-end games available, one thing that won't change from 2005 are the two highest hurdles that developers will face -- gaining access to the cell phone deck and porting games to an ever-growing number of handset models.


"Unlike the console market, where a developer can support the whole industry with 20 or so SKUs," explains GameLoft's Albert, "when you launch a title globally in the mobile space, depending on how many languages you intend to support, there can be as many as 1,500 or 2,000 SKUs. That's because right now there are around 300 handset types and, to do a worldwide launch, you're talking six or seven languages for each."


"The cost of porting is becoming prohibitive," observes Qualcomm's Yuen, "which is an issue developers really haven't come to grips with."


It's also an issue that separates the big players from the smaller ones, since only those with deep pockets can afford the average $1,200 per port when, say, 1,500 SKUs are involved.


There's also an increasing competition among developers for the cell phone carrier's attention since all the major carriers intend to decrease the number of games they plan to offer their customers while boosting the quality of those games.


"A few years ago, if you built a decent game and you went to a major carrier, you could probably get it into their catalog, but no longer," says Yuen. "The competition is becoming more and more intense. Which is why EA's acquisition of Jamdat -- with Jamdat's fantastic deck placement with the phone companies plus EA's tremendous brand -- is going to give EA a huge leg-up on everyone else."

In recent times, mobile games have gained popularity for providing personal entertainment on the go. This popularity has mobile gaming playing a pivotal role in revenue generation for the cellular carriers, game publishers, and handset makers, while generating numerous opportunities for game developers and associated professionals. With the number of mobile gamers around the world expected to reach 220 million by 2009, the mobile gaming business is projected to expand to higher levels and constitute a bigger portion of the profit pie for the cellular carriers and handset makers.

Mobile games can be classified into three broad categories:

Embedded games: Games that are hardcoded into the mobile handset's system and shipped with it. Soon to be outdated/obsolete. Example: Snake, shipped with all Nokia phones.
SMS games: Games played by sending text messages—for example, SMS to game server—that process them and sends back the result through SMS. Often in the form of live contests and polls. Not very popular because the cost of gaming increases with each SMS sent to the game server.
Browser games: These games are played using mobile phone's built-in microbrowser (net browser for mobile devices), either in online or offline mode. Players can play such games online through their cellular carrier's or a third-party game provider's game Web site, or download them for offline gaming. This category includes a wide range of games, such as solo or multiplayer games, network games, offline games, arcade games, and so forth
Among these three categories, browser games are today's most popular type of mobile games for their innovative and multimedia-rich content, appealing presentation, and lower cost of gaming compared to SMS games. This article discusses the development of browsing games and henceforth, the term "mobile games" will refer to "browser games" in this article.

Note: This article concentrates on 2D games. Because a large number of mobile phones in circulation today have very limited resources (small screen, limited memory and graphics support, cumbersome key input), the most suitable as well as commercially feasible games for these devices are 2D games. But, as capabilities of mobile phones are bound to increase over time, 3D games will become commonplace in the near future.
Mobile games can be developed using C++, Java (Java 2 Micro Edition, to be precise), and the Binary Runtime Environment for Wireless (BREW) platform from Qualcomm.

Although C++ has the advantage of being compiled into native code with direct access to system resources, and with BREW the platform provides end-to-end solutions to mobile game developers while allowing them to work with any desired language (including C++, Java, XML, and Flash), Java is the most popular choice for game development. Java, or the Java 2 Micro Edition (J2ME) platform to be precise, is identified as the most convenient for developing mobile games. (For more specifics on J2ME, see "What is Java 2 Micro Edition?") The driving forces behind J2ME's popularity are:

J2ME enjoys the status of an industry standard backed by all major handset makers, with most of the present day mobile phones being Java-enabled.
J2ME is a free and open platform. This helps keep the development costs low and provides the necessary flexibility with ample support freely available for developers using it.
Its highly portable nature ("Write once run anywhere") ensures that a game application written for one brand/type of handset will work with all other brands/types of Java-enabled handsets.
It is especially optimized for small devices, is lightweight, and is highly secure because applications written on it cannot access or affect other applications running on the phone/device.
J2ME consists of the Mobile Information Device Profile (MIDP) API that is designed specifically for developing applications for mobile devices including mobile phones, keeping in mind their limitations and constraints. Furthermore, the latest MIDP version 2.0 itself dedicates a whole API to game development, making game development simpler and quicker.

MIDP 2.0 API is a set of feature-loaded APIs used for developing secure, rich-content multimedia applications, including games, for mobile devices. MIDP 2.0 builds upon its predecessor MIDP 1.0 to provide a better development platform for building efficient and fast mobile applications. For more information on MIDP 2.0, see the Resources section at the end of this article.

MIDP 2.0 further refines the features and functionalities provided by MIDP 1.0. For information on the new features, see What's New in MIDP 2.0. One of the important additions made to MIDP is the Game API, or the javax.microedition.lcdui.game API package to be precise. Through the Game API, MIDP 2.0 provides game developers with the readymade building blocks that were to be developed from scratch in the case of MIDP 1.0. These building blocks are classes for creating and controlling various game elements such as game canvas, sprites, layers, and so forth (these are explained in the next section). Thus, MIDP 2.0 significantly reduces the time involved in game development.

The other two MIDP 2.0 API packages essential for game development, also explored by this article, are javax.microedition.midlet and javax.microedition.lcdui.

The javax.microedition.midlet API package provides a base for developing all mobile applications. It contains the javax.microedition.midlet.MIDlet class, which is the base class of all J2ME-based mobile applications (also known as midlets) and must be extended by the main classes of all mobile applications. Quite similar to the java.applet.Applet class, the MIDlet class provides resources necessary to create midlets.

The javax.microedition.lcdui API package is necessary to develop a user interface (UI) for all types of mobile applications. This API provides classes to create and control UI components (such as screen, form, text box, radio buttons, and so on) and processing input for mobile applications, including games. Developers who have GUI development experience with AWT and SWING will find that the elements of the javax.microedition.lcdui package are similar to elements from these APIs.

I'll discuss the elements of these APIs relevant to game development as upi encounter them during the development of the example game app.

“Let the games begin” were perhaps the words that A.S. Douglas muttered as he created the world’s first graphical computer game. Along the lines of Tic-Tac-Toe, this invention made Douglasthe first man to create a computer game.

Yet, even before Douglas, a 29-year-old engineer at an electronics firm had been given the task to build the world’s best TV set. Ralph Baer proposed that an additional feature be installed in his new, state-of-the-art TV to differentiate it from other televisions sets. While the management wasn’t impressed, Baer spent the next few years researching on TV games.

Meanwhile, physicist William Higinbotham created the first-known visual (video) game, Tennis for Two. The game bore resemblance to table tennis. Massachusetts-based student Steve Russell invented Spacewar!, the first game specifically developed for computers. Nolan Bushnell played Spacewar! and envisaged the concept of video game arcades.

These were a few of the visionaries who shared in Baer’s ultimate glory. Baer himself resurfaced in 1967 with Chase, the first video game played on a TV set. Soon, Bushnell too realized his age-old dream and collaborated with Ted Dabney to develop the first arcade game. Based on Russell’s Spacewar!, it was called Computer Space. Another year later, Bushnell devised the arcade game that would soon become a landmark in visual (video) game history – Pong. Bushnell and Dabney then launched Atari Computers and re-released Pong as a home game.

As gaming technology advanced, so did audio visual game production. In 1972, Magnavox released TheOdyssey. Designed by Baer, this was the first commercial home audio visual game. In 1975, Gunfight, the first microprocessor-based game, was launched, and a year later, Fairchild invented the Fairchild Entertainment System (Channel F). It was the earliest programmable home game console and among the first electronic systems to operate on a highly advanced microchip. Midway then introduced Space Invaders, the first arcade game to display high scores.

In 1980, Atari’s Asteroids and Lunar Lander became the first games to receive copyrights. Battlezone, the first 3D game, was launched. Thus, the decade heralded a new age in game production, with Nintendo, Sega, and other mega gamers coming to fore with consoles like PlayStation and Dreamcast.

Despite allegations of encouraging violence, audio-visual games have grown leaps and bounds. Today, products like Microsoft’s Xbox and Nintendo’s GameCube have taken modern gaming to new heights, where the sky’s no limit – truly, the game’s not over yet!

Mobile gaming, already a rage in the Far East, is now beginning to boom in the West as well. Mobile gamers hunched over their phones, punching away furiously at the buttons in their spare time are becoming an increasingly common sight at bus stops, train stations, airport lounges and hotel lobbies around the world.

With mobile phone density increasing by leaps and bounds globally, mobile gaming has become a popular source of entertainment. Millions of mobile users invariably turn to the games on their phones while commuting, when waiting for a rendezvous or simply killing time. While die-hard gamers might still prefer the console, the mobile industry is optimistic of winning them over in time because of the powerful lure of gaming on the go.

Mobile gaming had its humble beginnings in the late 1990s when Nokia introduced Snakes on some of its handsets. Snakes recorded sensational success and led all manufacturers of mobiles to add embedded games to each phone they have sold since.

But once the mobile gamers’ appetite was whet, it soon became insatiable. Mobile users were no longer content with the simple games installed in their phones. There was a demand for more complex games with cutting edge animation and realistic sound. Downloadable games emerged as the answer. Mobile users owning phones with WAP technology have demonstrated a willingness to pay and download games to increase their options for entertainment.

The makers of such legendary PC and arcade games like Asteroids and Space Invaders also saw a big opportunity in this new area of gaming. They were quick to convert their already famous games into mobile versions and have reported considerable success.

The rapid evolution of mobile phone technology has now made it possible for gamers to engage several other players located within a short distance (through Bluetooth) or even thousands of miles away (via GPRS). This has made mobile phone gaming interactive in real time. Also available are interactive games that operate through SMS or WAP.

Mobile gaming is fast gaining popularity across North America as well.

As games gravitate online, integrate the use of new peripherals, and are programmed for a wider array of mobile platforms, the skill sets required to build and market those games will, in many respects, differ greatly from past and present skill set expectations. Whether you are currently working in the industry or looking to get in, you need to know the skills required to build the next generation of games. And for those who don’t build the games, but, rather, build the business, what skills will game companies be looking for from its marketing, PR, and finance specialists? This series of articles will address what you need to know, how you go about acquiring that knowledge, and how best to apply it to your career. You will also get an inside view of how the industry’s biggest employers plan on maximizing efficiencies within their own organizations. Who will be hired? How will employers train current employees to assume new responsibilities? And what skills will they be looking for to support the increased number of multiplayer and persistent world games on their production and development schedules?

The industry has come a long way in a short period of time, and advances and changes continue to happen at an ever increasing pace, but with a little effort and direction you can definitely keep up. The first part of this series will overview mobile games, just one of the "hot" areas of game development, with tips on what skills you need to know as a programmer, artist, or designer, and go-to resources for getting your own skill set up to par.

MOBILE GAMES

Why is this a "hot" area? Take a quick glance at the upcoming list of industry events, and the impact of mobile games is readily apparent. Not only is the Game Developers Conference again presenting "GDC Mobile", but other big mobile game events on the horizon this year include the "Mobile Entertainment Summit" at CTIA WIRELESS 2004, the Games and Mobile Forum, and iWireless World just to graze the very tip of the iceberg.

The appeal of mobile game development is fairly obvious. The team size is typically a fraction of the size of a typical development team, the development cycle is a few months versus a few years, and the budget is generally less than $60,000 in contrast to more than $1,000,000. Moreover, phones are portable, networked, and more than one billion mobile phones are in use today. Whether mobile games will prove to be everything they’ve been hyped to be remains to be seen, but, for now, mobile games are hot and, consequently, so are those people with the skills to make them.

Getting Mobile
Games developed to run on mobile or "cellular" phones are typically referred to as mobile games or, in many instances, wireless games. Unlike those games already embedded on your phone, this area of game development more directly refers to downloadable games. Mobile games also include SMS (Short Message Service) games which deliver short text messages from one phone to the other. Further, according to Nokia, just about every phone shipped since 1999 includes a Wireless Application Protocol (WAP) browser. Very simply put, WAP games are played by going to the game provider’s URL to download and view pages. For purposes of this article, however, SMS and WAP will not be addressed.

Rather, the hot area now for mobile game development, and for the foreseeable future, is mobile games developed on platforms such as BREW and J2ME, as will be discussed in greater detail, below. Briefly, BREW (Binary Runtime Environment for Wireless) is a platform that allows for several different languages to work with a mobile device, including C++, Java, XML, Flash, etc. Similarly, J2ME (Java 2 Micro Edition) has a set of specifications that allow for a subset of the normal Java classes to work with a particular group of devices. Not all aspects of the language are supported, however, and different devices expose different capabilities for each. These tools give mobile game programmers an interface to the hardware just like other SDKs (Software Development Kits) such as the PS2 API (Application Programming Interface).


Defining the required skills for mobile game development can be a bit tricky as there is a current lack of standards for both hardware and software platforms. Moreover, some understanding of the ever-evolving hardware market is essential in making decisions related to the capabilities of handsets and which handsets to support. In July 2001, Ericsson, Motorola, Nokia and Siemens, founded the Mobile Games Interoperability Forum (MGIF) to define mobile games interoperability specifications and API in an effort to allow game developers to produce and deploy mobile games that can be distributed across multiple game servers and wireless networks, and played over many different mobile devices. The aim of the initiative is to specify a global standard and to develop certification procedures to encourage wide adoption of the standard. Nevertheless, as Eric Low explains in his article, Chaos in the Value Chain: Non-Traditional Paths to Market for Wireless Games, there are currently over 100 models of game-capable phones on the market and a myriad of development platforms.

Because the mobile environment is platform driven, the industry is seeing now, and can expect, in addition to J2ME and BREW, a much more advanced class of middleware than what the PC market typically sees. Companies such as Nokia, Siemens, Motorola, and Sony Ericsson will be the catalyst for bringing stakeholders -- that is, mobile phone manufacturers, distributors such as Verizon, Sprint, Cingular, etc., as well as the content developers or, in other words, essentially everyone in the value chain -- to a standard, promoting that standard among handset manufacturers, and providing the development communities with licensable middleware. The issue will undoubtedly become whether the stakeholders building the standard can accurately assess the real needs of the gaming consumer.

As is usually the Darwinian case, certain of the species have risen to the top. Today, the most common mobile game platforms are Java and BREW. Symbian, as Low further explains, a platform supported by Nokia, the market leader in handsets, has gained significantly more traction in Europe than the U.S. That trend may not last for long, however. Games developed on the Symbian platform that demonstrate the advanced capabilities of Nokia phones make Nokia a friend of the developer and may be an entry point for developers to reach carriers.

Key Skills and Resources for Mobile Game Programmers
As always, the best way to keep up to date with current job skill requirements is to look over job listings. Check the website of your favorite developer, this publication has ongoing job postings as well, or check the sites of recruiters such as GameRecruiter.com who tend to have dozens of listings of a wide variety. The following is a job listing posted on January 15, 2004 for a mobile game programmer:

Wanted: Game Programmer for Mobile Phones
Want to make BREW and J2ME games for current and future generation mobile phones? We are looking for a bright, enthusiastic, talented software programmer to join our experienced team of mobile phone game developers. Our ideal candidate is a self motivated team player, with strong Java and C/C++ skills (J2ME and BREW game development experience is a plus!). They should have client and server side experience, and a work ethic like a steel bear trap. The Game Engineer will be responsible for porting and programming (client and server side of) games on current and future generation mobile phones.
Java and J2ME: Invented by Sun Microsystems in 1995, Java technology lets devices of all kinds run different kinds of program. Today, Java technology is embedded in approximately 150 million mobile phones allowing the user to view and choose from a list of applications, games, and services. The application is then sent over the air to the handset, where it is installed and instantly available to use.

J2ME is a form of the Java language that is optimized for small devices such as mobile phones. J2ME is limited by comparison to desktop Java, but it significantly improves the ability of mobile phones to support games. While it is not the only interpreted language deployed on phones, it has become an industry standard backed by many of the big manufacturers and, therefore, knowledge thereof is becoming increasingly important.

BREW: Qualcomm’s BREW is not only a C/C++ API for the mobile phone platform, it is also a certification and distribution model for getting mobile phone applications out to your audience. While Java, at this point, is the more widely used platform, as it is also an open platform, it provides less developer support. Further, as there are many varieties of Java from which to choose, the code doesn’t always work when porting the game to multiple versions. However, Java returns more revenues to the developer. BREW, on the other hand, provides developers with more end-to-end support and billing functions. But with more support for developers comes a lower percentage of revenues back to the developer. Projections have more than 500 million BREW handsets in the market by 2008.

Symbian OS: To this point, the Symbian OS has been more popular in Europe, but this may be changing. According to the latest Canalys report over 2 million Symbian devices shipped in Q4 2003. In his article, Enabling Technologies for Mobile Gaming, Jouni Paavilainen explains that Symbian OS is becoming a standard operating system for "smartphones", as the device manufacturers supporting Symbian have taken decisive steps to ensure that the installed base of terminals with Symbian OS is as large as possible. To date, Symbian has been implemented or licensed by the majority of manufacturers, representing more than 70% of all cell phone makers.

Further, as Nokia’s N-Gage is based on the Symbian OS, this allows game developers to start developing games for Symbian phones and move on to N-Gage game projects smoothly because the underlying technology and development tools are similar. As with BREW, the programming language typically used for Symbian OS is C++.

OpenGL ES: Across the platform board, many game programming jobs require OpenGL experience and, in this regard, mobile games are no different. OpenGL ES brings advanced 2D/3D graphics capabilities to a wide variety of mobile devices, appliances and embedded displays. This standardized version of OpenGL for mobile platforms, OpenGL ES, is a low-level, lightweight API for advanced embedded graphics using well-defined subsets of OpenGL.

Mophun: While the need for experience with Mophun could currently be characterized as "low", this may be a platform to watch. Created by Synergix Interactive, Mophun is a software based gaming console for mobile devices. Sony Ericsson was the first manufacturer to integrate the Mophun games engine in its phones. For small developers, getting in on some of these niche markets, such as developing games for Mophun, could be a good idea. There are a few people out there who would love to see this on a resume.

Platform considerations and C++ knowledge aside, programming for mobile games requires additional skills. As Jason Lam, in his article Considerations for Mobile Game Development explains:

"In the mobile world where memory is expensive it is best to avoid using several objects unless truly necessary…This may sound easy, but trust me for those of you who are use to separating tasks into several objects and heavily rely on patterns will find reverting back to a more procedure way of development a challenging thing to do."

In a nutshell, due to the platform limitations, it is vitally important for programmers to be able to write efficient and compact code, and a good understanding of the language features (C/C++/Java) is valuable.

Key Skills for Mobile Game Artists
Do the skill sets for mobile game artists differ significantly from other platforms? What’s the difference between painting on a wall and painting on a stamp? Artists, nevertheless, will typically see the same skill sets required as on other games, with the one notable exception of a slight more emphasis on 2D skills.

Indeed, the technologies employed in creating mobile games from the art side are fairly straightforward. The most essential software application has been, and will continue to be, Photoshop. From there, programs such as Debabilizer for creating and matching image color palettes equal to or less than 256 colors are very important. In the next few years, Debabilizer will become less important as mobile devices continue to move toward hi-color displays, then true color. The only other 2D application that is regularly used is Paint Shop Pro but it tends to be more popular with programmers than artists.

Currently the mobile industry is really starting to see its first true 3D games, but the tools for those types of games are fairly limited. Eric Seiler of Monkeystone Games, developers and publishers of mobile games, including Red Faction for N-Gage, notes that everything 3D in that game was created with 3D Studio Max - levels, characters, etc. As 3DS Max is a popular package among almost all gaming platforms, but especially gaming consoles and the PC, it will inevitably gain popularity in the mobile arena as well. Competing programs such as Maya, Lightwave, and Softimage may also begin to make an appearance, but, Seiler predicts, 3DS Max will still be the dominant off-the-shelf 3D package for the next couple years.

A helpful skill, even for artists, is to have a basic understanding of scripting. In small teams, and as most in this arena are small, the artist often won't have access to a permanent tools programmer, therefore understanding macro scripts, or even writing your own, can make the workflow in Photoshop significantly faster, particularly when working with many small graphic files. It is much the same for 3DS Max – the ability to write scripts effectively can save the artist hours or even days of work.

Another helpful tool is to have a good image viewer. Seiler prefers ACDsee, which is capable of viewing just about any non-proprietary image format, but there are many such utilities on the market.

Given their size, mobile games will probably always have the most limitations in terms of hardware. In PC and console games having a 10,000 polygon model is often okay, but, for instance, as Seiler explains, the character models in Red Faction had to be limited to about 150 polygons. It doesn't matter how good the model looks, if it drops the game down to 5 frames per second, it has to go. Seiler advises that knowing how to do more with less is infinitely more important than knowing the latest and greatest in 3D acceleration.

Lastly, the most important thing for an artist in the mobile gaming world is to be flexible, and be willing to be the jack-of-all trades. Specialization will continue to grow, but, for now, the artist has to be willing to do anything and everything, from creating pixel fonts to animating polygon models.

Key Skills for Mobile Game Designers
Designers for mobile games face some rather unique challenges. In December 2003, at the Second Annual Conference on Mobile and Ubiquitous Multimedia in Sweden, keynote speaker Ernest Adams addressed "Practical Considerations of Mobile Game Design". This lecture addressed some of the practical considerations surrounding mobile gaming from the perspective of the game designer. Mobile games have a number of advantages and limitations not found in other forms of video gaming. In addition to the usual issues surrounding the small size of the device, and the features offered by networking, the designer must take into consideration such contingencies as the personal safety and security of the user, and the circumstances in which the game may be played (on foot, in a vehicle, etc.). Playing games on a mobile phone, it would seem, entail more than the occasional danger of spilling Mountain Dew on the couch. While seemingly mundane, these and other factors influence the designer's creative choices, and it is better to understand them in advance than to create an innovative game, which proves to be unplayable or unsalable for practical reasons.

Jess Dominguez, also of Monkeystone, summarizes that the reality of shorter shelf lives and smaller budgets for mobile games necessitates making important trade-offs in game design, and devising simpler yet creative gameplay elements that still result in a fun game.

As it with all good game designers, regardless of platform, scheduling and good communication skills remain a must. Game designers must be able to create tight schedules with a quick turnaround that take into account the maximum number of supported platforms, as well as the short-term foreseeable need for ports.

The mobile industry moves even more quickly than the PC industry. This fast pace, combined with additional lag times for contract negotiations with providers, BREW (or equivalent) provider-based testing, lower development budgets, and an emerging lag in game deployment by providers, all serves to pressure development teams to reduce their time to market. For example, Don McClure of Digital Element, says his company develops BREW and J2ME games from concept to completion in three months or less. By utilizing a global hybrid development approach, employing both full time and permanent overseas programmers – which is why he suggests that game designers also be familiar with languages such as Russian, Chinese and Hindi – as well as veteran Western-based development talent, McClure says he is able to achieve high production value with reasonable costs and schedules.

The designer must also consider the most appropriate means of generating revenue from a small game. As Low suggests in his article on how to make money from mobile games, design consideration examples include games that include updates or a global high score, games that incorporate on-going events, such as sports-based games, and games where the players can download add-ons are all examples. Developers may also consider incorporating "micropayment" elements to their game. For example, for 50 cents a gamer could download a tire upgrade in a racing game.

CONCLUSION

As Jess Dominguez of Monkeystone notes, in many ways, mobile game development is at the other end of the spectrum from console game development. Budgets are smaller, shelf lives are shorter, development cycles are reduced, team sizes are smaller, memory, processor and power are substantially lower, screen sizes and resolution are different, and the number of target mobile device platforms is ever expanding.

Perhaps more than any other area of game industry, whether programmer, artist, or designer, these intrinsic characteristics of mobile game development require jack-of-all-trades abilities among the team members. Mobile game developers will undoubtedly be called upon to touch the various subsystems of the game, and may find themselves working on the menu system, game AI, game physics, sound, and more.

Finally, the most important skills to add to your skill set if you want to make mobile games? Flexibility and a willingness to work on all aspects of the game.

RESOURCES

With the proliferation of mobile devices it is not uncommon for mobile game developers to be forced to create a different version of their game, customized for each target phone model, to accommodate differences in memory, processor, screen, and controller specifications, not to mention varying carrier guidelines. Porting from device to device is a fact of mobile game development life, and keeping up with the rapidly evolving device landscape is essential. Below are resources to help you keep abreast of current and upcoming mobile game trends and requirements. The upcoming installments in this series will cover key skills and resources for MMOG development and consoles, as well as those skills game companies will be looking for from its marketing, PR, and finance specialists. What you need to know and how you go about acquiring it, what the big guns are looking for, and how employers will train current employees to assume new responsibilities will also be covered, so stay tuned.

Forum Nokia - Mobile Games
The Nokia website offers an extensive amount of mobile game development resources including a "Step-by-Step Guide", "Introduction to Mobile Game Development", and "Introduction to Mobile Games Business". If you’re new to mobile games or looking for a nice overview of the business, this would be an excellent first stop.

Javaworld.com
Definitely check out the nicely done "Develop State-of-the-Art Mobile Games: Trends in Mobile Games and a Survey of Related J2ME APIs", a detailed article by Michael Juntao Yuan for JavaWorld.com.

Qualcomm Developer Resources
Qualcomm has a notable amount of resources readily available online on how to become a BREW developer.

Practical Java Game Programming
Upcoming book from Charles River Media by Dustin Clingman, Shawn Kendall, and Syrus Mesdaghi. Should be available April 2004.

More and more J2ME handsets are being deployed world wide by all major cellular carriers and are supported by mobile manufacturers like Nokia, Siemens, Motorola and Sony Ericsson. There will be if not already a huge demand in mobile development, one of these key areas undoubtly is mobile gaming.

With that being said this tutorial will give you a brief introduction in developing games using J2ME (Java MicroEdition), visit Sun MicroSystems for further details at http://wireless.java.sun.com.

What this Tutorial Is
Programming Approach

Hurdles/limitations in mobile development

Some solutions to improve performance

What Development Tools to Use

How to Market Your Game

Useful Links - News, Multiplayer, Bluetooth
Programming Approach

As everyone knows Java is an object-orientated language; thus, coders program with an OO approach and for the more advanced coders design patterns are put to use. A simple a hello program can easily bloom in to a dozen or so classes, of course in doing this it provides maintainability and extensibility. This is normally a good thing.


In the mobile world where memory is expensive it is best to avoid using several objects unless truly necessary. More about memory constraints will be explained later. This may sound easy, but trust me for those of you who are use to separating tasks into several objects and heavily rely on patterns will find reverting back to a more procedure way of development a challenging thing to do. However, you do not want to write one big giant super class that does everything, rather write your game in the simplest manner that is comfortable to you. After you should merge classes that do not provide much gain in functionality.

Memory Limitations

In general, there are three types of memory you need to concern yourself with, working memory, storage memory and application memory. Working memory is the memory where the game is executed during runtime. This is an obvisous concern because if the game is too big an out of memory error will occur.

When programming games you will need to store such things as high scores, user options, and other game state data. This is called the storage memory.

The game itself takes up memory storage as well. This is usually the same as storage memory, it is sometimes referred to as the application memory. Application memory takes into account the memory storage needed to hold all the games and applications.

Now knowing what memory constraints there are you need to code your game accordingly. You should consult the manufacturers specification for the mobile handsets you are planning to deploy your game to. Check for the maximum size a game can be during runtime and memory storage available.

Screen Limitation

One of the biggest problems are the displays themselves. Displays on J2ME enabled mobile handsets vary not only from manufacturer to manufacturer; but also from model to model produced by the same manufacturer. Things to consider when adjusting your game to the display are screen size, frame rate and color. You will have to make a decision which handsets you want to support. It is ideal to write the game generically then make alternate versions for certain handsets. Once again you should consult the manufacturers specification so you can make the appropriate adjustments.

Some Solutions to Improve Performance

As mentioned several times before you first need to decide which phones you want to support. This is very important because you if decide not to support the lower model phones you may not have to concern yourself with very limited memory constrained handsets with limited color and screen size. However, the reality is most cellular phones on the market purchased by regular consumers will be the lower model handsets. As well don't forget most promotions that offer discounts or even free handset give a ways usually involve only the lower model handsets.

Now that you've decided which models to support, what can you do within the code to optimize your game? First of all, use the least amount of classes, stick to shorter variable, method and class names. In general, keep it simple for example avoid using unnecessary protocols such as SOAP, granted its better to use a standard protocol it will increase your overhead because of all the extra layer of processing and the libraries themselves will take extra memory. Try to reuse objects rather then instantiating new objects over and over again. If the game is a network game then reduce calls to the server, this is especially so when obtaining resources such as graphics, maps and levels. Try to obtain all your resources in one request at the begining rather then several requests to reduce the chance of latency problems to occur. Optimize the graphics and merge the graphics into one sheet instead of spreading them out into several seperate graphics. Once you have completed your final version you should run an obfuscator against your code not only to reduce the chances of someone re-engineering you hard work but it will significantly reduce the size of the final jar file.

What Development Tools to Use

First get the J2ME Wireless Development Kit from Sun Microsystems, http://wireless.java.sun.com. If you are looking for an IDE, there are some free ones available:
Sun One Studio ME - http://wwws.sun.com/software/sundev/jde/index.html
JBuilder with the Mobile Set - http://www.borland.com
White Board SDK - http://www.zucotto.com

As well you should visit the individual manufacturers for their customize SDKs for their own mobile handsets.:
Motorola - http://kb.motorola.metrowerks.com/motorola/pcsHome.do
Nokia - http://forum.nokia.com
Siemens - http://www.siemens-mobile.com
SonyEricsson - http://www.sonyericsson.com
RIM - http://www.blackberry.net/developers/index.shtml

How to Market Your Game

Here is an excellent article at the Sun website about making money in the mobile world, http://wireless.java.sun.com/deploy/revenue.html. Now that you've read the article where do you go to get help to market your games. You have 4 choices, to approach the carriers themselves, established gaming companies that provide partnerships to market your game, a wireless agency or aggregator, list below are a few of them you can start with. However, if you are a single independant developer it is best if you approach an aggregator or agency. Most carriers and manufacturers prefer to deal with established gaming companies, aggregators and agencies rather then deal with thousands and thousands of independant developers.

Summary
Well there you go that was a brief overview about developing mobile games using J2ME, some directions where to start and where to go. I will be releasing more in depth tutorials on J2ME Development in the near future. Please email me for any suggestions, questions or flames. If you do flame me please let it be constructive flame.

Configurations
A configuration specifies a JVM and some set of core APIs for a specific family of devices. Currently there are two: the Connected Device Configuration (CDC) and the Connected, Limited Device Configuration (CLDC).

Connected Device Configuration
A connected device has, at a minimum, 512KB of read-only memory (ROM), 256KB of random access memory (RAM), and some kind of network connection. The CDC is designed for devices like television set-top boxes, car navigation systems, and high end PDAs. The CDC specifies that a full JVM (as defined in the Java Virtual Machine Specification, 2nd edition) must be supported.

The configurations and profiles of J2ME are generally described in terms of their memory capacity. Usually a minimum amount of ROM and RAM is specified. For small devices, it makes sense to think in terms of volatile and non-volatile memory. The non-volatile memory is capable of keeping its contents intact as the device is turned on and off. ROM is one type, but non-volatile memory could also be flash memory or battery-backed RAM. Volatile memory is essentially workspace and does not maintain its contents when the device is turned off.

The CDC is being developed under the Java Community Process. For more information on the CDC, see http://java.sun.com/products/cdc/. A Linux reference implementation is available.

The CDC is the basis of the Personal Profile stack. The Personal Profile is the next generation of PersonalJava, a Java application environment that is similar to JDK 1.1.8.

Connected, Limited Device Configuration
CLDC is the configuration that interests us, because it encompasses mobile phones, pagers, PDAs, and other devices of similar size. CLDC is aimed at smaller devices than the CDC. The name is a little misleading; really, the CLDC is designed for a small device with a limited network connection—"Limited Connection Device Configuration" might have been more accurate.

The CLDC is designed for devices with 160KB to 512KB of memory available for the Java platform. If you've ever watched J2SE gobble up tens of megabytes of memory on your desktop computer, you'll appreciate the challenge of J2ME. The "limited connection" simply refers to a network connection that is intermittent and probably not very fast. (Most mobile telephones, for example, typically achieve data rates of 9.6Kbps.) Between the small screen size, limited memory, and slow network connection, applications designed in the CLDC space should be very sparing with the use of the network connection.

The CLDC is based around a small JVM called the KVM. Its name comes from the fact that it is a JVM whose size is measured in kilobytes rather than megabytes. While the CLDC is a specifications document, the KVM refers to a specific piece of software. [1] Because of its small size, the KVM can't do everything a JVM does in the J2SE world.

Native methods cannot be added at runtime. All native functionality is built into the KVM.

The KVM only includes a subset of the standard bytecode verifier. This means that the task of verifying classes is split between the CLDC device and some external mechanism. This has serious security implications, as we'll discuss later.

You can find more information at the CLDC home page, http://java.sun.com/products/cldc/. Most deployed devices implement CLDC 1.0, but CLDC 1.1 is almost complete as this is written. CLDC 1.1 includes enhancements to CLDC 1.0, including support for floating-point data types.

Platform Standardization
Given the profusion of configurations, profiles, and especially optional APIs, how do you know what APIs are likely to be available on typical devices? Sun's answer to this question is JSR 185 (http://jcp.org/jsr/detail/185.jsp), impressively titled Java Technology for the Wireless Industry. This specification aims to standardize software stacks to bring coherence to the J2ME world.

In the next generation of J2ME, a concept called Building Blocks is supposed to replace configurations and profiles. A Building Block is just some subset of a J2SE API. For example, one Building Block might be created from a subset of the J2SE java.io package. Conceptually, a Building Block represents a smaller chunk of information than a configuration. Profiles, then, will be built on top of a set of Building Blocks rather than a configuration.

The definition of Building Blocks is a JSR, which is briefly described here: http://jcp.org/jsr/detail/68.jsp. Progress on JSR 68 has been extremely slow since its creation in June 2000. I suggest keeping your eyes on JSR 185 instead.

[1]The KVM was originally part of the Spotless system, a Sun research project. See http://www.sun.com/research/spotless/.

A profile is layered on top of a configuration (and someday, perhaps, on Building Blocks), adding the APIs and specifications necessary to develop applications for a specific family of devices.

Current Profiles
Several different profiles are being developed under the Java Community Process. The Foundation Profile is a specification for devices that can support a rich networked J2ME environment. It does not support a user interface; other profiles can be layered on top of the Foundation Profile to add user interface support and other functionality.

Layered on top of the Foundation Profile are the Personal Basis Profile and the Personal Profile. The combination of CDC + Foundation Profile + Personal Basis Profile + Personal Profile is designed as the next generation of the PersonalJava application runtime environment (see http://java.sun.com/products/personaljava/). As such, the Personal Profile has the specific goal of backward compatibility with previous versions of PersonalJava.

The PDA Profile (PDAP), which is built on CLDC, is designed for palmtop devices with a minimum of 512KB combined ROM and RAM (and a maximum of 16MB). It sits midway between the Mobile Information Device Profile (MIDP) and the Personal Profile. It includes an application model based on MIDlets but uses a subset of the J2SE Abstract Windowing Toolkit (AWT) for graphic user interface. Although the PDAP specification is nearly finished, to my knowledge no hardware manufacturer has announced that it will be implementing PDAP. The J2ME world currently is covered by MIDP on the small end and Personal Profile on the higher end.

Mobile Information Device Profile
The focus of this book is the Mobile Information Device Profile (MIDP). According to the specification, a Mobile Information Device has the following characteristics:

128KB of non-volatile memory for the MIDP implementation

32KB of volatile memory for the runtime heap

8KB of non-volatile memory for persistent data

A screen of at least 96 × 54 pixels

Some capacity for input, either by keypad, keyboard, or touch screen

Two-way network connection, possibly intermittent

Try to imagine a device that might be a MIDP device: mobile telephones and advanced pagers are right in the groove, but entry-level PDAs could also fit this description.

More information about MIDP, including a link to the official specification document, is at http://java.sun.com/products/midp/.

This book covers both MIDP 1.0 and MIDP 2.0. MIDP 2.0 features numerous enhancements, including support for multimedia, a new game user interface API, support for HTTPS connection, and other features. It is fully backward compatible with MIDP 1.0. I will indicate features that are specific to MIDP 2.0 throughout the rest of the book.

Given the spectrum of configurations and profiles, why is this book about MIDP? First, MIDP comes at a critical time, a time when MIDP devices, like mobile phones, are an exploding market. Simultaneously, MIDP devices are achieving the kind of processing power, memory consumption, and Internet connectivity that makes them an attractive platform for distributed applications. MIDP 1.0 is already deployed on millions of handsets all over the world, and MIDP 2.0 holds much promise for the future.

Second, of course, MIDP is the first J2ME profile that is ready for prime time. If you read into the next chapter, you can write MIDP applications today.

Portability
The advantage of using Java over using other tools for small device application development is portability. You could write device applications with C or C++, but the result would be specific to a single platform. An application written using the MIDP APIs will be directly portable to any MIDP device.

If you've been following Java's development for any time, this should sound familiar. It's the same "Write Once, Run Anywhere" (WORA) mantra that Sun's been repeating since 1995. Unfortunately, WORA is a bit of a four-letter word for developers who struggled with cross-platform issues in JDK 1.0 and JDK 1.1 (particularly the browser implementations). While Java's cross-platform capabilities in Java 2 are generally successful, WORA still has the taint of an unfulfilled promise.

Does MIDP deliver painless cross-platform functionality? Yes. There will always be platform-specific bugs in MIDP implementations, but I believe MIDP works as advertised because it is so much smaller than desktop Java. Less code means fewer bugs when porting to multiple platforms. Most of the cross-platform incompatibilities of JDK 1.0 and JDK 1.1 were caused by the nightmare of trying to fit disparate windowing systems into the AWT's peer-based component architecture. MIDP has nothing approaching the complexity of AWT, which means there's an excellent possibility that MIDP applications will seamlessly run on multiple platforms right out of the starting gate. Furthermore, while the JDK 1.0 test suite only included a few dozen tests, the MIDP compatibility test suite includes several thousand tests.

Security
A second compelling reason for using Java for small device development is security. Java is well known for its ability to safely run downloaded code like applets. This is a perfect fit—it's easy to imagine nifty applications dynamically downloading to your mobile phone.

But it's not quite such a rosy picture. For one thing, the KVM used in the CLDC only implements a partial bytecode verifier, which means that part of the important task of bytecode verification is performed off the MIDP device.

Second, the CLDC does not allow for application-defined classloaders. This means that any kind of dynamic application delivery is dependent on device-specific mechanisms. As you'll see, application deployment is not specifically defined in the CLDC or MIDP.

MIDP applications do offer one important security promise: they can never escape from the confines of the KVM. This means that, barring bugs, a MIDP application will never be able to write to device memory that doesn't belong to the KVM. A MIDP application will never mess up another application on the same device or the device OS itself. [2] This is the killer feature of MIDP. It allows manufacturers and carriers to open up application development to the world, more or less free from certification and verification programs, without the fear that rogue coders will write applications that crash phones.

In MIDP 2.0, MIDlet suites can be cryptographically signed, then verified on the device, which gives users some security about executing downloaded code. A new permissions architecture also allows the user to deny untrusted code access to certain API features. For example, if you install a suspicious-looking MIDlet suite on your phone, you can prevent it from making network connections.

[2]A MIDP application could conceivably launch a denial-of-service attack, (i.e., sucking up all the processor's time or bringing the device OS to a standstill). It's widely acknowledged that there's not much defense against denial-of-service attacks. Applications and applets in J2SE suffer from the same vulnerability.

Tooling Up
MIDlets are developed on regular desktop computers, although the MIDlet itself is designed to run on a small device. To develop MIDlets, you'll need some kind of development kit, either from Sun or another vendor. Remember, MIDP is only a specification; vendors are free to develop their own implementations.

The world is full of MIDlet development tools if you know where to look. Furthermore, many of these tools are freely available.

The bare bones set of tools is Sun's MIDP reference implementation. This includes the preverify tool (more on this later), a MIDP device emulator, source code, and documentation. You can download the MIDP reference implementation by following the links from http://java.sun.com/products/midp/. However, I don't recommend using the reference implementation unless you really enjoy being in the middle of the gritty details of building and packaging MIDlets. (You should also investigate the reference implementation if you are interested in porting the MIDP runtime to a new device or platform.)

A much better tool for beginners is Sun's J2ME Wireless Toolkit, available from http://java.sun.com/products/j2mewtoolkit/. The J2ME Wireless Toolkit (or J2MEWTK, as it's affectionately known) includes a GUI tool that automates some of the tedious details of building and packaging MIDlets, providing a simple path from source code to running MIDlets. At the same time, the J2ME Wireless Toolkit is a relatively lightweight solution, almost a miniature IDE, not something that will choke your machine.

Larger IDEs are available in abundance, from device manufacturers, wireless carriers, and IDE vendors, including the following:

Borland JBuilder MobileSet: http://www.borland.com/jbuilder/mobileset/

IBM WebSphere Studio Device Developer: http://www-3.ibm.com/software/pervasive/products/wsdd/

Metrowerks CodeWarrior Wireless Studio: http://www.metrowerks.com/MW/Develop/Wi ... efault.htm

Research In Motion BlackBerry Java Development Environment: http://www.blackberry.net/developers/na ... load.shtml

Sun ONE Studio, Mobile Edition: http://wwws.sun.com/software/sundev/jde ... tures.html

Zucotto Wireless WHITEboard SDK: http://www.zucotto.com/products/wb/whiteboard.html

You can use whatever development kit you wish. I suggest you start with the J2ME Wireless Toolkit, which is easy to use and authoritative. I'll be using the J2ME Wireless Toolkit throughout the rest of the book. Other development environments generally use the J2ME Wireless Toolkit as a plugin anyhow, so your experiences are likely to be similar no matter what tool you use. You'll notice details about the development environment most in this chapter, where I'll go into detail about the build tools and the emulators. For much of the remainder of this book, I'll be describing the MIDP APIs, so it won't really matter which development kit you use.

The emergence of Java, an application programming language and runtime environment developed by Sun Microsystems, revolutionized software development starting from the mid-1990s. The core idea behind the design of Java language was the capability to make the runtime environment available on as many different computing environments as possible and thus maximize the number of places where Java programs could be used. Now a special version of Java is aiming at the same goal in the mobile world and is widely supported by handset manufacturers around the world.

Java 2 Platform Micro Edition, J2ME, is a version of Java 2 technology that is optimized for use with small devices such as PDAs and cell phones.41 It has millions of potential developers because the larger-scale versions of the language and runtime environments are extensively used in both server and application programming.

The J2ME applications, properly called MIDlets, do not run natively in mobile devices. This means that the device must be provided with a special code interpreter, Java Virtual Machine, for executing MIDlets. Consequently, software written with Java needs more resources than the native applications that do not need an interpreter to run.

Because of the memory limitations of low-end cell phones, the permitted application size is relatively small. In some cases, the maximum application size is only a few dozen kilobytes. Newer handsets allow larger Java applications.

There are two ways to deliver mobile Java applications. The most common way is to download over the air (OTA) directly to the cell phone. Another option is to first download the MIDlet to a desktop PC and then install it to a phone via a serial cable, infrared, or Bluetooth connection.

Carriers encourage Java OTA downloads because they are able to generate revenue from the increased airtime. Additionally, they charge the third-party content providers for the billing of the transaction. In many cases, carriers sign revenue-sharing deals with game publishers and developers to generate more data traffic and to promote OTA download as a delivery channel.

Infra Red Connectivity
Most recent mobile phones have infra-red connectivity for data sharing with other phones or PCs. This connectivity is not really good for gaming because of its line of connectiviy should not be disturbed. No good player would enjoy this type of connectivity without moving his hands.

Bluetooth multiplayer games
Mobiles are connected through a wireless protocol called Bluetooth using special hardware. The games are designed to communicate with each other through this protocol to share the gaming information. The basic restriction is that both the users have to be within a definite distance to get connected. In this type of connection the game mode can only be one to one or two players more like a peer to peer connection between two PCs.

GPRS multiplayer game
In today’s gaming world, massive multiplayer is most loved by gamers. GPRS connection which is common among GSM mobile phones can be used to share the data globally. Developers can connect a mass number of mobile games with a single server and share data among the players. This is the latest craze in mobile game development. Some developers have even achieved cross platform games. A player with a mobile can play against another with a pc. Today the mobile multiplayer game development is still in turn based games and small RPG games. Since most of the counties have a weak GPRS speed in their carriers. In these types of games, the game communicates with a global server which acts like a router between the mobile phones.

3G and WiFi
3G and WiFi are just emerging in most of the countries, and has a good speed which is good for gaming. WiFi connectivity can only be used for a intra-networked multiplayer game.

Global multiplayer mobile games using GPRS connection
Mobile phones are no more used for just making calls and sending messages. It has become a valuable source for entertainment on the move. Creating multiplayer games for mobile using Bluetooth has not created a big craze with mobile gamers, so moving to a global multiplayer game using GPRS which says play from anywhere and with anybody around the world, is going to hit a big market on entertainment industry soon. This idea has just been implemented by some big manufacturers. The idea of going with their option for most multiplayer mobile game developers is a bit unimaginable, because of the cost they charge for each game to interact with their server. This article explains about how to create a great multiplayer game for mobile platform using GPRS.

Requirements:
1. A good web hosting server with a strong database server. 2. A GPRS service that allow http connections. 3. A finished game ready to go globally multiplayer. 4. A bit Server side scripting knowledge. This is all that are required to develop a global multiplayer mobile game using GPRS connection.

The game server:
The total concept of the game server is to build it like a router which gets data from any client and redirects to the right destination client. Our game server is going to do the same work.

Server client architecture:
The client SDK, which we are going to develop later, should first post a login username details and wait for the response of the server. The server should add the client details to the queue table and should respond back with a game Id which is unique for each game played. Then the client should wait for the opponents. Till then the client should post for the game status. Whether the game has started or still has to wait for another opponent. Now when the other client logs in, the server responds with the same game id. And the status of the game is changed to “started”. Now for reference the game id and the details of the game like who played when and who started will be stored in a different table. Now both the clients should be removed from queue table and taken to the pairs table which holds the game id and client ids. Now the server allots ip address like on a network. Both the clients should then get their ips from the server. Developers should write a routine which creates ips randomly. Ip here we call is not the actual one which we use in networking. It is similar to a GUID (16 byte value) so that we don’t have to check for uniqueness in the game. Once all these transactions are over, the clients start to exchange there usernames and details to display with whom the player is playing with. These transactions are handled in a different table where each entry represents a data transfer between clients. The details “who has sent to whom” and “what” will be stored there. Once all transaction has been taken before the game, both the clients transfer the game data to the other client. In SMNA we use acknowledgment make sure the other client has read the previous transaction. Unless a client acknowledges the message the other client will wait for the next transaction to take place. This is to avoid loss of data. To make it a complete featured game server we need to implement a high score list on the server. This is all what we do in SMNA. In this server script we have developed separate url script for every requests and posts, so that the load on the server gets spread during the game.

The Multiplayer game SDK development:
Coming to the development of SDK, the developer has almost completed most part of the project. Now having it as SDK will be more useful in the future, so that any game can be made multiplayer easily. The SDK should contain classes and functions like this, login(userdetails), checkForOpponent(), getGameID(), getOpponentName(), getIP(), sendData(), readData(). All these functions should use http post and read the server’s response back and feed the game routine with the information. Additional features like posting high scores and adding communities and rooms are very essential for the game server to reach the large market.

SMNA:
Smackall.com, a mobile game development company with a passion on multiplayer SDK development has developed a game server. The game server and SDK both are for sale. The game server is coded in PHP and J2ME. This is a cross platform game server, where people from a website or PC connected to internet can compete with a person playing on mobile. It has a good high score database and a community management system to review on the game.

Chennai, India - Smackall, the leader in mobile entertainment and Custom mobile game developer, announced that hundreds of thousands of players can expect to be able to connect through "FIND 4," a massively multi-player online game (MMOG) available on selected Java technology-enabled mobile phones through the SMNA Mobile service.

Rules

The game is played on a board with 7 columns and 6 rows, which is placed in a vertical position. The players have 21 discs each, distinguished by color. The players take turns in dropping discs in one of the non-full columns. The disc then occupies the lowest unoccupied square on that column. A player wins by placing four of their own discs consecutively in a line (row, column or diagonal), which ends the game. The game ends in a draw if the board is filled completely without any player winning.

Strategy and tactics

Beginners will often overlook a simple threat to connect four discs; it is therefore important to always check all vertical, horizontal and diagonal lines before making a move. In more advanced play, one aims at forcing a win by making two threats simultaneously; conversely, one should prevent the opponent from doing so.

As a general rule of thumb, discs played in the center columns are more valuable than border column discs, because they participate in more potential four-disc lines (and accordingly limit the opponent's opportunities).

Among good players, the short term goal is to connect three discs, thereby preventing the opponent from playing in a certain column and creating a "threat" in that column. A player who manages to create two threats immediately on top of each other wins directly.

Towards the end, the game then often turns into a complex counting match: both players try to win by forcing the other to play a certain column. In these situations, it is useful to realize that, if it's your move, then after filling an even number of places, it's still your move. Every column has an even number of places.

To download sample game, go to Global Multiplayer Mobile Games SDK. For more on the Smackall SMNA Mobile service, please visit .

About Smackall

Smackall is the world leader in mobile game developer. Smackall is dedicated to enhancing people’s lives and productivity by providing easy-to-use and secure products like mobile games and mobile applications.

Generating sudoku puzzle using low CPU power: Puzzle generator completely depends on the solver technique in terms of efficiency. So we are half the way through. for solver logic see here . The generator logic is bit easy. Usually these are two common ways to generate Sudoku puzzle.
One: filling an empty grip partially with random numbers in random cells and trying to solve it, if there is a unique solution, the puzzle is ready. Else add another number and try solving. if this fails to produce unique solution puzzle try again with filling a different random numbers in random cells. This method is not suitable for mobile phones, coz this takes along time.
Two: take a filled solution grid and hide some cells now try solving it, if more than one solution is possible then hide more cells, if there is a unique solution then stop hiding more cells. This method is simple and faster but requires some code on generating filled solution grid. To generate a filled solution grid you have to use some matrix theorem rather than filling a grid by random numbers. This is the most deciding part of the methods we have used. We have crossed all major tasks now. Your code efficiency and CPU usage depends on this piece of code. I have tried two extremes of coding in this part which results to generation time of 10 mins and the simplest (the on I have implemented now) which takes at the max 3 seconds on a 35 MHz processor.

the rest depends on you response.
Mobile Game Developer

Writing Sudoku solver is not a great task, but when it comes to writing it for a mobile phone it is really hard to choose which algorithm to use. We were in a bad situation to decide whether to write 1000s of lines and reduce the CPU power conception, or to write the most compact code. Considering a mobile phone which commonly has just 100 -200 MHz CPU and 100 kb memory, we finally decided to code in hardest way to solve sudoku which most programmers do not prefer. “Solving Sudoku by logic”, it is very similar how a human thinks when solving sudoku. We have implemented 4 methods to solve any hard puzzle. Finally we decided to start this forum to share how we made it.

Prepare the Possibility grid: first step we have to do is create possibility grid of 9x9x9 array for Booleans which represents the possible no’s that can occur in each cell. The [0][0][0] Boolean represents the possibility of occurrence of number 1 in the cell[0][0]. This possibility grid can be generated with some simple steps. Fill all cells with all Booleans, true. Now for each value in the puzzle, remove the other possible Booleans in the corresponding cell in the possibility grid, i.e. the only possibility should be the no in the possibility grid.

Step 1: Now see each row if there is a particular number which occurs only once. Then the only possibility for that number to occur in the row is that cell. So you can remove the possibilities of the occurrence of this number the other columns. Do this column wise and each block (3x3)

Check if all the cells have only one possible value then you have successfully solved the puzzle. If not you will have to implement the next method.

Step 2: Now you have a better possibility grid. See if a particular row in the possibility grid has a number occurring only in a particular block. Then remove the possibility of that number in the other cells of the block. Repeat this for columns. See in a particular row of a block if any number occurs only in a particular row or column. If so, eliminate the possibility of occurrence of that number outside the block in that row or column. Follow step 1 every time you effectively use this step. This simplifies our possibility grid for a reasonable extend.

Check if all the cells have only one possible value then you have successfully solved the puzzle. If not you will have to implement the next method.

Step 3: see if a two numbers combination occurs only twice in a particular row and both numbers occur only in these two cells, and then these cells must contain only these two numbers. You can remove the other possibilities of occurrence of other numbers in these cells. Follow step 1, step 2 and again step 1 every time you effectively use this step.

Check if all the cells have only one possible value then you have successfully solved the puzzle. If not you will have to implement the next method.

Step 4: if the number of elements in the union of N cells in a row is equal to N, then you can remove the numbers in the union from all other cells in the row. The N can vary from 3 to 8. Apply this for columns and blocks also. Follow step 1, step 3, step 1, step 2, and step1 every time you effectively use this step.

Main loop: Now repeat these steps again and again until you get a unique solution. Most hard and Moderate puzzles are solved in the first loop itself, some complicated puzzles may have to go for further repeating all these steps.

The looping which is recommended at the end of each step is really effective on reducing CPU usage. If these inner looping is not used, the main loop has to go for more than 10 looping.


Mobile Game Developer