Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Get the latest Education e-news
 
  • Book Excerpt: Creating Casual Games for Profit and Fun

    [04.19.07]
    - Allen Partridge

  •  Listening to Your Audience

    One way to stay in tune with the cognitive challenge your game is providing for your audience is simply to ask them and listen to them. Developers often poll players in the form of beta tests to find out what they think about the various challenges and rewards in a new game. You can even take this step further by enlisting the advice of your audience earlier in the development process, thereby getting a sense of their likes and dislikes before precious development time is wasted on features that are of little benefit. Regardless of how you learn your audience's tastes, it's important that you identify the characteristics of a given audience and work with representative members of that audience to make a game they enjoy.

    To do this you have to first understand who that audience really is. This can be tough for developers. The casual gamer is often referred to as stupid and casual games labeled as games for stupid ­people. This is, first, nonproductive and, second, not at all correct. Casual game players are not stupid. They are just not the sort of ­people who would think of themselves as gamers. They often don't have a lot of experience playing games and they aren't always very ­familiar with computers, especially computer interfaces for games. It would never occur to them to press keys to jump, run, or steer a game character. They don't immediately see what people with a lifetime of game experience see.

    A release candidate is a postbeta functional version of the software that is stable and believed ready for release. Only a stop ship or showstopper bug (something that would render the software unusable) is sufficient to make changes to the software at this point.

    A great first-hand reminder of this was provided when Podz was presented to a typical casual gamer to test. This game player is an office worker by day, exposed to computers and used to playing casual games on them, but not at all accustomed to "new game paradigms." In retrospect, she was the project's best beta tester. Immediately she had dozens of questions, many of which were literally dumbfounding. "How do I start?" she asked, staring at a screen with a bright green arrow (Figure 1.6).


    Figure 1.6 An early interface that was far too complex.

    Most portals expect a release candidate or gold version of the software to be ready by the time you start working with them. They do not want to spend expensive time waiting for last-minute changes.

    Based on comments from the beta testers, we made the arrow flash brightly, and it was the only motion on the screen. We removed the up-sell button and removed the three mode-setting buttons, including their huge expandable descriptions. We worked for months to figure out what exactly the player needed to know to play the game and concluded that there were only two critical concepts required to start (remember, easy to learn-no novella required). Those concepts are summed up in the final launch screen, which reads simply, "Feed Podz" and "Kill Slugz" (Figure 1.7).


    Figure 1.7 The final interface for Podz requires much less thought.

    Too much text on the screen frustrates and confuses many casual game players. They want to get to the fun, and don't generally like to read lengthy instructions. They will often ignore text, refusing to read lengthy instructions.

    We added a prescreen pop up to gather the player's name before a new player even reaches this screen. The result allowed us to create a drop-down menu, preset to the player's name, right next to a bright blue flashing arrow. After this change, players were no longer confused about how to begin the game. Much of the confusion of the original interface can clearly be attributed to information overload. Remember, a casual game player doesn't want to have to work to figure out how to play the game (Figure 1.8).


    Figure 1.8 This basic window appears first, to gather the player's name.

    Most casual game launch screens use text-based buttons to give users choices. This is probably to ensure that the players are absolutely certain of what will happen when they make a choice. Generally these choices avoid unusual words to describe choices, using words such as timed and story rather than descriptive or themed terms that might be less clear.

    We still let people play the game in the untimed and noncolor matching modes, but we simplified the interface to allow the player to toggle time and color modes on and off using the buttons on the bottom left. Clicking the clock button disables the game timers, and a bright red NOT symbol appears over the clock. Clicking again toggles the button back to timed mode. Clicking the button on the right toggles off the color-matching feature (all the balls match all the cones). Like the timer button, clicking it again sets it back to the original, multicolor mode (Figure 1.9).


    Figure 1.9 Labels appear when the mouse is over the buttons. Icons indicate button state.

    It's difficult for developers to imagine that you need more than a green arrow to know what to do, but the casual gamer doesn't want to have to think (or more importantly, worry) about what to do. This tester helped us realize that we needed a whole new definition of what kinds of things needed explanation. We couldn't rely on conventions of design or gameplay to teach the player how to interact with the game. This is why casual gamers have so much trouble with new game paradigms and why they need so much hand-holding to find their way through your puzzles.

    Visual feedback is essential in casual games. Players are often tentative, and it is essential to do things like reinforce the idea that an object is a button by making it glow.

Comments

comments powered by Disqus