Restructuring Mobile Games
content
0. Important Note
Although this document is somehow old (was last edited in
Oct/2005), but it is still valid. The idea of having a unified
structure that can be extended in the future to include new handsets
is what makes this document valid even three years after it has
written and in spite of the fact that more than 2000 new handsets
were added during that period. This document was the base for
the unified structure we follow for all of our mobile content in our
database. Since games are the most complicated
items, then most of the document will focus on the mobile game as
item, but the same arguments and ideas can be applied to any other
mobile content such as themes, ringtones, wallpapers. So you can
replace "mobile game" with any mobile "item".
1.
What is this document?
This document describes the new structure we use for our
catalogue of mobile games. A similar structure has been applied to
other content like Themes and Videos. This document is intended to
be read by any publisher who is trying to distribute our games. This
document is arranged as a series of Questions/Answers. We thought it
would be easier to achieve our aim this way. Your future questions
will be added to this document later.
This document is continuously updated
but never fully finished. Due to constant changes in the mobile
world and the adding of new technologies, new handsets, new
requirements, etc. etc. It’s very important that you provide us
with constant updates and feedbacks. If you encounter any
problem and this document doesn’t provide an answer, then please
contact us. We will update the document accordingly.
2.
Why new restructure is necessary?
ZGROUP MOBILE is a publisher of mobile
games. At the time of writing this document we have more than 1300
mobile games coming from around 120 developer/provider. If we
don’t build a unified structure for all games, then each game will
have its own structure. It will have all the info needed, but
organized in a different way. This will create a mess
and confuse the publisher/operator in each case and will make it
difficult for any provider to include the games into his/her
distribution channels and/or platforms. Thus it was necessary to
make one template and make all games follow the same structure.
It was also necessary to provide you
(the publisher) with a way to describe each component in each game
so that it will be easier for you to do an automated inclusion of
games into your platform.
Since we have good experience with most
CMS systems, then we can help you with the inclusion of our mobile
games into your platform.
3.
Can
you tell us more about the new structure?
Each game is packaged into a zip file.
If you try to explore several files then you will notice that all
files follow the same structure. Here are the main points of the
structure:
a.
There’s a binaries directory in which you will find
all the jar/jad of the game with different handsets. This directory
contains (in the first level) several sub-directories named after the
manufacturers (like
Nokia, Siemens, SonyEricsson, . . . etc). For all manufacturers except
for Nokia, you will find directories in the name of supported
handsets. For example in Siemens directory you can find the following
directories:
C60_MC60_M55_CF62_S55_S56_S57_A65_SL55_CX60
C65_S65_M65_CX70_SP65_SK65_S66_CX65
C66_SL65
CFX65
M50_MT50_C55
SX1
Note that each
of these directories contain a .jar/.jad combination. The name of the
directory describes which handsets the games will run on. Actually the
name of the directory is no more than a list of supported handsets
separated by “_”. For example the .jar/.jad found in the first
directory (in italics above) will run on Siemens C60, Siemens
MC60, Siemens M55, Siemens CF62, Siemens S55, Siemens S56, Siemens 57,
Siemens A65, Siemens SL55 and Siemens CX60. So you can always tell on
which handsets this version will run only by looking at the name of
the directory. Also if you want to know what version will run on
Siemens MT50, then you can go to siemens directory and search for a
directory name that includes MT50 and use the .jar/.jad files inside.
The
grouping above is important as in most cases a .jar/.jad files will
run on a series of similar devices. Note that in case the .jar/.jad
doesn’t run on a specific handset (due to specific limitations or
known bugs on that specific handset) then a separate directory will be
created for that game in specific. For example if we have a specific
version for Siemens C60 then you will find the following directory in
the Siemens directory:
C60
The Nokia
has a special case, as there are two levels of directories inside the
Nokia’s directory. The first level includes the different series for
Nokia devices. The second level includes the name of the devices as in
other manufacturer’s case. So the Nokia directory will include:
S30 –
Nokia Series 30 devices.
S40C –
Nokia new Series 40 devices like 6230i, 8800.
S40v1
– Nokia old but wide spread Series 40 phones like 7210, 6610. .. etc. Those are MIDP 1 handsets.
S40v2 –
New MIDP2 Series 40 phones like 6230, 5140.
S40v3 –
Series 40 version 3 phones.
S40v5 –
Series 40 version 5 phones.
S45 – Series
45 phones like 7600, 7270.
S60v1 –
Old series 60 phones like 3600, 7650, Ncage. (MIDP1)
S60v2 –
New series 60 phones like 6600, 6620, 6630 (MIDP2).
Let’s take
one of the directories: S40v1 includes the following handsets:
2650_3100_3105_3108_3120_3125_3200
3205_3220_3300_5100_6100_6108_6200
6220_6225_6585_6610_6610i_6800_6810
6820_7200_7210_7250_7250i_7260
And in
each of these directories you will find separate .jar/.jad files
running on these handsets.
b.
There’s a marketingMaterial directory in which you can
find all the necessary marketing material info about the game like
screenshots, document files, animated screenshots, video. In this
directory you will surely find:
i.
a series of screenshots in the size 128x128 numbered up from
zero or one. For example CannonBalls0.gif, CannonBalls1.gif. . etc.
ii.
a file called animated.gif which is a brief animation useful to
be included in web. The size is usually less than 100kb. The delay
between two frames is set to be 1 second.
iii.
Two wap screenshots. One is 75x75 pixels, the other is 95x95
pixels.
c.
Three files at the root of each game. The first one is for
short description suitable for wap display. The second is a detailed
description about the game, suitable for web display. The third file
(the most important one) is the descriptor file describing the
content of the game in a suitable xml format that can be used later
for automatic inclusion in your systems. More info about the xml file
will be detailed in the following paragraph.
4.
Can
you give me more info about the XML descriptor file?
Actually the descriptor file is an xml
file. It is the most important file as it includes all the info
above and it’s very necessary if you would like to do automated
jobs, like automated inclusion of games into your platform.
Here is a brief description about each
tag in the .xml file:
1.
Name: The name of the product. It’s the same as the
name of the package file. This is the official name of the game.
2.
Type: type of the product (J2me, Brew, Mophun, Symbian.
. etc) . Now it’s mostly J2ME.
3.
Verison: the version of the product.
4.
Description: Short description about the product. It can
be used to show on wap
5.
Category: The category of the game. Games are arranged
into different categories like Arcade, Action, Puzzle, Adult. . . etc.
If the game is a premium game then this will be added to the category.
6.
Vendor: This is the name of the publisher. It’s
always “ZGROUP MOBILE”
7.
Price: The minimum pricing of this product. In most
cases it’s according to the agreement signed between your company
and ZGROUP MOBILE.
8.
Availability: The territories in which this product can
be distributed. In 99% of cases it’s worldwide non exclusive. Anyway
you still have to watch this closely in some cases.
9.
Sample-webn: A list of screenshots for the game. The
size of those samples is 128x128 pixles. This is choosen to be the
best for web display.
10.
Sample-wap1:One screenshot of the game suitable for
display on wap pages. The size is 75x75 pixels.
11.
Sample-wap2:Another wap-screenshot of the game. The size
is 95x95 pixels.
12.
Sample-animation: Animated screenshot of the game. The
animation can include between 2-12 frames. The size is 128x128. The
size is less than 100k. There’s one second of delay between the
displaying of frames.
13.
filebundle: There’s a filebundle for each version of
the game. The info about the version on each handset. Here are the
sub-tags:
a.
Jad: the location of the .jad file in this package.
b.
Jar: the location of the .jar file in this package.
c.
Terminals: A list of devices on which the previous
.jar/.jad files will run. The terminals are separated by ‘;’.
5.
If
there's a new handset in the market, how will this structure change?
Actually there will be no change in the main structure. We will
have only to add an extra directory for the new handset. Suppose the
new handset is Nokia N73. Then we check to see what series is it.
This info can be found easily from Nokia's site. The handset is
Nokia Series 60 v3. So we create a directory S60v3 in the Nokia
directory (in case it's not already created). Then we create a
directory called N73 inside it. We have to put the jar/jad files for
this handset in the directory. Then we will have to include the new
handset in the xml file. This unified structure has lot
of advantages among which:
- New handsets can be added easily without much changing the
whole package.
- Having the content into directories will make it easily for
anybody to identify easily and accurately the binaries
compatible with a specific handset
- The publisher can ignore some handsets if they are old or not
very frequent in the database they have.
- The publisher will be able to offer users of new handsets with
games even if the new handset is not in the xml file. The
publisher will use the binaries from a compatible handset and
offer the users the same old base of games. This will ensure
that new-handsets users will have something
immediately.
| 
