Casual Games

Probably the biggest segment of games on Google Play consists of so-called casual games. So, what exactly is a casual game? That question has no concrete answer, but casual games do share a few common traits. Usually, they feature great accessibility so even non-gamers can pick them up easily, which immensely increases the pool of potential players. A game session is meant to take just a couple of minutes at most. However, the addictive nature of a casual game’s simplicity often gets players hooked for hours. The actual game mechanics range from extremely simplistic puzzle games to one-button platformers to something as simple as tossing a paper ball into a basket. The possibilities are endless because of the blurry definition of the casual genre.

Temple Run(see Figure 3-1) by Imangi Studios is the perfect casual game example. You guide a figure through multiple tracks filled with obstacles. The entire input scheme is based on swiping. If you swipe left or right, the character takes a turn in that direction (provided there’s an intersection ahead). If you swipe upward, the character jumps, while swiping downward makes the character slide beneath obstacles. Along the way you can pick up all kinds of rewards and power-ups. Easy-to-understand controls, a clear goal, and nice 3D graphics made this game an instant hit, both on Apple’s App Store and on Google Play.

Figure 3-1. Temple Run by Imangi Studios

Gem Miner: Dig Deeper(see Figure 3-2) by the one-man army Psym Mobile is a completely different animal. It is the sequel to the wildly successful Gem Miner by the same company. It only slightly iterates the original. You play a miner who tries to find valuable ores, metals, and gems in randomly generated mines. These treasures can be traded for better equipment to dig deeper and find even more valuable treasures. It exploits the fact that many people love the concept of grinding: without much effort, you are constantly rewarded with new gimmicks that keep you playing. Another interesting aspect of this game is that the mines are randomly generated. This increases the replay value of the game immensely without adding additional game mechanics. To spice things up a little, the game offers challenge levels with concrete aims and goals for which you get medals upon completion. It is a very lightweight achievement system.

Figure 3-2. Gem Miner: Dig Deeper by Psym Mobile

One more interesting aspect of this game is the way it’s monetized. Despite the current trend toward “freemium” games (the game itself is free, while additional content can be bought for often ridiculous prices), it uses the “old-school” paid model. At around $2 a pop and over 100,000 downloads, that’s quite a bit of money for a very simple game. These kind of sales numbers are rare on Android, especially with Psym Mobile having done basically no advertising for the game at all. The success of the predecessor and its huge player base pretty much guaranteed the success of the sequel.

A list of all of the possible subgenres of the casual game category would fill most of this book. Many more innovative game concepts can be found in this genre, and it is worth checking out the category in the market to get some inspiration.

Puzzle Games

Puzzle games need no introduction. We all know great games like Tetrisand Bejeweled. They are a big part of the Android gaming market, and they are highly popular with all segments of the demographic. In contrast to PC-based puzzle games, which usually just involve getting three objects of a color or shape together, many puzzle games on Android deviate from the classic match-three formula and use more elaborate, physics-based puzzles.

Cut the Rope (see Figure 3-3) by ZeptoLab is a superb example of a physics puzzler . The goal of the game is to feed candy to the little creature on each screen. The piece of candy has to be guided toward the creature by cutting ropes it is attached to, putting it into bubbles so it can float upward, circumnavigating obstacles, and so forth. Every game object is physically simulated to some degree. The game is powered by Box2D, a 2D physics engine. Cut the Rope has become an instant success, both on the iOS App Store and Google Play, and has even been ported to run in browsers!

Figure 3-3. Cut the Rope by ZeptoLab

Apparatus (see Figure 3-4) by Bithack (another one-man company) is heavily influenced by the old Amiga and PC classic Incredible Machines. Like Cut the Rope, it is a physics puzzler, but it gives the player a lot more control over the way she solves each puzzle. Various building blocks , like simple logs that can be nailed together, ropes, motors, and so on, can be combined in creative ways to take a blue ball from one end of the level to a target area.

Figure 3-4. Apparatus by Bithack

Besides the campaign mode with premade levels, there’s also a sandbox environment where you can let your creativity reign. Even better, your custom contraptions can be easily shared with others. This aspect of Apparatus guarantees that even if a player has finished the game, there is still tons of additional content to be explored.

Of course, you can also find all kinds of Tetris clones, match-three games , and other standard formulas on the market.

Action and Arcade Games

Action and arcade games usually unleash the full potential of the Android platform. Many of them feature stunning 3D visuals, demonstrating what is possible on the current generation of hardware. This genre has many subgenres, including racing games, shoot ’em ups, first- and third-person shooters, and platformers. This segment of the Android Market has gained a lot of traction over the past few years as big game studios have started to port their games to Android.

SHADOWGUN(see Figure 3-5) by MADFINGER Games is a visually stunning third-person shoot ’em up that shows off the computing power of recent Android phones and tablets. As with many AAA games, it is available on both Android and iOS. SHADOWGUN leverages Unity, a cross-platform game engine, and is one of the poster children for Unity’s power on mobile devices. Gameplay-wise, it is a dual-analog stick shooter that even allows for taking cover behind crates and other nice mechanics that usually aren’t found in mobile action games.

Figure 3-5. SHADOWGUN by MADFINGER Games

While hard numbers are hard to get a hold of, the statistics on the Android market seem to indicate that the number of downloads of SHADOWGUN is about on par with Gem Miner, previously discussed. This goes to show that it does not necessarily take a huge AAA team to create a successful Android game.

Tank Hero: Laser Wars (see Figure 3-6) is a sequel to Tank Hero and was created by a very small indie team called Clapfoot, Inc. You command a tank that you can equip with more and more crazy add-ons, like ray guns, sonic cannons, and so forth. Levels are very small and confined flat battlegrounds with interactive elements scattered around that you can use to your advantage to eliminate all opposing tanks on the playfield. The tank is controlled by simply touching enemies or the playing field, in response to which it will take the proper action (shoot or move, respectively). While it is not quite at the level of SHADWOGUN visually, it nevertheless has a rather good-looking dynamic lighting system. The lesson to be learned here is that even small teams can create a visually pleasing experience if they place constraints on the content, such as limiting the size of the playing field.

Figure 3-6. Tank Hero: Laser Wars by Clapfoot Inc.

Dragon, Fly! (see Figure 3-7) by Four Pixels is an adaption of the immensely successful game Tiny Wings by Andreas Illiger, which was available only on iOS at the time of writing. You control a little dragon that goes up and down an almost infinite number of slopes while collecting all kinds of gems. The little dragon can take off and fly if it accelerates fast enough. This is done by touching the screen while going down a slope. The mechanics are extremely simple, but the randomly generated worlds and the hunger for higher scores make people come back for more.

Figure 3-7. Dragon, Fly! by Four Pixels

Dragon, Fly!illustrates one phenomenon very well: often, specific mobile game genres turn up on iOS. The original creators often do not port their games over to Android, even though there is a huge demand. Other game developers can step in and provide the Android market with an alternative version. This can also totally backfire should the “inspired” game be too much of a rip-off, as was seen with Zynga’s take on a game called Tiny Tower (by NimbleBit). Extending an idea is usually well received, while blatantly ripping off another game is usually met with acrimony.

Max Payne(see Figure 3-8) by Rockstar Games is a port of the old PC game, which was published in 2001. We include it here to illustrate a growing trend of AAA publishers’ taking their old intellectual property and porting it over to the mobile environment. Max Payne tells the story of a policeman whose family was murdered by a drug cartel. Max goes on a rampage to avenge his wife and kid. All of this is embedded in a film noir–style narrative, illustrated via comic strips and short cut-scenes. The original game relied heavily on the standard mouse/keyboard combination we are used to using when playing shooters on the PC. Rockstar Games succeeded in creating touchscreen-based controls. While the controls are not as precise as on the PC, they are still good enough to make the game enjoyable on touchscreens.

Figure 3-8. Max Payne by Rockstar Games

The action and arcade genre is still a bit underrepresented on the market. Players are longing for good action titles, so maybe that can be your niche!

Tower-Defense Games

Given their immense success on the Android platform, we felt the need to discuss tower-defense games as their own genre. Tower-defense games became popular as a variant of PC real-time strategy games developed by the modding community. The concept was soon translated to stand-alone games. Tower-defense games currently represent the best-selling genre on Android.

In a typical tower-defense game , some mostly evil force is sending out critters in so-called waves to attack your castle/base/crystals/you name it. Your task is to defend that special place on the game map by placing defense turrets that shoot the incoming enemies. For each enemy you kill, you usually get some amount of money or points that you can invest in new turrets or upgrades. The concept is extremely simple, but getting the balance of this type of game right is quite difficult.

Defender(see Figure 3-9) by DroidHen is one of the most popular free games on Google Play, but it uses a simple spin on tower defense that is well known to flash gamers. Instead of building multiple towers, you have one player-controlled tower that can receive a number of upgrades, ranging from attack-power increases to splitting arrows. Besides the primary weapon, there are different tech trees of spells that can be cast to mow down the invading enemy forces. What’s nice about this game is that it is simple, easily understandable, and polished. The graphics are all clean and themed nicely together, and DroidHen got the balance just right, which tends to keep you playing much longer than you planned. This game is smart in how it monetizes in that there are a number of free upgrades you can get, but for the impatient, you can always purchase things a little early with real money and get instant gratification.

Figure 3-9. Defender by DroidHen

Defender has only one level, but it mixes up the baddies to deliver wave after wave of attack. It’s almost as if you don’t notice that it has only one level because it’s very nice looking and leads you to pay far more attention to the baddies, your weapons, and your spells. Overall, this should be good inspiration for the type of game a small team of developers can create in a reasonable amount of time, one that casual players will enjoy.

Social Games

You didn’t think we were going to skip social games, did you? If anything, the word “social” is the biggest buzz (and one of the biggest money makers) in our modern technology collective. What is social gaming? It is games in which you share experiences with your friends and acquaintances, interacting with each other usually in a viral feedback loop. It’s amazingly powerful, and if done right it can snowball into an avalanche of success.

Words with Friends (see Figure 3-10) by Zynga adds turn-based play to the already established genre of tile-based word creation. What’s really innovative about Words with Friendsis the integration of chat and multiple, simultaneous game play. You can have many games going at once, which takes the waiting out of waiting for a single game. One notable review (by John Mayer) said, “The ‘Words with Friends’ app is the new Twitter.” That’s a good synopsis of how well Zynga has utilized the social space and integrated it into a very accessible game.

Figure 3-10. Words with Friends by Zynga

Draw Something (see Figure 3-11) by OMGPOP is a game where players guess what someone is drawing stroke by stroke. Not only is it fun, but also other players submit their own drawings to friends, which makes for the magic of crowd-sourced content. Draw Something looks at first like a basic fingerpainting app, but just a few minutes into it, the essence of the game really pops out as you instantly want to submit your guess right then and there, guess another, and then draw your own and bring your friends in on the fun.

Figure 3-11. Draw Something by OMGPOP

Beyond the Genres

Many new games, ideas, genres, and apps don’t appear to be games at first, but they really are. Therefore, when entering Google Play, it’s difficult to really pinpoint specifically what is now innovative. We’ve seen games where a tablet is used as the game host and then connected to a TV, which in turn is connected via Bluetooth to multiple Android handsets, each used as a controller. Casual social games have been doing well for quite a while, and many popular titles that started on the Apple platform have now been ported to Android . Has everything possible already been done? No way! There will always be untapped markets and game ideas for those who are willing to take a few risks with new game ideas. Hardware is becoming ever faster, and that opens up entire new realms of possibilities that were previously unfeasible due to lack of CPU horsepower.

So, now that you know what’s already available on Android, we suggest that you fire up the Google Play application and check out some of the games just presented. Pay attention to their structure (for example, which screens lead to which other screens, which buttons do what, how game elements interact with each other, and so on). Getting a feeling for these things can actually be achieved by playing games with an analytical mindset. Push away the entertainment factor for a moment and concentrate on deconstructing the game. Once you’re done, come back and read on. We are going to design a very simple game on paper.

Core Game Mechanics

Before we start, here’s a list of what we need:

• A pair of scissors

• Something to write with

• Plenty of paper

In this phase of our game design, everything’s a moving target. Instead of carefully crafting nice images in Paint, Gimp, or Photoshop, we suggest you create basic building blocks out of paper and rearrange them on a table until they fit. You can easily change things physically without having to cope with a silly mouse. Once you are OK with your paper design, you can take photos or scan the design for future reference . Let’s start by creating the basic blocks of our core game screen. Figure 3-12 shows you our version of what is needed for the core game mechanics.

Figure 3-12. Game design building blocks

The leftmost rectangle is our screen, roughly the size of a Nexus One screen. That’s where we’ll place all the other elements. The next building blocks are two arrow buttons that we’ll use to control the snake. Finally, there’s the snake’s head, a couple of tail parts, and a piece it can eat. We also wrote out some numbers and cut them out. Those will be used to display the score. Figure 3-13 illustrates our vision of the initial playing field.

Figure 3-13. The initial playing field

Let’s define the game mechanics :

• The snake advances in the direction in which its head is pointed, dragging along its tail. Head and tail are composed of equally sized parts that do not differ much in their visuals.

• If the snake goes outside the screen’s boundaries, it reenters the screen from the opposite side.

• If the right arrow or left arrow button is pressed, the snake takes a 90-degree clockwise (right) or counterclockwise (left) turn.

• If the snake hits itself (for example, a part of its tail), the game is over.

• If the snake hits a piece with its head, the piece disappears, the score is increased by 10 points, and a new piece appears on the playing field in a location that is not occupied by the snake itself. The snake also grows by one tail part. That new tail part is attached to the end of the snake.

This is quite a complex description for such a simple game. Note that we ordered the items somewhat in ascending complexity. The behavior of the game when the snake eats a piece on the playing field is probably the most complex one. More elaborate games cannot, of course, be described in such a concise manner. Usually, you’d split these up into separate parts and design each part individually, connecting them in a final merge step at the end of the process.

The last game-mechanics item has this implication: the game will end eventually, as all spaces on the screen will be used up by the snake.

Now that our totally original game-mechanics idea looks good, let’s try to come up with a backstory for it.

A Story and an Art Style

While an epic story with zombies, spaceships, dwarves, and lots of explosions would be fun, we have to realize that we are limited in resources. Our drawing skills, as exemplified in Figure 3-12, are somewhat lacking. We couldn’t draw a zombie if our lives depended on it. So we did what any self-respecting indie game developer would do: resorted to the doodle style and adjusted the settings accordingly.

Enter the world of Mr. Nom. Mr. Nom is a paper snake who’s always eager to eat drops of ink that fall down from an unspecified source on his paper land. Mr. Nom is utterly selfish, and he has only a single, not-so-noble goal: becoming the biggest ink-filled paper snake in the world!

This little backstory allows us to define a few more things:

• The art style is doodly. We will actually scan in our building blocks later and use them in our game as graphical assets.

• As Mr. Nom is an individualist, we will modify his blocky nature a little and give him a proper snake face. And a hat.

• The digestible piece will be transformed into a set of ink stains.

• We’ll trick out the audio aspect of the game by letting Mr. Nom grunt each time he eats an ink stain.

• Instead of going for a boring title like “Doodle Snake,” let’s call the game “Mr. Nom,” a much more intriguing title.

Figure 3-14 shows Mr. Nom in his full glory, along with some ink stains that will replace the original block. We also sketched a doodly Mr. Nom logo that we can reuse throughout the game.

Figure 3-14. Mr. Nom, his hat, ink stains , and the logo

Screens and Transitions

With the game mechanics, backstory, characters, and art style fixed, we can now design our screens and the transitions between them. First, however, it’s important to understand exactly what makes up a screen:

• A screen is an atomic unit that fills the entire display, and it is responsible for exactly one part of the game (for example, the main menu, the settings menu, or the game screen where the action is happening).

• A screen can be composed of multiple components (for example, buttons, controls, heads-up displays, or the rendering of the game world).

• A screen allows the user to interact with the screen’s elements. These interactions can trigger screen transitions (for example, pressing a New Game button on the main menu could exchange the currently active main menu screen with the game screen or a level-selection screen).

With these definitions, we can put on our thinking caps and design all the screens of our Mr. Nom game.

The first thing our game will present to the player is the main menu screen. What makes a good main menu screen?

• Displaying the name of our game is a good idea in principle, so we’ll put in the Mr. Nom logo.

• To make things look more consistent, we also need a background. We’ll reuse the playing field background for this.

• Players will usually want to play the game, so let’s throw in a Play button.

• This will be our first interactive component .

• Players want to keep track of their progress and awesomeness, so we’ll also add a high-score button as shown in Figure 3-15, another interactive component.

  

  Figure 3-15. The main menu screen

• There might be people out there who don’t know Snake. Let’s give them some help in the form of a Help button that will transition to a help screen.

• While our sound design will be lovely, some players might still prefer to play in silence. Giving them a symbolic toggle button to enable and disable the sound will do the trick.

How we actually lay out these components on our screen is a matter of taste. You could start studying a subfield of computer science called human computer interfaces (HCI) to get the latest scientific opinion on how to present your application to the user. For Mr. Nom, that might be overkill, though. We settled on the simplistic design shown in Figure 3-15.

Note that all of these elements (the logo, the menu buttons, and so forth) are separate images.

We get an immediate advantage by starting with the main menu screen: we can directly derive more screens from the interactive components. In Mr. Nom’s case, we will need a game screen, a high-scores screen, and a help screen. We get away with not including a settings screen since the only setting (sound) is already present on the main menu screen.

Let’s ignore the game screen for a moment and concentrate first on the high-scores screen . We decided that high scores will be stored locally in Mr. Nom, so we’ll only keep track of a single player’s achievements. We also decided that only the five highest scores will be recorded. The high-scores screen will therefore look like Figure 3-16, showing the “HIGHSCORES” text at the top, followed by the five top scores and a single button with an arrow on it to indicate that you can transition back to something. We’ll reuse the background of the playing field again because we like it cheap.

Figure 3-16. The high-scores screen

Next up is the help screen. It will inform the player of the backstory and the game mechanics. All of that information is a bit too much to be presented on a single screen. Therefore, we’ll split up the help screen into multiple screens. Each of these screens will present one essential piece of information to the user: who Mr. Nom is and what he wants, how to control Mr. Nom to make him eat ink stains, and what Mr. Nom doesn’t like (namely eating himself). That’s a total of three help screens, as shown in Figure 3-17. Note that we added a button to each screen to indicate that there’s more information to be read. We’ll hook those screens up in a bit.

Figure 3-17. The help screens

Finally, there’s our game screen, which we already saw in action. There are a few details we left out, though. First, the game shouldn’t start immediately; we should give the player some time to get ready. The screen will therefore start off with a request to touch the screen to start the munching. This does not warrant a separate screen; we will directly implement that initial pause in the game screen.

Speaking of pauses , we’ll also add a button that allows the user to pause the game. Once it’s paused, we also need to give the user a way to resume the game. We’ll just display a big Resume button in that case. In the pause state, we’ll also display another button that will allow the user to return to the main menu screen. An additional Quit button lets the user go back to the main menu.

In case Mr. Nom bites his own tail, we need to inform the player that the game is over. We could implement a separate game-over screen, or we could stay within the game screen and just overlay a big “Game Over” message. In this case, we’ll opt for the latter. To round things out, we’ll also display the score the player achieved, along with a button to get back to the main menu.

Think of these different states of the game screen as subscreens. We have four subscreens: the initial get-ready state, the normal game-playing state, the paused state, and the game-over state. Figure 3-18 shows these subscreens.

Figure 3-18. The game screen and its four different states

Now it’s time to hook the screens together. Each screen has some interactive components that are made for transitioning to another screen.

• From the main menu screen, we can get to the game screen, the high-scores screen, and the help screen via their respective buttons.

• From the game screen, we can get back to the main menu screen either via the button in the paused state or the button in the game-over state.

• From the high-scores screen, we can get back to the main menu screen.

• From the first help screen, we can go to the second help screen; from the second to the third; and from the third to the fourth; from the fourth, we’ll return back to the main menu screen.

That’s all of our transitions ! Doesn’t look so bad, does it? Figure 3-19 visually summarizes all of the transitions, with arrows from each interactive component to the target screen. We also put in all of the elements that make up our screens.

Figure 3-19. All design elements and transitions

We have now finished our first full game design. What’s left is the implementation. How do we actually make this design into an executable game?

Application and Window Management

A game is just like any other computer program that has a UI. It is contained in some sort of window (if the underlying operating system’s UI paradigm is window based, which is the case for all mainstream operating systems). The window serves as a container, and we basically think of it as a canvas on which we draw our game content.

Most operating systems allow the user to interact with the window in a special way other than touching the client area or pressing a key. On desktop systems, you can usually drag the window around, resize it, or minimize it to some sort of taskbar. In Android, resizing is replaced with accommodating an orientation change, and minimizing is similar to putting the application in the background via a press of the Home button or as a reaction to an incoming call.

The application and window management module is also responsible for actually setting up the window and making sure it is filled by a single UI component to which we can later render and that receives input from the user in the form of touching or pressing keys. That UI component might be rendered via the CPU, or it can be hardware accelerated, as is the case with OpenGL ES.

The application and window management module does not have a concrete set of interfaces. We’ll merge it with the game framework later on. The things we have to remember are the application states and window events that we have to manage:

• Create: Called once when the window (and thus the application) is started up

• Pause: Called when the application is paused by some mechanism

• Resume: Called when the application is resumed and the window is again in the foreground

Input

The user will surely want to interact with our game in some way. That’s where the input module comes in. On most operating systems , input events such as touching the screen or pressing a key are dispatched to the currently focused window. The window will then further dispatch the event to the UI component that has the focus. The dispatching process is usually transparent to us; our only concern is getting the events from the focused UI component. The UI APIs of the operating system provide a mechanism by which to hook into the event-dispatching system so that we can easily register and record the events. This hooking into and recording of events is the main task of the input module.

What can we do with the recorded information? There are two modi operandi:

• Polling: With polling, we only check the current state of the input devices. Any states between the current check and the last check will be lost. This way of input handling is suitable for checking things like whether a user touches a specific button, for example. It is not suitable for tracking text input, as the order of key events is lost.

• Event-based handling: This gives us a full chronological history of the events that have occurred since we last checked. It is a suitable mechanism for performing text input or any other task that relies on the order of events. It’s also useful for detecting when a finger first touched the screen or when the finger was lifted.

What input devices do we want to handle? On Android, we have three main input methods: touchscreen, keyboard/trackball, and accelerometer. The first two are suitable for both polling and event-based handling. The accelerometer is usually just used for polling.

The touchscreen can generate three events:

• Touch down: This happens when a finger is touched to the screen.

• Touch drag: This occurs when a finger is dragged across the screen. Before a drag, there’s always a down event.

• Touch up: This happens when a finger is lifted from the screen.

Each touch event has additional information: the position relative to the UI component origin and a pointer index used in multitouch environments to identify and track separate fingers.

The keyboard can generate two types of events:

• Key down: This happens when a key is pressed down.

• Key up: This happens when a key is lifted. This event is always preceded by a key-down event.

Key events also carry additional information. Key-down events store the pressed key’s code. Key-up events store the key’s code and an actual Unicode character. There’s a difference between a key’s code and the Unicode character generated by a key-up event. In the latter case, the state of other keys is also taken into account, such as the Shift key. This way, we can get uppercase and lowercase letters in a key-up event, for example. With a key-down event, we only know that a certain key was pressed; we have no information on which character that keypress would actually generate.

Developers seeking to use custom USB hardware , including joysticks, analog controllers, special keyboards, touchpads, or other Android-supported peripherals, can do this by utilizing the android.hardware.usb package APIs, which were introduced in API level 12 (Android 3.1) and were also backported to Android 2.3.4 via the package com.android.future.usb. The USB APIs enable an Android device to operate in either host mode, which allows for peripherals to be attached to and used by the Android device, or accessory mode, which allows for the device to act as an accessory to another USB host. These APIs aren’t quite beginner material, as the device access is very low level, offering data-streaming I/O to the USB accessory, but it’s important to note that the functionality is indeed there. If your game design revolves around a specific USB accessory, you will certainly want to develop a communication module for the accessory and prototype using it.

Finally, there’s the accelerometer . It’s important to understand that while nearly all handsets and tablets have accelerometers as standard hardware, many new devices, including set-top boxes, may not have an accelerometer, so always plan on having multiple modes of input!

To use the accelerometer, we always poll the accelerometer’s state. The accelerometer reports the acceleration exerted by the gravity of our planet on one of the three axes of the accelerometer. The axes are called x, y, and z. Figure 3-20 depicts each axis’s orientation. The acceleration on each axis is expressed in meters per second squared (m/s²). From physics class, we know that an object will accelerate at roughly 9.8 m/s² when in free fall on planet Earth. Other planets have a different gravity, so the acceleration constant is also different. For the sake of simplicity, we’ll only deal with planet Earth here. When an axis points away from the center of the Earth, the maximum acceleration is applied to it. If an axis points toward the center of the Earth, we get a negative maximum acceleration. If you hold your phone upright in portrait mode, then the y axis will report an acceleration of 9.8 m/s², for example. In Figure 3-20, the z axis would report an acceleration of 9.8 m/s², and the x and y axes would report an acceleration of zero.

Figure 3-20. The accelerometer axes on an Android phone. The z axis points out of the phone

Now, let’s define an interface that gives us polling access to the touchscreen, the keyboard, and the accelerometer and that also gives us event-based access to the touchscreen and keyboard (see Listing 3-1).

Listing 3-1. The input interface and the KeyEvent and TouchEvent classes

package com.badlogic.androidgames.framework;

import  java.util.List;

public interface Input  {
public class  KeyEvent {
public static final int KEY_DOWN  = 0;
public static final int KEY_UP  = 1;

public int  type; public int keyCode; public char keyChar;
}

public static class  TouchEvent {
public static final int TOUCH_DOWN  = 0; public static final int TOUCH_UP  = 1; public static final int TOUCH_DRAGGED  = 2;

public int  type; public int x, y; public int pointer;
}

public boolean isKeyPressed(int  keyCode); public boolean isTouchDown(int  pointer); public int getTouchX(int  pointer);
public int getTouchY(int  pointer);

public float getAccelX(); public float getAccelY(); public float  getAccelZ();
public List<KeyEvent> getKeyEvents();

public List<TouchEvent> getTouchEvents()                                                                                                                                                                                            ;
}

Our definition is started off by two classes, KeyEvent and TouchEvent. The KeyEvent class defines constants that encode a KeyEvent’s type; the TouchEvent class does the same. A KeyEvent instance records its type, the key’s code, and its Unicode character in case the event’s type is KEY_UP.

The TouchEvent code is similar, and it holds the TouchEvent’s type, the position of the finger relative to the UI component’s origin, and the pointer ID that was given to the finger by the touchscreen driver. The pointer ID for a finger will stay the same for as long as that finger is on the screen. If two fingers are down and finger 0 is lifted, then finger 1 keeps its ID for as long as it is touching the screen. A new finger will get the first free ID, which would be 0 in this example. Pointer IDs are often assigned sequentially, but it is not guaranteed to happen that way. For example, a Sony Xperia Play uses 15 IDs and assigns them to touches in a round-robin manner. Do not ever make assumptions in your code about the ID of a new pointer—you can only read the ID of a pointer by using the index and reference it until the pointer has been lifted.

Next are the polling methods of the input interface, which should be pretty self-explanatory. Input.isKeyPressed() takes a keyCode and returns whether the corresponding key is currently pressed or not. Input.isTouchDown(), Input.getTouchX(), and Input.getTouchY() return whether a given pointer is down, as well as its current x and y coordinates. Note that the coordinates will be undefined if the corresponding pointer is not actually touching the screen.

Input.getAccelX(), Input.getAccelY(), and Input.getAccelZ()return the respective acceleration values of each accelerometer axis.

The last two methods are used for event-based handling. They return the KeyEvent and TouchEvent instances that got recorded since the last time we called these methods. The events are ordered according to when they occurred, with the newest event being at the end of the list. With this simple interface and these helper classes , we have all our input needs covered. Let’s move on to handling files.

File I/O

Reading and writing files is quite essential for our game development endeavor. Given that we are in Java land, we are mostly concerned with creating InputStream and OutputStream instances, the standard Java mechanisms for reading and writing data from and to a specific file. In our case, we are mostly concerned with reading files that we package with our game, such as level files, images, and audio files. Writing files is something we’ll do a lot less often. Usually, we only write files if we want to maintain high scores or game settings, or save a game state so that users can pick up from where they left off.

We want the easiest possible file-accessing mechanism. Listing 3-2 shows our proposal for a simple interface.

Listing 3-2. The file I/O interface

package com.badlogic.androidgames.framework;

import java.io.IOException; import java.io.InputStream; import  java.io.OutputStream;

public interface FileIO  {
InputStream readAsset(String fileName)  throws IOException;

InputStream readFile(String fileName)  throws IOException;

OutputStream writeFile(String fileName)  throws IOException;
}

That’s rather lean and mean. We just specify a filename and get a stream in return. As we usually do in Java, we will throw an IOException in case something goes wrong. Where we read and write files from and to will depend on the implementation, of course. Assets will be read from our application’s APK file, and files will be read from and written to the SD card (also known as external storage).

The returned InputStreams and OutputStreamsare plain-old Java streams. Of course, we have to close them once we are finished using them.

Audio

While audio programming is a rather complex topic, we can get away with a very simple abstraction. We will not do any advanced audio processing; we’ll just play back sound effects and music that we load from files, much like we’ll load bitmaps in the graphics module.

Before we dive into our module interfaces, though, let’s stop for a moment and get some idea of what sound actually is and how it is represented digitally.

package com.badlogic.androidgames.framework;

public interface Audio {
Music newMusic(String  filename);

Sound  newSound(String filename);
}

package com.badlogic.androidgames.framework;

public interface Music {
public void play(); public void stop(); public void  pause();
void  setLooping(boolean  looping);  void  setVolume(float volume); public boolean isPlaying();
public boolean isStopped();

public boolean isLooping();

public void  dispose();
}

package com.badlogic.androidgames.framework;

public interface Sound  {
void  play(float  volume);
...
void  dispose();

}

Graphics

The last module at the core of our game framework is the graphics module. As you might have guessed, it will be responsible for drawing images (also known as bitmaps) on our screen. This may sound easy, but if you want high-performance graphics, you have to know at least the basics of graphics programming. Let’s start with the basics of 2D graphics.

The first question we need to ask goes like this: How on Earth are the images output to my display? The answer is rather involved, and we do not necessarily need to know all the details. We’ll just quickly review what’s happening inside our computer and the display.

Of Rasters , Pixels, and Framebuffers

Today’s displays are raster based. A raster is a two-dimensional grid of so-called picture elements. You might know them as pixels, and we’ll refer to them as such in the subsequent text. The raster grid has a limited width and height, which we usually express as the number of pixels per row and per column. If you feel brave, you can turn on your computer and try to make out individual pixels on your display. Note that we’re not responsible for any damage this does to your eyes, though.

A pixel has two attributes : a position within the grid and a color. A pixel’s position is given as two-dimensional coordinates within a discrete coordinate system. Discrete means that a coordinate is always at an integer position. Coordinates are defined within a Euclidean coordinate system imposed on the grid. The origin of the coordinate system is the top-left corner of the grid. The positive x axis points to the right and the y axis points downward. The last item is what confuses people the most. We’ll come back to it in a minute; there’s a simple reason why this is the case.

Ignoring the silly y axis, we can see that, due to the discrete nature of our coordinates, the origin is coincident with the top-left pixel in the grid, which is located at (0,0). The pixel to the right of the origin pixel is located at (1,0), the pixel beneath the origin pixel is at (0,1), and so on (see the left side of Figure 3-21). The display’s raster grid is finite, so there’s a limited number of meaningful coordinates. Negative coordinates are outside the screen. Coordinates greater than or equal to the width or height of the raster are also outside the screen. Note that the biggest x coordinate is the raster’s width minus 1, and the biggest y coordinate is the raster’s height minus 1. That’s due to the origin being coincident with the top-left pixel. Off-by-one errors are a common source of frustration in graphics programming.

Figure 3-21. Display raster grid and VRAM, oversimplified

The display receives a constant stream of information from the graphics processor. It encodes the color of each pixel in the display’s raster, as specified by the program or operating system in control of drawing to the screen. The display will refresh its state a few dozen times per second. The exact rate is called the refresh rate. It is expressed in hertz. Liquid-crystal display (LCD) monitors usually have a refresh rate of 60Hz per second; cathode ray tube (CRT) monitors and plasma monitors often have higher refresh rates.

The graphics processor has access to a special memory area known as video random access memory, or VRAM. Within VRAM there’s a reserved area for storing each pixel to be displayed on the screen. This area is usually called the framebuffer. A complete screen image is therefore called a frame. For each pixel in the display’s raster grid, there’s a corresponding memory address in the framebuffer that holds the pixel’s color. When we want to change what’s displayed on the screen, we simply change the color values of the pixels in that memory area in VRAM.

Now, it’s time to explain why the y axis in the display’s coordinate system is pointing downward. Memory, be it VRAM or normal RAM , is linear and one dimensional. Think of it as a one-dimensional array. So how do we map the two-dimensional pixel coordinates to one-dimensional memory addresses? Figure 3-21 shows a rather small display raster grid of three-by-two pixels, as well as its representation in VRAM. (We assume VRAM only consists of the framebuffer memory .) From this, we can easily derive the following formula to calculate the memory address of a pixel at (x,y):

int address = x + y * rasterWidth;

We can also go the other way around, from an address to the x and y coordinates of a pixel:

int x = address %   rasterWidth;
int y = address / rasterWidth;

So, the y axis is pointing downward because of the memory layout of the pixel colors in VRAM. This is actually a sort of legacy inherited from the early days of computer graphics. Monitors would update the color of each pixel on the screen, starting at the top-left corner, moving to the right, and tracing back to the left on the next line, until they reached the bottom of the screen. It was convenient to have the VRAM contents laid out in a manner that eased the transfer of the color information to the monitor.

Note

If we had full access to the framebuffer, we could use the preceding equation to write a full-fledged graphics library to draw pixels, lines, rectangles, images loaded to memory, and so on. Modern operating systems do not grant us direct access to the framebuffer for various reasons. Instead, we usually draw to a memory area that is then copied to the actual framebuffer by the operating system. The general concepts hold true in this case as well, though! If you are interested in how to do these low-level things efficiently, search the Web for a guy called Bresenham and his line-and-circle-drawing algorithms.

Color Models

What we just discussed is called a color model, specifically the RGB color model. RGB stands for red, green, and blue, of course. There are many more color models we could use, such as YUV and CMYK. In most graphics programming APIs, the RGB color model is pretty much the standard, though, so we’ll only discuss that here.

The RGB color model is called an additive color model, due to the fact that the final color is derived via mixing the additive primary colors red, green, and blue. You’ve probably experimented with mixing primary colors in school. Figure 3-22 shows you some examples for RGB color mixing to refresh your memory a little bit.

Figure 3-22. Having fun with mixing the primary colors red, green, and blue

We can, of course, generate a lot more colors than the ones shown in Figure 3-22 by varying the intensity of the red, green, and blue components. Each component can have an intensity value between 0 and some maximum value (say, 1). If we interpret each color component as a value on one of the three axes of a three-dimensional Euclidian space , we can plot a so-called color cube, as depicted in Figure 3-23. There are a lot more colors available to us if we vary the intensity of each component. A color is given as a triplet (red, green, blue) where each component is in the range between 0.0 and 1.0 (0.0 means no intensity for that color, and 1.0 means full intensity). The color black is at the origin (0,0,0), and the color white is at (1,1,1).

Figure 3-23. The mighty RGB color cube

Encoding Colors Digitally

How can we encode an RGB color triplet in computer memory? First, we have to define what data type we want to use for the color components. We could use floating-point numbers and specify the valid range as being between 0.0 and 1.0. This would give us quite some resolution for each component and would make a lot of different colors available to us. Sadly, this approach uses up a lot of space (3 times either 4 or 8 bytes per pixel, depending on whether we use 32-bit or 64-bit floats).

We can do better—at the expense of losing a few colors—which is totally OK, since displays usually have a limited range of colors that they can emit. Instead of using a float for each component, we can use an unsigned integer. Now, if we use a 32-bit integer for each component, we haven’t gained anything. Instead, we use an unsigned byte for each component. The intensity for each component then ranges from 0 to 255. For 1 pixel, we thus need 3 bytes, or 24 bits. That’s 2 to the power of 24 (16,777,216) different colors. That’s enough for our needs.

Can we get that down even more? Yes, we can. We can pack each component into a single 16-bit word, so each pixel needs just 2 bytes of storage. Red uses 5 bits, green uses 6 bits, and blue uses the rest of 5 bits. The reason green gets 6 bits is that our eyes can see more shades of green than of red or blue. All bits together make 2 to the power of 16 (65,536) different colors that we can encode. Figure 3-24 shows how a color is encoded with the three encodings described previously.

Figure 3-24. Color encodings of a nice shade of pink (which will be gray in the print copy of this book, sorry)

In the case of the float, we could use three 32-bit Java floats. In the 24-bit encoding case, we have a little problem: there’s no 24-bit integer type in Java, so we could either store each component in a single byte or use a 32-bit integer, leaving the upper 8 bits unused. In the case of the 16-bit encoding, we can again either use two separate bytes or store the components in a single short value. Note that Java does not have unsigned types. Due to the power of two’s complement, we can safely use signed integer types to store unsigned values.

For both 16- and 24-bit integer encodings , we also need to specify the order in which we store the three components in the short or integer value. Two methods are usually used: RGB and BGR. Figure 3-23 uses RGB encoding. The blue component is in the lowest 5 or 8 bits, the green component uses up the next 6 or 8 bits, and the red component uses the upper 5 or 8 bits. BGR encoding just reverses this order. The green bits stay where they are, and the red and blue bits swap places. We’ll use the RGB order throughout this book, as Android’s graphics APIs work with that order as well. Let’s summarize the color encodings discussed so far:

• A 32-bit float RGB encoding has 12 bytes for each pixel, and intensities that vary between 0.0 and 1.0.

• A 24-bit integer RGB encoding has 3 or 4 bytes for each pixel, and intensities that vary between 0 and 255. The order of the components can be RGB or BGR. This is also known as RGB888 or BGR888 in some circles, where 8 specifies the number of bits per component.

• A 16-bit integer RGB encoding has 2 bytes for each pixel; red and blue have intensities between 0 and 31, and green has intensities between 0 and 63. The order of the components can be RGB or BGR. This is also known as RGB565 or BGR565 in some circles, where 5 and 6 specify the number of bits of the respective component.

The type of encoding we use is also called the color depth. Images we create and store on disk or in memory have a defined color depth, and so do the framebuffers of the actual graphics hardware and the display itself. Today’s displays usually have a default color depth of 24 bits, and they can be configured to use less in some cases. The framebuffer of the graphics hardware is also rather flexible, and it can use many different color depths. Our own images can, of course, also have any color depth we like.

Note

There are a lot more ways to encode per-pixel color information. Apart from RGB colors, we could also have grayscale pixels, which only have a single component. As those are not used a lot, we’ll ignore them at this point.

Alpha Compositing and Blending

Before we can start designing our graphics module interfaces, we have to tackle one more thing: image compositing. For the sake of this discussion, assume that we have a framebuffer to which we can render, as well as a bunch of images loaded into RAM that we’ll throw at the framebuffer. Figure 3-25 shows a simple background image, as well as Bob, a zombie-slaying ladies’ man.

Figure 3-25. A simple background and Bob, master of the universe

To draw Bob’s world, we’d first draw the background image to the framebuffer, followed by drawing Bob over the background image in the framebuffer . This process is called compositing, as we compose different images into a final image. The order in which we draw images is relevant, as any new drawing operation will overwrite the current contents in the framebuffer. So, what would be the final output of our compositing? Figure 3-26 shows it to you.

Figure 3-26. Compositing the background and Bob into the framebuffer (not what we wanted)

Ouch, that’s not what we wanted. In Figure 3-26, notice that Bob is surrounded by white pixels. When we draw Bob on top of the background in the framebuffer, those white pixels also get drawn, effectively overwriting the background. How can we draw Bob’s image so that only Bob’s pixels are drawn and the white background pixels are ignored?

Enter alpha blending. Well, in Bob’s case it’s technically called alpha masking, but that’s just a subset of alpha blending. Graphics software usually lets us not only specify the RGB values of a pixel, but also indicate its translucency. Think of it as yet another component of a pixel’s color. We can encode it just like we encoded the red, green, and blue components.

We hinted earlier that we could store a 24-bit RGB triplet in a 32-bit integer. There are 8 unused bits in that 32-bit integer that we can grab and in which we can store our alpha value. We can then specify the translucency of a pixel from 0 to 255, where 0 is fully transparent and 255 is opaque. This encoding is known as ARGB8888 or BGRA8888, depending on the order of the components. There are also RGBA8888 and ABGR8888 formats, of course.

In the case of 16-bit encoding , we have a slight problem: all of the bits of our 16-bit short are taken up by the color components. Let’s instead imitate the ARGB8888 format and define an ARGB4444 format analogously. That leaves 12 bits for our RGB values in total—4 bits per color component.

We can easily imagine how a rendering method for pixels that are fully translucent or opaque would work. In the first case, we’d just ignore pixels with an alpha component of zero. In the second case, we’d simply overwrite the destination pixel. When a pixel has neither a fully translucent nor fully opaque alpha component, however, things get a tiny bit more complicated.

When talking about blending in a formal way, we have to define a few things:

• Blending has two inputs and one output, each represented as an RGB triplet (C) plus an alpha value (a).

• The two inputs are called source and destination. The source is the pixel from the image we want to draw over the destination image (that is, the framebuffer). The destination is the pixel we are going to overdraw (partially) with our source pixel.

• The output is again a color expressed as an RGB triplet and an alpha value. Usually, we just ignore the alpha value, though. For simplicity’s sake, we’ll do that in this chapter.

• To simplify our math a little bit, we’ll represent RGB and alpha values as floats in the range of 0.0 to 1.0.

Equipped with those definitions, we can create so-called blending equations . The simplest equation looks like this:

red = src.red * src.alpha + dst.red * (1  – src.alpha)
green  = src.green  * src.alpha + dst.green  * (1  – src.alpha)
blue = src.blue * src.alpha + dst.blue * (1  – src.alpha)

src and dst are the pixels of the source and destination we want to blend with each other. We blend the two colors component-wise. Note the absence of the destination alpha value in these blending equations. Let’s try an example and see what it does:

src  = (1, 0.5,  0.5), src.alpha = 0.5,  dst  = (0, 1,  0)
red = 1 * 0.5  + 0 * (1  – 0.5)  = 0.5
blue  = 0.5  * 0.5  + 1 * (1  – 0.5)  = 0.75 red = 0.5  * 0.5  + 0 * (1  – 0.5)  = 0.25

Figure 3-27 illustrates the preceding equation. Our source color is a shade of pink, and the destination color is a shade of green. Both colors contribute equally to the final output color, resulting in a somewhat dirty shade of green or olive.

Figure 3-27. Blending two pixels

Two fine gentlemen named Porter and Duff came up with a slew of blending equations. We will stick with the preceding equation , though, as it covers most of our use cases. Try experimenting with it on paper or in the graphics software of your choice to get a feeling for what blending will do to your composition.

Note

Blending is a wide field. If you want to exploit it to its fullest potential, we suggest that you search the Web for Porter and Duff’s original work on the subject. For the games we will write, though, the preceding equation is sufficient.

Notice that there are a lot of multiplications involved in the preceding equations (six, to be precise). Multiplications are costly, and we should try to avoid them where possible. In the case of blending, we can get rid of three of those multiplications by pre-multiplying the RGB values of the source pixel color with the source alpha value. Most graphics software supports pre-multiplication of an image’s RGB values with the respective alphas. If that is not supported, you can do it at load time in memory. However, when we use a graphics API to draw our image with blending, we have to make sure that we use the correct blending equation. Our image will still contain the alpha values, so the preceding equation would output incorrect results. The source alpha must not be multiplied with the source color. Luckily, all Android graphics APIs allow us to specify fully how we want to blend our images.

In Bob’s case, we just set all the white pixels’ alpha values to zero in our preferred graphics software program , load the image in ARGB8888 or ARGB4444 format , maybe pre-multiply the alpha, and use a drawing method that does the actual alpha blending with the correct blending equation. The result would look like Figure 3-28.

Figure 3-28. Bob blended is on the left, and Bob in Paint.NET is on the right. The checkerboard illustrates that the alpha of the white background pixels is zero, so the background checkerboard shines through

Note

The JPEG format does not support the storage of alpha values per pixel. Use the PNG format in that case.

package com.badlogic.androidgames.framework;

public interface Graphics {
public static enum PixmapFormat   {
ARGB8888,  ARGB4444,  RGB565
}

public Pixmap  newPixmap(String fileName,  PixmapFormat format);

public void  clear(int color);

public void  drawPixel(int  x, int y, int color);

public void  drawLine(int  x, int y, int x2,  int y2,  int color);

public void  drawRect(int  x, int y, int width, int height, int color);

public void  drawPixmap(Pixmap pixmap, int x, int y, int srcX,  int srcY,
int srcWidth,  int srcHeight);

public void  drawPixmap(Pixmap pixmap, int x, int y);

public int  getWidth();

public int  getHeight();
}

package com.badlogic.androidgames.framework;

import  com.badlogic.androidgames.framework.Graphics.PixmapFormat;

public interface Pixmap  {
public int  getWidth();

public int  getHeight();

public PixmapFormat getFormat();

public void  dispose();
}