Secrets of the Wireless Elite: Mobile Applications Need Scripting Too!
by: John PapageorgeMobile Apps Developer Tom Park Imparts His Wisdom
Mobile game developer Tom Park believes that scripting for wireless devices is important for proficiency sake. And with the need to scale mobile applications across so many different platforms, proficiency is everything. Read Park's thoughts on scripting, as well as his ideas on wireless application development's future.
Meet mobile device application developer Tom Park. He designed his first game project 10 years ago, which was a series of 3D games with model-building multimedia tutorials published by Revell-Monogram. After a stint at Turner Interactive, Park moved to California to work on titles from the Star Wars and Sims franchises. Last year, Park left Electronic Arts (EA) to focus on creating mobile applications on his own.
Because Park dives deeply into his endeavors, he knows a thing or two about what does and doesn't work for developing mobile games. His business savvy, for its part, helps him make smart development decisions. Considering all that, we can benefit from Park's experience.
The Mobile Gamer's Toolkit
In his development toolkit, Park uses the IBM WebSphere Studio Device Developer (see Resources), which he finds blazingly fast for Java development. "I also use Sun's JDK (Java Developer Kit) and WTK (Wireless Took Kit) command line tools, and various OEM SDKs."
While he was working with Sun Microsystems' JDK, Park realized that JAR files obfuscated with the Retroguard obfuscator didn't work well on certain phones, so he switched to SourceForge's Proguard. "As a bonus, [Proguard] seems to compress a little better than Retroguard," he says.
As for Qualcomm's BREW initiative, the money-making game technology for Verizon phones, Park uses the standard tools: Microsoft Visual C++, ARM RVCT (RealView Compilation Tools), and Qualcomm's BREW SDK and tools.
When Park needs to put on his artist's hat for mobile development, he mainly uses Adobe Photoshop, but he also brings in Jasc's Paintshop Pro and Cosmigo Pro Motion. "I think one of [the two] actually uses Deluxe Paint, running in a PC emulator on the Mac because it won't run on the latest versions of Windows anymore," he says.
Park's Secret Weapon: Scripting
For creating mobile applications, scripting represents Park's secret weapon. "It sounds like an odd thing to do on small wireless devices, but I actually use a simple scripting engine," he says. "An app-specific domain language enables quick iterations on design and eases porting across devices. I worked on the scripted AI (artificial intelligence) engine on the Sims franchise at Electronic Arts, and saw how this technology enabled a profitable business model. There's no way that EA could have cranked out so many expansion packs so quickly and cheaply if it weren't for the scripting tools." Park continues, "If I don't make a title scriptable, then at least I make it extensively data-driven. Once you get used to writing code that way, you can be proficient at that level of abstraction, but it could be a challenge to those who aren't used to it."
What Every Wireless Developer Should Know
Park says that developing smart client software helps avoid many potential headaches. As certification costs and delays increase, deploying a new build becomes very expensive, he says. "It's best to build smart, scriptable, data- and content-driven client software that can accommodate upgrades via your server," Park says. "Deliver the client with a complete cache of content so it can operate offline, but allow it to download updates as necessary when it is online."
Park contends that while wireless application development differs little from other application development, the market is changing quickly. "Get your product to market within a couple months, while continuing to use your best development processes. Speed to market is especially important right now because the market is still young. When the market is more mature, you can develop heavier products."
Park contends that the wireless space is already fragmented. "Don't try to do it all," he insists. "Concentrate on an area you know and do it extremely well. There has been a lot of sloppy wireless software out there, so we have to overcome the image of unpolished work. It's a common platitude, but aim to be the best in your category."
As for testing, he says it's worthwhile to build testing infrastructure, such as automated test harnesses, into applications targeted for widespread deployment. When you consider that failing a test certification can set back your time to market by two to three weeks or more, the opportunity cost of failure could be huge, he says. Park advises that you create a process that makes application testing easy.
What Every Wireless Developer Should Avoid
Park dons his business hat when he encourages emerging wireless development companies to avoid growing too quickly. While it's best to finish products sooner rather than later, he advises you to make sure to stay in business. "Wireless developers will burn out quickly if they attempt Amazon.com-type growth," he says.
The Challenges Every Wireless Developer Faces
Park believes that testing and building for a plethora of devices represents the main challenge for mobile device developers. "Deploying an app to multiple operators in several countries might mean testing the app in over a hundred configurations," he says. "This requires disciplined development processes during the whole lifecycle of the app. Again, everyone should be using all the same development processes for wireless that they'd use for other software: source control, automated builds, unit tests, and a simple, well-understood content pipeline."
Time to Market Equals Success
When asked about his greatest success, Park replies, "I'm glad to have developed a couple of BREW titles that are leaders in their category. These are simple games and we were afraid we would be beaten to market. Thankfully, we managed to pass certification on the first submission, and were the first with branded word games that are popular with casual gamers."
Brand Games Extended to Mobile Devices
Park, considering whether an established game brand can migrate to the mobile space, says, "Why not? I read an article where someone at Sega said they didn't mind if Monkey Ball wasn't profitable because it generated awareness of the Monkey Ball franchise to a broader market. The game industry is growing and reaching more people than ever before. Mobile might be a terrific way to reach the new gamers and grab market share. Look around and you might see all sorts of opportunities. Look at Sorrent's exclusive deal to put Yao Ming Basketball on China Unicom -- it's such a smart move."
When asked about the perks and challenges when working with branded content, Parks replies, "Challenges: restrictions on use, need for approvals on use, lower revenue percentages. Perks: more sales based on brand recognition, more likely for the title to be picked up by a carrier, more buzz in general."
BREW vs. Java Technology
Considering BREW versus Java technology in the mobile space, Park wishes people would stop positioning the two against each other. Park contends that BREW serves primarily as a distribution/billing system, so he sees it competing against other distribution platforms. BREW can and will distribute J2ME (Java 2 Platform, Micro Edition) applications. Qualcomm's next generation chipsets will include the ARM Jazelle Java chip, so J2ME will soon run natively on BREW handsets, he says. "I do believe Java will eventually 'win out' because it's easier to test than a C++ executable. The expense of certification will probably kill off downloadable C++ binaries," he says.
Theory in Practice: Park's Example Code
To avoid computation, Park advises that you preprocess data and use it later. "It's nice when you can preprocess data at load time or during run time," he says.
He continues, "I wrote an American football game in which the AI could use hundreds of random numbers per second. In this case I could avoid a fair amount of computation by pulling from a pool of random numbers during each football play. Resource pools represent a simple and common concept employable in many other contexts."
Here's the code:
Listing 1. Class RandomPool
import java.util.Random;"Between plays, the pool refreshes with new numbers by calling RandomPool.generate()":
public final class RandomPool
{
private static final boolean DEBUG = false;
private static java.util.Random _randomGenerator = new java.util.Random();
private static final int POOLSIZE = 30;
private static int _poolsize = POOLSIZE;
private static int[] _randomInts = new int[POOLSIZE];
private static int _idxCurrent = 0;
private static int _wrapCount = 1; //init=1 to generate 1st entire pool
//------------------------------------------------------------------------
public static final boolean resize(int poolsize)
{
int[] pool = new int[poolsize];
if ((pool != null))
{
_randomInts = pool;
_poolsize = poolsize;
return true;
}
return false;
}
}
Listing 2. Method RandomPool.generate()
public static final void generate()"During plays, the game grabs numbers from the random number pool," he says. "Instead of refilling the pool when it runs out, the game reuses the numbers in the pool until the play completes, then refreshes the pool before the next play":
{
if (RandomPool.DEBUG)
{
int count = _idxCurrent + (_wrapCount*_poolsize);
System.out.print( "RandomPool: used "+ count +" numbers.\n");
}
int idx = _idxCurrent;
_idxCurrent = 0; //init number ptr
// Replace whole pool if all numbers were used
if (_wrapCount > 0)
{
_wrapCount = 0;
idx = _poolsize-1;
}
// Replace just the used numbers
while (idx-- > 0)
{
_randomInts[idx] = Math.abs(_randomGenerator.nextInt());
}
}
Listing 3. Refreshing the pool
public static final int nextInt(int limit)
{
// If we ran out of numbers, start reusing them from the beginning
if (_idxCurrent >= _poolsize)
{
_idxCurrent = 0;
_wrapCount++;
}
// Return number from 0 to limit
if (limit > 0)
return (_randomInts[_idxCurrent++] % (limit+1));
else
return _randomInts[_idxCurrent++];
}
}
Mobile Gaming: the Future
As for mobile gaming's future, Park believes that in the long run the wide demographic range for mobile device users will prove important. "I'm looking forward to the opportunity to reach people who normally don't play games," he says. "However, hardcore gamers are always willing to spend more money on games, so we'll probably see similar genres as we see in the PC market. But I'm sure there will be some surprises and am hoping for the creation of new genres."
Resources
• Find more developers who've spoken with John in previous columns.
• IBM WebSphere Studio Device Developer provides IDE PDA applications.
• Qualcomm offers an interactive demo so you can try a BREW application yourself.
• Download the Java 2 Platform, Micro Edition (J2ME) Wireless Toolkit.
• SourceForge offers more information about the Proguard obfuscator as well as free downloads.
© 2008 NetVisits, Inc. All rights reserved.