Chapter 2

Star Fighter: A 2-D Shooter

The game you will be creating as you work your way through this book is Star Fighter. Star Fighter is a 2-D, top-down, scrolling shooter. Even though the action is fairly limited, the story is surprisingly detailed. In this chapter, you’ll get a sneak preview of the game and the story behind it. You will also learn about the different parts of the game engine and what the game engine does.

Telling the Star Fighter Story

The story for Star Fighter is as follows; we will be referring to it periodically as we progress through this book:

Captain John Starke is a grizzled galactic war veteran. He fought his way out of every battle the Planetary Coalition has been involved in. Now, on his way back to earth and ready to retire from years of service to a quiet little farm in western Massachusetts, he finds himself caught in the middle of a surprise enemy invasion force.

Captain Starke prepares for battle. But this is no ordinary Kordark invasion fleet; something is different.

Starke cranks up the thrusters on his AF-718 and sets his guns to automatically fire. Luckily, the AF-718 is light and nimble. As long as he can avoid enemy guns and the occasional collision, the autofire cannons should make short work of the smaller Kordark fighters.

Unfortunately, what the AF-718 has in agility and autofire capabilities, it lacks in shields. Captain Starke is best served by avoiding the enemy craft altogether. If he does sustain any damage, after three strikes, he is out. The AF-718 can’t take very many direct blaster hits without good shields. As for a direct collision from an enemy, unfortunately, it is “one and done” for Captain Starke.

While Captain Starke is navigating his way through wave after wave of enemy ships, he may be lucky enough to come across some debris of other destroyed AF-718s—casualties of the last group to be surprised by the invasion force. As long as he is not destroyed along the way, Captain Starke may find a use for these parts.

The AF-718 has a very helpful feature that will aid Captain Starke in his fight. The latest versions of the AF-718, specially made for the last Centelum Prime Rebellion, are equipped with a self-repair mode. If Captain Starke gets into trouble and he is losing his shields, or finds that he needs even more firepower, all he needs to do is navigate his ship up to some of the AF-718 parts that are drifting around the battle space. He should be able to obtain anything from stronger shields, which could double or triple the amount of damage that his ship can take, to more powerful guns that are faster and require fewer hits to destroy the enemy.

Captain Starke and his AF-718 are not the only ones with tricks up their sleeves. The Kordark invasion fleet is made up of three different ships:

• Kordark Scout
• Kordark Interceptor
• Larash War Ship

Kordark Scouts are the most numerous of all of the ships in the invasion fleet. They are fast—just as fast as Captain Starke’s AF-718. The Scout flies in a swift but predictable pattern. This should make them easy to recognize and even easier to anticipate. Good thing for Starke, in diverting all of the Scout’s power to their thrust engines, the Kordarks gave them very weak shields. One good blast from the AF-718 should be all that is needed to take down a Kordark Scout. They do have a single blast cannon mounted on the front of the ship that fires slow, single-round bursts. Some rapid fire and quick navigation should get the AF-718 out of harm’s way and give Captain Starke the leverage he needs to destroy a Scout.

Kordark Interceptors, on the other hand, are very direct and deliberate enemies. They will fly slowly but directly at Captain Starke’s AF-718. An Interceptor is unmanned and is used as a computer-guided battering ram. They are programmed to take out all enemies as soon as they can lock on to an enemy’s position.

The Interceptor was built to penetrate the strong hulls of the massive Planetary Coalition’s battle cruisers. Therefore their shields are very strong. It would easily take four direct hits from the AF-718 best weapon to stop this craft. Captain Starke’s best offense, in this case, is a good defense. The Kordark Interceptor locks on to its target very early, and it is programmed not to break its path once it has locked on. If Captain Starke is in a clear area, he should have no problem moving out of the way before the quick Interceptor makes contact. If he is lucky, he might destroy one or two with his cannons, but that would take some definite skill.

The final type on enemy that Captain Starke will face is the Larash War Ship.

The presence of the Larash War Ships is what makes this invasion fleet unlike any other Captain Starke as ever seen. The Larash War Ships are as strong as the Kordark Interceptors, but they also have forward facing guns, like the Scouts. They can maneuver in a random pattern and should give Captain Starke his greatest challenge. Luckily for him, there are relatively few of these War Ships, giving him time to recoup between appearances.

The computer of the AF-718 will track how many ships are in the invasion force. It will notify Captain Starke when he has eliminated all of the potential enemies. These statistics will be sent to the forward command on Earth to let them know how he is ranking against the invasion.

Help Captain Starke eliminate as many invasion force waves as possible and reach Earth alive.

So there it is, the story that you will be referring to as you code Star Fighter. What game details can you get out of this story? Let’s list them, in the same way we did for the sample story in Chapter 1:

• The main character Captain John Starke will be piloting an AF-718 spaceship.
• The player will not have to operating any firing mechanism, because the ship has an autofire feature.
• The player can power up by obtaining more shields and guns.
• If the player sustains three hits from an enemy cannon without repair, the game will end.
• If the play sustains a direct hit from an enemy craft, the game will end.
• There are three different types of enemy ships:
  • Scouts move quickly in a predictable pattern and fire a single cannon.
  • Interceptors have no cannons but can take four direct blaster hits from the player. They cannot change their course once they have locked on to the player’s position
  • The War Ships have cannons and can take four direct blaster hits. They move in a random pattern
• The game will track the number of enemies in each wave. Every time the player destroys one, the counter will be decreased by one until the wave is finished.
• The scores will be uploaded to a central area.

This sounds like it is going to be a very fun, exciting, and detailed game to play. The best part is that the code needed to create this game will not be that complicated, or at least not as complicated as you might expect.

In the next section, you will learn about the game engine for Star Fighter. You will learn what the different parts of the game engine are, and what the engine as a whole does for your game. Finally, you will begin to stub out some basic engine functionality and begin to build your game.

What Makes a Game?

Now that you know what Star Fighter is going to be about, we can begin to look at the different pieces necessary to build the game. Many pieces will all have to fit together in a very tight and cohesive way to create the end product that is a playable, enjoyable Android game.

When you think about everything a game has to do to deliver a truly enjoyable experience, you will begin to appreciate the time and effort it takes to create even the simplest of games. A typical game will do the following:

• Draw a background.
• Move the background as needed.
• Draw any number of characters.
• Draw weapons, bullets, and similar items.
• Move the characters independently.
• Play sound effects and background music.
• Interpret the commands of an input device.
• Track the characters and the background to make sure none move where they should not be able to move.
• Draw any predefined animation.
• Make sure that when things move (like a ball bouncing), they do so in a believable way.
• Track the player’s score.
• Track and manage networked or multiple players.
• Build a menu system for the player to select to play or quit the game.

This may not be a comprehensive list, but it is a fairly good list of all of the things that most games do. How does a game accomplish all of the things in this list?

For the purposes of this book, we can divide all of the code in a game into two categories: the game engine and the game-specific code. Everything in the previous list is handled in one or both of these categories of code. Knowing which is handled where is critical to understanding the skills in this book. Let’s begin examining these two categories of code with a look at the game engine.

Understanding the Game Engine

At the core of every video game is the game engine. Just as the name suggests, the game engine is the code that powers the game. Every game, regardless of its type—RPG, first-person shooter (FPS), platformer, or even real-time strategy (RTS)—requires an engine to run.

One very popular game engine is the Unreal engine. The Unreal engine, first developed around 1998 by Epic for its FPS called Unreal, has been used in hundreds of games. The Unreal engine is easily adaptable and works with a variety of game types, not just first-person shooters. This generic structure and flexibility make the Unreal engine popular with not only professions but casual developers as well.

In general terms, the game engine handles all of the grunt work of the game code. This can mean anything from playing the sound to rendering the graphics onto the screen. Here is a short list of the functions that a typical game engine will perform.

• Graphics rendering
• Animation
• Sound
• Collision detection
• Artificial intelligence (AI)
• Physics (noncollision)
• Threading and memory management
• Networking
• Command interpreter (I/O)

Why do you need a game engine to do all of this work? The short answer is that for a game run efficiently, it cannot rely on the OS of the host system to do this kind of heavy-duty work. Yes, most operating systems have built-in features to take care of every item on this list. However, those rendering, sound, and memory management systems of an OS are built to run the operating system and adapt to any number of unpredictable uses, without specializing in any one. This is great if you are writing business applications but not so great if you are writing games. Games require something with a little more power.

For a game to run smoothly and quickly, the code will need to bypass the overhead that the standard OS systems create and run directly against the hardware required for the specific process. That is, a game should communicate directly with the graphics hardware to perform graphics function, communicate directly with the sound card to play effects, and so on. If you were to use the standard memory, graphics, and sound systems that are available to you through most OSs, your game could be threaded with all of the other OS functions and applications that are running on the system. Your internal messages could also be queued up with every other system message. This would make for a choppy looking game that would run very slowly.

For this reason, game engines are almost always coded in low-level languages. As we touched on earlier, low-level languages offer a more direct path to the hardware of the system. A game engine needs to be able to take code and commands from the game-specific code and pass them directly to the hardware. This allows the game to run quickly and with all of the control that it needs to be able to provide a rewarding experience.

Figure 2–1 shows a simplified version of the relationship among the game engine, the device hardware, and the game-specific code.

Figure 2–1. The relationship among the game engine, the game-specific code, and the device hardware

A game engine will not do anything specifically for the game. That is to say, a game engine will not draw a kitten to the screen. A game engine will draw something to the screen because it handles graphic rendering, but it will not draw anything specific. It is the job of the game-specific code to give the engine a kitten to draw, and it is the job of the engine to draw whatever is passed to it.

Therefore, you will never see the following function in a game engine:

DrawFunnyKitten();

Rather, you would have a function that is more like this:

Admittedly the final graphic rendering functions that you create in this book will require a few more parameters than just the name of the image that needs to be rendered, but you should be able to understand the point that I am making; the engine is very general, the game-specific code is not.

Now that you have a good overview of what an engine does, let’s contrast that with the game-specific code, so you will have the full picture of what makes a game.

Understanding Game-Specific Code

Let’s examine the role of the game-specific code. As we discussed earlier, the game-specific code is the code that is run by one game and only one game, unlike a game engine, which can be shared and adapted among multiple games.

The game-specific code is composed of all of the code that makes the characters in your game (the A-718, the Scout, and the Interceptor, etc.), whereas the game engine just draws a character. The game-specific code knows the main character fired a cannon shot and not a missile, whereas the game engine draws an item. The game-specific code is the code that will destroy the main character if he hits a Scout, but not if he hits a power-up; the game engine will just test for the collision of two onscreen objects.

For example, in simplified stub code, the collision of the A-718 and a Scout might look like this:

Although this is only a simplified version of what a section of the game routine might look like, it shows that we created the A-718 and Scout, moved them on the screen, and tested to see if they collided. If the characters did collide, goodGuy is destroyed.

In this example, goodGuy, arrayOfScouts, and the Destroy() function are all game-specific code. The Move() and TestForCollision() functions are parts of the game engine. From this short sample, it is easy to see that you could interchange goodGuy and arrayOfScouts for any characters in almost any other game, and the Move() and TestForCollision() functions would still work. This illustrates that the goodGuy and arrayOfScout objects are game specific and not part of the engine, and the engine functions Move() and TestForCollision() work for any game.

On a larger project, like a game that tens or hundreds of people are working on, the engine will be developed first and then the game-specific code will be created to work with that engine. In the case of small casual games like those in this book, the game engine and game-specific code can be developed simultaneously. This is going to give you the unique chance to see the relationship between the two blocks of code as you are creating them.

You will learn as you progress through this book that some of the functions of the game engine for small games can almost be indistinguishable from game-specific code. In small games, you may not be overly worried about the line between engine and game-specific code as long as the game works the way you want. However, I urge you to keep the line between the two as clear as possible to help promote the reusability of your own code and to help keep your development skills sharp. In other words, try to avoid lazy code and lazy coding practices.

In Chapter 1, you were presented with a list of items that compose almost any game. Let’s take a look at the list again and determine which of those items are handled in the game engine and which in the game-specific code; see Table 2-1.

As Table 2-1 shows, even the smallest games contain a lot of pieces. All of the elements of a game are handled by the game engine in some capacity; some of the elements are exclusive to the engine. This should give you a much better idea of the importance of the game engine and the line between the engine and the game-specific code.

Now that you know what game engines do in general, what will our game engine do for Star Fighter?

Exploring the Star Fighter Engine

The game engine for Star Fighter is going to be slightly different from the general game engine you may use. Keep in mind that Android is built on a Linux kernel, and the development is done using a slightly modified version of Java. This means that Android, as it is, is actually quick enough to run some casual games with ease. We are going to take advantage of this in Star Fighter and keep our coding efforts down.

We are not going to build a true, low-level, game engine in this book simply because it is not necessary for the games that we are building. Let’s face it; the more time you spend writing your game, the less time you have to enjoy playing it. Android has systems that we can take advantage of and, while they may not be optimal to running high-end games, they are easy to learn and well suited for the kind of games we will make.

The game engine for Star Fighter will utilize the Android SDK (and its related Java packages) to do the following:

• Redner graphics
• Play back sound and effects
• Interpret commands
• Detect collisions
• Handle the enemy AI

After reading the discussion earlier in this chapter, you may notice that some functions are missing from our game engine, such as noncollision physics, animation, and networking/social media. This is because the game we are building will not need to utilize those features, so we don’t need to build them.

To keep this book flowing smoothly and logically, we are going to build the engine and the game-specific code simultaneously. For example, you will learn to create the graphics renderer while you are creating the background and the characters. This will give you fully functional pieces of engine and game-specific code at the end of every chapter.

Creating the Star Fighter Project

As an initial task to get you up and running, in this section, you are going to quickly create the project that will be used for the Star Fighter game. We will use the project through this entire book.

First, open Eclipse, and click the menu button to open new Android project wizard; see Figure –2.

Figure 2–2. Starting the new Android project wizard

Once you open the wizard, you will be able to create the project. If you have experience with creating Android projects, this should be a breeze for you.

Figure 2–3 illustrates the options that you should select when creating your project. The project name is planetfighter. Since all of the code for the planetfighter game will be created in the same project, it makes sense to name the project planet fighter. This will also result in all of the code being put into a planetfighter package.

Figure 2–3. The new Android project wizard and its selected options

Now, you can select the “Create new project in workspace” option. This will ensure that you project is created in the standard Eclipse workspace that you should have set for yourself when you installed Eclipse. The “Use default location” check box is marked by default. Unless you want to change the location of your workspace for your project, you should leave it as it is.

Your next step is to select the latest version of the Android SDK, and click the Finish button. Figure 2–4 illustrates the finished project. We will begin modifying this project in the next chapter.

Figure 2–4. The project is correctly set up.

Summary

In this chapter, you learned about the story behind Star Fighter. You also explored not only the different parts to a generic game engine but also those that will be included in the game engine of Star Fighter. Finally, you created the project that will hold the code for your game.

In the next five chapters, you will put together the code that will make up the Star Fighter game. You will begin to build up your skill set as a casual game developer, and you will learn more about the Android platform.