Casual Games SIG/Whitepaper/Production and Design

International Game Developers Association

Contents 1 Introduction 2 Design Considerations 2.1 Key Design Elements of Casual Games 2.1.1 Simple and Meaningful Play with Transparent Rules 2.1.2 User Interaction 2.1.3 Depth & Complexity 2.1.4 Rewarding Players 2.1.5 Showing Progress 2.1.6 Forgiving Game Play 2.1.7 Visuals and Themes 2.1.8 Narrative and Characters 2.1.8.1 Does a Casual Game Even Need a Story? 2.1.8.2 Picking the right theme 2.1.8.3 Rules for creating a compelling story 2.1.8.4 Defining Characters: Some starting points. 2.1.9 Using Sound and Interactive Audio to Enhance Gameplay 2.2 Game Mechanics 2.2.1 Matching Games 2.2.2 Chain Popper 2.2.3 Find Subsets 2.2.4 Shape Manipulation 2.2.5 System Management 2.2.6 Breakout Variants 2.2.7 Casual Sports Games 2.2.8 Card & Parlor Games 2.2.9 Other Arcade Variants 2.2.10 Innovation beyond the Tried-and-True 2.3 Using Depth in Casual Games 2.3.1 What is depth anyway? 2.3.1.1 Keeping it Simple first and foremost 2.3.1.2 Just how long do we want this game to be? (And how do we know its enough?) 2.3.2 Simple Strategies for Depth 2.3.2.1 Discovery and Surprise (Hidden features, easter eggs, bonuses, optimal play strategies, optional play) 2.3.2.2 Just one more level, then I get a new Flower! (Rewarding Players) 2.3.2.3 Replay Variance and other Replay Strategies 2.3.3 Using Themes for Depth 2.3.3.1 Minimal Story – Maximum Depth 2.4 Key Design Elements for Advergames 2.4.1 Brand Messaging 2.4.2 Scheduling 2.4.3 Campaign Goals 2.4.3.1 Large number of plays 2.4.3.2 In-depth Experience 2.5 Key Design Elements for Casual Single-Player Games 2.5.1 Aspirational Fantasy 2.5.2 Optional depth 2.5.3 Showing Progress 2.5.4 Designing for Upsell of Premium Content 2.5.4.1 Deepening Gameplay Over Time 2.5.4.2 Higher Quality Experience 2.5.5 Using the free trial version to close the deal and make a sale 2.5.5.1 Content Limiting 2.5.5.2 Feature Limiting 2.5.5.3 Time Limiting 2.6 Key Design Elements for Casual Community Based Games 2.6.1 Head to head play 2.6.2 Leaderboards and Rankings 2.6.3 Viral Marketing 2.6.4 User to User Communication 2.7 Documentation 2.7.1 Structure of a Game Treatment 2.7.2 Structure of a Game Design Document 3 Production Issues 3.1 Process Differences 3.1.1 Smaller teams 3.1.2 Working with distributors to publish your content 3.1.3 Self-publishing 3.1.4 Working with Clients on a Work-for-Hire Basis 3.1.5 Working with a Publisher 3.2 Project Constraints 3.2.1 Money 3.2.2 File Size 3.2.3 Technology 3.2.4 Working with Team Members in Multiple Locations 3.2.4.1 Game Design Document 3.2.4.2 Project Timeline 3.2.4.3 Asset Management 3.2.4.4 Communication 3.2.5 Deadlines 3.2.6 Publishing & Portal Needs 3.2.7 Builds and DRM Issues 3.2.8 Community Management 3.2.9 Summary 3.3 Risk Management 3.3.1 Prototyping 3.3.2 Play Testing & Beta Testers 3.3.3 Production assets 3.3.4 QA 3.3.5 Tracking Versions 3.3.6 Good Client Relations 3.3.7 Technology Choice 3.3.8 Smaller Project Size, Smaller Teams 3.3.9 Funding 3.4 Localization 3.4.1 Poor Planning 3.4.2 Linguistic and Functionality Testing 3.4.3 Quality of Translations 3.4.4 File-Naming Conventions 3.4.5 Design Pitfalls 3.4.6 Cultural 3.4.7 Content 4 Conclusion

[edit] Introduction

The Casual segment of the games industry changes almost as rapidly as the Internet itself. Technology evolves, broadband usage increases and, every day, more and more people are playing and accessing and even playing their games online. Not only that, casual games are getting richer and more complex. The evolution in casual game design is finally taking its own path and leaving behind many design rules that applied to core video-games.

In this section, we will examine what it means to design games for the evolving casual games medium and its wide-ranging, international audience. Specifically we will examine the production and design issues facing developers who are looking to make a successful title for this market segment – and focus on the following issues:

• Design Considerations – Designing casual games with your target audience in mind.
• Game Mechanics – Typical game mechanics found in casual games.
• Key design elements specific to Advergames, Single-Player Games, or Community Based Games.
• Production Issues – Production and process issues inherent to casual game development.
• Process Differences – Differences between producing casual games vs. other gaming platforms (e.g., console).
• Localization - Effective ways of delivering your games to a world-wide audience.

There are many types of casual games - each with their own design considerations. The table below provides an overview of key design differentiators, typical file size and additional examples of each type of casual game discussed in this section.

[edit] Design Considerations

Web and Downloadable games have a unique set of design considerations. Many important issues in the development of Web and Downloadable games are common to all game design, but the nature of the audience, business model, and context of these games shapes their design philosophy. We know that Web and Downloadable game users play these types of games for three reasons: diversion, competition and socialization. These reasons are not mutually exclusive and the best games touch on all of these elements in one way or another.

[edit] Key Design Elements of Casual Games

[edit] Simple and Meaningful Play with Transparent Rules

At the heart of game design is the idea of meaningful play, the idea that players interact with a game in ways that produce clear and purposeful results. What differentiates games from other forms of media is that players engage the game’s system to change it in meaningful ways. This idea of meaningful play is manifested in a number of ways in casual games. First, there is the importance of understanding basic gameplay; players’ actions must elicit clear and understandable responses. In a similar vein, it is important that the rules of a game be transparent. Just as the basic interactivity needs to be entirely comprehensible, so the rules of the game should also be at best intuitive and at worst easily grasped by players. In even the most complex computer games, rulebooks are used only for reference; most of the play is learned through experimentation and in-game instruction. Similarly, a casual game’s rules should be intuitive and require no more than a one-screen help or simple tutorial to thoroughly understand.

[edit] User Interaction

Many times in casual games much attention and focus has been shifted towards making sure the game is attractive to the eye and utilizing animations and particle effects, however it is essential that users are able to play the games by utilizing visual and audio cues within the game.

Casual gamers will rarely go through a lengthy tutorial, and as we all know manuals are useless, even for videogames. So as a developer don't be discouraged if your game is complex. First try to figure out if you can explain the game through various levels, rewarding the user enough to keep them interested in the game. If you can't break your game into small chunks of interaction, then there could be something wrong in your design for a casual audience.

This is what makes interface design so important. The concept can be summed up as – “The user should always know what the next step is by just looking at the screen or know what is happening by watching/listening to the game.” It is important to make a game attractive to the eye, but if people cannot figure out how to play – they will stop.

Every game is different, so how to implement the visual and audio cues will always be different. Visually – anything important, or the “next logical step” should always “pop” in some way, especially if it is something outside of the normal mode of play. If a game is designed correctly, users will quickly become accustomed to how the game should be played. If a user needs to click something additional, they should be prompted in some way. Blinking, throbbing, hi-lights and even an arrow pointing at what to do next are easy visual clues as to what is happening. One trick some developers use is to look away from the screen. When you look back, the first thing that catches your eye should be the next thing you should do (click on).

Another good feature that developers have used is a “waiting user” prompt. If the user should spend a period of time not doing anything, or not making progress, the game will prompt the user in some way of what to do next.

The interaction between the user and the game should be limited to the computer mouse. The use of a keyboard in casual games can be an obstacle for some users. Since the pace of the casual game is usually relaxed, and the gameplay is easy, adding complexity in the form of the keyboard could be inadvisable.

Use of buttons, where possible, should be limited to the left button. Use of right button is actually possible in casual games, but ideally it should be used for an action that is not absolutely necessary. An example is the use of the right button in Zuma, where you can swap the current ball. Some players will never use it, whereas some advanced players will.

While designing the game, try to think how can you create a combination of control and interface that simplifies the number of clicks that the player has to do to accomplish an action. A good example is the contextual interfase in Plantasia, where when the player hovers over a bug the mouse icon turns into a insecticide can.

contextual interface in Plantasia

[edit] Depth & Complexity

An important issue is the complexity of games. Considering the normal play periods of casual games (short) and the game experience of the average players (limited), it is not appropriate for casual games to have wildly complex systems that require careful, constant attention and deep strategic thinking. A real-time strategy game with hundreds of units to choose from, or a 3D world with miles of virtual space to explore presents an experience designed to captivate a dedicated user for hours of intense play. However, many people play casual games to take a relaxing break from work or to pass the time with something engaging. This means that casual games should be based on simple core activity that leads to emergent complexity. Initial access to the game should be easy, and the difficulty and engagement of the game should come from doing that same basic activity in increasingly challenging environments. In other words, the game should give the player a simple way of interacting that becomes a rich experience in the game’s context. More complex forms of interactivity, as the real-time strategy game mentioned above, often have steep learning curves that run against the casual interests of the audience. This desire for simple core interactivity has a number of implications. First, a casual audience is generally not interested in memorizing complex macros or commands to understand a game. Thus, casual games are predominately mouse-based, either exclusively or with wholly optional hotkeys. When casual games do use the keyboard, it is almost always limited to arrow keys and a single action key. Thus, the core activity of the game is also fairly simple: clicking on a pair of grid squares to switch two objects, moving the mouse over a deck to reveal a card, or dragging an item from a palette to a specific spot on a game field. The complexity of the game comes from the way that simple interactivity mechanic is used in the context of new levels and available resources (new things to swap, new cards to see, new terrain on the field to negotiate).

In addition, the game should require very limited help to understand. Even more than other kinds of games, casual games should not require players to read detailed instructions or experiment extensively to grasp basic game concepts. Anything that is so complicated that it requires more than a single page of simple help or (at most) a tutorial first level is most likely too complicated for the market. It is also important to keep in mind that many of the tropes that hardcore gamers have internalized are not part of many casual players’ vocabularies. This means that what may seem standard conventions to gamers (e.g. asdw for movement, smashing crates to get health) will be lost on a large part of the Web and Downloadable game audience. This is all the more reason why the basic gameplay must provide clear and consistent feedback.

[edit] Rewarding Players

As part of the experience, reward is very important in Casual Games. The player's main reason to play Casual Games is to get away from the worries and frustrations of every day life. Being constantly rewarded is a way to make the player feel good about what they are doing.

Of course, the Casual Game designer shouldn't confuse rewards with simplicity of play. The game's challenge should still be there, but in many steps of the way the player should be notified of their good deeds. Bonus points for specific actions have been a common reward resource in Casual Games. Combos is another way.

Rewards are also related to the optional depth that can be added into the game (see the Optional Depth section for more info).

rewards in Feeding Frenzy 2

[edit] Showing Progress

Rewards will not be relevant if there is no place in the game where progress is represented. Probably one of the most important elements of any game is the score as this is a key motivation factor for many games. If the game is score-centric, anything that either adds to or takes away from the users score should be point blank obvious. Users should immediately know when they have done something good and their score increases, or when something bad happens. Even if the game is not score-centric or there is some other kind of task that is necessary for a user to complete to move ahead in the game, accolades should always be represented with some kind of positive audio cue.

progress bar in Shopmania

[edit] Forgiving Game Play

Casual games should be very forgiving, particularly in the early part of the game. The game should not punish players too harshly for initial mistakes, and should give new players time (whether it be in early levels or beginner’s modes) to learn the core interactivity. The grace period can last quite far into the game, with the difficulty only ramping up well into the experience. Consider that the majority of this audience prefers games such as Bejeweled Easy Mode, which is very difficult to lose unintentionally. Difficulty should be less of an obstacle that players must struggle to overcome than a natural growth that matches the player’s increasing expertise of the game. Overall, increased rewards for successful actions and reduced penalties for early mistakes are key components to making a successful game for the casual games market. The consumers driving this market generally do not see themselves as “gamers” looking for a deep challenge. Often, they are looking for an immediately fun and positively rewarding entertainment experience similar to the benefit one receives when tuning into a trusted primetime TV show that provides a mental escape with a minimal learning curve.

[edit] Visuals and Themes

Keeping the audience in mind, the visual design in a Casual Game could vary depending the target audience. The game designer should ask first who is going to play the game before deciding on a particular theme or visual style.

On downloadable single-player games, historically successful visual themes were something that players are somehow familiar with. Games that are based in real life environments (ie: Cinema Tycoon) give the player a sensation of playing in a familiar environment. Other non real environments that casual players are familiar with are those that have been portrayed successfully on very popular Hollywood films: magic (Lord of the Rings) or exotic places (Indiana Jones) are some examples. Contrary to popular belief in the technological crowd, sci-fi movies are not as popular across the mass audience. Casual Game designers should stay away from putting sci-fi themes in their games.

Cinema Tycoon

Many downloadable, single-player games take the path of a "realistic" look. But some have started to have cartoon-like looks (ie: Diner Dash). The key is to not make the player feel they are playing a game for kids. Contrary to puzzle games in arcade machines in the 80s (ie: Pengo), since most downloads get purchased by an older audience players in general get put off by "cute" characters or visual elements that make the sensation of watching a Saturday morning cartoon. Exceptions to this case tend to gravitate towards those games who have a realistic theme (ie: Cake Mania) or have UI and supporting graphics with a mature look (ie: Chuzzle).

Cake Mania

Chuzzle

When it comes to online web games, the choice of themes and visuals tend to be different. Since the age range of web game players goes across the board, there are all kinds of visual themes used successfully. It will depend on the web site's audience mostly. Sites like Cartoon Network, Nick, and to a big extent Neopets target younger players and hence cartoon like visuals are the norm and work very successfully.

Use of bright and shiny colors, appropiately used, is a plus. Even some special effects (ie: the use of particle systems to create an explosion of stars when an award is given) have worked well in some games.

[edit] Narrative and Characters

Any discourse on story and character (and by extension, narrative and metaphor) in casual games, ought to probably be prefaced by a brief acknowledgement of the challenges our larger industry faces in brokering the thus-far awkward marriage between interactive entertainment (including console or “core” video games) and compelling narrative (including story telling and character development).

There are numerous books and courses available on storytelling, character development and approaches to narrative structure. Many of these focus on writing for film, television and fiction. There are some on comic book writing, a few for games, but next to none on casual games. When folks do discuss storytelling’s dance with video game design, inevitably they bemoan the lackluster job we as game designers have done (to date) of seamlessly integrating story and interactive play. But the common wisdom is that, as a relatively new medium, video games are still getting their sea legs when it comes to sophisticated approaches to story telling, defining a compelling character or, more famously, of moving a player to tears.

The question is, where do Casual Games fit into this larger polemic? Do we operate under the same rules and are we wading through the same challenges as core game designers? Or, are the idiosyncrasies of casual games and their non-hard-core-gamer audience going to liberate the casual game designer and give him or her a uniquely advantageous position at the cutting edge of elegantly interpolating story and interactivity?

[edit] Does a Casual Game Even Need a Story?

Not all successful casual games have needed story and character. After all, isn’t gameplay everything? Who cares about story? Why add characters? Why add story? It costs more, right? And it’s hard!

Sure, a game has to have good gameplay or you’re sunk. But here are some reasons it may just be worth the effort.

1. Artistic merit. If video game making is an artistic medium, we should be able to use it for all kinds of self expression, especially story telling. Story and character are tools for entertaining, for touching people’s hearts, for making an emotional impact beyond the mechanics of the game, beyond a high score, a game’s interactivity or its puzzle.
2. The value of character IP. Additionally, as our industry matures the opportunity to build character I.P. has obvious financial upside. Lara Croft, Tomb Raider. Nuff said.
3. Good Narrative = Crack. From Charles Dickens’ Victorian masterpieces, to today’s Sopranos or Lost, serialized fiction is infamous for sucking in its audience and keeping them coming back to find out what happens next. For Casual Games especially, where a 30-60 minute free trial often stands as an obstacle to a purchase, the use of story might just be the holy grail of conversion, motivating users to keep playing. Especially stories with –compelling characters in cliffhanger situations.

[edit] Picking the right theme

Casual Gamers love Aztec themes, right?

A rich game metaphor provides back-story, defines the play environment, adds a compelling motive to the player's game goals, and gives the user a deeper feeling of immersion into the experience. What’s different here about the casual game audience? The story goes that as video games first began to explore narrative themes, the game-making community chose themes that appealed to game makers. Thus the over-saturation of spaceships, robots, archeological tomb hunters, elves and dragons that blast, shoot, swing or roar their way through the game players’ imaginative landscape. Casual games have for the most part trodden the same narrow territory – space ships, aliens, goblins and elves all make their way through the casual game landscape. When you throw in ancient archeological lost city themes like Mesoamerican (think Incan, Mayan or Aztec) and Ancient Egypt you’ve just about covered half the casual games out there. But over the last two years we’ve seen some brave experiments emerge, testing the waters on broader narrative themes and more everyday characters. We’ve seen successful games like Insaniquarium, Mystery Case Files, Diner Dash, QBeez2 and Granny in Paradise, all borrowing from the popular arts of prime time television, making for a more varied buffet of metaphor and themes dotting the interactive entertainment landscape.

Will your casual game’s story and characters appeal to the casual game market (most of whom are not adolescent boys and many of whom are adult women)? If you’re thinking about a game with dungeons, bloody battles, spaceships and robots, you might be going down the wrong path.

[edit] Rules for creating a compelling story

It’s worth noting that a good deal of the following may be subjective. Not all stories work by the same rules. Not all stories will benefit from the same approaches. This section therefore may prove more subjective than say, the section on publishing or distribution models, but here goes. As a game designer there are a host of rules to follow or break as you see fit when telling a story in a casual game. What’s so different about casual games? The main difference is the audience. Whereas in a core game, the audience may forgive bad dialogue, poor character development or no story at all in exchange for super cool graphics and hi-tech themes like shooting rampages, battling droids or half-clothed bikini elves, the audience of casual games is made up of many non-hard-core gamers and the bar for entertainment quality is set not by other games, but by television and film.

Here are some often cited oft maligned rules of thumb for story telling in casual game making.

1. Immersion. Create the illusion that the player is in the story world. Take care not to shatter that illusion.
   • Keep the technology invisible. Don’t remind players they are on a computer. Immerse the user in the narrative world.
   • Don’t break the fourth wall. Try to avoid breaking the fourth wall (the wall between the characters on stage and the audience – thus avoid lines like “Hello there player! Use the mouse and click and drag that item over here!” – or “type on your keyboard”)
2. Respect the player’s imagination. You don’t need to tell the user every detail. They will enjoy the interaction more if you let them participate in how the story emerges.
   • Allow for closure. Visual theorists call it “closure” when an artist lets a viewer fill in the gaps of a broken circle or on what happens between panels of a comic book. As a story teller, you don’t need to tell every detail of your whole story. Allow the user to fill in the blanks with his or her imagination.
   • Start as deep in as possible. Start the story as deep into the narrative as you can, allowing the player to fill in the blanks.
3. Waste not, want not. With small file sizes and small budgets, typically you can’t afford extensively animated cut scenes or tons of casted and recorded character dialogue. But big budgets and big file sizes don’t always mean good story telling.
   • Less is more. Brutally edit your dialogue. Write a script for scene, then cut it in half – then take a breath and cut it in half again. It’s cheaper and it’s likely that your story will be more interesting if less is revealed. Most players don’t want to read. If your game has a comic book page, can the player get the gist of the story just by looking at the artwork and not reading any text?
   • Naturalism. Save time in writing and casting. Go for naturalism in your casting, dialogue writing and directing. People are used to standards set by television and film. No one wants to listen to an overacted set of affected lines read in a deep hoarse throaty manner. No matter how evil it makes your character sound.
   • Action is key.
     • Animation is expensive, can you use comic strips instead of animated cut scenes? If you’re going to animate make sure it’s interesting – ask yourself if it’s really worth animating?
     • Content in the context of action. Never tell when you can show. Avoid talking heads with lots of exposition. If you need the characters to convey to the player some information, can you convey it within a dialogue as the players are scaling a wall, or climbing a tree or…?
   • Rely on Audio. Audio is typically cheaper than animation as a tool for storytelling. Sometimes music, voice and audio sound effects to help immerse, set a mood tell the story.
4. A story is different from a list. If you’re going to tell a story in your game, keep in mind that a good story is not just, “first this happened, then that happened, next a third cool thing happened.”
   • Foreshadow. A good story has narrative structure, offers thoughtful foreshadowing during early stages of the narrative to set up expectations.
   • Use a “Third act twist”. A good story then plays with or twists those expectations (usually in the “third act” or final act of the game).
5. Seamless integration. Maybe the hardest part. Can you weave interactivity and story around each other without making the story feel contrived or tacked on as an afterthought? Playing the game should feel like you’re making the story unfold further. Can the story change depending on the player’s choices?

[edit] Defining Characters: Some starting points.

1. Do you know who your character is? Creating a Rich Backstory. Knowing who your character is will make it much easier to write natural dialogue and compelling stories. Take the time to define your characters’ back story, their likes and dislikes, family history, strengths and flaws. Their pet peeves. Their quirks and catch phrases. If you do this right, you will know much more about your character than you ever will be able to tell in a small file game but it will make the dialogue flow freely if you can really channel your character and see into their inner world.
2. Do you care about you character? A lot? If you don’t care about who your character is, then don’t expect the player to care who he or she is!
3. Draw on what you know. Don’t just add a character because you think you need one. Draw on your own experiences and your own world to create more believable characters that people will care about and understand.
   • Is your character someone with whom players can identify?
   • Is your character aspirational? Someone players might identify with or aspire to be?
4. Work with your artist. The character artwork should tell you as much as possible about that character (while avoiding stereotypes)
5. Test!!!! What we think is appealing may not be appealing to our audience. Draw out multiple versions of your characters and run them by potential players. TEST!!

[edit] Using Sound and Interactive Audio to Enhance Gameplay

Sound can make a powerful addition and percieved added value among casual game consumers. Audio can add emotional context for a player to excite and involve them in the game. Because of the repetative nature of casual game play as well as typically less narrative content than a console title, audio is an area that allows developers to keep the gameplay fresh and interesting as the game progresses. Audio is typically broken down into three sections.

• Music
• Sound Effects
• Dialog

Most games in the casual gamespace have at least some basic set of sound effects and music. There are many basic areas where sound add value to a game.

• Game Environment and Narrative Context - Similar to a visual backdrop, music and sfx can add emotional and contextural elements to the game. Usually this is done through music, but sometimes through sound effects.
• User Interface - Typically these are just simple rollover, navigation, and click feedback events that are in line with the overall theme of the game.
• Game Interface - These are similar to the UI but are in game event related. This is a good place for some elements of randomization if possible.
• Game Feedback - Sound effects usually accompany scoring and reward events, as well as any negative feedback in the game.
• Easter Eggs and Surprises - These elements help to engage users over the long term. Surprises with the audio can be an inventive way to keep the game fresh and new with content.
• Music as a Gameplay Element - Occasionally the music itself is a gameplay element; this is most obvious in a rhythm action game, but also could mean that at the end of a level the music branches to warn the player.

Largely due to size and budgetary constraints, the biggest challenge of audio is avoiding repetition in gameplay. Randomization techniques, and other adaptive strategies should be used to increase replay ability. Here are some examples of techniques used in casual games.

• Random Music and Narrative Based Music Branching - Music is usually broken into small 2-8 bar chunks that are placed end to end randomly or in some strategy that fits the gameplay. These branches can be tied to gameplay elements, when you move on to the second part in a level branch to this music seemlessly.
• SFX Playlists - Sfx that either cycle through a playlist or randomly pick from a list is sometimes used for game and UI events.
• Split Track Music Playlists - Music can sometimes be broken down in a way that allows the game to change one part while the other continues. For instance having the rhythm split out from the melody might allow you to save not only space but allow the parts to change randomly for more variation in your game.
• Real Time Tempo Changes - Increasing the tempo during parts of the game might be an effective way to increase emotional tension, and add excitement to the game.
• Additive and Subtractive Music Mixing - Another musical adaptive technique when the music is split out (ie melody, rhythm, chords) is to add and remove parts directly based on gameplay.
• SFX Customization - Another unique way to deliver personalized gameplay experience is to use things like dialog synthesis to relay the persons score in real time.

With randomization it's important to remember that randomization should be placed in areas where the user expectation is low. Many events need a specific sound effect that never changes because it's so integral to the game experience and to do so would confuse the player. Usage of randomization in key places might confuse the player.

The unique nature of the casual market also allows composers and sound designers with break boundaries with their approach to themes and genres. Since there is typically a shorter chain of approvals in casual game development, it's easy to push though new and interesting genres of music that have never been heard in a game before. Unexpected genres are commonplace in the industry including music from the 50's golden age of tv, modern, abstract, cartoony, early 80s, star trek, therimins, whatever. The ability to break out of the normalcy allows a game to find a audience because it is unique and unusual.

As with the other areas of game development, technology and size will inform and sometimes limit the amount of things that are possible with audio. Many technologies and middleware have specific constraints as to what is possible with music. See the technology section of this white paper for additional notes on sound technologies.

[edit] Game Mechanics

The contributing factors of distribution, technology, and audience have shaped the current casual content offering. It is for these reasons that the casual gaming industry does not consist primarily of first-person shooters and tactical simulations. Instead, genres have emerged that address the needs of the Web and Downloadable games market.

As mentioned in the introduction, casual games have been largely dominated by a surprisingly small number of game play styles. Puzzle games make up the largest single group, followed closely by a variety of simple arcade games, word games, and classic card and board games. Within these larger genres, most casual games segment further into a handful of specific types.

[edit] Matching Games

Description

Players are faced with a grid of a limited variety of objects. The objective of the game is to swap, drag, shoot, or transform these objects to create sets of two or more, which then disappear for points. These games often contain "power-up" objects that clear larger parts of the grid or award bonus points for sets including them.

Match-Three Examples

Chuzzle (PopCap Games), The Da Vinci Code (Sony), 7 Wonders (Mumbo Jumbo)

Chuzzle

[edit] Chain Popper

Description

Arguably a sub-genre of Match-Three, this genre consists of games who's core mechanic is as follows: A 'chain' made up of a limited variety of objects moves along a fixed path. If it reaches the end-point, the player is penalized. The player slows progress of the chain by firing additional objects into the chain, aiming to form groups of three or more matching objects. Once removed, the more advanced part of the chain either stops or slides backward along the path until connected with the trailing part of the chain.

Chain Popper Examples

Zuma (Popcap Games), Luxor (MumboJumbo), Tumblebugs (Wildfire)

Luxor

[edit] Find Subsets

Description

Players are given a number of objects, a timed end point manifested as a clock, and sometimes a steady increase in the number of objects. The player's role is to find sets within the field objects based on a particular criterion (similar color, shape, etc.). Correctly finding and selecting these sets earns the player points and either delays the end point or advances the user to the goal.

Examples

QBeez2 (Skunk Studios), Collpase 3 (Game House), Magic Match (Codeminion)

A notable specific case in this genre is the word game. In this case, the rules of the game's language determine a correct set. Points are often given for correctly spelled words, with greater rewards being credited to players who spell longer words and/or words with rarer letters.

Examples

Bonnie's Bookstore (PopCap Games), Word Whomp (Pogo), Big Kahuna Words (Reflexive), TextTwist (GameHouse)

Magic Match

[edit] Shape Manipulation

Description

Players are presented with a empty container divided into different shapes, and a series of pieces that can fit into that container. The player's goal is to fill up the container by picking up, rotating, and placing pieces inside the contact so that no pieces overlap and no empty spaces remain.

Examples

Mosaic: Tomb of Mystery (Reflexive), Safari Inlay Adventure Edition (GameHouse), Shopmania (Gamelab)

Shopmania

[edit] System Management

Description

The player is put in charge of a small ecosystem of objects that interact in a variety of ways. The player may add, remove, or alter objects in the system to create particular effects and thus earn points.

Examples

Cake Mania (Sandlot Games), Plantasia (Gamelab), Fish Tycoon (Big Fish Games) , Diner Dash 2 (Play First)

Fish Tycoon

[edit] Breakout Variants

Description

The player controls a paddle, and uses the paddle to ricochet a ball into a set of blocks. The goal is to clear the screen of blocks. Power-ups alter the core game in a few ways including speeding up and slowing down the ball, making the paddle sticky, or increasing the number of balls on the screen.

Examples

Break Quest (Nurium), LEGO Bricktopia (Large Animal Games)

Lego Bricktopia

[edit] Casual Sports Games

Description

Simple sports games that are very forgiving and generally accessible to the widest audience possible in terms of game controls and game objectives.

Examples

Tennis Titans (Skunk Studios), Pin High Country Club Golf (Skyworks), and Backspin Billiards (Pixelstorm)

Tennis Titans

[edit] Card & Parlor Games

Description

This genre includes a variety of traditional playing-card games and parlor game favorites.

Examples

Mah Jong Adventures (Skunk Studios), Hearts, Spades, Hotel Solitare (Zylom)

Mahjong Adventures

[edit] Other Arcade Variants

Description

This genre includes a variety of traditional arcade-style gameplay.

Examples

Feeding Frenzy 2 (Sprout Games), Granny in Paradise (Sandlot Games), Tropix (Super Robot Brain)

While this list is by no means exhaustive, even a glance at the games available in the casual games marketplace reveals a preponderance of games that fit within this handful of categories. There is also a strong degree of overlap among the games within a single category, such that many games have nearly identical mechanics and are only differentiated by narrative context and visual style. In fact, there is a deluge of derivative games in the Web and Downloadable game market that seek to capitalize on the success of a proven mechanic. As the Web and Downloadable game industry grows, new game play, design and genres will emerge and evolve to the next level.

Feeding Frenzy 2

[edit] Innovation beyond the Tried-and-True

Innovation in the casual games field must still adhere to the principles of user interactivity and audience expectations as described in the previous sections. The casual gamer is simply a different user group than the hardcore gamer, and the kinds of experimentation and approaches that appeal to the latter may not be successful with the former. Of course, there have been examples of games that have provided different gameplay styles that have also been successful in the casual game market. "Diner Dash" and "Tradewinds" are both games that have previously unseen gameplay for casual games. They both have been commercially successful. Web-only games have seen even more radical experimentation. Games such as Grow (http://www.eyezmaze.com/grow/v3/index.html), Samarost (http://nlp.fi.muni.cz/~xsvobod4/amanita/samorost/intro.html), and Squares 2 (http://www.albinoblacksheep.com/flash/squares2.php) all demonstrate the ways Web-only games can push the boundaries of typical play patterns. Thus, there are possibilities with the constraints provided by a casual audience for new play styles, both as modifications of tried-and-true genres or as more dramatic experimentation.

Grow

[edit] Using Depth in Casual Games

[edit] What is depth anyway?

Depth is the set of features in a game that makes the core game mechanic richer and more complex. You can have a really good core game mechanic, but without a good set of features that extends it your game will be fun for just a little while.

In a way the three basic elements of Game Design (core game mechanic, depth, and level design) are similar to a house, in the sense that the foundation is the core game mechanic, the framing and walls are the depth, and the furniture is the level design.

Using these features across your game will make sure that the player is still interested in the game after a while. The spreadhseet at http://spreadsheets.google.com/pub?key=pRS6aR2P33d18YUfnsco0dg outlines all the different features introduced on Feeding Frenzy 2. We use this game as an example as the developers took very special care so each level is a different experience.

[edit] Keeping it Simple first and foremost

Game Designers, for most of the time, are experienced game players. And this makes it hard for them sometimes to imagine simple game mechanics accessible to everyone. Experienced players demand more complex game mechanics. But complex game mechanics from the get go are frustrating to even experienced players in most cases. At the same time, we all know how if a game contains only a fun and simple game mechanic it will be interesting for a little bit of time. A few years ago this was fine in the casual gaming industry, but today's casual gamers don't buy just any game.

It is important to design games with a core and simple game mechanic that can be extended into a more complex one by adding gameplay modules progressively throughout the game. These gameplay modules can be various different things, which we will cover in this section.

[edit] Just how long do we want this game to be? (And how do we know its enough?)

How many features you should pack in a casual game? The answer is enough to keep players entertained for the number of hours of gameplay you are targeting. Some web games provide just 20 minutes of gameplay, although this trend is changing as more complex games for the web are emerging. In the case of downloadable games, typical gameplay is around 5 to 8 hours. In order to keep players playing till the end, you should make sure you have enough features to introduce during the course of the game.

[edit] Simple Strategies for Depth

There are several ways to add depth in the game, and it will depend on the type of core game mechanic in the game which elements of depth can be added.

One thing to keep in mind is that every depth feature takes a significant time of development hours. So if your budget and timeline are like most Casual Games then it's better to plan features that are children of another feature. In Feeding Frenzy 2 for example, there is a "Leopard Shark" and a "Barracuda". The Leopard Shark is introduced in Level 8, and it basically is a fish that will always eat you doesn't matter your size. The Barracuda is introduced in Level 10, and it behaves exactly like the Leopard Shark, except for the fact that you can bite his tail. So the Barracuda is an extension of the Leopard Shark.

[edit] Discovery and Surprise (Hidden features, easter eggs, bonuses, optimal play strategies, optional play)

Many players, particularly in the casual gaming space, tend to prefer directed challenges or quests over open environments with many possibilities. But that doesn't mean the design of the game can't contain hidden features or easter eggs which give additional rewards to the player, even when finding them requires additional actions. And this is because discovering hidden elements and knowing where to find them is extremely rewarding for players.

In fact, Loco Roco (PSP) makes the pursuit of hidden objects as the whole point of the game. You can play Loco Roco sequentially, just trying to get to the exit. But the game will be mostly dull. If you start playing looking constantly for hidden paths the game's objective changes, and makes it a much more compelling game.

Another way to add an extremely rewarding experience is with the use of "special moves" or other optional ways to interact with the game to accomplish objectives. The key is to design them so the execution of them is a little bit harder than what a regular "move" would be, and make them more rewarding. Key is to include flashy and interesting visuals to emphasize the fact that the objective has been achieved through a special move created by the player.

[edit] Just one more level, then I get a new Flower! (Rewarding Players)

As we already identified the fact that providing rewards is one of the key design elements in Casual Games, we shouldn't repeat ourselves here, but relating rewards to the depth in a game is a very useful element in order to keep players interested in a game. An example of this would be when in a game players are rewarded trophies or material rewards which combined give a new skill or tool to the player.

[edit] Replay Variance and other Replay Strategies

Different gaming modes, or having to play levels of a game in different ways in order to discover all the content in them are ways of extend the play time in a game. But as a player skill or tools in a game increases, it is okay to put the player back with a similar challenge found in a previous level. Because of the player's new skills or tools he/she will be able to finish the level with less work involved, and that's a very rewarding experience, as the player recognizes the challenge as familiar and realizes his/her progress.

This technique should not be abused though. Players can assume that the game lacks enough content, and abandon the game. And there is always the issue of a proper difficulty increase, if the levels' difficulty doesn't increase progressively that would be another reason why the player would not be compelled to continue playing.

[edit] Using Themes for Depth

Themes can provide the hook for situations in a game where there are a significant number of repetitive tasks to be done in order to reach a goal. Themes can be the uber goal players aspire to.

[edit] Minimal Story – Maximum Depth

A casual game’s story is like water; in small quantities it's refreshing, but too much and you drown. Adding a page of text does not correspondingly add a layer of depth to a game, but a few concise lines interjected at the proper times will pay dividends. Most users do not want to read more than 1 to 4 sentences at a time; heck, they won’t even read the instructions, never mind a novella.

An good example of the successful use of minimal story in a casual game can be seen in the game Luxor. Originally, the design called for screens at the end of each stage, with custom art and text that advanced the storyline. A radically shortened development cycle, however, required that these be sacrificed; the only elements to survive were the chapter titles that served as the stage names. When the game shipped, comments poured in praising the game’s ‘great story’. The chapter titles were sufficiently descriptive to allow the player’s own imaginations to fill in the details. The most minimal of stories had surreptitiously added a layer of depth.

Here are some tips to help keep the story short and sweet:

• Outline the story early in the design process, and edit aggressively throughout the production cycle.
• Use story during natural pauses; never interrupt the game to advance the storyline.
• Tie story elements into the game; if you make the Deadly Daisy of Dogarth an important element in the story, make it prominent in the game as well.
• Avoid making the user read more than 1-4 sentences at a time.

And, most importantly,

• You always have the right to remain silent; exercise that right to the fullest possible extent.

[edit] Key Design Elements for Advergames

The challenge for an advergame developer is not only to make a great game, but to design it in such a way that it accurately and positively promotes the brand messaging, and ideals. This will also have to be done on an often extremely tight deadline, with key decision makers completely uninvolved until the very end.

[edit] Brand Messaging

Brand positioning is the most important part of an advergame for the end client. The developer needs to find out as early as possible what the overall theme, and messaging is going to be for this particular campaign. The game will usually be part of a larger ad-run incorporating banners, TV spots, print ads, and more. Keeping the game on message will be key to the overall success from the client's perspective.

Ideally, the game will be designed around the various aspects of a brand, creating a unique experience custom-tailored to the product or message.

[edit] Scheduling

Scheduling is often one of the biggest issues affecting advergame developers. The games are generally developed as part of a larger ad campaign, which incorporate ad buys, tv spots, and print runs with very long lead times. As a result the deadlines are typically very had deadlines and cannot be missed. In the agency world, a development time of 2-3 months is long, and 6 months is almost unheard of. This must be considered as the scope of the game is generally more limited by time, than it is budget.

[edit] Campaign Goals

When creating an advergame it is important to consider the overall campaign goals. While a casual game generally has the goal of earning revenue, advergames fit into marketing budgets, and do not need to focus on revenue. However, they will need to meet other, possibly more difficult, goals.

[edit] Large number of plays

If the goal is to reach as wide of an audience as possible, then distribution and compelling content is the key. The game will need to be extremely easy, allowing the player to play the game effectively in no more than 30 seconds. The most successful games here are generally very short, lasting no more than 2 minutes, and will also often include humorous elements to encourage viral distribution.

[edit] In-depth Experience

If the goal is to create a very in-depth brand experience, then the developer will need to focus on depth and variety of gameplay. In these instances, the game will still need to be easy to play, but the extended features will allow for more gameplay variation. It is not unheard of for advergames to be so engrossing that they receive 30-60 minute average play durations. With proper save games, and somewhat episodic content, it is possible to garner up to two hours or more of avergame playtime across an extended advergame campaign.

Another great example of in-depth experience are Alternate Reality Games (ARGs) which typically spread a mystery to be unraveled by a massive global playerbase. More information about ARGs can be found on the IGDA's ARG SIG (http://www.igda.org/arg/)

[edit] Key Design Elements for Casual Single-Player Games

The challenge for a single player game developer is to keep the player engaged and always wanting more. It is one thing to entertain the player enough to keep him or her interested in playing the free version. It is much harder to get the player so involved in the game that they are willing to pay to continue playing beyond the trial period or pay to upgrade to the “premium version”. Even then the job is not done. The premium version had better deliver a good value to the player or he will become an unhappy customer very quickly. To accomplish this, the game must have depth, measure and show progress, and keep the content seeming fresh for many hours of play.

[edit] Aspirational Fantasy

Aspirational Fantasy is a design element used as a recourse to immerse the player into the game. It's the environment around the gameplay that makes the player relate to the game. A very good example is the environment set in Aloha Solitaire, where the player sets sail to different islands and plays cards under a palm tree. The sound of a calm sea is listened while playing. This mood set in the game takes the player away from their daily routine, and helps the game to be a considered by the player as a "place" to forget about problems.

Aloha Solitaire

[edit] Optional depth

Optional depth, sometimes called Z-Axis of Gameplay or Secondary Strategy, is an element of gameplay which is not part of the core gameplay in the game, but it adds depth to the gameplay by having the player be able to choose different paths to the end goal, or make the user have more than one goal in the game (completion of a task and scoring as more poitns as possible). Here are some examples:

• In Diner Dash, matching customer colors with seats gives the user additional points. Since points are what the end goal in the game is, these bonus points help the player achieve the end goal quickly.
• In Feeding Frenzy, catching the bubbles give the player additional points (stars) or elements that enhance the player (thunder = speed bonus). The points in the game help the player achieve higher scores per level, but they don't help to achieve the end goal. The elements that enhance the player helps him or her achieve the end goal faster.

getting a bonus for matching colors of clients to seats in Diner Dash

[edit] Showing Progress

Most games have a very simple set or rules that define the core play mechanic. Included in that core play mechanic is the definition of a win scenario for the “level”. (or round, stage, day, session, match, board, puzzle or what have you) Beyond that, most games have some type of “meta game” that a player progress though each time a “level” is completed.

Having a clear way of tracking and displaying long term progress in the game can be crucial to keeping the player engaged and wanting more than just what is offered in the free trial version. Most games should have some kind of end game scenario or a way to “beat the game.” This should extend way beyond a single game session. Many games use the simple metaphor of “levels” where you may have to be 50 levels to finish the game. Other games track a character though an evolving career path or story. No matter how it is themed, it is important to show the player a long term goal, and then track though progress towards that goal visually. The simplest way to do this is with a “world map” similar to ones used in Cake Mania, and Feeding Frenzy. After each level, session, match, chapter, or round the player should see an updated world map to see how far they have come and how much is left to go to get to the next milestone or to the end goal. Progress should be carried over from one game session to the next rather than making the player restart from the beginning each session.

Some games succeed at tracking the player’s personal increase in skill on a high scores lists. These games may require to player to stat from the beginning each session and try to get a better score than last time. This is quickly becoming an outdated play mode that is rarely successful in modern casual games. It is usually batter to use check point or automatic save games to track a players progress along a map though many levels. Of course, these “levels” and “maps” can be completely re-themed and disguised as something entirely different. Big Kahuna Reef tracks and rewards progress by showing species of fish that have been discovered, Chuzzle makes extensive use of trophies to track progress, Majonh Towers Eternity tracks a player though a series of character class upgrades, and although Cake Mania has a word map, many players use their collection of equipment upgrades as the primary way to setting goals and tracking progress. In all these cases, it is not only important that the payer advances though a sequence. It is equally important that the way of displaying the progress makes it clear how far along the sequence the player has come and how far is left to go. And it is also good to have intermediate milestones along the way with additional rewards.

Cake Mania's Progress Map

[edit] Designing for Upsell of Premium Content

Game developers who create premium versions of content (played or accessed online) hope that customers will pay money for these titles. To persuade customers to pay money for titles, developers must offer a compelling play experience that customers feel is significantly richer than the free web game demo equivalents. Since players will frequently experience the game via an online version first, and then download and install the game on their PC, there must be significant motivation for a customer to proceed to the downloadable version. Customers are typically motivated by one or more of the following reasons:

[edit] Deepening Gameplay Over Time

During the trial period, the gameplay convinces the player that one will want to continue to play this game over and over. Developers want to ensure the customer isn’t questioning, “It was fun for an hour, but will it get any better if I purchase the full game or is it just going to be more of the same?”

[edit] Higher Quality Experience

Premium content offline play is usually full-screen and advertising-free, typically with enhanced graphics and sound.

[edit] Using the free trial version to close the deal and make a sale

With downloadable games, the ultimate goal is to convince the player to purchase the full game. Sometimes this can be accomplished solely with a web version, but usually a player will evaluate a free downloadable trial version of the game before making a purchase. The trial version must be carefully designed to motivate players to purchase. It‘s a difficult balancing act to make the free trial version compelling enough to motivate the customer to buy the game without giving away so much gameplay in the free trial that the player has had their fill.

[edit] Content Limiting

Many games will include the first X number of levels (or the first mission pack) in the free trial version and require a purchase to play additional levels. Typically a player can re-play these demo levels indefinitely. This is how demos of retail CD-ROMs games are usually designed. Some downloadable game developers also use this model for their games. Content limited is especially had to do well in some kind of games such as action games. These playable games make it difficult for the designer to decide how many levels to give away. Including too many levels in the trial version can leave little reason for the player to buy the full version since the trial is satisfying, but not including enough levels in the demo to give the player an experience of what makes the game fun, can damage purchase potential. It can be easier to make effective use of content limiting in a story driven game or any game where the player previous progress is carried over into the next level.

[edit] Feature Limiting

A common way to differentiate the trial version from the full version is to lock out some features in the trial version. The player must purchase the full version to unlock these special features, such as: Internet high score posting, level editors, expansion packs, or special content such as power-ups or alternate game play modes. By allowing the player full access to many levels, the player can fully appreciate what makes the game fun, but those few locked out features can motivate the player motivation to the purchase.

[edit] Time Limiting

Most large distributors prefer that all their games are limited to a specific amount of play time during the trial period. After 60 minutes of play, the game becomes unusable unless the player purchases the full version. This can be a very effective way to give the customer a full, featured trial play of the game. Players are allowed to experience every feature and play every level they can reach during the trial period. This gives the player a realistic sample of what the purchased game will be like and allows the game designers to show off his best levels to convince the player to buy, without worrying about giving those levels away permanently; the player will only be allowed to play the levels for a short amount of time.

The Digital Rights Management (DRM) systems and wrappers used most portals only allow for time limited demos. It is usually not possible to implement feature limiting or time limiting for the version of the game distributed though these channels because the same version of the game is used for the trial and the full version and it is not always possible to determine if the game is running in trial mode. Designers of downloadable games should take this into account in their game design and make sure the game is a good 60 minute experience. Some DRMs do provide an optional SDK with an API to communicate with the DRM so that it is possible to implement content and feature limits. But the 60 minute trial will always be the lowest common denominator for some of the largest casual games portals.

[edit] Key Design Elements for Casual Community Based Games

By definition – “Community” means “A group of people having common interests”. As for the Casual Games space, Community is an oft used term which is defined differently depending on who you are talking to. The term “Community” has come to include any or all of the following:

In-Game

• Allowing players to play against each other in the same game room – Multiplayer
• Allowing players to play a game (self paced) in a room with other people

Displaying a player’s score to everyone playing in the room

• Allowing user interaction during game play (full chat or canned messages)
• Announcements of player achievements during game play (amazing feats or events of extraordinary rarity).
  • This can be done via Chat or other system message area
• Tournaments or other incentive-based game play over a fixed period of time

External –(Post Game Community Features)

• Rooms which are set up according to geographic areas or special interests in order to put people in rooms with other people who have a common interest
• Recording of a users score to a Leaderboard or High Score Board
• A player ranking system – usually based on a complicated mathematical formula to determine a player’s skill vs. another’s. This is generally used to gauge skill for setting up head to head game play.
• Archiving and displaying Top Scores for different periods of time (Day, Week, Month, Lifetime, etc)
• Having a Hall of Fame system to recognize long term outstanding achievements
• A Message Board or Blogging area where players can chat about their favorite games
• A system in which a player can invite another player to compete with them
• Players can win Coins, Points, Tokens, Trophies, Talismans, Badges, Dots or some other kind of award during the course of game play
• Players are rewarded for spending extended periods of time playing games (Longevity award)

Most community based features are based on different ways of displaying (and recording) player related data. Such data as scores, time spent, achievements and other player based information can all be displayed on a web site. Game web sites will generally use a combination of the above features.

No matter what, what makes the community great is the people playing your game. You cannot CREATE a community, you can only foster the growth of a community willing to grow.

[edit] Head to head play

Competition is the key motivating factor for any head to head game. Most common are your 2 player “standards” such as Chess, Checkers, Backgammon and Billiards. Mahjong games have a renewed popularity in the casual game space these days, however you do not see many multiplayer versions online. Your multi-player parlor style games also appear like Hearts, Spades, Gin, 7/27 and any Texas Hold Em style game. Thanks to the rise in media attention these days, those sites who offer Hold ‘Em have seen an upturn in game play. And you have your multiplayer casual games such as Team Bingo, Slingo, any of the multiplayer games at Pogo, MSN, Yahoo! or Games.com. One thing you do not see too much of in the Casual Game space are Cooperative Play games in which players are required to work together to accomplish goals.

[edit] Leaderboards and Rankings

As part of any community based game, an efficient Ranking system is a must in order to keep players coming back. But don't think of it lightly, most common leaderboards (like a high-score table) or ladders don't scale well, and it actually could hurt your game if players are not able to see that they are progressing.

Sometimes the best approach is not to create a unified ranking, but give players a way of identifying who are the best players in the game. That way they can always find who to look up to.

[edit] Viral Marketing

Word of mouth is becoming increasingly a very effective marketing tool. Thanks to the Internet, it has become very efficient because all it takes is to paste a URL in an email or an instant messaging window. You can increase word of mouth in your game if you give players the tools and incentives to do it.

If your game has a virtual economy, you can give incentives to players if they get their friends to sign up. However, be very careful on the amount of the incentives as this can break up your economy flow. Also, have security measures in place so to prevent abuse.

Other effective tool is a feature to notify friends about achievements within the game, so to incentive competition. An example would be a feature that notifies all your friends that you beated their high-score.

[edit] User to User Communication

In order to build a strong community of players, users need to be able to communicate effectively. Most games stamp chat boxes on all parts of the lobby and inside the game. However, that may not be the most effective solution. Room lobbies have been proven to be a nightmare for community administrators, as they are usually flooded with hundreds of messages a minute when the room is full.

In-game chat is effective when the pace of the game let's player relax and be able to talk. Players don't really talk in real-time games, but the chat window among players of the same team is an effective way to coordinate strategies.

Buddy lists are extremely important in any community based game, since creating ties within users keeps making them come back.

[edit] Documentation

During the design process, there are various different documents the game designer and producer is going to need. The structure, the length, and the intended audience (who is going to read it) vary in each document.

Commonly, these documents are:

• Game Treatment: The Game Treatment is the document used to explain the core game mechanic and the project's goals. The intended audience is whoever is going to authorize the funding for the development of the game (i.e.: upper management, publisher). It's a relatively short document (around five pages), and its main objective is to "sell" the idea of the game.

• Game Design Document: The Game Design Document is the main reference that the entire development team is going to use during the development of the game. It's usually continuously updated as the project moves along.

• Project Timeline: The Project Timeline is the document used by the leader in the team to keep track of what has been done, what needs to be done, and who is responsible for it. We will talk more about it in the Production Issues section.

[edit] Structure of a Game Treatment

As the treatment is your sales pitch, it is the document that your potential publisher sees before they decide they want to keep discussing the idea with you or not. Focus on all the things the reader will have in mind while evaluating the idea:

• Is it a good game?
• Is it original?
• What's the game's target audience?
• Is it a good theme?
• Is the genre of the game overcrowded with titles at the moment, or is this game a good opportunity?
• Will it be fun to play after the first hour?

Here is an example of the structure of a treatment:

Your company Logo Name of the Game

• Introduction: Use this section to grab the reader's interest. Describe the game in one sentence, but don't try to tell it all in one paragraph. Example: "Flo lives a busy life as a stock broker, but she is tired of the corporate life. She wants to open her own restaurant and live a better life. Help Flo manage the restaurant and become successful!". With this paragraph, you are telling the publisher the theme (girl that hates working at an office, sets up her own business) and the type of game they are going to read about (system management game).
• How To Play: Use this section to dig in the details of the core gameplay. First include a mockup of the whole game screen. And then, step by step, with images depicting each particular action, describe how the game works.
• Additional Features: Give examples here on how you plan to extend the game. In the case of Diner Dash, different customers and number of tables per restaurant are two examples of the features you would describe in this section.
• Story and Theme: You can use this section to describe the theme of the game. Extend the idea of the theme you started to describe in the introduction. Include some character mockups. Give the reader an idea of the type of fantasy players will be exposed to.
• Timeline and Budget: Use this section to say how long is going to take you to build this game, and how much is going to cost (it's obvious why this section should be at the end of the document, isn't it?). Nobody expects you to be exact in your timeline, but everybody expects you to be as exact as possible on how much it's going to cost. Be realistic, asking for too little money doesn't make you serious, asking for too much either.

[edit] Structure of a Game Design Document

to be written.

[edit] Production Issues

The lower financial stakes of casual games make it possible to explore a variety of innovative and unusual topics and game mechanics. However, even a small game can go over budget and schedule without proper planning and management. Developers of casual games face numerous production constraints.

[edit] Process Differences

The differences between casual games as compared to consoles and other more traditional game platforms (e.g., GBA, PS2, and XBox) are the following:

[edit] Smaller teams

The smaller project size of casual games usually means smaller development teams in which each team member must wear multiple hats. The game designer or programmer may double as producer; the concept artist, lead artist, and art director may actually be the same person; and everyone on the team will put in time as a QA tester. As a result, management overhead may be reduced considerably and breakdowns in team communication can be less of a risk. However, projects may be more complicated to plan and budget when a single person is doing multiple tasks. While the smaller scope of Web and Downloadable game projects would seem to make the project management simpler, in reality this simplicity is offset by the fact that most developers of such games need to produce several games concurrently in order to meet their cash flow requirements.

[edit] Working with distributors to publish your content

Although the distributor/developer relationship in the casual space is often likened to the publisher/developer relationship in the traditional retail space, they are actually very different, since distributors in the casual space do not typically share the financial risk of development. The developer assumes all of the up-front risk, while the distributor is typically not involved until much later in the development cycle when the game is nearly complete. However, even at this stage, the distributor can provide invaluable feedback and beta-testing resources to help guide the final tuning and polishing of the game. For casual titles that are being self-funded by the developer, there is often no specific budget, but instead a more flexible number that evolves out of a compromise between the cash-flow reality and a sense of the product that is needed to compete in the marketplace.

Developers working on self-funded original titles may be able to enjoy a more organic, iterative process of creating games. When a publisher's financial oversight is replaced by the developer's, the development process can be more flexible, but developers need to be careful to take advantage of this flexibility rather than fall victim to it. Developers also need to be aware of the additional effort involved in working with distributors. Often, the distributor will require that their branding be incorporated into framing and peripheral elements of the game. For web games, developers may be required to integrate distributor features for server-based services such as chat, rewards/loyalty points, high scores, etc. For casual games, additional time will also be needed for wrapping the game within the distributor's DRM solution and possibly for producing promotional graphics and copy that can be used on the distributor's website. All of these things can add days to the end of the production cycle and should be planned for by the developer.

For casual games that are being developed to promote a particular consumer brand or product, budgets and timelines are usually immutable and therefore call for a more formalized management approach. Also, a significant portion of the development time is often consumed in incorporating the client's brand identity and getting approval for the brand's representation within the game.

[edit] Self-publishing

Whereas in the videogame space there is a clear cut between the publisher (i.e.: Activision), and the distributor (i.e.: Target), in the casual space the line is blurry. Online portals behave as the distributors and as the publishers in many cases, and this is a trend which will grow in the next couple of years. On the other hand, when there is not an exclusive distribution agreement with a portal, nothing stops a developer from publishing their game to their own web site. Attracting traffic is a big challenge. Please refer to the business model section of this paper for more information.

[edit] Working with Clients on a Work-for-Hire Basis

In many cases, developers tend to own their Intellectual Property (IP), whereas traditional game developers are often working for a larger publisher and/or with big licensed names on a work-for-hire basis where they do not retain rights to the IP they develop.

[edit] Working with a Publisher

There are good definitions out there on what a Video Game Publisher is, so we won't replicate them here. Having said that, it's worth mentioning that there are differences between traditional Game Publishers and Casual Game Publishers. One of the reasons is because most Casual Game Publishers have been formed by successful independent developers or by people who left the traditional Game Industry to work on Casual Games.

The financial conditions in a typical contract tend to be more benefitial with Casual Games Publishers than traditional ones. And as the volume of sales of Casual Games increase, Casual Games are going to be a more attractive proposition for the small game developer.

Projects are shorter and milestones are less, so developers move from project to project much more quickly. However, the risk of getting a project killed still exists, so small game developers should be careful not to have all their eggs in one basket and have more than one project at any one time.

With the Internet, there is always the question of the need of the Publisher role. But the truth is that for newcomers is becoming very difficult to get their games on the major portals, so only a few companies today have the infrastructure and the deals in place to get wide distribution. But most of these companies would work with a developer if they believe the game will be successful, and they will offer a developer a much better deal than what a publishing deal would look like. This type of deal is usually called "exclusive distribution deal", and some times include some type of advance. In this particular case then, the game developer needs to fund most of the development of the game, as the publisher typically will not sign a exclusive distribution deal if the game is not almost complete.

[edit] Project Constraints

[edit] Money

Games developed for the casual market are typically smaller in scope than retail PC and console games. Project timelines are much shorter and budgets are smaller. Whereas it is not uncommon for a PC or console title to have a development budget of $5-10 million (US), casual games are typically produced for approximately $50,000 to $150,000 USD. Today there are a number of publishers out there who will be willing to bear with the development costs in order to have exclusive distribution rights for a title. Smaller budgets mean smaller teams in which each member must possess a diverse skill set. The implications of this are discussed in more detail below under "Process Differences". With a original title there might be backend royalties based on the success of the title. Publisher-developer relationships might include recoupable costs before royalty payouts on advances determined by the contract. See the business model section of this whitepaper for more information.

Advergames typically have a fixed budget that is restrictive relative to the desired deliverable. The clients who outsource these games are looking to get as much out of their budget as possible and may not have a particularly deep understanding of what it takes to develop a game. Skill games usually take the form of lightweight Web playable games and have some additional constraints.

Here is an example of the production cost breakdown for an example game.

20-25% art

20-25% code

20-25% game design / narrative / script

15-20% production

10% sound

[edit] File Size

File size is an issue wherever digital distribution is concerned, and the mass-market audience targeted by successful games in this space is especially sensitive to large downloads. The most downloaded titles are typically less than 9 megabytes, and there is a sharper drop-off at 13 megabytes. This is particularly relevant to those publishers who are looking to extend the lifespan of titles in their back-catalog; titles that were originally designed for retail distribution are usually quite large in file size. The size constraints for web games are much smaller, with a 50-500KB initial download being the norm.

In breaking down the file sizes here are some example percentages of assets of a typical game that are visual, audio, code, etc.

60-70% art

15-25% audio

15-20% code

5-10% game design / narrative

[edit] Technology

While hardware support is a concern for anyone developing computer games, it is particularly important for the casual market, where players typically are not interested in buying special equipment to make games run better. Developers should assume that their games are being played on machines that are a few years old and that were probably not even state-of-the-art at the time of purchase. Sound and video cards are not as robust, processing speeds are slower, etc.

Since casual game budgets are not usually large enough to support the development of custom technology, many casual game developers use higher-level middleware such as Director, Flash, Torque, or the Popcap Framework to develop their games. With these environments, developers can produce both Web and Downloadable versions of their games from a single source. It should be noted that reliance on middleware does mean working within the limitations of the latest version of the software. These technologies are discussed in greater detail in the Technology section of this White Paper.

[edit] Working with Team Members in Multiple Locations

Many casual games development teams are composed of members in different locations. The producer's job becomes harder as he/she has to deal with making sure the project stays on track by calling or IMing people, keeping everybody in the loop with updates on the project, and sometimes keeping track of multiple timezones so to make sure that each member of the team has what they need at the begginning of their day.

It's not an easy job. Here are some recommendations of good practices.

[edit] Game Design Document

Since remote team members will not be able to listen to some of the game design discussions you'll have with team members in your office, you need to be serious about mantaining a Game Design Doc all the time. But one very common problem is to update Word docs and send it to the team. Did the artist used version 0.41 or version 0.50 when he designed the main character? Confusions will be common.

The best thing is to use a tool that will let you update the doc where it will be at a particular location, and refresh automatically on everybody's computer if they have it open. Some of those tools are Macromedia Contribute, Writely, and Office Live.

And lastly, you need to let everybody know of every change you made to the GDD. And put special emphasis (like giving them a call) with those who will be impacted by that change.

[edit] Project Timeline

A similar problem arises with Excel spreadsheets and Project Timelines. Sometimes people will not download the new timeline if it means that the days have not changed, only tasks have been resolved. But then you have people sitting waiting for somebody to deliver something.

Again, best thing to do is to use an online tool. Examples are Google Spreadsheets and Office Live. Create an spreadsheet and mantain it online. Talk to each member of the team and make sure they know when they have to deliver what. Give reading access to other stakeholders in the project (publisher, distributor, business guys), so they can always see what's going on with the project.

In addition to these, there are several online project management solutions where one can review tasks that need to be done, bugs that need to be fixed, and a way of distributing the work can be a good way to keep everyone up to date and track progress. Some various project managers that game companies use include DotProject, Jira, Trac, Bugzilla, Flyspray, PHPBugTracker, and Mantis.

And yes, even with this never forget to make sure that every member of the team has checked the timeline in the last few days.

[edit] Asset Management

This one is very simple: it's almost insane to work without a version control system (such as Subversion or CVS) if you have team members in remote locations. You'll incur into errors, problems, and work being done twice (such as programmers updating art, music, or level design scripts into the game every hour when they should be programming).

Set your project development tree so artists and musicians and level designers can try things inside the game without programmers having to do something. Get everybody to be very verbose on the description of their updates.

Distrubition of materials can also be helped with a central location for all materials. Besides using a control-version system for software, having another place to review art, design documents, audio, timelines etc. can be invaluable. There are several solutions to this including a private editable Wiki or FTP site where all the team members can change, modify and contribute in a collaborative way.

[edit] Communication

Communication costs can go through the roof if you are not careful. At the same time, not keeping track of time zones can add additional days (and cost) to your timeline. If one of your artists lives 8 time zones ahead of you, it's not useful if you write the specification he needs in the morning. By the time he'll get it it will be the end of his day.

When you organize dependencies into your project, think about timezones. You can even have a very effective team, one who could produce games faster than a team in the same location. Artists can be working on art while programmers are sleeping, and vice-versa.

IM is a very effective communication tool. Having said that, there are some things that are better discussed over the phone. If there is a misunderstanding or a disagreement about something, grab the phone, don't try to fix it on IM.

And lastly, there is nothing that replaces the face to face communication. Plan to visit your team members once or twice a year. Combine getting together at conferences with a yearly visit to their location. It will help build team membership.

[edit] Deadlines

The casual game market is less sensitive to seasonal purchasing patterns than the retail PC and video game industry. While this creates an opportunity to make the games highly polished before they are released, developers should be careful not to invest so much in the polish cycle that the games become unprofitable. Games that are created for a client, such as advergames, typically have a much more rigidly defined schedule, especially if they are tied to an external event, such as a movie launch or product rollout. Seasons and holidays have a small influence in overall sales and traffic. It is better to spread out releases over the year to secure launches with distributors and portals.

[edit] Publishing & Portal Needs

Each publisher or portal may have different needs. One way to quickly understand what a publisher or portal desires is by reviewing what content is heavily promoted on their web sites. If possible, the best way is to talk directly to the portal or games site management. You never know how many developers are making another clone, and by the time you submit your game to the publisher, he may have another 10 games that are very similar.

Try to always provide something new. Revolutionary ideas can be risky, but very rewarding. At the same time, small improvements to proven formulas tend to be very successful as seen by Sandlot's Cake Mania.

[edit] Builds and DRM Issues

Unfortunately, there is no standard in the way builds are submitted to publishers and portals. Most likely you will have to create 10 versions of your game for 10 distributors who will each have their own requirements. It's very important to abstract your calls and have separate functions for different DRM calls (see below on the DRM section). It's the same case with Publisher's and Portal's logos.

Some DRM requirements are:

• Wrapper friendly exes (no self modifying),
• Integrating DRM APIs,
• Making games patchable (regardless of multiple wrappers)

[edit] Community Management

This section is specifically for community based games.

Once people begin to congregate and because of the freedom / anonymity of the internet, your player’s actions need to be closely monitored to ensure that everyone is having a good time. There are several factors you can employ for sites that permit communication between players:

• Have a rock solid Terms of Service – If there are no rules pertaining to your community, then it is mob rule. The TOS for your site should be no different than a software EULA. It should specifically spell out what players are allowed to do, what they are not allowed to do, and what will happen to them if they break the rules.
• Monitor All Communications– Either record it in logs, or allow people an opportunity to report offensive chat. Since people spend most of their time in game rooms playing games, this is where most of the problems will happen. The most common issues are:
  • Vulgarity (Chat that is obscene or sexual in nature)
  • Room Harassment (Scrolling and being obnoxious)
  • Personal Harassment (Directing attention at a particular player)
  • Use Judicious Caution – Communities that get close will start to share very personal information with each other. For the most part, your staff will not be trained psychologists or have the expertise necessary to deal with serious issues. People with problems should be directed to their local authorities or other experts (suicide hotlines and other such organization’s information should be kept handy to pass to members as needed)
• Provide Adequate Support – Every different person has a different person and a different problem. Not all people will be able to fix a problem by reading an FAQ and surprisingly, many people are not computer literate enough to follow the directions. Issues you will experience range from web based issues, to complicated technical problems. Communities are going to require support and you need to be adequately prepared to deal with those issues or people will go elsewhere.
• Listen to your Community!!!!!! – Your community has developed because you have great games and have offered them an opportunity to express themselves. They are going to tell you what they like. They are going to tell you what they don’t like. Obviously, all suggestions cannot be taken seriously, but the feedback you get from a community is invaluable to making a product better. This is the only way your community will grow and stay healthy. ALWAYS have an Email address where people can reach a human being and get a response.

There are several different ways in which you can monitor your community, but the most common are:

• Automated Methods – Various scripts and jobs can be run to automate several community functions. This could include automatic Email support (or a solid FAQ section). This could include a series of server based jobs which monitor logs for illegal scores or offensive chat. None of these solutions, however, deal with the human element which most communities survive on.
• Employ Community Managers – Put people on the payroll, or subcontract to remote staffers who are responsible for facilitating chat, fostering a good environment by reminding people of the Terms of Service and actioning those people who break the TOS. These people need strong training and should be given explicit direction as to the level of power they should employ when dealing with the community. You do NOT want to lose players from a Community Manager on a power trip. They are there to facilitate the community, not police it.
• Utilize Community Volunteers – Sometimes there are people that spend so much time playing community games that you might as well give them something to do. There are many sites which use Volunteers for such mundane tasks message board moderation and chat patrol.

NOTE – Check your local laws to see if there are specific laws about using volunteers to work on your web site.

[edit] Summary

Clearly there is no shortage of constraints for the developer producing casual games. However, these constraints can also be viewed as potentially useful design parameters that can help focus the development team (and ultimately the player) on the essence of the game experience they are creating. The key lessons from this section can be summarized as follows:

• Know your customer
• Build the game at the customer's skill level….not your skill level
• Gameplay is king - make sure you have a solid game design
• Differentiation: How is your game better or different from what is in the marketplace?
• Consider building a game with a free web, downloadable and skill-based gaming component. Why leave money on the table but only focusing on one gaming version? Advergaming is probably the one area that is specific.

[edit] Risk Management

The keys to successful risk management are:

• Continuously identify what can go wrong (risks);
• Rank the risks at each stage;
• Create a plan how to handle the risks.

Risk management is a concern throughout every phase of a project. The following section gives an overview for each section and identifies possible hazards that are relatively common in the Web and Downloadable production process.

The best way to limit your risk is to have a thorough schedule and adhere to it. Concept, proto, alpha, test, beta, test, gold are stages that need to be managed. The main fears are: "Have I spent enough time on any one and/or did I spend too much on any one." Another risk is that at any time during the production process, you may just not be satisfied with the games and may want to stop production wasting time and money for nothing. Finally, you could even end up with a great game but it may not sell. A game not selling well in the marketplace is probably the biggest risk, but let's discuss some of the other possible risks with individual elements and questions that you should be asking yourself before (if ever) you get to that point.

[edit] Prototyping

You have a great idea but not sure what to do with it? When does prototyping end and play testing begin? Is this the kind of game that you think is cool or is it the kind of game that you think will sell?

[edit] Play Testing & Beta Testers

Play testing is just feedback. The most difficult part is interpreting the feedback. Knowing your audience versus knowing your beta testers is critical to judging their comments and making changes to the game. It is critical to gather feedback from one's target audience if designing a word or puzzle game. Conduct user surveys, invite players to your office to play your game and watch them as they play. Don't invite experienced players - but try to find the mainstream casual gamers who will be your primary target audience.

[edit] Production assets

Did you build that game with the ability to quickly integrate assets, swap and modify with limited risk and time? Waiting for art assets can be a time sink but should not stop the production process.

[edit] QA

Even before prototyping, you need to ask yourself: Who is the audience and what kind of machines are they using? Who or what is going to do your QA and what are their qualifications? Do they have the right tools to efficiently cover your needs?

• Testing guidelines such as how to conduct a usability study
• Types
  • Compatibility testing
  • Looking for bugs
  • Usability testing
  • Play balancing

[edit] Tracking Versions

Keeping track of which versions has which fixes/art/brands/upgrades might seem time consuming but at the end it will save you time, money and frustration. Various software solutions exist for this, including version control systems like CVS or Subversion and many bug tracking/job assignment solutions like Trac, Jira, Bugzilla etc.

[edit] Good Client Relations

Good communication with your clients will help you not only build a better game but also strengthen your relationship with the client. Your end goal is to ensure the client's expectations and goals are met.

Distribution partners can help you advise you as you create the game so it will appeal to the partner's audience, and being part of the process helps distributors be excited about your title so that when it's finally finished, they are ready (and motivated) to properly market and distribute it. The first time working with a distribution partner might be frustrating as one is learning their requirements but it should be an easier process with future games.

[edit] Technology Choice

Teams can sometimes go bad, and you have to move the project away to a new team. This is where the technology choice is so important; choosing a technology that only a few people know how to use limits you in the number of people who can continue with your project. At the same time, choosing a technology that requires development time to create basic elements common in popular frameworks will cause the loss of significant time. Check the Technology Section of the White Paper for more information.

[edit] Smaller Project Size, Smaller Teams

Obviously smaller project size can mean smaller teams. Does your team have all the skills that it needs to develop the game? Do you have the right artist or developer to do the job? Who will be driving the project if not you? Are you wearing too many hats as the designer/producer/lead developer/business development lead? When teams are small it is obvious that individuals will have to take responsibility for different roles. The question becomes can you manage continuity and capability of the team with the least amount of risk?

[edit] Funding

You have a great idea for a game but you need funding. What are you willing to give up for that funding? Are you willing to have someone supervise the entire project? Did you give up distribution rights? Did you retain control of the IP but lost the platforms? We all want to see projects become games, but there is a tradeoff between control and funding.

[edit] Localization

Localization covers a wide range of production tasks and contains several areas in which things can quickly get out of control. Localization pitfalls can be easier to rectify than technical pitfalls, since they generally do not need to be fixed by adding new game code. They can usually be avoided if the localization process has been thought out thoroughly and planned for accordingly.

[edit] Poor Planning

Poor planning is the number-one cause of difficulties during localizations. As discussed throughout this book, a number of items must be planned for and considered when developing localized versions. For example, localization-friendly code is not something that happens late in the project, it must be planned for in advance.

People often make the mistake of putting localizations on the back burner instead of working on them throughout the production process. Localizations should be an integral part of the production planning because there are many external and internal resources to coordinate. Items such as translations, foreign voice recordings, and linguistic testing all need to be planned ahead of time. These things can't be planned until the developer knows the scope of the localization, which includes what the code can handle, how the assets are organized, and how many assets there are to localize.

[edit] Linguistic and Functionality Testing

Linguistic and functionality testing are time-consuming tasks, and developers have a tendency to underestimate the testing schedule. If the developer has no experience developing localized versions, testing may be thought of as something that can happen on short notice and not take a long time.

Even if the localized versions are using the same code base as the English version, linguistic testing is time consuming. In addition, checking French, German, Spanish, and Italian language assets with four different sets of testers requires a lot of time just to coordinate the bug-fixing process. If the developer is in charge of fixing the linguistic bugs, a lot of time is spent looking over bug reports for all these languages and making fixes.

A general rule of thumb is that it takes a linguistic tester about three to five days to do a first pass on the game, and it takes the developer one day per language to make the fixes. Add in time for making a new build and getting it back to the testers, and the schedule extends quickly.

[edit] Quality of Translations

The quality of translations is something the developer has no direct control over, but is a problem for localized products in general. If the translator does not thoroughly understand the main concept of the game, appropriate translations will often not be provided. For example, if the game features a character that uses a lot of goofy puns or sarcastic one-liners and the translator does not understand these jokes, the phrases and jokes will likely be translated incorrectly. Therefore, instead of having a goofy character in the French and German versions, the character may appear to talk nonsensically.

Voiceover acting can also contribute to poor quality localizations. If the voice actors and director for the localized voiceover do not understand the context and delivery of the lines, the localized voiceover may not match the game's context. For example, if the characters in the game are human and interact in a realistic environment, the voice acting should match this style. If the voice actors for the localized versions deliver their lines in a cartoon-like, over-the-top fashion, the localized versions will appear less realistic.

Due to cost, travel, or scheduling issues, it is unlikely that the developer will be able to send someone to direct the localized voiceover sessions. However, it is something to consider, especially for high-profile titles. It will be difficult for a non-native speaker to direct voice actors, but if onsite, the developer can assist in the session and provide some context and direction for the lines in general. If possible, the developer should talk with the directors of the localized VO sessions to explain the game and provide examples of how the lines should be delivered.

The developer must provide resources for directing the actors in the localized voiceover sessions. By sending a build of the game to the voice director, the actors can see how their voiceovers will be used in the final product. The final English voiceover files are also helpful because the actors can hear how the line is delivered in English and adapt their line delivery accordingly. The developer can also include context and voiceover direction for each line in the script. Any other resources, such as detailed character notes, pictures of the character, or sample line readings in the appropriate language will also help the performance of the voice actors.

[edit] File-Naming Conventions

File-naming conventions themselves are not a pitfall; it is the lack of a file-naming convention that can cause problems. Because localized versions require the involvement of so many external people, things can quickly get confusing if there is no standard way of referring to the assets. If the filenames are consistent throughout the project, the developer and translator will better understand what information has been sent.

A file-naming convention for the language assets is also important. If the asset names provide some information about what information is contained in the assets, the developer will have an easier time organizing and tracking what is sent to the translator. For example, a text file named "Game Text" does not provide any information about which part of the game the text is from. If this file is the only text file from the game that needs translated, then this is not a problem. However, if several text files need to be organized for translation, and they are named "Game Text 1," "Game Text 2," "Game Text 3," and so on, it will be difficult to provide specific context on what the file contains. A good filename is more descriptive, such as using "Mission 01," "UI Text," "Help Text," or the name of the character. Of course, the developer can always open the file to check the contents, but this can get time consuming if there are many of them.

Informative filenames are especially important for voiceover files. Some games contain hundreds of voiceover files, some contain thousands. If they are named in a consistent manner, the developer can tell what the file contains just by looking at the name and will not have to open every file to check the contents.

[edit] Design Pitfalls

Game design pitfalls are harder to define because game design is subjective. What one person decides is fun to play may be boring to another. However, developers should still take into consideration other cultures and languages in order to design games that appeal to a global audience. Developers do not want people who buy the localized versions to feel short-changed by a game that is very Euro- or U.S.-centric if this is something that can be avoided. However, a global game is heavily dependent on the game's context. As an example, True Crime: Streets of L.A. is obviously a U.S.-centric game based in Los Angeles. Changing the setting for a global audience would take away the game's flavor and context.

[edit] Cultural

Cultural issues are best identified by having the game design elements reviewed by people from other countries. If the developer works for an international publisher, the company will have access to people in international locations who can provide some basic feedback on how suitable game design and features will be for gamers in their country. They will provide information on cultural taboos, such as language or actions that are considered offensive. They will also know if the game will appeal as a whole to their country and culture. If international resources are not readily available to a developer, feedback can be solicited from international people available locally, such as at college campuses.

[edit] Content

Actual game content can also create some issues for localized versions. In some cases, the content is not offensive; it is just not the best choice for the localized versions. For example, Shanghai: Second Dynasty is a tile-matching game that contains a set of tiles called "Spelling" in the English versions. The basic premise for this tile set was for players to match pictures of objects with written words, thus the name "Spelling." The artwork for the tiles had the text and pictures embedded into the .bmp files.

This tile set caused some concern when the game was localized into German and Japanese. Both countries wanted the tile set localized into their language and were distressed that a tile set of this nature had been included in the game without a plan for the localized versions. Due to the production schedule, there was no time to design a set of words and pictures for the German and Japanese versions, or to completely redo the tile artwork for each language. Completely removing the tile set was briefly considered, but was rejected because it meant altering the game code and putting the release schedule at risk. In the end, each country decided to just rename the tile set to "English." This was an appropriate compromise since English is something taught to children in Germany and Japan.

Developers must be aware of potential content issues sooner rather than later so they can be fixed before the game assets are in full production. The best way to do this is to gather international input early in the pre-production process and solicit this input through the game's production.

[edit] Conclusion

Developers of casual games face a unique set of production constraints, most of which grow out of financial and technical limitations. However, these constraints can be embraced by the optimistic developer and used to guide a more focused development process. This focus is also the first step towards managing the risks associated with game development for this market. Though the budgets are small compared to console and PC games, the risks are still significant for the small developer and require continual vigilance and creative management solutions.

Game design for the casual market demands a great sensitivity towards the less-experienced user and a tremendous respect for the player's time. The casual game audience's level of patience and tolerance toward learning a new game is very low. However, while their level of initial commitment may be low, casual players also have few preconceptions about gaming genres and conventions. There is still plenty of room for innovative core game mechanics that build on these players' experience. Choice of thematic content is critical and has the promise to hold player's attention while they are gently introduced to new game mechanics. Ultimately, players' equity in the game experience should be the goal for any developer and at some level, all of the production and design considerations discussed above feed into that goal.

Form last year, we haven't seen a lot of progress in the community based space as we hoped, or different business models than the try and buy or the advertising sponsored. The try and buy model limits game designers (as most of the production budget is spent in the first hour or gameplay) and there is not a clear ROI on advertising funded games (budgets are low, technology to create a web game is limited, and there is not a big incentive from the portal to the developer as they don't share advertising revenue). Micro-transactions are growing, and we are glad that some games are taking advantage of it in the western world. Still, there is the need and opportunity out there for a back-end company to provide a multi-player and billing hosting solution for the development community.

We have seen that the taste of the casual gamer has evolved and is embracing more complex games. Still, we believe that the core of casual game design will be simplicity, so a good balance must always be achieved.