Presentation is loading. Please wait.

Presentation is loading. Please wait.

Game Development Presented by Jason Kratzke. What is a Game?  Many conflicting definitions  Set of interesting choices?  Engaging play?  Narrative?

Similar presentations

Presentation on theme: "Game Development Presented by Jason Kratzke. What is a Game?  Many conflicting definitions  Set of interesting choices?  Engaging play?  Narrative?"— Presentation transcript:

1 Game Development Presented by Jason Kratzke

2 What is a Game?  Many conflicting definitions  Set of interesting choices?  Engaging play?  Narrative?  Only one consensus: rules

3 Game Rules  Have many different purposes  Restriction  Freedom  Balance  Good rules = fun!

4 Evolution of Game Development  Began with small teams  Originally not commercial  First game for consumers: Spacewar (1962)  Team sizes grew  Games became complex  Planning/process necessary

5 Game Development Cycle  Preproduction  Concept  Requirements  Implementation Plan  Production  Testing  Postproduction

6 The Teams  Art  Visual and audio experience  Design  Game features and world  Engineering  Implementation and asset pipeline  Quality Assurance  Test plan and balance

7 Preproduction: Game Concept  Often begins as a simple idea or question  Must be expanded  Target audience  Genre  Platform  The most important decision for a game

8 Competitive Analysis  Identify competition  Strengths vs. competition  Weaknesses vs. competition  Exploit strengths  Downplay weaknesses

9 Game Pitch  Make publisher(s) excited for the idea  Create early prototypes  Polish prototypes within their limited scope  A good prototype can create early hype  Listen to publisher feedback  Present competitive analysis

10 Preproduction: Game Requirements  Requirement quality is important  Gaming market is competitive  Prevent function creep  “Wouldn’t it be cool if…” can lead to severe function creep

11 Creating Requirements  Gathering is different  Customer is entire audience  No designated person to get requirements from  Entire team helps  Remember past games  What has worked and what hasn’t?

12 Feature Decisions  Features should fit game concept  Not the other way around  Even great-sounding features follow this rule  Example: futuristic shooter game  Team member visualizes/describes the greatest turn-based combat feature ever  The feature would be completely absurd in the game; do not include it.

13 Importance of Features  Features must be prioritized  Important (core) features must be done before “frills”  Cuts down on “function creep”  Game must distinguish itself from competition  Game-specific features impress publishers

14 Preproduction: Game Implementation Plan  High probability of failure without a plan  Just like any software!  Game-specific planning  More art than other software  Balance testing  Extra prototypes

15 Planning for Art  Games require enormous amounts of art  Levels, characters, objects, music, etc.  Concept art – introduces visual style  Assets needed early on  Early builds can use placeholders  Even placeholders must be created first  Scheduling voice actors

16 Important Game Milestones  Alpha general criteria  50% art done (rest placeholders)  All core features finished  Code Complete – no more feature revisions  Beta – anticipated by many  When game features (minor and major) finished

17 Production  All game assets are created and integrated  Stage most often associated with development  Would be difficult without preproduction  Relies heavily on good plan & hard work  Requires strong team skills

18 Production: Artists’ Work  Art is extremely important for games  Visual and audio work together  Defines the game’s atmosphere  Inspires emotions to involve players  Art must support the game’s concept  Example: colorful, strange artwork for a game of absurdity (e.g. Katamari Damacy)

19 Other Benefits of Good Art  Draws in those who do “judge a book by its cover”  Makes games feel more realistic or fantastic  Minor gameplay complaints can be overshadowed by powerful art or music  Great interface art improves menus

20 Production: Designers’ Work  Constantly reviewing features  Features as implemented must match “feel” of the game  Tweaking and improving features  Occasionally feature must be redesigned  A complete redesign is expensive  Should only be done if the feature does not fit with game concept as was thought

21 The Game World  Designers expand the game world  Create all major and minor world details  Most important done in preproduction  Gaps (and gaping holes) filled in during production  Story development draws in players  Plot must still support game concept

22 Story Detail  Level of story detail depends on game  Games based on reality need little background  Fantasy requires building entire worlds  Role-Playing Games (RPGs) need rich worlds, characters, and history  Well-known example: Final Fantasy

23 Level Design  Level – the area or context of a player’s actions  Traditional “levels” or locations in a larger world  Levels define the gameplay experience  Often what makes or breaks a game

24 Artificial Intelligence  Comes in many levels of complexity  Desired effect determines implementation  Examples: A guard patrolling around a building needs simple AI, but a tough computer opponent in a strategy game requires complex AI  Can add to immersion

25 Player Rewards  Important for motivation  Types of rewards vary  Meeting the challenge  Gaining power  Changing the game world  Many others  Must be meaningful

26 Game Balance  Balance: remaining between extremes  Extremely important in games  More important in multiplayer games  Most important: risk vs. reward and power balance  Risk vs. Reward: make no choice clearly superior or inferior  Power: maintain challenge without creating frustration

27 Multiplayer Considerations  Multiplayer balance: difficult yet rewarding  All players must have equal opportunities for success  Imbalance = boring for overly powerful, frustrating for less powerful  Communities form  Decide how to support game’s communities

28 Production: Engineers’ Work  Implement features according to plan  Software  Hardware  Ensure hardware can handle features  Features may require redesign if hardware is inadequate  Worst case: feature goes unimplemented due to hardware/software constraints

29 Asset Pipeline  Pipeline allows assets (art, music, etc.) to be added to games  Sometimes simply involves converting files  Require specific organization  Must be kept as simple as possible  Short pipelines avoid human error

30 Production: Quality Assurance  Create test plan for all features  Test features as soon as they are available  Game-specific test areas  Fun  Immersion  Pacing  None of these are quantifiable!

31 More Balance  QA is also concerned with balance  Some game aspects are quantifiable  Balancing on these can be achieved through mathematics  How does one balance those that aren’t?  1. Testing!  2. Modification!  3. Back to step 1!  Total balance – almost impossible  Must decide what is close enough

32 Testing  Generally starts during production  When production ends, testing continues  Important testing deadlines:  Alpha: ensure features fit the game  Code freeze: no new features to be added  Beta: Remove most of the elusive bugs  Second purpose: increase game visibility  Final goal of testing: ready game to be shipped

33 Alpha Testing  Purpose: ensure all features fit game concept & work together  Starting point varies  Normally when 50% of art assets finished, all core features implemented  Primary question: Do the features make the game feel like a fun, cohesive whole?  Generally done by in-house testers

34 Code Freeze  Also known as code complete  No new features to be added  Generally occurs after alpha finishes  Does not mean the game is done  Only means functionality is set  Interactions between functionality must be verified  Balance is generally not complete

35 Beta Testing  Final thorough testing effort  For games, usually done by players  Useful for finding obscure defects  Great way to test game balance  Adding new features during beta: danger  Easily leads to function creep  Need clear system for reporting issues

36 Finishing Testing  End-of-testing goals  Remove remaining defects  Except those deemed “will not fix”  Create release candidate  Check release candidate against entire test plan  Console manufacturer/licensor approval  Finally, create gold master

37 Postproduction  Plenty of work left  New features, fixes added in patches  Defects left behind in games are exploited  This can destroy balance!  Most online games are expected to be patched  Review development process

38 Postmortem  Important questions  Did we achieve our goals for the game?  Were the project’s expectations realistic?  What went right?  What went wrong?  What lessons did we learn?  Player feedback answers many of these  Continually improve development process

39 Conclusion  Games require planning  Usually more than other software  Games are different  Art and music  Balance  Emotional appeal  Most importantly: Fun!

40 References  Chandler, Heather Maxwell and Rafael. (2011). Fundamentals of Game Development. Sudbury, MA: Jones and Bartlett Learning.  Flynt, John P. (2005). Software Engineering for Game Designers. Boston, MA: Thomson Course Technology PTR.  Kremers, Rudolf. (2009). Level Design: Concept, theory, & practice. Natick, MA: A K Peters, Ltd.  Schell, Jesse. (2008). The Art of Game Design: A book of lenses. Burlington, MA: Morgan Kaufmann Publishers.

Download ppt "Game Development Presented by Jason Kratzke. What is a Game?  Many conflicting definitions  Set of interesting choices?  Engaging play?  Narrative?"

Similar presentations

Ads by Google