Developing Creative Mobile Games

6of 6Christina Hsu

Game Apps Design

Agenda Mobile Game Design Basic Designing Virtual Currency Designing Virtual Markets Q&A

Mobile Game Design, Basic

                                          

                                    

Designing Mobile Games

Speaker Introduction Name: Greg Costikyan Organization: NRC/Game House Location: New York How am I involved in (mobile) gaming: 3 decades

as a game designer (30+ titles published), co-founder of one of US’s first mobile game developers, used to edit game section of Forum Nokia website, now work as a games resarcher for NRC.

What Does the Player Do? Game design is not about story or character. Game Design is about action.

Not necessarily fast action, but the player takes actions to affect the game state.

What does the player do? Media assets are the “nouns” of the game—allowable actions

are the “verbs” UI allows you to trigger the verbs. Each verb mapped to a UI feature. In a mobile game, ideally 1 key = 1 verb

Possibly to net menus, etc., but preferable to keep actions mapped to individual key presses

Write down your list of verbs. Possible to build a good game with limited verbs: Doom has only

8 (left, right, ahead, back, jump, shoot, switch weapons, pick up) Can you see how your list could produce an interesting game?

Verbs Will a single key-press suffice?

E.g., two used in golf games (direction and power). Avoid multiple simultaneous key-presses when possible, as

many J2ME implementations don’t permit this. If feasible, avoid mapping multiple actions to a single key,

or different keys to the same action, to avoid player confusion.

A single key to mean “act” or “select” can work, IF the meaning is always clear in context.

Game design has two main components: UI specification and gameplay algorithm specifications. The two must dovetail neatly, and it is worth thinking about clean UI design from the start.

Struggle & Challenge A game should be a struggle.

If too easy, it is boring. If too hard, it is frustrating. Have to find a happy medium.

Players enjoy overcoming challenges. Difficulty settings help.

Dynamic difficulty adjustment can be used, but carefully. Three basic kinds of challenges:

Physical Mental Opponents (AI or players)

Types of Challenges Physical: Depends on timing and mastery of the interface. Mental:

Resource trade-offs Tricky placement of game objects Interacting systems whose behavior is hard to solve Combining game objects Even if your game is not puzzle-based, think about how to use the verbs of

the game to produce interesting puzzles Opponents

For multiplayer, this is provided by the other players In single-player, this is provided by AI. Even simple AI can make opposition more interesting to the player

Example: Space Invaders After defining verbs, defining the sorts of challenges your players will

face comes next.

Categories of Pleasure Marc LeBlanc’s taxonomy of game aesthetics

Always useful to think about what aesthetic pleasures players will draw from the game

Sensation: Graphics, sounds, tactile feeling, etc. Fantasy: Consistent and appealing background/world/story.

Can be simple: “An Italian plumber must rescue his girlfriend from a giant ape.”

Narrative: Not necessarily “story,” but narrative arc: Sense of heightening tension and release.

Challenge. Fellowship: Important particularly for multiplayer, but even with

soloplay games, players enjoy talking about their experiences. Discovery: Exploration, new things (with each level?) “Masochism:” Submitting yourself to the structure of the game. Does your design provide each/some of these?

Constraints Constraints do not limit creativity; they spur it.

The sonnet. Application size. Application memory space

When running, application consumes more than the app size itself—graphic buffers, objects created at runtime, etc.

Screen size & format: Characters should be ~10-15% of height and width of screen If a “HUD” is used, it must be simple—ideally <6 pieces of

information. Portrait rather than landscape format.

Processing power (complicated simulations a problem)

Constraints II Mobile Device UI

Can generally rely an ITU-T keypad, two soft keys, D-pad No pointing device Variable keypads

The social space of mobile devices Handle interruptions gracefully Go easy on the sound (and gameplay MUST NOT depend

on it) Keep the backlight on High color contrast for readability in direct sunlight

How Multiplayer Games Differ Players provide the challenge

Provide ways to help and hinder each other Handle player drops gracefully

“Civil Disorder” AI take-over Replacement player Or design so that the loss of a player is unimportant

Player Matching “Quick game.” Challenges “Reserving” a game for friends (buddy lists?) Use of rankings to match players of equivalent skill

Short play sessions Ideally <=15 minutes

Multiplayer Differences Replayability vital. “Balance” no longer = right difficulty level

Instead = all players have equal chance of winning However, asymmetric games can be balanced Diplomatic games are self-balancing

Physical: Depends on timing and mastery of the interface.

Game and Network Issues Server-driven games

Ongoing cost for game provider Secure data storage Makes cheating harder Bandwidth-to-user not normally a constraint

Peer-to-peer Cheaper for game provider Cheating easier With large numbers of players, bandwidth becomes a bottleneck

Particularly for Bluetooth, which is always hub-spoke configuration Not feasible with legacy phones (requires IP address, SIP, or

Bluetooth) Player matching/discovery becomes a problem

Dealing with Latency Always a problem with networks

On wired Internet, 100-200ms latency rules out street fighters

On 2G networks, ~1 second latency If HTTP must be used, ~5 second latency NRC tests show that UTMS can produce >100ms latency

---But in lab, actual network deployments may be slower..

And generically, “3G” doesn’t solve all problems—EV-DO in deployment ~500ms latency

In general, unless targetting UTMS, must always work around latency issues

Dealing with Latency II Approaches:

Turn-Based games (round robin or simultaneous movement)

Act-whenever Slow update games Shared solitaire games Mask latency with game fantasy Untie game outcomes from specific play

configuration

Designing for Community Shared high-scores, tournaments, etc.

But many pitfalls: Avoid incentives for player drops Don’t encourage newbie-bashing No “perfect” scores Permanent high scores can be a deterrent

Chat Keypad text entry a problem—taunts? SMS for persistent/long term games Pathway to Glory use of VoIP

Designing for Community II Friend Finding

Buddy lists Phone number/User ID query SMS challenges

Diplomacy Web presence

The Metagame Richard Garfield & Magic: The Gathering Anything surrounding the game that increases player

interest Tournaments/seasons Trading Offline activities Stable strategies

No Single Methodology Tried to provide a coherent framework here This is an art, not an engineering discipline Kipling: “There are four and twenty ways/of writing

tribal lays/And every single one of them is right.” But in general, if you think about “what the player

does,” what pleasures players draw from the game, and what techical and business constraints apply, you’ll start from a solid base.

Designing Virtual Currency

Designing Virtual Markets

Thank You! Any Question?