20131105 concepts of game design
Download as PPT, PDF0 likes267 views
This document summarizes a presentation on designing creative mobile games. It discusses defining player actions or "verbs", incorporating different types of challenges, considering categories of player pleasure, and designing for constraints like screen size and processing power. It also covers multiplayer game design, dealing with latency issues, designing for community features, and incorporating a "metagame" to increase player interest. The presentation emphasizes that there is no single methodology for game design and that considering what players do and what pleasures and constraints exist provides a good starting point.
20131105 concepts of game design
- 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
- 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.
- 80. Thank You! Any Question?