Post on 15-Jan-2016
transcript
Multimedia Games Development
COM429M2
Week 4 Game Development Process
Learning outcomes
Understand the game development process Understand steps from initial idea/proposal to
working prototype to full game development Extension to earlier lecture, Early game
development
Preproduction processNext stage in process after initial game idea/proposal has being approved
Preproduction process involves initial development of the game
Objective is to complete game design process Produce documentation Create working prototype to prove technical and
commercial feasibility of concept
Documentation Requires production of range of
documentation Documentation pads out/structures initial
idea Formalizes concepts Provides game blueprint
Documentation includes Game design document Game production path Art bible Technical design document Project plan (Timescale/deliverables)
Game Design Document End of preproduction process results in game
design document Document details all aspects of game e.g. levels,
storyline, game play Similar to software requirements/design document Iterative process, constantly evolving document
Game Design Document
Reference document (Bible) during development
Should be easy to read Concise, written in a factual style Use standard company/industry template Include comprehensive and detailed table of
contents for easy navigation Include one page summary at start
Design Document Summary
Summary should include Central game concept or focus Concise summary of story (paragraph) Highlight important game play
features/aspects Conclude with game innovations
Design Document StorylineNeeds to include an easy to read narrative of events in
the game. These should include
Game setting Plot elements (standard structure) Back story Characters (Playable) Characters (Non playable) e.g. player
supporting/player opposing, neutral
Design Document Storyline
This is fleshed out version of story summary
Helps presentation of story Includes storyboards showing key moments
in the game/plot elements and cut scenes Includes dialogue
Game play mechanics
Essential and most important part of document
Expanded version of section from game proposal
Needs to be very detailed, without assumptions
Covers all aspect of game
Game play mechanics
Describes player interaction with the game world
Details possible player actions and results Discusses what the player does in the game
and how they do it Serves as a starting point for user manual
Game play mechanics
Should include game genre and any extensions/variations from expected norms
Details players capabilities/skills and how these are done
Covers user interface and interaction modes Discusses game start-up process and player
options (customise character) Highlights requirements for character
maintenance and development
World BehaviorDocuments changes to game world in response to players actions
Complements section on mechanics to give complete coverage of how player and world/NPC’s interact
Describes NPC features and skills, context sensitive behaviour and triggering actions
Covers interaction between NPC’s Covers actions of NPC’s when not interacting with player Covers behaviour of non character elements of world More detail = less unpredicted behaviour = less QA problems
Game Elements
Game elements include Characters (non player controlled elements) Items utilized/wielded by the player/NPC’s Any other game objects or mechanisms and
their possible combinations e.g. puzzles, door locks
Be as detailed as possible
Game Elements
Be well organized
Arrange elements in groups/sub groups or classes Include a physical description of each element Include a description of each elements operation/behavior Show relationships between elements Include concept art if possible
End objective is to ensure that there is enough detail for an artist to create good artwork or a programmer to code up the element.
Game Progression
Progression described in events/player experiences/levels
Shows evolution over time Complements storyline development Usually done on a per level basis where
appropriate or on a stage by stage basis
Game Progression
Should include detail on each stage/level of game
Structure and organization Aesthetics,look/feel Major obstacles/puzzles/challenges encountered by
player Level/stage and relationship with storyline Player experience, level of difficulty, emotional
involved, skills developed
System Menus
Description of menus/option screens outside of main game play
Extra to game design, warrants own section Describe functionality/features of menus
/screens, their interaction and place/functionality in the game
List user interaction with menus and outcomes Again be as detailed as possible
Common Mistakes
Document not sufficiently detailed Poor structure, hard to use. Excessive focus on storyline to the detriment
of other essential elements Blue sky document with unfeasible
functionality Dated or poorly maintained scripts
Art BibleDuring preproduction phrase it is essential toestablish game look and style
Can take the form of pencil sketches but the more detail shown the better
Should be complimented by notes and annotations with description of artistic style, direction and instructions
Should be the starting point for story boards/concept art included in the design document
Production Path
Production path details all stages of game
development from concept to working prototype
Includes the art, modeling, rendering, level editors, sound etc…tools to use
Need to ensure cross compatibility of tools used Helps determine timescale for implementation and
project costs
Spore developmentSpore Team Size
0
10
20
30
40
50
60
70
80
Sep
-99
Dec
-99
Mar
-00
Jun-
00
Sep
-00
Dec
-00
Mar
-01
Jun-
01
Sep
-01
Dec
-01
Mar
-02
Jun-
02
Sep
-02
Dec
-02
Mar
-03
Jun-
03
Sep
-03
Dec
-03
Mar
-04
Jun-
04
Sep
-04
Dec
-04
Mar
-05
Jun-
05
Sep
-05
Dec
-05
Mar
-06
Jun-
06
Sep
-06
Dec
-06
Mar
-07
Tea
m S
ize
Technical Design Document Complements game design document from
earlier Game design document describes how the
game will function Technical design document describes how
that functionality is implemented Includes description of software design and
code structure, artificial intelligence, graphics animation, sound, networking etc..
Project Plan
The project plan is the roadmap describing the milestones in game development
States tasks to be completed and any pre-requisites or dependencies and manpower costs
Helps in development of project schedule Usually includes resource management plan, project
budget, schedule/milestones Typically needs major revisions and updating as project
progresses
Constraint Triangle
Trade off between time/cost and quality Balance between 3 elements Increase staff, project delivered in less time
but more money Decrease staff, reduce quality/functionality
Production stage
Production stage follows preproduction Full development of the game based on
feedback from preproduction Involves extensive game testing Release to manufacturer Ongoing maintenance following release
(patches and upgrades)
Game prototyping The physical outcome at the end to the
preproduction process is the game prototype Working demo which captures game essence Essential to highlight game novelty and
strengths Hard to do well as all technology/content is not
available Large parts of the game are simulated Critical to proceeding to full scale development
Development process
Development process long and involved Typically lasts 6 months - 2 years Less than 6 months unrealistic More than 2 years increases risk of being
obsolete
Development process
Good time management essential Tasks always take longer than expected Create small manageable tasks with clear
deliverables and allocation of responsibilities Essential to track and ensure progress
Development process
Iterative process be prepared for changes Ensure documentation is current Typically use a software development model
to structure project (Waterfall model)
Development process
Essential to maintain good communication across development team
Expect problems Have road plan of functionality and features
with ability to discard elements if required
Development process: Testing
Testing is important for game development. Includes
validation and verification testing
Validation testing looks at game and game play design and whether the right game is being created.
Verification testing looks more at functionality and focuses on removing imbalances and eliminating bugs
Testing is an iterative process and should occur frequently
Types of Testing
Unit testing involves testing individual elements of the game e.g. networking module
System testing checks the interaction between modules
Acceptance testing is where the “complete” game is checked before publishing
Types of Testing
Alpha testing
Internal testing where the game is mostly playable from start to finish.
Some content and and gameplay maybe absent, but the engine, interface etc are complete
Involves focus shift from construction to completion (polishing of product)
Types of Testing
Beta testing Internal or external testing, all elements are
integrated into final game Objective is bug elimination If possible do public beta testing Last part of beta testing is “Crunch time”
where the only objective is game testing
Testing: Warning Signs During testing there are a number of possible
indicators of poor game design If addressed early these can be rectified
before release If missed or ignored then the game could be
seriously comprised
Testing: Warning Signs
Development team constantly needs to help players in using controls, user interface or game objectives
Provision of natural level of information is expected for game play but excessive manuals or help tutorials may be indication of deeper problems
Game should be self contained and provide any required guidance
Players should easily become familiar with game and move on quickly
Testing: Excessive loading/saving
Excessive loading and saving of a game may indicate high level of game difficulty
Major concern if across large player group Problem resolution involves identifying
location of excessive loading and saving Will help identify problem area Problem area should be lessened or
removed
Game imbalance
Players consistently select the same character/ weapons/units/strategies maybe sign of sign of game imbalance
Similarly if players consistently ignore something
Imbalance can be detected by tracking player preferences and analyzing statistics
Excessive offensive behaviour
Players ignore defensive tactics or strategies Indicates either defense is poor/ineffective or
there is limited risk in pure aggression E.g. poor weapon balance, excessive power
ups or availability of health Requires game tuning to rectify
Constant control reconfiguration
Most games offer flexibility to reconfigure game controls
However if majority of players reconfigure default controls then it may be an indication of a problem
Ideally controls should require minor tuning Adhere to genre conventions e.g. Doom
WASD
Constant viewpoint reconfiguration
Player’s viewpoint should be adjusted automatically to complement game action
Optional manual tuning should be available but should not be a requirement
Excessive viewpoint reconfiguration is an indicator of poor game implementation
Player balance
Players should always hover between victory and disaster
Both should be a constant presence/possibility Excessive strength or weakness leads to lack
of balance in game play
Showcases
Avoid games that solely showcase technology Fundamentals still essential regardless of
technological novelities
Meeting deadlines
If possible do not release a poor game due to time constraints
Harms long term viability of product
Testing: Code freeze
Code freeze occurs many times during game development
Prevent changes that could cause significant problems and delays
Allows developers to integrate modules without coming across unexpected changes
Prevents feature/funcationality creep late into development process
Late in Beta allows only critical bug fixing
Testing summary
Test extensively Listen to tester feedback and address
concerns Fix problems early, more costly in the long
term
Going Gold
Game released to manufacturer Game thoroughly tested For console games, this will involve approval
of the console manufacturer
Maintenance phrase
Following release there are often smaller updates
Patches to fix bugs/hardware incompatibilities discovered after release
Upgrades and updates are typically additional content which enhances original game e.g. new levels
Development problems
Always plan for things to go wrong Particular problems will constantly arise
during development process Impossible to prevent but contingency
planning will help to minimize impact
Typical problems Over optimistic timescales Feature creep/game bloat Staff motivation Inadequate staff skills Disruptive staff Poor working conditions Unreliable external contractors Over ambitious objectives Poor management
Typical problems
Inadequate level of detail in task definition Misunderstood objectives Diversely located staff/poor communication Inflexible planning Poor response time in bug fixing
Poor strategic planning
Plan to catch up later Impose mandatory overtime Throw more resources at the problem Hold more meetings
Good strategic planning
Most effective way to reduce workload is to reduce project scope
Complete critical tasks first/prioritize wish list Create essential content first/ first/prioritize
wish list Keep staff motivated
Summary
Large number of steps in game production Early concept to game design document and
project planning Involves high level of planning and attention
to detail Plan for problems
Examples GDC 2007
Spore: Preproduction Through PrototypingEric Todd
Overview: This session explains how prototyping can be the heart of a virtuous cycle during preproduction. The cycle is illustrated with concrete examples and numerous prototypes from Spore’s preproduction phase. Potential pitfalls are highlighted.
Spore: Preproduction through Prototyping
Examples GDC 2007
From Design to Product: A Model for Independent Game Production Nick Soutter Overview: So you've got an idea? Congratulations! Now what? This lecture will focus on how to turn your idea into reality, withpractical examples and concrete methods drawing from anexperienced developer. Learn how to start a small game companyand leverage limited resources ($10K or less) to get your gamedeveloped into a commercial product.
From Design to Product: A Model for Independent Game Production
Examples GDC 2007
Play Early, Play Often: Prototyping Sid Meier’s Civilization IV
Dorian Newcomb, Soren Johnson Overview: This session gives a look at the first few builds of the development of CIVILIZATION IV. It demonstrates how games areprototyped at a studio where design rules, and offers unique approaches to get the most out of ideas earlier, rather than later.
Play often Play Early
Multimedia Games Development
COM429M2
Week 4 Game Development
Process