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:
What is a Game? Many conflicting definitions Set of interesting choices? Engaging play? Narrative? Only one consensus: rules
Game Rules Have many different purposes Restriction Freedom Balance Good rules = fun!
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
Game Development Cycle Preproduction Concept Requirements Implementation Plan Production Testing Postproduction
The Teams Art Visual and audio experience Design Game features and world Engineering Implementation and asset pipeline Quality Assurance Test plan and balance
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
Competitive Analysis Identify competition Strengths vs. competition Weaknesses vs. competition Exploit strengths Downplay weaknesses
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
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
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?
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.
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
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
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
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
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
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)
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
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
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
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
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
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
Player Rewards Important for motivation Types of rewards vary Meeting the challenge Gaining power Changing the game world Many others Must be meaningful
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
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
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
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
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!
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
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
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
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
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
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
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
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
Conclusion Games require planning Usually more than other software Games are different Art and music Balance Emotional appeal Most importantly: Fun!
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.