Theme: “Latest Trends in Creating Mobile Games”
This day commemorates the 3rd anniversary
since the CUBIES Game was approved as a Thesis Proposal during CBG 2006 or
officially known as Games of the VIIth Colympiad. It was derived from two of
the most popular puzzle games of our time namely: Flipull and Tetris. From then
on, it is widely known as the very first CCSS Mobile Game Thesis at UE Manila.
Also, it will continue to serve as an inspiration for future Mobile Games in
the Philippines.
This year discuss 2 of the most popular software
technologies used to create exceptional Mobile Games namely JME and Brew.
a.) JME (Java Micro Edition) – a specification of a subset of the Java
platform aimed at providing a certified collection of Java APIs for the
development of software for tiny, small and resource-constrained devices based
on microcontrollers. It was designed by Sun Microsystems and is a replacement
for a similar technology, PersonalJava. Originally developed under the Java
Community Process as JSR 68, the different flavors of Java ME have evolved in
separate JSRs. Sun provides a reference implementation of the specification,
but has tended not to provide free binary implementations of its Java ME
runtime environment for mobile devices, rather relying on third parties to
provide their own.
This
is the very software used for coding, testing, and verifying the CUBIES Game
which was developed by Sun Microsystems. Originally predicted to be a standard
platform that would be identical on any handset from any manufacturer and
consequently able to run any piece of compatible software, the wide-ranging
hardware differences between ever-evolving phone models has rather Sun's
utopian vision. As a result, although JME exists as a single product name and
shares a fundamental core, there are slight differences in its implementation
on various handsets, at least between handset families – one reason why a
particular game can sometimes run on one handset but not another, even if the
handsets are made by the same manufacturer.
Like just about everything else in
the mobile world, Java is forever evolving and being adjusted, and indeed we
are currently witnessing the transition from an older version of JME components
to a more modern iteration called the Mobile Information Device Profile (MIDP),
which is part of the platform that specifies just what can be achieved by
applications made to run on JME. The game developer can download the software
development kit, program a game and then release it for download by himself.
Until recently, handsets have
featured MIDP version 1.0, which was not all that well-suited to gaming,
assuming a small screen size, no audio and a limit on the actual size of a
program. Restricted graphical performance was the main drawback, and it
hampered games developers. The newer version, MIDP 2.0, is much more powerful
in all regards. A relatively easy language with which to pick up and begin
programming (similar to the PC language C++), the only drawback is
compatibility testing. With so many different versions of JME out there, each
one for a different family of mobile phone handsets, even if a developer only
aims to cover the popular handsets testing can dwarf the actual creation of the
game.
JME runs atop a Virtual
Machine (called the KVM) which allows reasonable, but not complete,
access to the functionality of the underlying phone. The JSR process serves to
incrementally increase the functionality that can be made available to JME,
while also providing Carriers and OEMs the ability to prevent access, or limit
access to provisioned software. 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 utilize the entire
functionality of a phone (as Java software can only do what this middle-man
layer supports.
Because of this extra security and compatibility, it is
usually a quite simple process to write and distribute Java mobile applications
(including games) to a wide range of phones. Usually all that is needed is a
freely available JDK (Java Development Kit) for creating Java software itself,
the accompanying Java ME tools (known as the Java Wireless Toolkit) for
packaging and testing mobile software, and space on a web server (web site) to
host the resulting application once it is ready for public release from many
sites you can download mobile software.
As of 22 December 2006, the Java ME source code is
licensed under the GNU General Public License, and is released under the
project name phoneME.
As of 2008, all Java ME platforms, even up to BD-J, are
currently restricted to JRE 1.3 features and uses that version of the class
file format (internally known as version 47.0). Should sun ever declare a new
round of Java ME configuration versions that support the later class file
formats and language features, such as those corresponding JRE 1.5 or 1.6
(notably, generics), it will entail extra work on the part of all platform
vendors to update their JREs.
b.) BREW (Binary Runtime Environment for
Wireless) is an application development platform created by Qualcomm for
mobile phones. It was originally developed for CDMA handsets, but has since
been ported to other air interfaces including GSM/GPRS. BREW is a software
platform that can download and run small programs for playing games, sending
messages, sharing photos, etc. The main advantage of BREW platforms is that the
application developers can easily port their applications between all Qualcomm
devices. BREW acts between the application and the wireless device on-chip
operating system in order to allow programmers to develop applications without
needing to code for system interface or understand wireless applications. It
debuted in September 2001.
Software for the BREW-enabled handsets can be developed
in C or C++ using the freely downloadable BREW SDK. The SDK includes a BREW
Emulator, or starting with BREW Version 3.15 and above, the BREW Simulator, for
testing during the development process. Unlike the Java ME platform, where any
developer can upload and execute software on any supported handset, BREW
applications must be digitally signed. Because BREW provides complete control
over the handset hardware, only content providers or authenticated BREW
developers have the tools necessary to create a digital signature. Furthermore,
developer-signed applications can only execute on test-enabled handsets (BREW version 3.1 and newer devices are
already "test-enabled"). Once the application has been developed and
internally tested, it must be submitted to NSTL for TRUE BREW testing. After
the application passes all tests, it may be offered to a mobile operator
(content provider) to be accessible for download to general handsets. The
application is then signed by the content provider, to allow its execution on
any supported BREW handset.
The BREW Emulator (currently called BREW Simulator) does not emulate
handset's hardware. Instead, the BREW application is compiled to native code
and linked with an x86-compatible BREW runtime library. Because of this,
obscure platform bugs related to memory alignment and various firmware related
glitches make debugging applications without a BREW handset difficult.
Developers must test their applications on real BREW-enabled handsets. To do
that, the handset must be enabled for BREW testing (Qualcomm's development labs
can do the service). Starting from BREW 3.1, test-enable bit functionality was removed, and now all that is
needed is a developer's digital signature.
For testing purpose, BREW applications can be transferred
using a USB or serial cable to any BREW-compatible handset using BREW AppLoader from Qualcomm. A BREW
application contains several components which must be present; otherwise it
will be automatically deleted on reboot. This includes a name.mif file which describes the
application, the features it uses and permissions requested a name.mod file which is the actual
compiled binary, name.bar which
contains string and image resources if required, and a name.sig which is the application digital signature.
Once the application passes testing, it's available to
carriers, but this does not guarantee that any carrier will make it available
to end users. Carriers have to be persuaded to offer the application to end
users.
.
On May 28, 2008, Qualcomm and Adobe announced a
partnership to integrate Adobe Flash Lite as a supported user interface on
BREW.
.
In terms of use, BREW can provide complete control of the
handset and access to all its functionality. However the power provided by
native code with direct access to the handset APIs has caused the BREW
development process to be tailored largely towards recognized software vendors.
While the BREW SDK (Software Development Kit) is freely available, running
software on real mobile hardware (as opposed to the provided emulator) requires
a digital signature which can only be generated with tools issued by a handful
of parties, namely mobile content providers and Qualcomm themselves. Even then,
the game will only work on test
enabled devices. To be downloadable on regular phones the software must
be checked, tested and given approval by Qualcomm via their TRUE BREW Testing
programme.
Once again, HAPPY
CUBIES DAY TO EVERYONE!!!
