| |
| | ||||
![]() | ||||||
| | | |||||
|
Developing Action-based Mobile GamesMobile DevelopmentDespite the advances, creating mobile games is much different than traditional game development. It’s very difficult to create compelling games. It’s more difficult than console or PC development because of the numerous devices with different memory, sound, and display capabilities. On top of that, you must manage different development environments like BREW and J2ME. Mobile game development requires a different approach. The budgets in the mobile game space are small and timelines are short. The platform has a variety of hardware and software combinations, without a lot of common ground between the hardware manufacturers First, spend more time planning. Developers have a tendency to cut corners. However, to create a world-class game, you must apply world-class development processes. Apply the same set of processes used for console, PC, or Gameboy projects. The key steps are design concept, pre-production, production, and QA/testing. Unfortunately, because of the diversity of devices and carriers, developers are forced to spend much more time upfront planning projects carefully. There’s a risk that a design that may work on one device could be impossible on another. Second, like the PC, develop to the lowest common denominator of hardware, meaning your code base must not make any low-level assumptions on how the hardware interacts with the operating system and/or programming language. Third, similar to the hardware issue, develop to the basic functionality between the two APIs. Compare the differences of the software development environments and design around their weaknesses. Developers must spend more time understanding both platforms, but the efficiency on the back end is well worth it. Incompatible Operating EnvironmentsThe two leading mobile development environments are J2ME and BREW. J2ME is the leader in mobile application development with the support of most US carriers. However, Verizon, the largest carrier in North America, and Alltel both support the BREW API developed by Qualcomm, thus making BREW a necessary platform for the foreseeable future. BREW is more of an OS and supports programming languages like C and C++, allowing for very tight and efficient code. J2ME is an interpreted language that runs on any OS (including BREW) that has a virtual machine, causing, in general, slower code and more challenges in optimizing code. In both environments, developers are at the mercy of a manufacturer’s
implementation. For example, if display speed is not a priority, manufacturers
can support the basic version of J2ME and BREW – neither of which
has a standard internal method of direct access to the screen, which could
result in routines that cannot support fast full screen draws. For example, BREW 1.0 supports masked blits, whereas J2ME MIDP 1.4 does not. Also, some J2ME phones do not have sound support. So your base code should not depend on masked blit support or sound support. For example, if you create custom bitmap fonts, you might think you need masking. However, you could create font bitmaps with the correct background color ahead of time. Both platforms make it possible to make palette changes while loading a file, allowing you the capability to adjust the font background colors dynamically, meaning, of course, the text must appear over a solid background. If a phone has masked blit support, use it. It’s much easier to scale up than to scale down. Tips _______________________________________________________ |
|||||||||||||
|
|