1. Game Design

I love games. That’s a fairly simple statement to make, but it really sums me up quite nicely. I’ve been playing games ever since I got my first computer back in 1982. That Sinclair Spectrum 48k (see Figure 1.1) was something I nagged my parents about for months! And there, among the torn wrapping paper on Christmas morning of 1982, was my first computer. It was black and shiny with little gray rubber keys, and as far as I was concerned, it was a thing of beauty and magic.

Figure 1.1 My original 1982 Sinclair ZX Spectrum.

I had no idea how or why it worked—it just did. As I sat and watched my first game slowly load and appear on my portable television and listened to the odd screaming noise coming from the cassette drive, I knew I was at the start of a long relationship with computers.

It wasn’t long after getting that Spectrum that I started playing as many games as I could get. I wanted to know how the computer—and the games—actually worked. At the time, there were a number of magazines you could buy that gave you information on how to program in BASIC on the Sinclair. Those magazines, such as Sinclair User or ZX Computing, contained all the code for the programs, which also meant that you had to very carefully type in that code line by line before you could run the program. I spent many hours trying to get something to work, only to be disappointed.

What seemed like an exercise in futility also proved to be a valuable learning exercise. By typing all that code, I learned how things worked and what necessary building blocks were needed for a game. It also showed me that anyone—including me in my bedroom with a Spectrum—could write computer games without being part of some giant company.

The process of sitting down and working out how to create games on the iPhone has been very much a repeat of those early years. I’ve worked on plenty of ideas that have not worked and been disappointed, but this has been easily forgotten, as other ideas have proved to be successful. The feeling of achievement when something you have been working on actually does what you expect is fantastic. To this day, I still get the same excited feeling when I see something I’ve written actually working. I’ve had the same feeling when writing software at work, but to be honest, it’s nothing like the feeling I get when I see something flying around the screen in a game. It’s just so much more exciting.

Writing games for the iPhone, I feel like I’m 12 again, minus the complexion problems and homework. I think that many people are realizing that it is possible to create and share their own games. Although the technology has moved on considerably and the mechanism for sharing these games is much easier than reproducing tape cassettes, coming up with the ideas and working on bringing your very own game to life is very much the same.

This chapter covers the key design principles and game elements that I considered when designing and developing the game that we cover in this book, such as the following:

• High-level game design

• Storyline

• Game play components

It’s important that we build a solid base from which the game will grow, and this chapter provides you with the information needed to start our journey into creating a game on the iPhone.

The Game That Started It All (For Me)

At the time, I was mostly inspired by Matthew Smith, the 17-year-old who created the hit title Manic Miner.¹ Manic Miner (see Figure 1.2) was a platform game with 20 levels, and it even had an in-game soundtrack, which was a first back then. Matthew created Manic Miner in just six weeks, and although he was obviously talented, it proved that anyone with some imagination and technical ability could create a game.

Figure 1.2 First level of Manic Miner on the ZX Spectrum.

Since then, computers have been a huge part of my life, and I’ve made my career out of them. Not designing best-selling computer games, but within the enterprise. Although this is something I have enjoyed, a big part of me has always wanted to create a game for others to play. I’ve created plenty of simple prototypes over the years in all sorts of languages (with Java being the latest), but none of them have seen the light of day. Until now.

I was already a huge fan of Apple long before the iPhone was launched, but of course, fell in love with the device as soon as I saw it. When Apple then released the SDK, I immediately downloaded it and started to play, as did thousands of others, and I watched as more and more games started to appear on the App Store.

It felt just like those early days with my Spectrum. It was obvious that people sat in their bedrooms, creating games for the iPhone and using Apple and the App Store as their publisher and distributor. It wasn’t long before I was hunting the Internet high and low for information that would help me start to develop a game, and that journey has ultimately lead to you reading this book.

So, What’s the Big Idea?

Every game starts with a concept—an idea. When I started thinking about the game for this book, I went to the best source I could think of for ideas: my children. I must have sat there for about 30 minutes scribbling down notes as they described the most incredible world to me, how things should interact, what weapons you should have, and most importantly to them, how you die. When you have two boys, it’s all about the gory details. I don’t think I realized until then just how seriously they take their gaming, and once I explained that I would not be able to create Halo 10, they quickly scaled back their suggestions.

I have to admit that a number of ideas for this game have come from classic Spectrum games I played in the 1980s. I enjoyed them so much, I just could not resist using some of their classic game play within my first public iPhone game.

A Game That Fits with the iPhone

One of the big considerations while working on the concept for the game was how people actually use the iPhone. I love playing games on the iPhone, but I don’t spend hours and hours playing those games like my boys do on their Xbox. Most people pick up their iPhone, launch a game, and play for a few minutes (often while in meetings), and then put them down again. This also seems to be an ever-increasing theme among games that I’ve seen on the App Store.

This is an important consideration and can impact the game design in different ways, including the following:

• Players should be able to quit and resume play where they left off (or at the beginning of the level from which they quit).

• The game controls need to be intuitive and easy to master, quickly. If your user is only expected to play in bits and spurts, having an easy-to-use set of controls is key. They also need to be designed specifically for the iPhone. Making use of the accelerometer and multi-touch are mechanisms that should be considered carefully.

• The storyline should not be so complex that time away from the game causes the players to lose the plot and feel lost when they play again.

• There needs to be a clear and easy-to-understand objective to the game. This could be a goal or simply score- or time-based.

These are just a few of the things I considered when designing the game. Given that I wanted the game to be casual, I decided that players would be allowed to carry on from where they left off at the last session. For the controls, the game makes use of an onscreen joypad that will be both familiar to most players and easy for them to use.

Based on the casual nature of the game (and that there’s just no way I could build Halo 10), I ended up with a classic 2D game based in a haunted castle. The castle is inhabited by ghosts and ghouls, and it is a place where only the foolhardy dare to venture. With this in mind, I wrote a storyline to the game to help me build an image of how it was going to look and also give me something to refer back to as I programmed the game.

The Storyline

You play the role of a young knight, Sir Lamorak, who seeks adventure—as well as fame, fortune, and the attention of the fair maidens in the local village—by proving that there is no such thing as ghosts in the long-abandoned Egremont Castle near the Forest of Ulpha.

As Sir Lamorak arrives at the old moss-covered castle, he starts to feel uneasy—as though a thousand eyes are watching him approach the main entrance. After jumping down from his trusty steed, Buttercup, his horse turns, snorts, and bolts back to town, leaving our brave Sir Lamorak all alone. With nothing but the wind pushing against him, Sir Lamorak is blown (or sucked, maybe) into the large wooden castle doors as they open with a loud creak, as the rusty hinges give way to years of neglect.

Slowly, Sir Lamorak moves forward into the main entrance of the castle and peers into the darkness before him. He sees nothing, but can hear the wind moaning through the castle and the dripping of water in the distance. Suddenly, a large gust of wind rips through the hallway with a howl, the main doors behind him slam shut, and Sir Lamorak jumps forward in panic. He turns and runs to the door, grabbing and pulling on the handles, but it will not open. He is trapped.

Standing in the darkness, wondering why on earth he decided to visit this place, Sir Lamorak hears an evil voice through the darkness:

“Only those who can cast the Spell of Release can leave this place, else, you are trapped here with us forever…mwahahahahaha!”

Shaking with fear, Sir Lamorak is now standing in a dark castle and has absolutely no idea what the Spell of Release is, where it can be found, or who the evil voice belonged to. One thing, however, is certain…he is not alone.

What’s in a Name?

I love creepy stories, and this storyline sets us up nicely for the rest of the design. At this point, I also wanted to give the game a name. I can then refer to the game using this name going forward, and it helps build the game’s identity.

You would not think that naming your game could cause problems, but you need to be aware of a couple of important issues when it comes to deploying your game to the App Store. At the time of writing, there are over 150,000 apps in the App Store. That’s a lot of apps and a lot of names that have already been used up, and that is the tip. Before you spend time, and maybe money, on artwork for the game using its name, you need to make sure that no one else has used that name on the App Store. There is nothing more annoying than having everything done, only to find that someone else has used your cool name before you.

You also want to make sure you are not using a name that is copyrighted in some way, as it would also be a real pain to be asked to take down your game because of copyright issues. This goes for all content in your game, really. You are asked during the process of loading your app onto the App Store whether all the content is yours so as to make sure you are not infringing any copyrights. It’s worth checking.

As for the name, all you can do is keep checking the App Store for the name you want to use and hope that someone else does not use it before you. For example, it is easier if you don’t name your game something beginning with “i,” as there are thousands of those being used.

You are also limited to the number of characters that are shown under app icons on the Springboard screen of the iPhone: It’s around ten. For this reason, you either need a small catchy name or to use the initials of your full game name. If you use more than the max number of characters, the name will be shortened to fit under the icon.

The full name I’m using for this game is Sir Lamorak’s Quest: The Spell of Release, and the shortened name for it is SLQTSOR.

The Game’s Objective

Having created a gripping story for the game, I needed to come up with the game’s objective. After all, once Sir Lamorak is in the castle, you’ve got to do something to get him out, and it appears the only way to do that is with the Spell of Release, whatever that is. Based on the game’s storyline, I knew the objective was reasonably simple: The player would need to navigate Sir Lamorak around the castle looking for the Spell of Release. Building on the preceding storyline, I started to add some more detail. For example, the Spell of Release is written on an old parchment that has been torn onto three pieces by an evil wizard and is hidden throughout the castle.

Once all the pieces of the spell are found, the player needs to return to the entrance hall and escape through the main doors. Although that might sound simple, the evil wizard isn’t going to make it so easy for Sir Lamorak to escape. The wizard placed nasty specters and obstacles to make the hunt for the spell harder. As Sir Lamorak moves throughout the castle, he accumulates a score based on the baddies he kills and is timed to see how quickly he completes the quest.

I was trying to think of a reason why someone would want to play this game over and over. I felt that by having the player complete the game as quickly as possible, while at the same time attempting to get a good high score (and not get killed by the baddies), it would make someone want to play the game again to better their high score as well as their time. That meant that the parchment pieces for the Spell of Release would have to be placed around the castle randomly, so that each time the game is played, the player would need to hunt for the parchment all over again, rather than memorizing the locations.

Game Play Components

With the storyline and objective in place, it was time to think about the mechanics of the game. I had to think of things like how the player would lose and regain health points and kill baddies and what things aside from the baddies could hinder Sir Lamorak’s progress. To sort out these issues, I just started writing down my ideas. As part of the thought process, I wanted to make sure that the game play wasn’t too hard or too easy. The game needed to require some thought and some skill. I also knew that it was going to take a lot of play testing to get it just right. From my previous experiences at developing games, even simple ones, balancing the difficulty of the game can be tough. The following sections present the game mechanics that I started with. And although I knew they could change as the game developed, it was important to lay down ideas and start plotting the course.

Time

Time can either be used to limit the amount of time a player has to carry out a task or used to measure how long something has taken. For this game, I decided to use time to record how long it takes the player to complete the game. Having both a score and a time gives players a couple of different measurements they can use when tracking both their progress and level of achievement within the game.

Another form of timer in the game is the player’s health. The health of players will be constantly reducing, even when they are just standing still. This means they have to always be moving, looking for the food to make sure they don’t run out of energy.

Lives

Games are supposed to be challenging, so it’s inevitable that the player will die at some point. When this happens, we could slap them and make them start over again, or use up one of a predefined number lives and let them carry on. Although I have come across a number of games that make you start over from the beginning, I decided to give the player three lives.² This is just an arbitrary number, but most arcade games give you three lives at the start, so I thought I should, too. When it comes to adding the game content and then testing the game, the number of lives could change if we find that the game is too easy or too hard.

Health

The health of players is critical to the game and is something they will need to manage as the game progresses. I didn’t want to just have the player’s health reduced when a baddie hits him, as I felt it reduced the player’s involvement in the game. If he was quick to fire and move, then he could most likely move throughout the castle without too much effort. So, to add a little more depth to the game, I decided that the player’s health would continually decrease, even when ghosts are not attacking the player. Just moving around uses up energy, and our hero is moving around the castle at a somewhat frenetic pace. Sir Lamorak certainly does not want to be in the castle longer than he needs to be, so the running around means that his energy levels within the game are continually reducing. When he does get slimed by a baddie, his health reduces even further.

To help our hero survive while in the castle, Sir Lamorak stumbles upon items to increase his health. By consuming these (done by simply moving Sir Lamorak over them), his health is increased. To further increase the thought required by the player, there are also a limited number of these items around the castle. Once they are used up, no others will be provided. This makes the game challenging and causes players to think carefully about how and when they use these items so that they don’t run out of energy before completing the game. This also introduces an element of skill. Knowing when to find energy will be key to surviving while they hunt for the parchment pieces. Oh, and avoiding the baddies will be key to surviving, too.

Objects

All games have objects of one type or another. These could be weapons that are collected, energy packs, ammunition, extra lives, bonus points, and so on. What objects are needed within the game and how they should be used vary depending on the nature, storyline, and game mechanics that are going to be used. Although it would be cool to give Sir Lamorak an Uzi 9mm or the Ghostbuster backpacks, it doesn’t really fit with the story. We also don’t want him running around shouting “I’ll be back….”

For this game, I decided that I would not go too far and settled on just three types of objects in the game: energy to restore health, keys to open locked doors, and the parchment pieces to allow the player to escape. As I mentioned earlier, it’s good to get your ideas down, even if they may change later. Some of your ideas will be fundamental to the game story or plan and cannot change or be dropped, whereas others could be adapted based on how the game is progressing.

Keys

I decided that, to make things more challenging for the player, there are a couple of different door types. The first are normal doors that simply open and close randomly as the player is moving around the castle. The second type of door is a colored door. The idea is that these doors do not open unless the player is carrying the appropriately colored key with him. If he has the correctly colored key, the door opens as he approaches. If not, the door remains closed and blocks his way.

Energy Items

A number of energy items can be found throughout the castle, each carrying a predefined amount of energy. As the player passes over these items, they are automatically collected and the player’s health is increased accordingly. The player’s health cannot increase beyond 100 percent, and once an item is absorbed, it’s no longer available.

Parchment Pieces

There are only three of these items within the game. As you will remember from the game’s storyline, the player has to guide Sir Lamorak around the castle to find these pieces of parchment. Once they have all been collected, our hero will be able to read the Spell of Release and exit the castle through the main doors. One further detail is that when picking up parchment pieces, they will be held within the player’s inventory. This inventory will only be able to carry a maximum of three items, including keys, so the player needs to place all the parchment pieces into his inventory to be able to read them.

Doors

Doors within the castle will open and close on their own, with some assistance from the ghosts that inhabit the castle, of course. For example, the ghosts might close an open door that Sir Lamorak was just about to go through, forcing him to find another route and expend more energy. This type of obstacle can make game play more challenging, especially if the player was about to enter a room where an energy item is located. The way the doors open and close is completely random and not based on some fixed time that players could memorize after playing the game a few times. A door stays open or closed from between one and ten seconds. This is something that could change once we start playing the game to adjust the difficulty.

Weapons

Many games have a collection of weapons the player can use. Being a knight in a haunted castle, I’ve decided to give the knight just one weapon, a mighty axe, which Sir Lamorak flings at the baddies with great skill. Only a single axe should be thrown at a time, and it will bounce off walls, killing all the baddies it touches, and then disappear after a couple seconds.

Once it has vanished, the player can fire the axe again. Only being able to fire a single axe at a time is an idea I have seen used in some classic Spectrum games, and I’m hoping to introduce a little more skill into the game by using this technique rather than the player just shooting blindly to get past the baddies. It also answers the question of where Sir Lamorak keeps finding all of those axes. With a single axe, it is easy to believe that it acts sort of like Thor’s Mighty Hammer, which boomerangs back after being thrown, and Sir Lamorak simply catches it on the rebound. Having a never-ending supply of axes is, well, just fantasy.

Entities

No game would be complete without entities. As Sir Lamorak runs around the castle looking for the Spell of Release, it would get rather boring if nothing happened but a few doors opening and closing on him. To really increase the challenge, we need to provide our hero with foes to battle. My idea here is to have a number of different entities that can appear and attack the player, such as the following:

• Ghost

• Pumpkin Head

• Witch

• Bat

• Zombie

• Frankenstein

• Vampires

These entities appear and hover around inside the castle and have two behaviors. First, they just move around randomly, changing direction and speed at will, with no defined path. This should stop the player from being able to get accustomed to their movement. The second behavior has them track and chase the player rather than just mill around. The entities may change some way to signify to the player which mode they are in, or stay the same and keep player guessing. These behaviors will also not be constant—that is, the ghost could change from wandering to chasing and back to wandering again at will, providing the player with further stress.

Player

This may be the last in the list of game components, but it is one of the most important. The player is the central character within the game around which the story has been built, and there are specific actions the player will need to be able to do. From the storyline created earlier, we know that the player is a knight trapped in a castle and that he carries an axe. Based on this and the game components we have already described, we can create a list of actions the player needs to be capable of, as follows:

• Move around the castle.

• Throw his axe in either the direction the player is facing or toward the player’s touch on the screen.

• Collect energy items by walking over them.

• Collect keys. This also means he will need some kind of simple inventory in which to store the keys he is carrying. This is also true of the parchment pieces; he will need to be able to carry these as well.

• Walk through locked doors when he is carrying the correctly colored key.

• Be blocked from passing through closed doors or locked doors if he does not have the right key.

• Walk through the main castle door if all three pieces of parchment are held in the player’s inventory.

These are the basic actions, based on our current game design, necessary to enable the player to interact with the game and achieve the objectives. How the player is to be actually implemented—his look and feel—will be covered through the rest of the book.

Summary

This has been a long, wordy chapter, but we have already covered a lot of ground. We have gone through what this book aims to provide and what to expect. We have also gone over the game idea that is going to be developed throughout this book. This led to us coming up with a storyline, the game’s objective, and the components that are needed to implement the story and game objectives.

We have only briefly covered the components that we need to create within our game. We go into more detail on that later in this book.

Now that we have decided on the name, storyline, objectives, and components, we need to look at the technology we are going to need. By this, I mean, “How are we going to take those concepts and actually code them up for the game?” We start covering this in the next chapter, as we discuss the terminology that is often used within games, such as sprites, texture atlases, and so on. We also cover, at a high level, the technologies we will use to implement our game, including Objective-C, OpenGL ES, and OpenAL.

There are areas we did not discuss in this chapter, such as In-App purchases. Although Sir Lamorak’s Quest isn’t making use of this capability, it is worth considering how In-App purchasing could be used within your game. Allowing the player to purchase new content (levels, weapons, energy, and such) extends the life span of the game and can create a loyal fan base that can be approached when launching a new game.