Date post: | 08-Jan-2017 |
Category: |
Design |
Upload: | christina-hsu |
View: | 41 times |
Download: | 2 times |
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?