Planning the first game

In this section, we will flesh out exactly what our game will be. The backstory; who is our hero and what are they trying to achieve? The game mechanics; what will the player actually do? What buttons will he press and in what way is that a challenge or fun thing to do? Then, we will look at the rules. What constitutes victory, death, and progress? Finally, we will get technical and start to examine how we will actually build the game.

Backstory

Valerie has been defending the far outposts of humanity since the early '80s. Her brave exploits were originally immortalized in the 1981 arcade classic, Defender. However, after over 30 years on the front line, she is retiring and it is time to begin the journey home. Unfortunately, in a recent skirmish, her ship's engines and navigation systems were severely damaged. Therefore, now she must fly all the way home using only her boost thruster.

This means that she must fly her ship by simultaneously thrusting up and forward, kind of bouncing really, while avoiding enemies who try to crash into her. In a recent communication with Earth, Valerie was heard to claim that it was, "Like trying to fly a lame bird." This is some concept art of Valerie in her damaged ship because it helps to visualize our game as early as possible.

Now that we have learned a little bit about our hero and her predicament, we take a closer look at the mechanics of the game.

The game mechanics

Mechanics are the key actions that a player must make and become good at, to be able to beat the game. When designing a game, you can rely on tried and tested ideas for mechanics or you can invent your own. In Tappy Defender, we will be using a mechanic where the player taps and holds the screen to boost the ship.

This boosting will raise the ship up the screen, but will also make the ship speed up and therefore be more vulnerable. When the player removes their finger, the boost engine will cut out and the ship will fall downward and decelerate, thus making the ship slightly less vulnerable. Therefore, a very fine and masterful balance of boosting and not boosting is required to survive.

Tappy Defender is of course heavily inspired by Flappy Bird and a multitude of similar games that followed its success.

Instead of a how-far-can-I-get scoring system like Flappy Bird, Tappy Defender will have a goal of reaching "home". Then, the player can replay the game multiple times in order to try and beat their fastest time. Of course to go faster, the player must boost more frequently and put Valerie in greater peril.

Note

In the unlikely event you have never played or seen Flappy Bird, it is well worth spending 5 minutes having a play with this type of game now. You can download one of the many Flappy Bird inspired apps from the Google Play store:

https://play.google.com/store/search?q=flappy%20bird&c=apps

Rules for the game

Here, we will define things which balance the game and make it fair and consistent for the player:

• The player's ship is much tougher than the enemy ships. This is because the player's ship has shields. Each time the player collides with an enemy, the enemy is instantly destroyed, but the player loses a shield. The player has three shields.
• The player will need to fly a set number of kilometers to reach home.
• Every time the player reaches home, they win the game. If their time was the fastest, they also get a new fastest time, like a high score.
• Enemies will spawn at a random height on the far right of the screen and fly toward the player at a random speed.

The player is always positioned on the far left of the screen, but boosting will mean the enemies approach more quickly.

The design

We will use a loose design pattern, where we will separate our code based on a control part, model part, and view. This is how we will separate our code into three areas.

Control

This is the part of our code that will control all other parts. It will decide when to show the view, it will initialize all our game objects from the model, and it will prompt decisions based on the states of data to take place within the model.

Model

The model is our game data and logic. What do the ships look like? Where on the screen are our ships? How fast are they going, and so on. Furthermore, the model part of our code is the intelligence system for each of our game objects. Although our enemies in this game don't have sophisticated AI, they will know and decide for themselves how fast they are going, when to respawn and more.

View

The view is exactly what it sounds like. It is the part of our code that will do the actual drawing based on the state of the models. It will draw when the control part of our code tells it. It will not have any influence over the game objects. For example, the view will not decide where an object is or even what it looks like. It just draws and then hands control back to the control code.

Design pattern reality check

In reality, the separation is not as clear as the discussion suggests. In fact, the code for drawing and control is within the same class. However, you will see that the logic of drawing and controlling is separate within that class.

By separating our game into these three parts, we will see how we simplify the development and avoid getting tied up in messy code that constantly expands as we add new features to our game.

Let's look more closely at where this pattern fits in with our code.

The game code structure

First of all, we must take account of the system we are working within. In this case, it is the Android system. If you have been making Android apps for a while, you may be wondering where this pattern stuff fits in with the Android Activity lifecycle. If you are new to Android, you might ask what the Activity lifecycle is.

The Android Activity lifecycle

The Android Activity lifecycle is the framework we must work within to make any type of Android app. There is a class called Activity that we must derive from and is an entry point to our app. In addition, we need to be aware that this class, that our game is an object of, also has some methods we can override. These methods control the lifecycle of our app.

When an app is started by the user, our Activity object is created and a number of the methods that we can override are called in sequence. This is what happens.

When the Activity object is created, three methods are called in sequence; onCreate(), onStart(), and onResume(). At this point, the app is now running. In addition, when the user quits an app or the app is interrupted, perhaps by a phone call, the onPause method is called. The user may decide, perhaps after completing their phone call, to return to the app. If this happens, the onResume method is called, following which the app is running again.

Should the user not return to the app or the Android system decides that it wants the system resources for something else, two further methods are called to clean up. First onStop(), and then onDestroy(). The app is now destroyed and any attempt to return to the game again will result in the Activity lifecycle starting from the beginning.

All we have to do as game programmers is be aware of this lifecycle and observe a few rules of good housekeeping. We will implement and explain the rules of good housekeeping as we proceed.

Note

The Android Activity lifecycle is much more complex and far more nuanced than I have just explained it. However, we know everything we need to get programming our first game. If you want to know more please have a look at this article on the Android developer's web site at:

http://developer.android.com/reference/android/app/Activity.html

Once we have catered for the Android Activity lifecycle, the core methods of our class representing the control part of the pattern will be as simple as this:

1. Update the state of our game objects.
2. Draw the game objects based on their state.
3. Pause to lock the frame rate.
4. Get player input. Actually because parts 1, 2, and 3 happen in a thread, this part can happen at any time.
5. Repeat.

One last bit of preparation, before we start to build our game for real.

The Android Studio file structure

The Android system is quite particular about where we put our class files, including Activity and where in the file hierarchy we place our assets like sound files and graphics.

Here is a really quick overview of where we will be putting everything. You don't need to memorize this, as we will remind ourselves of the correct folder while adding assets. We will step through the activity/class creation process the first few times we need to do it.

As a heads up, here is an annotated diagram of what your Android Studio project explorer will look like by the end of the Tappy Defender project:

Now, we can actually start building Tappy Defender.