Finally, the good stuff! The first three chapters of this book introduced the basics involved in programming for the iPhone and the concepts behind a game engine. We even laid out a nice framework to get us started. All that’s left is to make our game…but wait, aren’t we forgetting something? What kind of game are we going to make? Before we start coding away, we need to have a plan. We need a game design.
The first step in coming up with a good game design is brainstorming. What will the game look like, and how will it feel to play the game? What are the goals, and how will you keep players entertained? Remember that as much fun as it is to make a game, the end result needs to be something that’s fun to play.
To begin, we’ll need to keep in mind the special considerations of the iPhone:
Touch-screen input
Limited resolution and memory
Play sessions that are short and can be interrupted at any time by a phone call
This means we need to come up with a design that incorporates:
A simplistic input scheme
Efficient use of memory for graphics and sound
Game play that is broken into short segments that can easily be stopped and resumed
To fulfill all of these requirements, we will create a 2D tile-based engine. Tile-based means the level background will be composed of a limited number of square tiles that are repeated and put together to form the level (this allows us to create a large level that uses only a small amount of texture memory). Most 2D games are static (the screen does not scroll at all—think puzzle games), side-scrolling (think Super Mario Bros.), or top-down (like Zelda). A puzzle game is going to be too limiting in terms of AI logic, and most side-scrolling games are too demanding in terms of user input, so top-down best fits our needs. And since this is an O’Reilly book, we’ll borrow from the theme of O’Reilly animals.
With these parameters in mind, let’s create O’Reilly’s Wildlife Adventure. As the name suggests, this will be an adventure game involving wild animals. Players will need to help our main character, Tom O’Reilly, as he tends to the animals of a wild animal park. Each “level” will represent a different animal pen, which will nicely segment game play and allow us to challenge players in unique ways with each type of animal they encounter. Tom will handle various special objects as he deals with each animal.
This game design probably won’t win any major awards, but it will definitely cover all of the major facets of game development for the iPhone.
Now that we have finished brainstorming, it’s time to nail down exactly what we need to bring this design into reality.
- Graphical layout
To render the game, we will need to draw:
The level background
The main character
Several different types of animals
Any random objects that may appear in a level
If the levels are larger than the screen, we will need to be able to scroll our view into the world to keep the player centered on the screen.
- Input
We will need to interpret user input to:
Control the main character
Create an AI engine to control the animal behaviors
Code up some physics to handle the movement and interaction of those entities with each other and the level
We will also need game logic to determine when goals have been met and store the player’s progress.
- Display
Apart from drawing the world, we may need to overlay additional information in a heads-up display (HUD) for things such as:
The player’s condition
Notification of any special items that have been picked up
Possibly a button to open a pause menu
Furthermore, we will probably need to display some text for dialogs if our main character has anything interesting to say.
- Game progress
So far, we’ve discussed only what goes on during game play. We will also need to add:
Code to link the levels together and show game progression
Something like a map that lets players choose what level to play next and unlocks new areas as they complete old ones
Putting it all together, we have the following technical feature list:
A 2D tile-based render engine with scrolling capability
Animated sprite entities for the main character, animals, and possibly level entities
Functions to handle user input to control the main character
Animal entity logic for several types of animals (such as lions, crocodiles, and emus)
Physics to allow entities to move where they should, and not where they shouldn’t (such as into other entities)
Level logic to determine when goals have been met and to store the player’s progress through the game
A HUD for important information, including character dialogs
A menu that allows players to select what level to play and displays their progression through the game
As we mentioned earlier, the touch-screen feature of the iPhone means user input has to be a major focus of game design. Specifically, there are three problems that our game design should try to avoid.
The first problem to avoid is requiring accurate touches. When a player touches the screen, she is actually touching many pixels at once; the iPhone will estimate the center pixel among those pixels and events will correspond to just that one pixel. It is important to make touchable interfaces (such as buttons) or in-game objects large enough that an inaccurate touch event will still find its mark if the player touched close enough. Therefore, we should use a rule of thumb (pun intended) that touchable objects should be at least 44×44 pixels.
The second problem to avoid is causing the player to cover the screen with her hand while trying to use the screen for input. This is one of the major downsides to a touch-screen interface; because both input and output happen on the same surface, they end up fighting each other for space. One way to solve this is to require as little input from the user as possible. Another is to take user input only in nonessential parts of the screen, or nonessential application states—states where fast response to game actions is not required.
The third problem to avoid is requiring many different types of touches. The iPhone can record not only single and double taps but also finger dragging. With a little work, it is even possible to detect when the player forms symbols (such as a circle or square) with her finger. However, it is important to keep in mind that game play can get frantic, and complex input schemes will frustrate players if they cannot quickly and easily communicate their intended actions to the game.
We chose a top-down design to help reduce the amount of user input activity needed to play the game. Specifically, with a top-down view, we can keep the camera zoomed out far enough that the player can tap an area of the level she wants to move to, and the game will plot out a path and move the character for her. In this way, one simple input (tapping a part of the level) is translated into a series of more complex movements (move forward, turn right, move forward, turn left, move forward), saving the player from a lot of busy work.
However, movement is not the only type of input that will be required during game play. We may also need to handle special actions such as jumping, picking up items, and anything else the game requires. We can handle these in a similar fashion to movement: by translating a simple command into an intelligent behavior. Specifically, we know that if the player touches an area of the level the character is not standing in, we should move the character to that point. However, if she taps the square the character is already standing in, we can treat it as a special command.
But how do we know what that special command is? By determining the context in which the command is used. If the character is standing on the edge of a gap when the player taps, we could consider this as a command to jump across the gap. If instead the character is standing next to a door, we could consider this as a command to open the door. Based on the proximity of the character to a special feature of the level, tapping the character will cause the character to interact with that feature. Such actions are considered context-sensitive.
This allows us to have a system that can produce a lot of complex behavior, but the input system remains absolutely simple. In fact, the player needs to know only two motions: tap the area you want the character to move to, or tap the character itself to perform a context-sensitive action.
By now, we have a basic understanding of the structure of the game world (top-down, tile-based, with entities moving about) and how the user will interact with it (by tapping the level or the character). It is time to come up with some level concepts. However, an important part of level design is to consider the game’s learning curve.
When a player first picks up your game, she will not be an expert at it. In fact, learning how to play your game will be part of the fun for her. But if the first levels she encounters are too challenging, she will become frustrated easily and stop playing. On the other hand, if she masters your game in the first five minutes, she will get bored and put it down.
Therefore, it is important to design the levels in such a fashion that the player is neither bored nor overwhelmed. Typically, you should try to introduce one new concept (or a combination of two previously introduced concepts) per level to ensure that players stay awake.
Our first level will involve merely walking about, with no context-sensitive actions or fear of death. However, if the player only had to walk from one side of the level to the other without a challenge, she would get bored. So, we will give her something to chase to motivate her to keep playing.
A mother emu’s chicks have wandered from the nest and our character will have to chase them in the right direction. This will also give us a chance to work on some flocking AI.
Our second level will continue with the movement-only-centered activity, but will increase the intensity of the game.
Specifically, we will ask the player to walk across a habitat filled with sleeping lions to the back of the cave to grab a McGuffin. A McGuffin is a nonsense term that means “something that moves the plot.”[1] Basically, we need a reason to send our main character to the back of a lion’s cave. It doesn’t have to be a good reason, just a reason. That’s what the McGuffin is for. If the player avoids the lions, the level will be easy. If she gets too close, the lions will wake up and swipe at her. This will allow us to work on some multistate AI (sleeping and chasing).
The third level will dial back the intensity, but it will introduce a new concept. Here, we’ll teach the player how to use the context-sensitive actions by providing her with button objects she can interact with to change the level.
We will set up the level as a puzzle: a grid of cells (3×3) will contain a cat and a mouse, as well as cheese below a control room that contains three buttons and the main character. Between each cell is a door that can only be opened by pressing the corresponding button from the control room.
The goal is to open the doors in such a way that the mouse reaches the cheese without meeting the cat. This will show the flexibility of our game engine, being able to create a casual puzzle type of game play experience.
The fourth level will focus on using the context-sensitive action method of input in a time-sensitive setting. We will place a McGuffin at the top end of the level past several streams of water that must be crossed.
To do this, we will place logs in the streams that the player can jump on, using the context-sensitive action. The player will have to move quickly, however, as the logs will slowly sink and disappear into the water, requiring a series of decisive jumps.
And if that weren’t enough, we will also have crocodiles patrolling the waters, jumping and snapping at the player if she gets too close.
At this point, we are ready to start implementing. Please download the Chapter 4 example code from https://sourceforge.net/projects/iphonegamebook/files/.
Get iPhone Game Development now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
