We've spent some time talking about the basics of getting to know Unity iOS and we've looked at some examples of how to use some of its basic functions, but we need to bring it all together to build a game for the iOS market. While we could dream up any game concept we want, we need to be aware of our platform and the user expectations of the platform. Just because something worked well on a Nintendo DS or a PC with a keyboard and mouse, that doesn't mean that the game is appropriate for players whose primary interface is touching the screen and moving the device.
In this chapter we shall:
- Walk through the design decisions for building an iOS game
- Organize our project
- Determine the project asset budget
- Import and optimize assets for our project
As this is the first game we're going to be building for the app store, we will start with something that is fun, but relatively basic in concept and implementation—a third person perspective dungeon crawler. The design inspiration for the game will be the arcade classic Gauntlet. We will take advantage of common services used for mobile games through plugins and third party services to exploit some of the iOS functions available in Unity.
Every game needs a story and this one is no different. A story doesn't have to be a grand epic, but it should explain to the player why they are doing what they are doing and give them the motivation to play the game – and its sequel. For Battle Cry, which is a fairly simple third person shooter game, we will go with a fairly simple story.
The planet of Vosh is the ancestral home of your people. The planet has one special resource – heavy water that, unbeknownst to the people of Vosh, is highly sought after by other intelligent species in the universe as it is used in their fusion power reactors. The people of Vosh have been filtering the heavy water into a special type of beverage for the royal family of the planet.
One day an alien craft appears in orbit above Vosh carrying aliens that have determined that they need the heavy water and start an invasion of the planet. You are a soldier that is based at one of the filtering factories and responsible for defending the facility. Your commanding officers have called out for support, as your weaponry is limited. All you need to do is hold out and keep the facility in good repair.
With this simple story we can drive the player through our scene and easily incorporate elements of multiplayer gameplay.
The interface for this game can be relatively rudimentary and that is important as our gameplay has relatively straightforward gameplay considerations. We need a way to move our character through the world, a way to have them attack enemies, a display for health, and a way to keep score:
This mockup represents the interface that we will need to construct for our game. The game design requires touch with the device and up to this point there is no reason for us to process voice, shake the device, or anything else. If there is no reason for these features, there is no reason to add them. Good game design is a matter of following the KISS principle (Keep It Simple Stupid).
Control is one of the more difficult things to get right on a touch screen device and it's usually because you're dealing with a device that is designed to be held. Given this you have two general orientations of the device that you need to prepare for.
The first use case is that the user is holding the device in the hands. In this case the primary user interaction is going to be their thumbs – a relatively low precision touch instrument and one that does not lend it self to rapid movement.
The second use case is that the user has positioned the device on a table and is looking down at it. In this case the user is more likely to be using a pointing finger, which is higher precision and capable of more rapid movement.
Why is this important, you may ask? If the user is working with a lower precision control instrument and a slower moving finger, to remove an element of frustration for a wide variety of genres of game, you need to make your control area larger and you need to make your game more responsive to its movement and vice versa. Given this, we need to give the user two sets of controls to reflect the different user hand sizes and we need to allow those controls to have variable sensitivity – preferably configurable by the user in the game's settings.
Audio is usually an after thought in game design when it really should be thought about in great detail early in the design, so that it feels part of the game. If you feel that the audio of your game isn't nearly as important as the graphic element I offer you two challenges: listen to your favorite movie with the sound off, do a search on the Internet for video game music. Sound and music done properly will elicit an emotional response in the user and allow for a deeper emotional attachment to the rest of the game.
We will want to have sounds for a variety of user interactions – the grunts of enemies, the battle cry of the champions of the city, the sounds of arrows in flight, the cries of the slain, and so on. Additionally, we will want to have several sets of music that will reflect the different moods of the game. Most importantly, we want all of this sound to actually fit on the device. We could make a design decision and allow the user to access their iTunes music library for music, but it isn't appropriate in this context.