Designprocesser lecture1
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Designprocesser lecture1

on

  • 257 views

- Course description and assignments (slides 3-10) ...

- Course description and assignments (slides 3-10)
- Game system design
-- Game elements (slides 12-29)
-- Hints for design (slides 30-32)
- References + reading list (slides 33-34)

Statistics

Views

Total Views
257
Views on SlideShare
257
Embed Views
0

Actions

Likes
0
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Designprocesser lecture1 Presentation Transcript

  • 1. Design processer för spel Introduction to the coursePetri Lankoski
  • 2. Table of Contents 1. Course description and assignments (slides 3- 10) 2. Game system design  Game elements (slides 12-29)  Hints for design (slides 30-32)  References + reading list (slides 33-34)Petri Lankoski
  • 3. Learning Goals  Identify and describe the design theories and design techniques from game science, human-computer interaction and interaction design  Describe and use various creative methods to generate game ideas, choose ideas and develop them  Describe game ideas in different ways, both verbally and non-verbally, and effectively communicate and market the game concept in different contexts and for different audiences, such as for their team and for funders  Iterate design using prototyping  Describe the basic connection between the games design and mechanics, and the players motivation  Evaluate their own and others design work and relate to it in relation to the artifact itself, gameplay and the game in relation to society.Petri Lankoski
  • 4. Course Content  Design theory and practice (All)  Game system design (All)  Narrative design & design processes for narrative design (First: all; the second and third: Designers & Artists)  Object-Oriented Analysis & Design (programmers)  Partly Problem Based Learning  You are not given all answers, but problems  To solve the problems requires learning in those areas  Development diary  You should provide evidence of your leaning to me!Petri Lankoski
  • 5. Course content…  Narrative design assignment 1 & 2 (artist, designers) (G)  Object-Oriented Analysis & Design assignment (programmers) (G) You continue with this  3 Design iterations (G) project at  Playable game prototype demonstrating core the Level mechanics, visual style, and storytelling (G,VG) Design course if your  Development diary (G,VG) project is ready  Being present at sprint reviews and retrospectives enough (G)Petri Lankoski
  • 6. OOD & A  Programmers  Read Read McLaughlin, Police & West, Head first object-oriented analysis & design, pp. 1–144 & 577.  By Thu, April 28, 10 o’clock  You should be able to describe the concepts:  Class diagram  Requirement  Scenario  You should be able to describe why OOD&APetri Lankoski
  • 7. Narrative Design  Assignments will be introduced at Narrative Design lecturesPetri Lankoski
  • 8. Design Iterations & Prototype  Mon, Mar 11 – Tue, Mar 12  Wed, Mar 13 – Thu, Mar 14  Core mechanic:  Core mechanic:  Collection  Exploration  Chance(luck) element  territorial acquisition  Visual style: Line art (black and  Visual style: Monochrome white)  Fri, Mar 15 – Mon, Mar 18  Tue, Mar 19 – Mon, Mar 25  Final design:  Core mechanic:  Choose one design (design 1–  Racing 3) and create playable digital  Puzzle prototype of the game that demonstrate the core mechanics, visual style, and  Visual style: 6 colours (select) story-telling approach.Petri Lankoski
  • 9. Note on Level Design  You continue with this game in Level Design course  If the design is ready enough  Ready enough means  I can playtest the core mechanics by playing your prototype  Your prototype demonstrates look and feel  I understand your storytelling approach by playing your prototype  The storytelling is implementable within Level Design coursePetri Lankoski
  • 10. Development diary  An entry per day during the project  These questions are to help  What where you working on? you to write an entry  What was the goal of the work?  No need to answer all the  What theories or methods did questions each day, but to you use? write on entry based on the  Did you reach your design goals relevant ones  Did you make compromises  You might have learnt (due technical or limited something at one day resources)?  You might have solved a  What problems did you have? problem at another day  How did you solve the problems?  Should show evidence that  What did you learn? you have gain understanding  Is there something else worth to in areas defined by learning mention? goalsPetri Lankoski
  • 11. Game System DesignPetri Lankoski
  • 12. What Games are? Chess Table-top RPGs September 12 Eve Online Poker War Hammer 40 000 Sims Graveyard Doom World of Warcraft Sim City Space Invaders Flower Cow Clicker Heavy RainPetri Lankoski
  • 13. What Games Are?  There are prototypical games  Tetris, Chess, Space Invaders,…  Understanding what make these things tick help you to understand game design  BUT going out from the box might produce something very interesting  Sim City, Little people, Sims  Graveyard, Every day the same dream  However, if a game is too novel, players do not get itPetri Lankoski
  • 14. What games are about  Meaningful decisions In other words  Twitch skill  That the players’ actions and choices have an  Puzzle solving impact  Challenges  In the game  To the players’ emotions  Learning to play  Mastering the gamePetri Lankoski
  • 15. What is game design?  Creating rules or game systems  Creating goals for players that  Creating content  Not always purely game design  But content and game design are always linkedPetri Lankoski
  • 16. Why Theories? What are your building blocks? How the building blocks relate to each other? What are the consequences of your design?Petri Lankoski
  • 17. Game Autopsy  Components  Game environment  Actions  What a player(s) can do  Verbs  Mechanics  Goals  Game State  Game ViewPetri Lankoski
  • 18. Components  Components are something that can manipulate or owned  Components-of-self Components-of-other  Components-of-system  Components-of-other  Components in Chess  Components-of-self  Pieces that I move  Components-of-other  Pieces that the other player moves  Components-of-system  Does not have Components-of-selfPetri Lankoski Chessboard: Klin, ILA-BOY, Beao, en.wikipedia.org/wiki/File:Chess_board_blank.svg
  • 19. Game Environment  Area where the game take place  Area can be  Field as in Soccer, Ice Hockey, Basket ball  Game board as in Chess, Backgammon  Screen as in Space Invaders,  Game world as in Elder Scrolls  Designed or randomly generated,  But no clearly defined environment  Shadow Cities  GeocachingPetri Lankoski
  • 20. Actions  What players do when they play game  Actions can be expressed as verbs  Shoot, hide, sneak, drivePetri Lankoski
  • 21. Game State  All information that can change during the gameplay and that is needed to construct a situation in a specific moment  Consists of  All components, their positions, values  Whos turn it is (in turn-based multiplayer)  Possible previous game states when the previous states influence the current statePetri Lankoski
  • 22. Game State examples  Poker  Cards in hands  Discarded cards  Bot  Who’s turn it is  What is the stage in the game  Tetris  The position and rotation of falling blog  Blogs on the ground  Score  LevelPetri Lankoski Poker: image by Todd Klassy, en.wikipedia.org/wiki/File:Holdem.jpg
  • 23. Game View  What kind of view a player have to the game state  Perfect Information  The game state is fully visible to a player of to all players  E.g., Chess  Imperfect Information  The game state is partly hidden  E.g., PokerPetri Lankoski
  • 24. Mechanics  game system, algorithms or rules,  The core of game  Mechanics defines how game behavesPetri Lankoski
  • 25. Goals  What is the goal of playing  What is needed to win the game  Victory conditions / conditions for loosing game  Important for motivating playPetri Lankoski
  • 26. Dynamics  Patterns that happens when the game system is motion, in use  Approximately the same as Gameplay  Same dynamics in (among other dynamics)  Bridge  Trump  Spades  Core mechanics is trick-taking  Same core mechanics -> similar dynamics  But dynamics depends on implementation and other mechanics in the gamePetri Lankoski
  • 27. Core Mechanics  Territorial acquisition  Chase or evade  Prediction  Trading  Spatial reasoning  Racing  Survival  Destruction  Not exhaustive list  Building / Resource  These are commonly used management  Very useful  CollectionPetri Lankoski
  • 28. Core Mechanics  Tetris  Spatial reasoning  Settlers of Catan, Carcassonne  Building/Resource management + TradingPetri Lankoski
  • 29. Theme  A game can have a theme  Visual theme vs narrative theme  Example  Ico is a game about a boy who get captured because he is different to others and he needs to escape  Not all games have a theme  Poker  TetrisPetri Lankoski
  • 30. Where to Start?  What this game is about?  How do I play?  Verbs  How do I complete the game/How do I win?  Goals  What challenges I face?  Obstacles, enemies  What are the things I need to do to reach the goals?  Why I do want to play?Petri Lankoski
  • 31. Work with the Limitations  Game design is about working with limitations  Limitations are not negative thing  Limitations force you to be creative!  Set limitations for the design  Our game should contain  A core mechanics, a design pattern, etc.  E.g., territorial acquisition, ROLE-REVERSAL, one-button control  Our game should not contain  Limit away the most obvious direction  E.g., No shooting  The style of the game is  E.g., Dali-like, cute animals, pop art, wild west + magicPetri Lankoski
  • 32. Some Tricks to Overcome Designers Block  Kill a rule, remove a feature  Limit or unlimit a resource  Take one random design patterns from Björk & Holopainen and add that to the game  Change a value in the game system or in rules  Multiply or dive by two  Change the visual theme or narrative theme  Try something very different to the current one Test the design after a change to get a fresh perspectivePetri Lankoski
  • 33. References  Brathwaite & Schreiber, 2008, Challenges for game designers. Charles River Media, chapters 1-2  Järvinen, 2008, Games without frontiers, Tampere University Press, chapter 4.Petri Lankoski
  • 34. Reading for the Project  Brathwaite & Schreiber:  Schell: The art of game design  Change/luck: pp., 69–74  Change/luck, pp., 153–169  Puzzle: pp., 40–50  Puzzle: pp., 208–219  Exploration as puzzle: p.,  Carson: Environmental Storytelling 47  http://www.gamasutra.com/view/  Strategy: pp., 83–91 feature/3186/environmental_storyt  Territorial acquisition elling_.php  Twitch skill: pp. 99–102  http://www.gamasutra.com/view/  Racing feature/131593/environmental_sto rytelling_part_.phpPetri Lankoski