Wednesday, August 22, 2007

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.

No comments: