Chapter 2

Designing Your Game

In This Chapter

Understanding mobile games

Getting into the mind of your audience

Designing user interfaces for games

You may already know what kind of games you want to make. Most of the time, game developers work on the kinds of games that they love to play. But not all genres and formats of games fit well on the mobile platform, while some are perfectly suitable for games on the go.

Even though the hardware and software for Android devices continues to get more sophisticated and powerful, bleeding-edge games that strain the limits of these devices’ memory and processing power may not be the best way to go. You need to keep in mind that most people won’t have the latest and greatest devices, and if you want to target a wide part of the market, your games will need to run on older devices.

In a word, the short answer to the question of what kinds of games are best for mobile is: Short!

Deciding What Kind of Game to Make

Choosing the kind of game you want to make isn’t just a matter of deciding what type of game you like to play, or which type of game you think will be the most marketable (although both of these are important).

We consider genre first, though, before moving on to other factors (such as number of players) that affect design.

Genre

Currently Google Play has eight subcategories in Games, each one corresponding to a game genre:

Arcade & Action: fast-paced games where timing and reflexes are usually important, such as

• Pac-Man

• Pinball

• Fighting games

Brain & Puzzle: games you have to think to be good at, such as

• Crosswords

• Sudoku

• Chess

Cards & Casino: usually games with dice or cards with a random element, such as

• Slot simulator

• Poker

• Mahjongg

Casual: generally easy-to-learn, easy-to-play games for a broad audience, such as

• Connect the dots

• Music games

Live Wallpaper

I’m not sure why this category is in Games, but it includes backgrounds for your Home screen that are animated.

Racing: cars, motorcycles, that sort of thing

Sports Games: football, baseball, and so on

Widgets

Another strange subcategory for games, refers to miniature apps with their own UIs that reside on your Home screen

Discounting Live Wallpaper and Widgets, there are six actual game categories.

One of the first things you should do is browse these categories to get a sense of what games are currently available and which are the most popular. If you haven’t already, you’ll also want to download and play a few.

One of the upsides to being a game developer is that playing games is considered research!

Market position matters. You’re providing a product to users who have many alternatives:

An important consideration is how crowded a particular subcategory is.

Arcade & Action is probably the most fiercely competitive game category on Google Play at the moment. You might consider developing a game that falls into a less competitive genre.

If you want to go up against the toughest competition, you’ll need to at least be familiar with it and try to bring something of value that your competitors don’t, such as

• Lower cost

• More features

• A better interface

Be mindful about how neatly your game may fall into a particular genre.

If you’ve just come up with a mind-bending hybrid of a game (say, a racing word game)

• Which category would it fit in better?

• Which category might face less competition and garner more usage?

Category membership is one aspect of your game that you can update dynamically, so just as with choosing a price point, you may want to experiment if your game doesn’t fall neatly into one particular category.

Number of players

The number of players for your game may depend on your goals and on the nature of the game.

Single player

Single-player games may be games that are either

Naturally are played alone, like solitaire

Played against a computer version of the usual human opponent

Single-player games a couple of advantages for players and developers:

The virtue of generally not requiring data connectivity to play means the game won’t rely on a potentially spotty Internet connection — which means that it can be played anywhere, anytime.

If you’re not dealing with data connectivity, the game is also generally going to be less complex, so single-player games are a good idea for the first games you make.

Multiple players

Multiplayer games involve two or more players interacting with one another:

Most often this interaction is via the internet. Players may either

• Interact in real time, such as a fighting game

• Play asynchronously, making a move at their leisure, which alerts the opponent it’s his or her turn to make a move.

A multiplayer chess game might work this way.

Another form of multiplayer game is local multiplayer. Instead of playing someone sight unseen, you play someone sitting in the same room:

• Devices can still communicate via the Internet.

• You might also have the option of using a local communication protocol such as Bluetooth or Wi-Fi.

This multiplayer format is generally less popular than non-local multiplayer, but in some cases it may be the perfect format for your game.

Yet another version of multiplayer is pass-and-play, where players use a single device, physically handing it off to one another to make plays.

This form of multiplayer is a bit clunky, but does have the advantage of not requiring device-to-device communication.

It’s probably not a good idea to implement pass-and-play as the only way to play your game, but you might consider it as an additional feature.

Most developers starting out in games aren’t members of huge teams with million-dollar budgets, so your best bet is to avoid trying to make a large, complex game right out of the chute. Completing even a simple game can be difficult, but gives you invaluable experience and a sense of accomplishment.

Once you’ve successfully developed a single-player game, it makes sense to try your hand at multiplayer games, if that’s your ultimate goal.

A good intermediary is the asynchronous multiplayer game. Some of the most popular mobile games on the market today fall into this category, in which one player updates the game state locally, then sends those updates to another player.

Asynchronous games have a couple of advantages:

This type of game is less complex and requires less fault tolerance than one that needs to be updated in real time.

If an update to the game state doesn’t go through on the first click because of a spotty connection, just allow them to attempt again.

Asynchronous games also allow players to engage with the game at their convenience, rather than having to coordinate a time when both players are available simultaneously.

This format works beautifully for mobile gaming, in which a player can make a move in a game when they have a pause in their busy day, waiting in line at the supermarket or in the dentist’s office.

A lot of new game developers overreach. They may love playing MMORPGs (Massively Multiplayer Online Role-Playing Games) and have a dream design for one. Often they underestimate the time, energy, complexity, and resources involved in creating such a game:

Role-playing games, even the simplest ones, usually require a large amount of graphical resources.

Most players of RPGs want to find a variety of armor and weapons, as well as face off against a wide variety of bad guys. You can heavily reuse the same graphics, but then the game becomes monotonous.

MMORPGs or multiplayer FPSs (first-person shooters) are played in real time, which requires sophistication in handling how the game state is updated between players.

Mobile connectivity is generally less reliable than wired data connections, so this can make your game unplayable unless you are really savvy at handling the limitations of mobile technology.

Thinking about how and when people will play your game

Mobile games, as opposed to those played on a console or PC, are generally played

On smaller screens

On devices with fewer memory and processing resources

For shorter periods of time

Some important ramifications of this to your game design are

The duration of game play. Typically players won’t want to stare at and click a small screen for hours at a time.

Think about how sessions of your game might work as “bite-sized” chunks. As a reference point, most of my games have a median session length of about six minutes.

Fat fingers! The size of the screen is crucial in mobile game development. Android devices may have a variety of input hardware:

• The G1, the first Android device, had a trackball.

• Some have hardware keyboards, others don’t.

The most consistent input method for your game will likely be the touchscreen.

Make buttons for your application

• Large enough for easy interactivity

• Spaced far enough so that the player does what they want to, when they want to do it

Size of text and graphics. You’ll want to make sure any text is clearly readable, especially on smaller devices.

The Android SDK lets you scale text according to screen size, but any text embedded in graphics will need to be readable across all resolutions.

One other important design decision that is often overlooked especially by beginning game developers: colorblindness. Up to 10 percent of males can have some form of colorblindness, and if your game relies on color to differentiate between game elements, it may be difficult or unplayable to a significant segment of your market. Not long after I published my puzzle-RPG hybrid Puzzle Lords, I received an e-mail from someone who was colorblind, asking if I could add a colorblind mode. The game requires the player to match gems of the same shape by dropping them in a grid. Figure 2-1 shows a sample combat screen without colorblind mode enabled.

Figure 2-2 is the same combat screen, with colorblind mode enabled. As you can see, I added symbols (X, square, circle, and triangle) to the circular gems:

The circular gems are much more important for matching than the square gems

I determined that adding symbols to all the gems would look overly busy.

This intermediate solution lets players play comfortably in colorblind mode, and the person who originally e-mailed me was happy with the addition.

No matter what you do, you won’t make all of your players happy. Design decisions are often tradeoffs in which you try to

Please the largest number of players.

Reach the widest audience.

Issues such as localization (making your game playable in other countries and locales) and accessibility (making your game playable to those with special needs) often depend on how much time and how many resources you are willing to spend versus keeping your target player base happy.

Identifying Your Target Audience

Android is becoming more and more popular every day, and so the demographics of the users are becoming larger and more varied. As of this writing, the demographics are still skewed in particular directions, possibly enough to impact some of your design decisions. In any case, it never hurts to have more information about the audience for your games.

I’d encourage you to use some form of analytics to learn more about your player base and how they are using your app. Google Play has some built-in analytics, breaking down a lot of useful information about your game and its users, such as

Downloads versus active installs. Five thousand people may have downloaded your app, but only 500 of those decided to keep it installed.

You’ll want to know what your retention rate is, since it’s one good indicator of the quality of your game.

Google Play also breaks down active installs and downloads for a particular time frame, as well as by

• OS version

• Device

• Country

• Language

• App version

• Carrier

Even though there is a wealth of information through the developer console on Google Play, you may want to install a third-party analytics package or even implement your own.

Some app analytics provide information such as session length and frequency of sessions. Typically user behavior follows a long-tail distribution. That is, you’ll usually have

Some small number of users that play your game a lot

A lot of users that don’t play your game that much

But keeping an eye on average play length for a given session or average sessions per week will give you some insight into how engaging your game is and how you might update it to make it more appealing to players.

Besides particular information you might gather about the audience for your particular game, there are a number of general demographic trends for Android users that might be of interest.

The Android user base

Because Android was first presented as an open, more technically customizable alternative to iOS, early adopters tended to make up a larger percentage of the user base. These days they still do, but to a lesser extent; with the wide array of devices on every carrier in the US (and many around the world), attracting fans of cutting-edge tech is less of a factor in a game’s success.

The Android user base continues to skew slightly more toward males.

• Their median income tends to be lower than that of iOS users, probably due to the fact that Android offers a wide array of devices, including budget ones.

• Some research indicates that Android users are less likely to purchase apps or make in-app purchases, but may be more likely to click in-app ads.

This kind of information may guide how you choose to monetize your app.

For some game genres, such as casual game formats like hidden-object (where the player tries to find objects in a scene), the demographic for PC players skews slightly toward older and female.

If you decide what kind of game to develop based solely on maximizing your potential audience, you may want to consider the particular makeup of the Android user base. However, a good rule of thumb is to make a game that appeals to a wide spectrum of users.

You can’t go too wrong with a game that everyone wants to play!

Casting a wide net or finding a niche

Making a game with widespread appeal might be a strong decision. However, you might find success by targeting a specific demographic that is underserved. As of this writing, Google Play has around 500,000 apps.

When I started developing for Android, I had to contend with only a handful of apps on the market, so competition was far less severe. These days it’s difficult to find a segment of the user base that isn’t already being served, but it’s still possible. And if you can do that, you might find a group of players that will become loyal to you and your brand:

Historically, females are underserved by the video gaming industry. One way you might stand out from your competition is by bucking the demographics and making games specifically for females.

That doesn’t necessarily mean filling your game with the first thing you think of that seems “girlish.” (Okay, depending on the game, pink unicorns and such might be a good idea! Making hasty assumptions isn’t.) More importantly, it means understanding what your audience wants out of a game experience.

A social game focused more on collaboration than competition might be more suited to a female player base. If you can tap in to what makes a particular subset of gamers tick — and give them what they want — they’ll come back for more.

Another potential niche is kids’ games. More and more smartphones and tablets are being used to either augment kids’ early education and development, or at least keep them occupied for a while in the car.

If you can develop games with an educational bent, or that have particular appeal to young children, you just might have a hit on your hands.

Those with special needs, such as the blind, are very underserved by gaming. Designing games without visual input is especially challenging, but it might also flex your creativity in ways you never imagined.

You may choose to find a niche based on something entirely different. For instance, I live in southern Louisiana where a card game called Boo-Ray is fairly popular. Last time I checked, there was no Boo-Ray app on Google Play. Granted, the user base would be small, but possibly highly dedicated if you chose to implement a regional game that has a strong following.

The simultaneous advantage and disadvantage to developing for a niche is that your audience will necessarily be smaller:

This lets you tailor your app for that user base.

A targeted game may engender more loyalty than a game with widespread appeal, but it may ultimately be too limiting.

Either way, it’s a good idea to think hard about what kind of player base you want to develop for.

Targeting Devices

When designing your game, you’ll need to determine which devices you are willing to support. This is nearly always a tradeoff between increasing your audience size at the expense of using the latest, greatest features of devices, including enhancements in performance and new features in the OS. Of course, if you do target only the latest devices, eventually the industry will catch up, but it may take some time.

From time to time, the dreaded “F” word rears its head in discussions of Android: Fragmentation refers to the proliferation of different Android devices and firmware versions, potentially leading to a disjointed ecosystem where users don’t have a consistent experience between Android devices, and developers face the nightmare of developing for way too many different configurations.

iPhone developer advocates like to point out that there are far fewer hardware and software versions to worry about when you’re developing for iOS. Okay, technically this is true, but variety is both the boon and the bane of Android. The wide spectrum of OS versions can lead to inconsistent user experiences, but it also entails a rapid release cycle, so innovation marches on at a breakneck pace. The wide spectrum of hardware allows buyers to choose options in all price ranges. You can get a budget Android phone with less power and fewer features, or you can spend more money and get the latest and greatest. The headaches to developers can be mitigated by

Cleverly managing resources

Following Google’s guidelines for supporting multiple devices

Meanwhile, offering Android in a variety of shapes, sizes, and costs means that it will penetrate the market at all levels, which means a bigger audience for your games.

In general, I like to try to support as wide a swath of devices as possible, so the examples in this book will follow that principle.

Firmware

The term firmware refers to the operating system of a smartphone. The version of Android that a given device runs will determine what features are available, its speed, and many other important factors.

You’ll need to think about which versions you want to support:

A big part of that decision is what kinds of features you want to use in your game — and the difficulty in making your game compatible with all the versions you want to support.

You should test on all supported versions, and that can be a headache, so you’ll probably want to try to support a subset of the versions in use.

Android versions

Google maintains a website (http://developer.android.com/about/dashboards/index.html) which shows a monthly snapshot of Android versions currently used worldwide.

Historically, the Android ecosystem has had a large number of versions available at any given time:

Though two or three versions tend to make up the vast majority (75 percent or more) of the current user base, and those tend to be the more recent versions.

Some small percentage of users will still be running much older versions of Android. You would certainly make those users happy if you offered games that ran on those devices, but if development and testing time are at a premium and you have to leave those versions out, the loss is negligible.

When you’re making decisions about which OS versions to support, it generally makes sense to prepare for the future, rather than try to cling to the past. You and your user base will be happy if you

Avoid using APIs that vary (or are nonexistent) between versions.

Keep things simple.

Develop in a way that enables your game to play happily regardless of OS version.

Custom ROMs

Because Android is open-source, anyone can take it, modify it, and release a custom version. Manufacturers often “skin” Android to give it a particular look and feel on their particular lines of devices. Some examples include

Motorola Blur

HTC Sense

Samsung Touchwiz

Though these modifications typically only manipulate the main user interface of the device, rarely the changes made may affect apps run on these devices.

Ideally you would want to test your game across a wide variety of devices, including those that run manufacturers’ custom versions. Of course, an indie developer may not be able to afford a test suite of dozens of devices, in which case you may have to make do by downloading emulated versions from manufacturers’ websites, or simply crossing your fingers when you release and trying to fix problems after you get feedback from players.

Another, smaller segment of your player base will be those users who have installed custom Read-Only Memory. An avid community of ROM developers is always ready to take the latest builds of Android, modify them, and make them available for anyone who wants to take the risk of rooting their phone and installing a non-factory build of the OS.

There are a surprising number of users with custom ROMs installed, though they can be more difficult to track. Testing for compatibility with custom ROMs is even more difficult than with the normal variety of standard configurations, but be ready for the occasional support e-mail from players using customized ROM.

Hardware

Along with the variety of OS versions, Android is available on a dazzling array of hardware. Before developing and certainly before publishing a game on the platform, you should be mindful of the different types of hardware and how they might affect the way your game looks and plays.

Processors

The first Android device sported a 528-MHz processor and anyone who had one probably remembers the interface being a little sluggish, certainly compared to other smartphones at the time. The hardware has advanced a great deal in a short time, and new devices are now coming with multi-core processors, each in the GHz range.

More powerful devices mean better performance for games, but not without a price. Even playing a relatively simple 2D game can drain the battery pretty quickly, due to

Increased CPU power

Larger, denser displays

Games that use a lot of juice can tend to make a device generate a fair amount of heat as well. So while you can make more CPU-intensive games, you might not want to.

Screen sizes

An important distinction to make is between

Screen size (the actual physical measurement of the screen)

Density (which is the number of pixels in a given area).

Current screen sizes are lumped into one of four categories, based on the length of their diagonals, as shown in Figure 2-3.

The densities of screens are classified in Table 2-1.

Table 2-1 Screen Density

Name	Pixels	Abbreviation
Low-density	120	ldpi
Medium-density	160	mdpi
High-density	240	hdpi
Extra-high density	320	xhdpi

As with processors, increased innovation in hardware is resulting in higher density screens with crisper graphics. A good rule to follow when developing across different screen sizes and densities is to

Target the largest screens and make sure your game looks good on those.

Scale down to the smallest screens you’re willing to support.

This book lays out the graphical elements so that our games will be playable on every device. Supporting multiple screens can be a daunting and complex subject, though. Google maintains a website specifically for supporting multiple screen sizes:

http://developer.android.com/guide/practices/screens_support.html

You should bookmark this page, study it, and refer to it often.

Input types

Along with the variety of Android devices comes a variety of input methods. You can safely bet that most devices will have a touchscreen, but they may include the following forms of input:

Keyboard

Trackball/Trackpad

Microphone

Camera

Accelerometer (senses movement)

GPS (detects location)

You may have an innovative idea for a game that uses one or more of these forms of input. The entire class of augmented reality (AR) apps and games generally rely on camera input as they meld real-world images and locations with overlays on the device. Some very popular games use the accelerometer for control inputs, allowing the player to tilt the device to manipulate on-screen elements.

I have a prototype of a game that uses voice input as part of casting spells, which requires a microphone. If the device is a phone (as many Android devices are), that’s fine. Just be aware that not all Android devices may have the particular kinds of input your game requires. Luckily, the Android SDK includes ways of letting you specify what hardware is required for your app — and that’s covered in Chapter 4. For now, just be aware that in the planning stages, the less standard your input types are, the more you might be limiting your potential audience. Keep in mind whether this is something your game really requires, and whether or not more than one set of control options might be available. For example, you might make your game use the touchscreen as input by default, but also make it playable via microphone.

Phones

There are dozens of Android phones available now, and they will likely be the primary target for your games for a long time to come.

Accordingly, while designing your game, keep in mind that phones typically have smaller screens than other devices; you’ll want to use inputs and graphics that are easily visible and interactive on small screens.

Tablets

Android has not currently penetrated the market for tablets nearly as effectively as it has for smartphones. A notable exception is the Kindle Fire by Amazon, which has sold extremely well.

The most sensible plan for prioritizing for Android devices is to develop for phone first, then tablet. If your goal is to try to do well financially, you may have a difficult time targeting tablets as the primary device. However, as the Android tablet market grows, you will definitely want to make sure your game runs and plays well on larger screens.

Tablets have the luxury of large, often very-high-resolution displays. So games will generally be easier to play because game elements will be easier to see and inputs will be easier to interact with.

One potential drawback is that many Android tablets don’t have the same auxiliary hardware that many smartphones do. The Kindle Fire doesn’t have a camera, microphone, or any location-based services. If your game only uses touch input, that’s fine. But take these factors into consideration before you begin to code.

TV and beyond

Google TV, which at its core is Android-powered, has been released in standalone set-top boxes as well as integrated into televisions and DVD players. So far it has not caught on, but Google seems intent on continuing to push and support TV as a platform for Android.

While many apps may run on Google TV, the input system is completely different from those of other devices. Currently, Google TV supports input through a remote keyboard device, which has a touchpad. A game designed specifically for touch input would probably have to be modified significantly for use on Google TV, although some games may be more amenable to the format. Right now, if your game doesn’t run in that format, the size of the audience doesn’t justify putting in the extra developmental effort. But this may change in the future, so it’s a good potential market to keep an eye on.

Other — more speculative — markets may include cars. Some major car manufacturers are working on pre-installed Android devices for playing media and navigating via GPS. Of course, you wouldn’t want to design a game that the driver would need to interact heavily with, but games for road trips (like I Spy or singing games) could be designed for existing devices, and may port easily over to car systems when they begin to become popular.

And because Android really can run just about anywhere, there are other uses and markets that are likely to arise in the future. Flexible screens will be hitting the market soon, allowing for wearable devices such as armbands! Google’s Project Glass is a design in the works for wearable glasses that carry out many smartphone functions. Be ready for thinking about how you might design for such devices.

The more streamlined and intuitive your interface and controls are, the easier it will be to adapt them to future devices. Technology moves rapidly, and if you want to stay in front, you’ll need to stay informed and be thinking ahead!

Designing the interface and controls

You’ve got a lot of important choices to make when it comes to designing how players will change what happens in the game by interacting with it.

Some of the most important factors when considering interface design are to be sure that game elements and controls are

Intuitive: After you’ve completed a workable version of the game, one of the first things you’ll want to do is give “The Grandmother Test”. This doesn’t mean actually giving it to your grandma to play (though that may not be a bad idea if she’s up for it). Here “grandmother” refers to someone who is generally not a hardcore game player. The idea is to see how quickly they “get it” when trying to navigate and play your game.

• If they pick up how to play your game right away, you’re doing something right.

• If anything is confusing or frustrating, you’ll want to try to ask targeted questions to figure out just what about the interface you need to change.

Clean: Make sure that the players can easily see what they need to see and click the things they’re trying to click.

If your users can’t find their health bar or habitually click one button when they mean to click another, you’ll need to think about revision.

Pretty: If you want your players to spend a lot of time with your game, you’ll want it to look (and sound) good. Nice production values go a long way in making a game popular and keeping it that way.

A big difference between some games that do well and those that don’t is often the amount of polish. After coding your game for weeks or months (or even years!), you may not feel like making a lot of cosmetic changes, but the extra effort is often rewarded with happier users who are more willing to play your game — and recommend it to others.

Hardware controls

Depending on the type of game you’re planning on implementing, you may want to use hardware, such as the keyboard or trackball/trackpad, for input. If the player is not using the touchscreen for input, there’s the added advantage that fingers or thumbs won’t be obscuring the screen, leading to a more natural game experience. In practice, this approach isn’t always feasible because of the inconsistency among hardware configurations of Android devices.

Prototype your control scheme early in the development process to get a feel for

Whether it’s going to work

Whether a wide variety of Android devices will support it

Virtual controls

Sometimes you want to mimic the functionality of hardware controls such as buttons or joysticks when the hardware just isn’t available. Virtual controls are emulated versions of hardware controls implemented in software.

For example, you may want your game to use a directional pad (d-pad) for moving a character through the game. If you wanted to implement this feature on a phone or tablet that doesn’t have a d-pad, you could draw something that looks like a d-pad in one corner of your game, using the touchscreen to capture inputs so that portion of the touchscreen functions like a d-pad.

I’ll just come right out and say it. I don’t like virtual controls. I’ve never played a game with virtual controls that I like:

In general, the response time — not to mention the touch and feel — of virtual controls will be far inferior to what you get from actual hardware.

They take up a lot of screen space. Real estate on small screens is at a premium. If you clutter the screen with controls, you have less space to show other elements.

For some games, virtual controls make the most sense. An implementation of Pac-Man without a joystick and buttons, even virtual ones, just wouldn’t be the same. They do have the advantage of working on any device with a touchscreen.

Other cultures and languages

App stores are global markets, and Google Play is able to offer your apps in dozens of countries around the world. You might want to consider localizing your game so that players around the world can enjoy it:

A number of freelancers and companies will charge you to localize the language in your game.

If you have a friend who’s a fluent speaker of a particular language with a large demographic, that’s even better!

As a general rule, you’ll want to maintain the text of all your user interface (UI) elements (such as buttons, titles, and warnings) in a separate file. Chapter 4 will go into more detail about how this is done in practice.

One other thing to consider is cultural differences. Think about how your game might be perceived by particular cultures. If the enemies in your game are WWII Japanese soldiers and they’re portrayed very negatively, your game might not go over very well in Japan. You don’t need to be overly fussy about political correctness, but your game really is going to be available to a global audience as soon as you hit that Publish button.

Players with special needs

Consider players who are blind, deaf, or unable to use traditional modes of input to Android devices. Designing playable games for these types of users can be extremely difficult. But if you specifically target such an underserved demographic, you will probably develop a particularly loyal fanbase.

Tutorials

One way to make your game more playable, especially if it introduces new or unfamiliar concepts, is to include a tutorial.

If your game is novel, you’ll want the learning curve to be gentle at first, ramping slowly up in difficulty as you introduce more concepts:

A practice mode is one possible way to implement assistance as the player becomes familiar with your game.

A dedicated “tips” window can appear when the player enters a new screen.

You can display tips on loading screens, a popular practice on many modern games because it works extremely well.

Pay close attention when you give the game to friends or family for the first time, and see how easily they pick it up:

If they are having difficulty, it could be an issue with the interface or an inherent problem with the game design.

It could be that your game is just new and complex enough that new players need your help to figure out how to engage with it.

Most beginning game designers don’t think of themselves as teachers — they just want to make a cool game! — but sometimes a little teaching goes with the territory.

Your game may be extremely intuitive to you because you’ve spent so much time tweaking it in your head. Try to be objective and think about what it’s like to see and play your game for the first time. Testers will help you with this, of course, but train yourself to think this way as well. When you do, you’ll often find that familiar aspects of the game — obvious to you, the maker (of course) — must be pointed out to many of your potential players. That’s where tutorials come in.

Finding and/or creating resources (graphics and sound)

Unless you’re designing a game that doesn’t require graphics or sounds, you’re going to need some visual and audible whiz-bang. Even if your game doesn’t require graphics, you’ll still need an icon and a banner for the market listing. You’ve really got two choices for these resources: buy them or make them yourself.

Create your own

As a game developer, you’re already going to have to wear a lot of hats. If you’re an indie, you’ll probably have to handle all the business, support, marketing and PR, and any other day-to-day business of running a small game company. Rare is the person who can do all that and produce quality art, sound effects, and music.

If your game is not very graphics- or sound-intensive, you might be able to get away with doing everything yourself. If you’re working on something like a card game or an abstract physics puzzler, you might be just fine opening up your favorite graphics program and creating resources yourself. But be warned: Some in the game development community have come to refer to bad graphics as “developer art”. Even so, a lot of indies don’t have the budget to hire an artist, and even making do by themselves they can enjoy a fair amount of success.

If you do tackle your own game art, you should at least invest some time and effort in learning some basics about art and graphic design. Your game is going to be available to millions of people around the world. You want it to look good! Your icon is especially important in making a first impression to prospective players; the appeal of a good-looking icon can’t be overstated. Find some books on art and graphic design, and consider taking a course or two at a community college or in continuing education.

Hiring creative contractors

The ideal situation is to hire artists to create wonderful art and music for you. In addition to getting a higher-quality product, you’re less likely to stretch yourself thin, giving you more time to develop and make your game more playable and fun.

Even on a relatively small budget, you can take some steps to maximize your return on the money you spend on art and music. The stereotype of the starving artist is, unfortunately, too often true; you can often find students or artists just starting out who are willing to work with you to provide you with affordable art and music for your game.

Art

You’ll want nice art in whatever game you develop, but if you’re working in a genre like hidden objects or any genre with lush, full-screen art, you’ll definitely want to invest in a good artist. If you don’t know one personally, you can try to find one either online or in your local community. As with any type of contracting, face time has a lot of value. If you can sit down with your artist over coffee and work through sketches and ideas, meetings can generally be more productive than they’d be over the phone or online:

You might want to consider posting flyers at local colleges, in the mailrooms or cafeterias, and of course wherever art classes are held. You might be surprised at the amount of interest. A lot of aspiring art students may be willing to collaborate just to help build a portfolio.

Online, you can find a great resource for indie game developers in the forums at Indiegamer.com (http://forums.indiegamer.com/). A wide range of both artist and music and sound people post samples of their work, as well as posts of availability for projects. You can contact artists via e-mail and ask for hourly or project quotes if you like their work.

Another place to scout out for artists is deviantART.com. Amateur and professional artists showcase their work here, and it’s a great place to scout them out and approach them with offers to work.

Sound and Music

In many ways, sound and music are generally less prominent for the mobile platform (hint: tiny speakers), but they can still be a key ingredient of a successful game.

Because people will likely be playing your game when they’re out in public or otherwise surrounded by other people, often they may be inclined to play your game without sound or music, even if those features are available. (Imagine, say, a user not wanting to wake up the sleeping baby in the next seat on the plane.)

Sound effects or music in your game should be slightly lower on your priority list, and if you do implement them, always offer the option to disable them.

As for finding quality people to generate art and music for you, a lot of the same advice as for finding graphical artists applies: Scout your local colleges for students, as well as the forums at Indiegamer.com.

You obviously want great resources for as little money as you want to spend. But everyone values their time and talent, so try to use tact when dealing with creative contractors. I’ve seen many complaints in game development forums about how many artists are flaky and don’t follow through with contract work, but that’s probably because you’re more likely to hear when something goes wrong than when it goes right. I’ve personally dealt with a number of creative contractors, and overall I’ve had very good experiences.

A good policy for contracting work, even for relatively small projects, is to make everything clear in writing up front. A simple contract works well, but at the very least draw up some kind of document that states what is expected of each party, with realistic deadlines. With this approach, there’s much less chance of confusion and disagreement down the line.

Treat people with professional courtesy and respect, and they will be much more likely to reciprocate.