Mobile Game Industry

This article is intended to provide you a general backgrounder on mobile games development and the industry so that you could take informed decisions on whether this is what you might want to chose as your career (or you just want to kill some of your time, reading though something interesting ;-)


Mailed to me by anupam@tinfomobile.com

Mobile game development is an art. As with most other forms of art, it demands two attributes from its practitioners and practitioners-to-be: aptitude and attitude. While attitude can be built up, aptitude is something that is inherent (or conditioned over time). A better term to use would be – talent. The only point I would like to stress here is that though it is by no means a rocket-science, one just cannot expect everyone with a degree in computer science to be good mobile game developers by default. So if you really want to be in the games development industry you should have by now at least tried to have made your own game – at least a tic-tac-toe and whenever you've played Roadrash on your PC, you should have pondered and thought over how you could do something like it yourself! If yes, you're on the right track. Read on.

This article is intended to provide you a general backgrounder on mobile games development and the industry so that you could take informed decisions on whether this is what you might want to chose as your career (or you just want to kill some of your time, reading though something interesting ;-)

Why Mobile?

Thats a 'Yeh PSPO nahin jaanta?' kind of statement. Anyways, it makes sense to know why anybody (people like us) would want to bother about making games and applications for mobile phones in the first place!

1. The mobile handsets today are essentially programmable / re programmable devices.

More than 90% of the handsets being shipped nowadays have some programming interface. Java is one of the most popular options today but not the only one.

2. They are connected devices. Connectivity is a built in feature of the mobile handset. Assuming that you have signed up for data services, the mobile phone is now a device that is capable of sending and receiving data over the Internet.

3. The mobile phone is clearly the most popular digital device in the whole wide world. Just look around and count. The number of mobile handsets you see will outstrip the number of the other digital devices that are around you. And this represents enormous opportunities. In India, there are a total of 120 million mobile subscribers! If what you make is wanted by even one percent of this number – that is a significant figure. And that my friends is the basic reason for the existence of the mobile entertainment industry.

4. Mobile game development is cool! Game development in itself is considered the cutting edge of programming. While most software engineers will end up in typical software services firms; only a chosen few will get to be in this industry. For the moment – this IS niche :-) !

It might also be helpful at this juncture to have an overview on mobile network technologies prevalent today. GSM and CDMA.

GSM stands for Global System for Mobile communications. This clearly is the more popular sibling.

Narrowband TDMA, 8 calls on one freq.

1 billion + subscribers (2004 statistic).

India 2006 August: ~90 million

CDMA (Code Division Multiple Access). Based on a declassified US Defence encoding technology to which Qualcomm Inc. holds the patent (So for every CDMA handset sold anywhere on the globe they get a royalty!) Supposed to be more spectrally efficient than CDMA and is completely digital.

Based on spread spectrum modulation.

25% market.

India 2006 August: ~30 million

Mobile games are different

Since I belong to the mobile entertainment industry, this article will be based on the mobile platform. Mobile games are different from games on other computing platforms due to following reasons:

1. Too many constraints. Everything is limited and in short supply including screen-size, memory and customer's patience. So mobile game programming is all about writing the most optimized codes and designing optimal graphics and putting it all together in the smallest package.

2. Shorter development cycles. While game or console titles' development typically spans over a year, a mobile game takes a few months to develop. Therefore, while a full scale title on a PC would cost billions of dollars nowadays, a mobile game would cost only its fraction.

3. Mobile users are spread out among all socio-economical classifications and therefore a major chunk of the users comprises of casual gamers or first time gamers. The primary function of a mobile phone is not gaming and this must be kept in mind while designing the game. A gaming console on the other hand is designed from the ground-up for gaming and for gamers. The games there would be a bit more mature in nature and might not be as generalized as a mobile game might be. Another important statistic now available says that there are almost as many female mobile entertainment users as there are male.

4. You must keep in mind that the mobile games market is already crowded. Make sure what you develop is something that is clearly different from what is already available.

Assuming that you are by now convinced about the size and scope of the task at hand (and are still interested), lets carry on. We will now move into the actual process that we at Tinfo Mobile use for developing a mobile game.

The starting point

Keeping all the things mentioned above in mind, the starting point for a game is – your mind. The whole cycle begins from an idea that you get (while you were perhaps taking bath in cold water on a chilly Monday morning ;-). The first step would be to document this into a form that even a layman could understand and appreciate. If possible (if you can draw decently well), add mock up-screen shots as well.

Remember, a sketch is sometimes better than a thousand words. Present your concept to your colleagues/ friends and get their feedback on it. Obviously, one attitude a game designer must have is to be very open to criticism.

Documenting the concept

So now your concept document is ready. It’s time then to create the design document. The design document essentially connects the concept to the intended game play and takes into account the constraints that might be imposed by the target handsets. The design document should be treated as the main reference material for your game project. It would be a living document which grows with your project. The design document should capture the aim of the game; describe the characters, friendly objects, enemies, platforms, levels and how each of these

elements would interact with each other in simple words. It could also specify which keys are supposed to do what function in the game, the target handsets and the audience.

Graphics

As a part of the design process, you must have also come up with a list of graphics assets that will be required in the game. The artwork is the skin and clothes for your game. It is what will be visible to the rest of the world. Make your artwork as snazzy as possible. The specialized artform for mobile games is called pixel art. (It is a specialization skill in itself – google it out to know its wonders). The following is a sprite set. It is a pixel art of a mosquito flying (3 frames) and being hit (1 frame). A pixel artist makes all the graphics assets as per specs.

Levels, structures, algorithms

Now comes the phase called level design. Its basically like making the map for the game, tile-by-tile. A sample level map from one of our games:

Selecting the programming environment

The following list provides the options available today for converting your design / idea into a mobile software executable:

• Symbian (C/C++)
• J2ME (Java :-)
• BREW (C/C++)
• MS Smartphone, pocket pc (C/C++/eVB)
• Others

· Mophun (C/C++)

· Ex-En (Java)

· Do Ja (Java)

Most widespread = J2ME (>80% of the market)

Coding

One thing that your teachers might have taught in your software engineering class is cent percent true. Design is more important than coding. If you have done your design well, you would know what code should come where and your thought process would be guided easily by the documentation. We have seen many a project fail when the design part was not given its due importance.

The only guidelines to be followed for coding are – follow standards, write tons of comments, take backups, re-use knowledge and code. Most APIs for mobile development are well documented with samples and are freely available on the Internet.

QA and testing

Once the game has been developed, real gamers and QA professionals put it to test against standard checklists and other game specific test-suites. This is an iterative process that goes on till all wrinkles have been ironed out.

Porting

Porting is the bane of the mobile games industry. Unfortunately, most handsets differ from each other and have their own peculiarities. If your game has to be successful in the market, it should address as many of the handsets as possible. The process of modifying and adapting a game to a set of target handsets is called porting. There are many companies that specialize in porting itself as it could be a pretty intensive process.

Publishing

Someone has to publish and provision the games before they become available to the public. This role could be done by either the operators, or aggregators or the developers themselves. The game files are uploaded to special content delivery servers that can automatically send the correct files for each handset over the air using GPRS or CDMA data channel for transport.

Viola! Your game is now ready and is being enjoyed by millions! Depending on how good it turns out to be, the vagaries of the mobile market, the reviews, the critics, and how many telcos espouse it….

Your game becomes a hit! …. Or hits the dust… or lands up somewhere in between.

Some help

If you know to google well – well you've got it! Trust me, as they say – if you ever need a helping hand, theres always one at the end of your arm – just use it to type into the google search box :-) . If even that does not help do shoot us an email. Our website is www.tinfomobile.com and my email address is anupam@tinfomobile.com

Ant Based Builds in J2ME Application Development

Ant Based Builds in J2ME Application Development

This article takes a look at the point of using Ant based build tools in J2ME application / game development and what are the various build tools and so on. The article is basically built on the documents mentioned under the reference title.

What’s the difference?

When developing J2SE applications, things are much easier, mostly because of two steps which are required by J2ME which aren’t in J2SE. With J2ME your compiled classes must be preverified before you can upload them to the device. In J2SE verification of class files takes place in the JVM, but because of the memory limitations on the device, the CLDC-VM or KVM (Sun’s implementation) has a stripped down verifier and some of the functions were moved to the compile-phase (off-device). One thing more we have to watch out for is the emulation of the device. In J2SE, the development platform is the device, not so in J2ME. Because of this, we must have a suitable testing step. Due the heavy fragmentation in J2ME devices (differences in screen sizes, heap, implementation of sound etc.) leads that each application / game has to be specifically tuned for devices. This is pretty cumbersome with managing of different code base for each and every device. A solution for this problem is use preprocessing commands like #include, #if defined etc. in a single code base and let the build system make different target source for each devices based on conditional compilation. Hence we need a defined build process

Why do we need a defined build process?

A defined build process is an essential part of any development cycle because it helps close the gap between the development, integration, test, and production environments. A build process alone will speed the migration of software from one environment to another. It also removes many issues related to compilation, classpath, or properties that cost many projects time and money.

Make Tool

In computer programming, make is a utility for automatically building large applications. Files specifying instructions for make are called Makefiles. make is most commonly used in C/C++ projects, but in principle it can be used with almost any compiled language.

The basic tool for building an application from source code is the compiler. make is a separate, higher-level utility which tells the compiler which source code files to process. It tracks which ones have changed since the last time the project was built and it invokes the compiler on only the components that depend on those files. Although in principle one could always just write a simple shell script to recompile everything at every build, in large projects this would consume a prohibitive amount of time. Thus, a makefile can be seen as a kind of advanced shell script which tracks dependencies instead of following a fixed sequence of steps.

Today, programmers increasingly rely on Integrated Development Environments and language-specific compiler features to manage the build process for them instead of manually specifying dependencies in makefiles. However, make remains widely used, especially in Unix-based platforms.

Makefile structure

A makefile consists of lines of text which define a file (or set of files) or a rule name as depending on a set of files. Output files are marked as depending on their source files, for example, and source files are marked as depending on files which they include internally. After each dependency is listed, a series of lines of tab-indented text may follow which define how to transform the input into the output, if the former has been modified more recently than the latter. In the case where such definitions are present, they are referred to as "build scripts" and are passed to the shell to generate the target file. The basic structure is:

# Comments use the pound sign (aka hash)

target: dependencies

        command 1

        command 2

           .

           .

           .

        command n

A makefile also can contain definitions of variables and inclusion of other makefiles. Variables in makefiles may be overridden in the command line arguments passed to the make utility. This allows users to specify different behaviour for the build scripts and how to invoke programs, among other things. For example, the variable "CC" is frequently used in makefiles to refer to a C compiler, and the user may wish to provide an alternate compiler to use.

Example makefile

Below is a very simple makefile that would compile a source called "helloworld.c" using cc, a C compiler. The PHONY tag is a technicality that tells make that a particular target name does not produce an actual file. The $@ and $<>

helloworld: helloworld.o

        cc -o $@ $<

helloworld.o: helloworld.c

        cc -c -o $@ $<

.PHONY: clean

clean:

        rm -f helloworld helloworld.o

Issues with the Make Tool

The make tool is been in the existence for more than 20 years, though it is still used widely it has it long list of limitations.

1. Make tool based builds are not portable as they rely on the underneath shell and the features of the file system.
2. Issues like one-letter names for macros, one namespace for file and command targets make Make tool one of the most complex of the build systems.
3. Limited Syntax
4. Difficult Debugging

The Make Alternatives

A lot of make alternatives are currently available which include Opus Make, GNU Make, Nmake and there are evolutions like JAM, COOK which move away from the syntax of the existing Makefile system. There are also alternative build tools like GNU Build System. However one of the most notable and interesting script based make alternative is the ANT

Defining Build Process with ANT

Ant is a platform-independent scripting tool that lets you construct your build scripts in much the same fashion as the "make" tool in C or C++. You can use a large number of built-in tasks in Ant without any customization. Some of the most important tasks are shown in the following table but explained in more detail in the example that follows.

Here are some useful commands that are built in the Ant distribution.

Command	Description
Ant	Used to execute another ant process from within the current one.
Copydir	Used to copy an entire directory.
Copyfile	Used to copy a single file.
Cvs	Handles packages/modules retrieved from a CVS repository.
Delete	Deletes either a single file or all files in a specified directory and its sub-directories.
Deltree	Deletes a directory with all its files and subdirectories.
Exec	Executes a system command. When the os attribute is specified, then the command is only executed when Ant is run on one of the specified operating systems.
Get	Gets a file from an URL.
Jar	Jars a set of files.
Java	Executes a Java class within the running (Ant) VM or forks another VM if specified.
Javac	Compiles a source tree within the running (Ant) VM.
Javadoc/Javadoc2	Generates code documentation using the javadoc tool.
Mkdir	Makes a directory.
Property	Sets a property (by name and value), or set of properties (from file or resource) in the project.
Rmic	Runs the rmic compiler for a certain class.
Tstamp	Sets the DSTAMP, TSTAMP, and TODAY properties in the current project.
Style	Processes a set of documents via XSLT.

While other tools are available for doing software builds, Ant is easy to use and can be mastered within minutes. In addition, Ant lets you create expanded functionality by extending some of its classes.

Simple build process with Ant (simple.xml)

The first line contains information about the overall project that is to be built.

The most important elements of the project line are the default and the basedir.

The default attribute references the default target that is to be executed. Because Ant is a command-line build tool, it is possible to execute only a subset of the target steps in the Ant file.

% ant -buildfile simple.xml init

That will execute the ant command and run through the simple.xml file until the init target is reached. So, in this example, the default is deploy. The Ant process invoked in the following line will run through the simple.xml file until the deploy command is reached:

% ant -buildfile simple.xml

The basedir attribute is fairly self-explanatory as it is the base directory from which the relative references contained in the build file are retrieved. Each project can have only one basedir attribute so you can choose to either include the fully qualified directory location or break the large project file into smaller project files with different basedir attributes.

The next line of interest is the target line. Two different versions are shown here:

The target element contains four attributes: name, if, unless, and depends. Ant requires the name attribute, but the other three attributes are optional.

Using depends, you can stack the Ant tasks so that a dependent task is not initiated until the task that it depends on is completed. In the above example, the clean task will not start until the init task has completed. The depends attribute may also contain a list of comma-separated values indicating several tasks that the task in discussion depends on.

The if and unless commands let you specify commands that are to be performed either if a certain property is set or unless that property is set. The if will execute when the property value is set, and the unless will execute if the value is not set. You can use the available command to set those properties as shown in a following example, or you can set them via the command line.

The init target from the simple example contains four lines of property commands as shown here:

These property lines let you specify commonly used directories or files. A property is a simple name value pair that allows you to refer to the directory or file as a logical entity rather than a physical one.

If you wanted to reference the sourceDir variable later in the Ant file, you could simply use the following syntax to alert Ant to obtain the value for this tag: ${sourceDir}.

Two other commands present in the above buildfile are:

These commands are used to ensure that there are no extraneous files in the outputDir (or classes directory when dereferenced as mentioned above). The first command removes the entire tree contained under the outputDir. The second command creates the directory again.

The last line of major interest to the developer is the following compilation line:

The javac command requires a source directory (the input location of the .java files) and a destination directory (the output location of the .classes file). It is important to note that all directories must either exist prior to the running of the ant command or be created using the mkdir command. Ant does not create directories based upon intuition, so you must create the outputDir, using the mkdir command prior to the compilation step above.

After the compile task has completed, the deploy task will perform the copy operation to move all JSP files from the source directory to a deployment directory.

Ant for J2ME

Ant can be easily used for building J2ME application. To start with we need to define a directory structure. One of the most commonly used directory structure for J2ME application is listed here. Presented here is a sample build.xml file for this structure. However one need to modify the it for their own specific use.

	Directory Contents	Manually Created
/bin	Where you would place the JAD and MANIFEST file	Yes
/src	Where you would place the source files, its not necessary to include the structure of the java packages, but you can if you like. The package structure should be automatically taken care of as long as the java source files properly define the package names	Yes
/res	Where you place resources such as graphics, maps, text files… etc. You will need to explicitly create the path to correctly represent the package layout defined in the java source files.	Yes
/build	Where you place resources such as graphics, maps, text files… etc. You will need to explicitly create the path to correctly represent the package layout defined in the java source files.	No
/obf	Where compile and preverify takes place	No
/deploy	The final result you would deploy to production	No

jarfile="${build}/bin/${program_name}.jar"
manifest="bin/MANIFEST.MF">

jarfile="${build}/bin/${program_name}.jar"
manifest="bin/MANIFEST.MF">

Reference

1. ANT MIDP Build Process (focus on Siemens C55)
(c) by Marc Logemann (Loge)

2. J2ME - Using Ant With J2ME

By Jason Lam
Expert Author
Article Date: 2003-06-11

3. Adrian Neagu, in Editorials -

http://freshmeat.net/articles/view/1702/