CSCE 552 Spring 2010 Game Design II By Jijun Tang.

Slides:



Advertisements
Similar presentations
Chapter 5 Development and Evolution of User Interface
Advertisements

10 Software Engineering Foundations of Computer Science ã Cengage Learning.
Ch 3 System Development Environment
CSCE 590E Spring 2007 Game Design II By Jijun Tang.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development.
Alternate Software Development Methodologies
CSCU 411 Software Engineering Chapter 2 Introduction to Software Engineering Management.
CSCE 590E Spring 2007 Game Design II By Jijun Tang.
Chapter 15 Design, Coding, and Testing. Copyright © 2005 Pearson Addison-Wesley. All rights reserved Design Document The next step in the Software.
Chapter 2.2 Game Design. 2 Overview Game design as… full-time occupation is historically new field of practical study – even newer.
Chapter 3.1 Teams and Processes Being a programmer.
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
Chapter 3.1 Teams and Processes. 2 Programming Teams In the 1980s programmers developed the whole game (and did the art and sounds too!) Now programmers.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Valve’s Design Process for Creating Half-Life 2  Presented by David Speyrer and Brian Jacobson.
EE694v-Verification-Lect5-1- Lecture 5 - Verification Tools Automation improves the efficiency and reliability of the verification process Some tools,
COMP 350: Object Oriented Analysis and Design Lecture 2
A Technical Game Project 4 Due dates: Game Idea Friday, March 16 th Game Plan Friday, March 23 rd Web Page Sunday, April 9 th First Playable Wednesday,
CSC230 Software Design (Engineering)
Configuration Management
Gearbox Software PRODUCTION PIPELINE – JOBS TITLES – JOB DESCRIPTIONS.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Extreme Programming.
Introduction to Interactive Media 02. The Interactive Media Development Process.
S/W Project Management
Chapter 2.2 Game Design Part 2. 2 Game Theory Decision under certainty Players know the outcome of any decision Risky decisions Probabilities of nature.
Chapter 3 – Agile Software Development 1Chapter 3 Agile software development.
1 Shawlands Academy Higher Computing Software Development Unit.
Managing the development and purchase of information systems (Part 1)
Principles of User Centred Design Howell Istance.
Software Project Planning CS470. What is Planning? Phases of a project can be mostly predicted Planning is the process of estimating the time and resources.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
MULTIMEDIA DEVELOPMENT
Project Workflow. How do you do it? -Discussion-
Introduction to Interactive Media The Interactive Media Development Process.
1 The Software Development Process  Systems analysis  Systems design  Implementation  Testing  Documentation  Evaluation  Maintenance.
Extreme/Agile Programming Prabhaker Mateti. ACK These slides are collected from many authors along with a few of mine. Many thanks to all these authors.
Software Engineering EKT 420 MOHAMED ELSHAIKH KKF 8A – room 4.
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
Rapid software development 1. Topics covered Agile methods Extreme programming Rapid application development Software prototyping 2.
SE: CHAPTER 7 Writing The Program
Computer Game Development By Jijun Tang. Contents for the Presentation Group members, group name, logo Description, specification, goals, game play System.
Chapter 2.2 Game Design. CS Overview This introduction covers: –Terms –Concepts –Approach All from a workaday viewpoint.
I Power Higher Computing Software Development The Software Development Process.
CS 111 – Nov. 22 Chapter 7 Software engineering Systems analysis Commitment –Please read Section 7.4 (only pp ), Sections –Homework #2.
Chapter 3.1 Teams and Processes. CS Programming Teams In the 1980s programmers developed the whole game (and did the art and sounds too!) Now programmers.
Chapter 2.1 Game Design. 2 Overview Folk games [Costikyan] “Traditional” games, cultural origins Examples: Tic-Tac-Toe (Naughts and Crosses) Chess Go.
The Software Development Process
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Systems Development Life Cycle
Lecture 4 – XP and Agile 17/9/15. Plan-driven and agile development Plan-driven development A plan-driven approach to software engineering is based around.
Connecting with Computer Science2 Objectives Learn how software engineering is used to create applications Learn some of the different software engineering.
SOFTWARE ENGINEERING. Objectives Have a basic understanding of the origins of Software development, in particular the problems faced in the Software Crisis.
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Software Quality Assurance and Testing Fazal Rehman Shamil.
Oman College of Management and Technology Course – MM Topic 7 Production and Distribution of Multimedia Titles CS/MIS Department.
1 The Software Development Process ► Systems analysis ► Systems design ► Implementation ► Testing ► Documentation ► Evaluation ► Maintenance.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
1 Multimedia Development Team. 2 To discuss phases of MM production team members Multimedia I.
Software Design and Development Development Methodoligies Computing Science.
CSCE 552 Spring 2009 Game Design II By Jijun Tang.
Sound Practices of Games Business and Design Presented by Brian Jacobson.
4 Chapter 4: Beginning the Analysis: Investigating System Requirements Systems Analysis and Design in a Changing World, 3 rd Edition.
Large-Scale Design Process
Design and Programming
Gathering Systems Requirements
Extreme Programming.
Gathering Systems Requirements
Presentation transcript:

CSCE 552 Spring 2010 Game Design II By Jijun Tang

Announcements Send me group names and logos XNA demo/learning on Feb 1 st, in 1D11  Please go to to register and download XNA Game Studiohttp://creators.xna.com  Install Game Studio and VC# Express on your laptop  Please bring your laptop to the class Presentation on Feb 3 rd  In 1D11  Each group 10 minutes to present, 3 minutes to answer question

Game Design Presentation Expecting formal presentations with powerpoint files, pictures, musics, etc 10 points total for this presentation Grade will be group based, you can have the whole group or part of the group to present Grade will be based on scores from me and from the class

Contents for the Presentation Group members, group name, logo Description, specification, goals, game play System requirement, audience, rating Interface, input/output, interactions, cameras Premise/limitations/choices/resources Content designs/3D/2D/animation, audio Level designs, flexibility/scripting language? Actor/Verb/Noun/Use case/UML (rough) Engines (graphics, game, sound, physics) to use Version control/testing strategy/documentation Brief timeline (demo date is early May)

Models A model of the player – game Seven Stages of Action

Resources/Economies Resources  Things used by agents to reach goals  To be meaningful, they must be … Useful – provide some value Limited – in total or rate of supply Economies  Systems of supply, distribution, consumption  Questions regarding game economies: What resources exist? How and when will resources be used? How and when will resources be supplied? What are their limits?

Interface Typical perspectives:  First-person  Over-the-shoulder (OTS)  Overhead (top-down)  Side  Isometric

First person

OTS

Overhead and Side

Isometric

HCI Human-Computer Interaction Goal: improve the interaction between users and computers by making  computers more user-friendly  More receptive to the user's needs. It is the study of …  Communication between users and computers  How people design, build, and use interfaces  Better support for cooperative work

HCI Goals

Cognitive Ergonomics Ergonomics: designing the equipment and workspace to fit workers Cognition: desire to know Cognitive ergonomics:  studies cognition in work settings  in order to optimize human well-being and system performance It is especially important in the design of complex, high-tech, or automated systems.

Design of Everyday Things Norman ’ s five principles of design  Visibility: Making the parts visible  Mappings: Understandable relationships between controls and actions  Affordances: The perceived uses of an object  Constraints: Prevent the user from doing things they shouldn ’ t  Feedback: Reporting what has been done and accomplished

System Design Two general approaches to design  Special case Experiences built one scene/level at a time Anticipate states while pre-scripting events Solved by discovering the intentions of the designer  Systemic General behaviors are designed Scenes/Levels are specific configurations Some events may still be pre-scripted Solved by understanding the system

Systems A set of entities comprising a whole where each component interacts with or is related to at least one other component Game systems exist to enable play mechanics Relationships between components determine how the system works to produce results

System Components Objects: Pieces of a system Attributes: Properties determining what objects are Behaviors: Actions the objects can perform Relationships: How the behavior and attributes of objects affect each other while the system operates

System Behaviors Emergent complexity  Emergence is the development of complex organized systems  Emergent complexity: Behaviors that cannot be predicted simply from the rules of a system Dynamics  The behavior of systems over time  Dynamics determined by a given architecture  Generalizing dynamic behavior is hard

System Dynamics Is an approach to understanding the behavior of complex systems over time Created by Jay Forrester 1956, MIT A discipline for modeling and simulation Originally a tool for policy analysis, but applicable to any system

Cybernetics Study of communication, control, and regulation Model

Cybernetic System A basic cybernetic system has:  Sensor – detects a condition Thermometer  Comparator – evaluates the information Switch  Activator – alters the environment when triggered by the comparator

Example System

Feedback Feedback:  information about the internal or external changes of system that make the system adjust its output  The portion of a system ’ s output that is returned into the system Feedback Loop  The path taken by the feedback

Positive Feedback Amplify changes Leads to runaway behavior Difficult to make use of From Bob Craig

Negative feedback Counteracts changes Leads to goal seeking behaviors Most common form in systems From Bob Craig

Feedbacks in a Game Negative feedback  Stabilizes the game  Forgives the loser  Prolongs the game  Magnifies late successes Positive feedback  Destabilizes the game  Rewards the winner  Can end the game  Magnifies early successes

Platforms Platform: General description of hardware and software  Personal computer – PC, Mac, etc.  Console – Wii, PlayStation, Xbox, etc.  Handheld – DS, Game Boy Advance, PSP, etc.  Mobile device – Cell Phones, NGage, PDA, etc.  Arcade – custom vending games (e.g. Time Crisis) PC Games compared to other platforms:  PC Games are developed and used in the same platform, other platforms may require proprietary development kits.  Console games are popular because consoles are used in a “lean-back” position, while PC is used in a “sit-forward

Game Saves Save triggers:  automatically saved at certain points  Disadvantage: Player has little control Save-anywhere  Allow the player to save the state at any point in the game  Disadvantage: System needs to save many different variables, also may make it too easy for the player Save points:  Save only the accumulated points  Disadvantage: Rather limited Coded text saves to save a bit space Do you really want user to save?

Genres Genre – a category describing generalities of conventions, style, and content

Major Genres Action Adventure Arcade Casual Education Fighting First-person shooter Platform Racing Rhythm Role-Playing (RPG) Simulation Sports Strategy Puzzle Traditional

Audiences Target audience  Group of expected consumers  Age, gender income …  What does your audience know?  What does your audience demand? Demographics  Study of relevant economic and social statistics about a given population Demographic variables  The relevant factors

Audiences Market  Demographic segmentation of consumers  Market segments: Smaller sub-segment of the market; more tightly defined Demographic profile  Typical consumer attributes in a market  Age, Social class, gender etc.

Audiences Heavy Users  Those of the numeric minority of potential users responsible for majority of sales of any product  80/20 rule: in anything a few (20 percent) are vital and many(80 percent) are trivial. Hardcore gamer  Game industry term for heavy video game users Casual gamer  Game industry term for all other gamers

Hardcore Players Play games over long sessions Discuss games frequently and at length Knowledgeable about the industry Higher threshold for frustration Desire to modify or extend games creatively Have the latest game systems Engage in competition with themselves, the game, and others

Design Procedure Waterfall method  Development methodology  Design and production are broken into phases Iterative development  Practice of producing things incrementally  Refining and re-refining the product  May iterate many cycles before get it right

Waterfall vs. Iterative testing

Prototypes  Early working models of the product  Used to test ideas and techniques Physical prototypes  Non-electronic models; physical materials Software prototypes  Used regularly during iterative development

Testing Software testing: Process of verifying performance and reliability of a software product Tester: Person trained in methods of evaluation, may be the first job in the industry for a fresh graduate Bug: Discrepancy between expected and actual behavior Problem/Bug report: Description of the behavior of the discrepancy

Testing Types Unit test  written from the developer's perspective  focus on particular methods of the class under test Focus test  Testing session using play-testers  Testers represent the target audience  Lots of feedback at one time  Data can be compromised by group think Acceptance test

Unit Testing With very large codebases, it's difficult to make changes without breaking features Unit tests make sure nothing changes Test very small bits of functionality in isolation Build them and run them frequently Good test harness is essential

Unit Test

Acceptance Testing Also called functional tests High level tests that exercise lots of functionality They usually run the whole game checking for specific features Having them automated means they can run very frequently (with every build)

Bug Report and Trace Bug database Keep a list of all bugs, a description, their status, and priority Team uses it to know what to fix next Gives an idea of how far the game is from shipping Doesn't prevent bugs, just helps fix them more efficiently

Bug Report

Balancing Tuning  Developing solutions by adjusting systems  Iterations are faster  Changes are less dramatic Balance:  Equilibrium in a relationship  Player relationships, mechanics, systems, etc.

Balancing Intransitive relationships  Multiple elements offer weaknesses and strengths relative to each other as a whole  Balanced as a group  Example: Rock-Paper-Scissors (RPS)

Creativity Ability to create Ability to produce an idea, action, or object considered new and valuable

Classic Approach to Creativity Preparation: Background research and comprehension Incubation: Mulling things over Insight: Sudden illumination – Eureka! Evaluation: Validating revealed insights Elaboration: Transforming the idea into substance

Brainstorming Generating ideas without discrimination Evaluation after elaboration, can be unfocused

Creativity Six Thinking Hats  White Hat – neutral and objective  Red Hat – intuition, gut reaction  Black Hat – gloomy, naysayer  Yellow Hat – Pollyannaish, optimistic  Green Hat – growth and creativity  Blue Hat – process and control Symbolize perspective worn by people involved in the creative endeavor

Hats

Inspiration Board games  Spatial relationships Card games  Resource management Paper RPGs  Dynamic narratives Books  Fantasy and agency Sports  Team competition Film  Continuity techniques Television  Serialized stories Music  Temporal systems Martial arts  Discipline in action Children  Invention

Communication Documentation  Methods vary widely  Written, descriptive model of the game Depth varies according to the needs of the game Development documentation  Docgen  Wikidot

Communication Treatment: A brief, general description of the game and the fundamental concepts Used to sell and show off your idea May include:  Concept statement  Goals and objectives  Core mechanics and systems  Competitive analysis  Licensing and IP information  Target platform and audience  Scope  Key features

Example of Treatment ser/DH2650/spel08/The%20Game%20 Treatment.doc

Other Document Types Preliminary design document Initial Design Document Revised Design Document General Design Document Expanded Design Document Technical Design Document Final Design Document

Communication-Flowcharts Flowcharts  A typical technique for diagramming steps in a process  Most developers are familiar

Example Flowcharts

Communication-Diagrams Associative diagram  Drawing that helps manage and organize information visually Mind Map  A style of associative diagram  Key words and figures are placed on branches

Psychology Working Memory  Holds roughly 7 ± 2 items at one time while other cognitive operations on them  Each slide should not have more than 6 items Attention  Method of enhancing perceptions relative to other stimuli in the same environment  How we focus on important things  Limited capacity

Psychology Classical conditioning  Reaction to stimulus is conditioned by pairing with another stimulus that elicits the desired response naturally

Psychology Unconditioned stimulus – Meat Unconditioned response – Salivation over meat Conditioned stimulus – Tone Conditioned response – Salivation over tone

Psychology Operant conditioning  Learning by encouraging or discouraging Operant  A response; the action in question Example: pressing a button Reinforcement contingency  Consistent relationship between the operant and a result in the environment

Psychology Reinforcers  Increase the probability an action will be repeated Positive reinforcement  Positive stimulus that reinforces the behavior Ex. Use umbrella and be dry Negative reinforcement  The removal or prevention of a negative stimulus Ex. Use umbrella and keep from getting wet Punishment  Reduces the likelihood of a behavior with a stimulus Ex. Being burned by a hot stove

Programming Teams In the 1980s programmers developed the whole game (and did the art and sounds too!) Now programmers write code to support designers and artists (content creators)

A Team Picture

Different Programs Game code Anything related directly to the game Game engine Any code that can be reused between different games Tools In house tools Plug-ins for off-the-shelf tools

Team Organization Programmers often have a background in Computer Science or sciences They usually specialize in some area (AI, graphics, networking) but know about all other areas Teams usually have a lead programmer They sometimes have a lead for each of the major areas

Skills and Personalities Successful teams have a mix of personalities and skills:  Experience vs. new ideas  Methodical vs. visionary But hard-working is always the key

Methodologies A methodology describes the procedures followed during development to create a game Every company has a methodology (way of doing things), even if they don't explicitly think about it

Methodologies: Code and Fix Unfortunately very common Little or no planning Always reacting to events Poor quality and unreliability of finished product “Crunch” time normal

Methodologies: Waterfall Very well-defined steps in development Lots of planning ahead of time Great for creating a detailed milestone schedule Doesn't react well to changes Game development is too unpredictable for this approach

Methodologies: Iterative Multiple development cycles during a single project  Each delivering a new set of functionality  Refinements are needed The game could ship at any moment Allows for planning but also for changes

Methodologies: Agile Methods Deal with the unexpected Very short iterations: 2-3 weeks Iterate based on feedback of what was learned so far Very good visibility of state of game Difficult for publishers or even developers to adopt because it's relatively new

Make Coding Easier Version control Coding standards Automated build Code review Unit testing and acceptance testing

Version Control Recommended to use for team project Version control is  Database with all the files and history.  Only way to work properly with a team.  Branching and merging can be very useful  Used for source code as well as game assets (text and binary) Tools:  CVS is one of the most popular tool  Source anywhere

Coding standards Coding standards are  Set of coding rules for the whole team to follow  Improves readability and maintainability of the code  Easier to work with other people's code  They vary a lot from place to place Some simple, some complex Get used to different styles Sample standards can be found at: lott.org/resources/cstyle/CppCodingStandard.htmlhttp:// lott.org/resources/cstyle/CppCodingStandard.html

Automated builds Dedicated build server builds the game from scratch Takes the source code and creates an executable Also takes assets and builds them into game-specific format Build must never break

Quality Control Code reviews  Knowing others will read the code will make coding more carefully  Another programmer reads over some code and tries to find problems  Sometimes done before code is committed to version control  Can be beneficial if done correctly Follow coding standards, and put comments

Avoid Run-time Errors Run-time errors are hardest to trace and have the biggest damage Initialize variables, use tools (Visual.Net is good at this), check boundaries, etc.  purify on Windows  valgrind on Linux Asserts and crashes  Use asserts anytime the game could crash or something could go very wrong  An assert is a controlled crash in the debug version  Much easier to debug and fix  Happens right where the problem occurred  Don't use them for things that a user could do Open a non-existing file Press the wrong button

Homework #1 Game Treatment Document Due on Feb 8 th after class Each group turn in one hard copy and the grade will be assigned based on group