Mobile handsets as gaming devices. Part III

(...Continued from Part II)

The following graphic depicts a rough time-line. Most of the handsets like the Motorola T720 and the Nokia 7650 are now extinct.


A notable and notorious handset as far as mobile gaming is concerned was the N-Gage and the N-Gage QD from the Nokia stable. Though visionary in its purpose, it failed in its execution at being a mass market gaming device which could also make phone calls. The take-away from its life was the fact that until the technology so matures, mobile phones are not a hard-core gamer's first port of call. They will always have their PS3s for that.

However, what is notable is the progress made in handset technology over these few years (you may note that a major part of this whole 'history' I am talking about has unraveled in just about half a decade! The growth IS that frantic and this means that the cool phone that I carry today will be tomorrow's junk. This rapid evolution can be tracked using the following attributes which are relevant from a developer's perspective.

a. Screen resolution
The following representation should give you a good idea:

...2001...

100 x 80

...2002...

128 x 128

...2004...

176 x 220

...2005...

240 x 320

...2007...

480 x 320, 160 dpi - The iPhone

b. Keypad and its layout
Undoubtedly the most used and abused parts of most erstwhile digital devices. More so for phones used as gaming devices.

......2001...

Number keys only.
Other keys did not exist except for make / break call ones.
Even if other keys existed, their use inside apps was undefined and unintended.

...2002...

Standard layouts.
Soft-keys defined.
4-way simple joysticks incorporated and used in menus as well as simple games.

...2003...

Additional game specific keys prominent.

...2005...

Six+ way joysticks.
Simultaneous multiple keypress detection.

....

Other innovations in human interface including screen-touch and camera motion detection.

c. Processing power

...2001...
Very slow, inefficient processors, primarily intended to feed text only screens and very simple computational needs.

...2003...
Playable frame-rates for arcade style games. Reasonable number crunching.

...2004...
Good frame-rates, even 3D gets introduced, advanced screen rendering algorithms.

.....
The lines between personal computers and personal mobile phones is blurring further and further. Some devices as capable as earlier PCs and some like the iPhone carving a niche for the way in which the UI and power has been designed to give a superior user interface.

d. Memory
All the graphics, sound effects and rendering code need space - the more the better. More space translates into a better ability to pack in richer textures, detailed sprites and backgrounds with a good color-depth and range. Also, games gobble a good amount of working memory - the stack and the heap to give a better gaming experience. There is a lot of data associated with any game instance and these must be buffered for quick access. In simple terms abundant heap and stack space translates into a smoother and richer game-play.

...2001...
32 to 64KB jar size
200KB heap

...2004....
200KB jar size
512KB heap

...
Jar size in Mega Bytes
Introduction of Virtual memory...?

This pretty much sums up the evolutionary pattern being followed by mobile handsets. I'm sure as technology progresses, these parameters will be redundant - but until then and even beyond, they're welcome to stay on my journal ;).

In the next piece I intend to list out a few notable games that can be called milestones in the handsets' journey of evolution. Till then - adios!

Mobile handsets as gaming devices. Part II

(...Continued from part I)
Around the same time, Qualcomm launched BREW - a rival platform for CDMA phones running on its chip-sets. While J2ME had a mass following due to a high number of Java developers available, BREW had a smaller following.

Many would argue that despite the ease of coding and huge developer network, BREW had an edge over Java for the reason that it was built as a product with a monetization mechanism built it, while the engineers at Sun Microsystems were more intent on building a 'standards platform'. That apart from the fact that BREW code works closest to the machine and hence has potentially better performance.

However, considering its reach, J2ME (now known as JavaME) which is available on almost all GSM phones and a few CDMA phones is unrivaled.

The following is the first Java enabled phone from Motorola - the i3000

Year 2001. Motorola i3000. Screen 110 x 110 px. Black and White

Siemens too launched its first Java handset the same year- the SL45. For many J2ME enthusiasts, the Siemens SL45 was an introduction of sorts.

Year 2001. Siemens SL45. Screen 100 x 80 px. Greyscale (better than BW :) )

Not to be left behind, Nokia too came out with its classic Java enabled phone. The rugged and handy Nokia 3410 candybar was perhaps the first mass market J2ME MIDP 1.0 device.

Year 2002. 3410, Nokia Series 30. Screen 96 x 96. Greyscale

The 'other' platforms

It was not as if there were no other mobile development platforms around, infact there were a handful of them, some very good ones too - alas, not all are as successful as J2ME and BREW.

The most notable among the 'other' platforms was Mophun. Mophun was a revolution of sorts. Initially built for the Sony Ericsson T300 (We called it the soap-box phone ;) ), it was the first arcade level mobile gaming platform with a freely download-able SDK. The T300 was one of the first handsets to have an 100 x 80 color screen, sound effects support and a joystick. It even supported an external camera ;)

Year 2002. SonyEricsson T300. Screen 100 x 80. 256 colors

Infusio meanwhile developed another Java based platform name ex-en. It featured on a few Sagem, Philips, Toshibas and its likes.

Another notable platform was Do-ja. Again Java based (J2ME based to be more specific) with the exception of having a proprietary Profile originally built for the Japanese telcos.

The year 2002 and beyond witnessed mobile technologies literally leapfrogging. The screens kept getting better, the processor got faster and memory was bigger. The mobile world as we know it can be called the post 2002 era which we will explore in the next article.
(To be continued ...)

Mobile handsets as gaming devices. Part I

The humble mobile phone has come a long way. There was a time when this device was available only to the elite few, looked like a brick and cost a fortune to have and to keep. Heres how it all started. Though many wireless devices did exist before this brick, it holds the distinction of being the worlds first 'cellphone'.

Year: 1984. The Motorola DyanTac 8000x.

Nokia (which started in 1865 as a wood pulp mill!) debuted its first GSM mobile phone only in 1992 with Nokia 1011 (though it too had made the first transportable phone in 1984)

Year 1992. The Nokia 1011

Mobile phones were pretty serious business till some geek at Nokia decided to add some fun to it and along came Nokia 6110 with Snake on it!

Year 1997. Nokia 6110 - There's a snake on board!

Nokia's Snake is considered the 'pioneer' in mobile gaming.
The enormous interest on this mobile game, even among the typical 'business' folk is legendary, with people vying with each other to break the high score record. For a few years, games such as Snake were production-embedded on handsets.

All that changed in 2000-2001, with the Java platform claiming a new playground. (... To be continued in part II)

I want to make a mobile game! - Part II

Continuing from where we'd left. Its time to get into the typical process of mobile game development - lets call it 'Life of a mobile game'.

Day 0 - A game idea is born!

The starting point

Keeping all the things mentioned in Part I 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.

End of Month 1, still doesn't say ‘mama’

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 art-form for mobile games is called pixel art. (It is a specialization skill in itself – google it out to know its wonders).

There are a few game components that every game developer must be familiar with. The first among them is a Pixel. A pixel is simply the smallest distinguishable unit of a screen display. Currently there are no direct techniques to draw less than one pixel on the mobile screen.

The second is a Sprite. (No, its not the green bottle of carbonated 'all taste, no gyan' that I am talking about :-) ). A sprite is a transparent image, usually depicting a character or an object in a game. Every character in a game therefore has its set of sprites for each action that is involved. The image containing the set of sprites is usually referred to as the sprite-sheet. The following is a selection of sprites for the the protagonist 'Ramson', from the game Ramson's Quest.

© Tinfo Mobile 2006

The next component is called a Tile. A tile is conceptually similar to the mosaic or ceramic tiles that might have been used on the floor of your house. A tile is a rectangular (mostly square) piece of the background of a game screen. In other words, a set of tiles arranged as rows and columns make up the background layers of a game. Why use tiles? Why not have a large image that could be drawn on a screen? Consider a platform adventure game like Ramson's Quest, where the hero has to move across platforms (which are pretty long) to reach some destination point. Assume that the level is currently 100 tiles wide and 15 tiles high. If each tile is 16 x 16 pixel square in size, that translates to an area of 100 x 15 x 16 x 16 = 384000 pixel square. Since every pixel of image space costs two bytes space, this translates to a whopping 750 KB just for the background image! This is simply not feasible due to the following reasons:

1. Most devices have a hard limit on the maximum image dimensions. Though there is no hard and fast rule, it would be a safe bet to limit any image within 255 x 255 pixel square size.

2. Most devices do not have a separate image memory and the heap in most devices is restricted to 200 KB (again, this could vary, but 200 KB limit is the safe limit, 512 KB is quite usual on most MIDP 2.0 phones).

3. Such a large image will take a lot of space in the jar file. (A Java application is packaged as a Java Archive file- the same as a compressed zip file and has an extension .jar). The safe limit for the jar size is very low. On some devices, as low as 64KB.

4. A game involves a fair amount of interaction between the background and the characters. Having a big image will necessitate getting the pixel data at a given position. For example, Ramson can stand on grass but has to be hurt by a water-fall. If the image is single piece, the only way to do this would be to get the pixel data at the location where Ramson is situated. But this, is not directly possible at least in MIDP 1.

5. Certain regions in the background need to be animated, for example the waterfall in Ramson's Quest is animated, to make it appear as if its flowing. This is not again not possible with a single background image.

All these reasons effectively rule out the possibility of using a single background image for the entire level. Now let us see how tiles help.

Below is a small section of a game level from Ramson's Quest 2 (a 1200 x 200 image scaled down to fit blog):

© Tinfo Mobile 2006

This 'big' image can be drawn using just a handful of 'small' tiles (just around 12 of them)!

To map which tile gets drawn where on the screen, we have a Tile-Map. A tile map is a two (or one) dimensional array which says which tile is to be drawn at the given location of a map.

The tile-map for the layer above may look something like:
0,0,0,0,0,0,0,0,1,0....

0,0,0,0,0,0,0,0,2,0...

0,0,0...

0,0,0...

4,0,0..

4,0,0..


(Assume, waterfall tile numbers are 1,2. Blank tiles are 0 and 4 is the wall tile)
I hope you get the picture.

As to how exactly a tile-map and a tile-sheet (an image containing the set of tiles) can be used to render a background and thus design game levels is something we will investigate in the next article.

As an exercise, google out the terms mentioned in bold in this article and know more about them. For the more enterprising readers, do go ahead and make a tile drawing algorithm! And do post a comment if you need any help.

I want to make a mobile game! - Part I

(Or, how do I get started on a mobile game development career?)

Introduction

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! Whenever you've played Roadrash on your PC, you should have pondered and thought over how you could do something like it yourself! If you think 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 ;-).

As for me, my initiation to this enchanting word was perchance (providential). I just happened to be put on a mobile game project half a decade back with nothing more than a web browser to rely on. So, most of the things I learnt - I learnt the hard way (Which is kinda good, since you know how exactly things should not be done). Anyways that brings us to the all important question:

Why mobile?

Thats a 'Yeh PSPO nahin jaanta? (an ancient Indian television saying ;) )' 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 almost 200 million mobile subscribers! And that my friends is the basic reason for the existence of the mobile entertainment industry. Even if the revenues might not be initially attractive, the customer base is.

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. This does not have a direct relation to the gaming world except for the fact that most CDMA handsets use BREW, while most GSM handsets use Java.

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

Usually Narrowband TDMA, 8 calls on one freq.
1 billion + subscribers (2004 statistic).
India 2007 August: 135 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.
Roughly 25% market.
India 2006 August: ~40 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.

In Part II, we will move on to the actual process followed in developing a mobile game.