2. All About Design

It is no accident that we’ll be discussing game design before you start coding. Every time you create a game, this should always be the order of events. Design is about fleshing-out your game concept, to be sure, but it is also about working with the hardware specs of your game platform, and limiting the design to those features that can be achieved within your available time and budget. All of these factors should influence your design, and in the end, your game. Design is also an organic process. Just as your programming strategy may change over time, so will your design.

What Is Game Design?

A game is doomed to fail if it isn’t well designed or hasn’t had the benefit of an adequate planning and thinking phase.

As you are probably the designer and developer of your game, it can be tempting to skimp on the design phase and get started coding. I highly recommend not doing that. You wouldn’t ask a builder to skip the blueprint and build a house from the seat of his pants. You shouldn’t do that with your games. The end results would be the same: poor house/game architecture that works for awhile but eventually collapses under its own haphazard weight.

Design isn’t just about how the game looks. A nice looking game is great, but many crudely drawn games succeed because of fantasic gameplay, or because a fresh concept offers players something new and exciting. What a game does is ultimately more important than what it looks like.

Your iOS game design probably doesn’t need a formal design document that specifies all aspects of the game. If you were creating the next multi-million dollar blockbuster with an international development team, then you’d definitely need to define everything. But at this stage, your one- or two-member team can probably get started with a few hand-drawn sketches and notes.

Choosing a Game Genre

Matching your game genre to your target hardware is an all-important consideration. Although an iOS device has a lot of power, you need to remember that its power isn’t unlimited, nor is its screen as big as a computer or game console display. As a result, some game genres just won’t work well on an iOS device.

For example, a real-time strategy (RTS) game with a large, detailed map full of information might be ideal on a computer but an eyestraining ordeal (and a programming nightmare) on a iOS device. Trying to convey that amount of RTS information on a mobile device would probably get in the way of playing the game and ruin any chance of player enjoyment.

On the up side, single-screen action games or puzzle games are very suitable for the iPhone and iPad. A quick browse of the Apple App Store will confirm that, with games like Angry Birds and Plants vs. Zombies selling very well and ranking high in iTunes charts and sales.

At present, the most popular iOS games are quick to play and best experienced in short periods of time. Current usage statistics suggest that most iOS users play their devices for brief stretches, so you should favor easy accessibility when choosing a game genre. While some users may sit and play an iOS game for extended play sessions, most players will just pick up a game for a few minutes at a time.

Therefore, the best kind of game for iOS is simple to play, addictive, and probably takes place in a single screen. (Although that may change in the future as iOS devices become even more powerful, and more serious gamers acquire them.)

With that in mind, I introduce Raiders, a modern take on the classic, “good guy takes on marauding army on his own” game. Our game will be played on a single screen, and it will be easy to play, addictive, and fun. So, the design is done, right? Wrong.

Establishing a Look

Once you’ve formulated your idea of what your game will do, it’s time to think about how you want your game to look. At this point, I usually sketch out on paper the general look of the game screen.

A rough pencil sketch helps you focus your thoughts in a physical form (Figure 1.1). By doing so, you’ll gain a better idea of layout; where things will fit on the screen; and the issues that will need future attention, such as player and enemy movement, control issues, and screen constraints. You’ll also be able to compile a list of the sprites you’ll need to create.

Figure 1.1 Rough pencil sketch

For example, in the previous quick sketch it is clear that the game needs a player sprite, enemy sprites, a sprite to depict the barriers, and two sets of laser sprites. Thinking beyond the visuals, you’ll probably also need sounds for the laser firing, and perhaps a musical jingle to play in the background. (Yes, sound design is also an important part of game design.)

From this pencil sketch, you can also formulate questions about your game rules: How many lives will the player have? Will there be different types of enemies? How will the enemies move? How will the player move? Will the player be able to shoot more than one laser at a time? How many shots will a barrier take before it is destroyed?

Another important design consideration specific to iOS devices is to ask if the game will be locked into a single view mode (landscape or portrait) or if it will change views to suit the device orientation.

For this game design, we will lock the game into portrait mode. Supporting changing view modes would alter the game too much to maintain consistent gameplay. In landscape mode, the shorter length of the play field would radically reduce the length of time a player would have to shoot enemies, and would potentially change the look of the game too much, for no real benefit.

For the actual look of the game, the more talented artists among you might want to use your computer and Photoshop or Pixelmator or a similar application to create your initial game graphics. Photoshop templates are also available on the Internet with the correct dimensions of the iPhone screen, and you can use them as a graphics starting point. A quick search for “iPhone mockup template” will help.

Keeping Everything Under Control

In a console- or PC-based game, controls comprise supporting keyboard, mouse, or joystick/gamepad. In an iOS game, you have access to two main forms of control: the touchscreen and the accelerometer.

Because in Raiders the player moves only across the bottom of the screen, you could exclusively use the accelerometer to tilt the player to the left and right. The advantage of doing so is that you don’t need to draw onscreen controls that take up valuable onscreen space. The disadvantage is that you must ensure that the tilt performance isn’t too sensitive—so the player flies off the edge of the screen with the slightest bump—or too sluggish—so the player has to tilt the device so extremely that he can no longer see the game screen.

You could also implement left and right touch areas to control the player movement. This way, the player can keep the device level and the game screen visible. Another touch method you could employ would be to allow the player to swipe left or right.

Controls make or break a game. I’ve played many games that looked great and could have been excellent, but failed because they were too difficult to control or didn’t offer alternative controls if a player disliked the touch or accelerometer control schemes. To quote an industry veteran, “When in doubt, let the player decide. So many games fail because the designer thought he knew better than the player. If the device and the development time/budget allow, give the player reasonable options to play the game the way he wants to play. You’ll sell more units.”

To keep everyone happy, Raiders will allow three input methods that can be configured before the game starts, or changed when the game is paused. This decision will not only give your game greater flexibility, it also offers you the chance to program all three control options.

Playing by the Rules

Game rules are basically the boundaries of the game world, the constraints the designer enforces on the player to make the game flow logically while remaining fun and challenging. The following questions raise some of the things you might need to think about when establishing rules for Raiders.

HOW MANY LIVES WILL THE PLAYER HAVE?

The number of lives should be dictated by the difficulty of the game or level. A game in which you are competing against the clock, for example, has no need to limit lives, but a platform game might.

As you create your game, you will become a very good player. You will know the patterns of the enemies, and you’ll know the gameplay inside and out. It’s useful to have other people test the game. Their feedback will help with selecting the number of lives.

DO WE NEED DIFFERENT TYPES OF ENEMIES?

HOW WILL THE ENEMIES MOVE?

A variety of enemies is important. The player will quickly get used to the characteristics of a particular enemy. Multiple enemy types keep the player on his toes and having fun.

To maintain game challenge, enemies’ traits and characteristics can vary as the player proceeds through the game. The first few enemies should be easy to kill, have predictable patterns, and not present an unreasonable difficulty. Nothing is more discouraging than picking up a game and dying straight away.

Equally as bad is a game that is too easy. Varying enemy movements can be a good way to increase difficulty. Increased speed of movement or randomized movement patterns are also ways to make the game continually more difficult.

In Raiders, the enemies will become increasingly fast and more accurate over time. This will help make the game easy to pick up at the start, but will maintain the challenge as the player continues.

HOW WILL THE PLAYER MOVE?

Will the player have the ability to move in a full arc, or is the player movement limited in some way? Limiting movement can change the feel of a game. A game that limits movement to left and right, for example, requires that the enemy approach the player primarily from the top and sides, whereas a player who can move forward and back can take on enemies from all sides.

In Raiders, the player moves left and right only, with enemies attacking from the top down.

WILL THE PLAYER BE ABLE TO SHOOT MORE THAN ONE MISSILE AT A TIME?

This choice can affect the pace of the game. If the player has the ability to shoot many shots at once, then logically, the enemies will be destroyed more quickly, and you will want more enemies on the screen at once.

This can create a faster-paced game, but can also result in a game that doesn’t demand the same level of accuracy as a game that requires the player to make every shot count.

In Raiders, the enemy will attack in waves. A multiple shot, rapid fire system could make the game a little too easy, so Raiders will employ a single-shot mode that rewards shot accuracy.

WILL THE PLAYER HAVE ANY PROTECTION? IS THE PLAYER LEFT OPEN TO ENEMY ATTACK, OR CAN SHE HIDE BEHIND A BARRIER?

If your game employs difficulty levels, a varying number of hits to break a player-protecting barrier could be a good way to make gameplay easier or harder. In an easy mode, the barrier might absorb three hits, but might be destroyed by only one hit in a difficult mode.

ARE THERE ANY OTHER CONSTRAINTS OR RULES TO CONSIDER?

You may want to consider the following questions: What happens when the player gets to the edge of the screen? Does she loop around to the other side of the screen, or does she just stop near the edge? Will a player’s shot be able to destroy an enemy shot, and vice versa?

In Raiders, player shots will destroy enemy shots, but not the other way around.

Finding Graphics and Sounds

Now that you have done some design, thought about your game rules, and considered game controls, the next thing to do is think about the actual game resources, the physical game objects. In Raiders they would be the player sprite, the enemy sprites, the laser sprites, and any sounds we might need.

A few options are available to acquire games resources. The first and probably most obvious is to create your own. You can create your visuals in any pixel-based graphics editor. Photoshop is a clear choice, but many others can be suitable. I like Pixelmator, which is available from the Mac App Store, or the free and open source GIMP image editor.

If you do decide to create your own sprites, remember that the iPhone screen is effectively 320 × 480 pixels, so your sprites need to fit into this relatively small space. And sprites that look great in your image editor might not look that great on the actual iOS device. Examine your pencil sketch to estimate what size each of your sprites needs to be. In Raiders the enemies will be stacked in a row about five enemies wide; so with a little padding, the enemies should be only 50 × 50 pixels.

Likewise, the player sprite will be about 100 × 50 and the barriers about 100 × 100. It will take a bit of experimentation with the scale of these element to get the end result looking right. You will learn more about how to do this in later chapters.

You might be asking, “Don’t the iPhone 4 and latest iPod touch—not to mention the iPad—have larger displays?” This is correct. But in reality, and to be backward compatible, the iPhone renders the screen to look identical in either version; it’s just that the retina versions are a lot sharper. This is achieved by scaling images for a non-retina display to exactly double the resolution and appending @2x to the filename of that graphic. It is a very clever way to handle image scaling, yet still keeps graphics looking sharp on both sets of displays.

But I’m Not an Artist

Not everyone, me included, has the artistic talent to create his or her own sprites. If you fall into this category, you have three other options.

The first option is to post a job offer on the many contract/freelance sites available on the Internet. You will be surprised how many talented artists are out there looking for work. It’s beyond the scope of this book to offer much more detail, but I would recommend going to a reputable site and hiring only people that have a lot of positive feedback.

Another option is to purchase graphics from graphic stock websites, such as iStockphoto.com. Be sure to check the usage rights on any images or artwork that you purchase. Some graphics can be used anywhere for any purpose, while others require an additional charge when distributed within a game or website.

The third resource is free and open source websites. If you do a search for “free sprites,” you will find hundreds of websites with sprites that you can use in your games at no charge. Again, you will need to verify the usage rights, but most sources just require attribution somewhere in your game. If you’re just having a bit of fun and creating your own game as a hobby, then I would definitely recommend exploring this resource first.

Let’s Make Some Noise

A game will probably not fail if it has bad or little sound, but spot-on sound effects and a good musical score can improve the overall feel of the game and add to its polish. Sounds can also add a bit of comedy to a game, such as a funny audio effect when an enemy is hit.

The sounds in Raiders will be used for spot effects, such as enemy explosions and weapon fire.

Sounds are also available on the Internet. A quick search for “free game sound effects,” will yield some excellent resources. The sounds for Raiders were all acquired from free, open source sound effects websites by performing that exact search.

iOS is limited to playing the following audio formats: WAV, MPEG, CAFF, and AIFF. Most sound effect websites offer sounds as WAV or MP3 files. You use an application such as Audacity to convert audio clips to the correct formats.

Wrapping Up

You have seen that good game design is essential, and you have asked some questions about your game and the constraints and rules it may require. Remember that your preliminary design isn’t set in stone. Don’t be afraid to change the design once you have started coding, particularly if something isn’t working as you thought it might.

In the next chapter, you will take your first look at OpenGL ES and create a template to use during game development.