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