Developing mobile games, short-term lectures for college students, 6 of 6

1. Developing Creative Mobile
Games
6of 6
Christina Hsu
Game Apps Design

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

3. Mobile Game Design, Basic

4. Designing Mobile Games

5. 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.

6. 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?

7. 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.

8. 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)

9. 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.

10. 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?

11. 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)

12. 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

13. 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

14. 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.

15. 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

16. 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

17. 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

18. 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

19. Designing for Community II
 Friend Finding
 Buddy lists
 Phone number/User ID query
 SMS challenges
 Diplomacy
 Web presence

20. The Metagame
 Richard Garfield & Magic: The Gathering
 Anything surrounding the game that increases player interest
 Tournaments/seasons
 Trading
 Offline activities
 Stable strategies

21. 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.

22. Designing Virtual Currency

45. Designing Virtual
Markets

80. Thank You! Any Question?