Larger Projects

Mark Green

School of Creative Media

Introduction

Larger projects differ in several ways from smaller projects: More opportunity for failure Need for funding Larger teams

Management issues Communications politics

Introduction

For projects that last longer than 6 months, and require a team of more than 6 people we need to use a different production process

If all the team members can’t go to lunch together and sit at the same table, then we need to have good design documents

Projects

To set the context, what types of projects are we thinking about: Computer games Educational software

Both require teams with a range of skills and an extended development period, varying from 6 months to several years

Context

More organized development process: Better design documentation Well defined team structure

For large projects need to have the major components well defined

Will be developed by different people, must to fit together at the end of the project

Context

Without clear documentation project could lack consistency: Different parts have different visual styles Characters behave differently in different parts

of the games Rules change as the player moves through the

game

Context

Many different skills required, and many people

Need an effective organizational structure, both to organize the work flow and organize the people

Need to know “who is in charge” for the various parts of the project

Team Structure

Project Manager: person at the top, responsible for entire project, also called producer or director

Artistic Director: responsible for all of the art work

Technical Director: responsible for the programmer and other technical issues

Team Structure

Chief Designer: responsible for the design of the product

R&D: usually not directly associated with a project, explore technology and techniques that are new to the company

Team Structure

Project Manager

ChiefDesigner

ArtisticDirector

TechnicalDirector

R&D

Artists Programmers

Concept Formation

You have a great idea, but you need: Money Team members

Need to get people excited about your project, want to participateTreatment: a short document, 5 pages or less, that describes the project, gets people’s interest

Treatment

First paragraph should catch their interest, how the game starts

Explain the basic idea of the game: Why will it be fun Similar games on the market Target audience What’s new and interesting

Treatment

Financial side: How much will it cost How long will it take Who will buy it

Team What skills do you need Who is already involved

Treatment

The treatment gets the ball rolling, use it to sell the project: Publishers: get a publishing contract, source of

funds Potential team members: get good people to

join your team Financial people: arrange funding for the

project if publisher doesn’t cover all of it

Preliminary Design

Starts once treatment has been successfulDone by the chief designer with some input from the artistic director and technical directorAround 50 pages in length and takes several week to produceFirst relatively complete description of the product

Preliminary Design

The preliminary design should cover: The story behind the game, the player’s

motivation, the story line Basic game play, reward structure Structure of the game – number of levels,

movement through levels, etc Characters and objects in the game

Preliminary Design

A very fluid document, be prepared to change it frequentlyThis is where you “think out” the basic designDon’t worry about writing quality, just get the ideas down in a clear formIf you can’t describe it, you need to spend more time on its design

Preliminary Design

There should be enough information for: Artist Director: estimate the skills required,

team size, software required, and time to produce the art work

Technical Director: estimate the team size, critical components, time required

R&D: identify special requirements, skills required, time to produce solutions

Refinement

The preliminary design document (PDD) is the first rough cut at the design

the next stage is to refine this document with the aim of producing the final design

there are several ways of doing this: produce a sequence of documents each with more

detail evolve the existing document towards the final

design document

Refinement

Different companies will work in different ways, but the end is the same

the PDD is initially reviewed by the chief designer, project manager, artistic director, and technical director: evaluate: will this work, what needs to be

changed refine: fill in the details

Refinement

PDD usually produced by the chief designer working alone

the refinement process is more team based, will involve all of the designers - each working on an individual part, plus other team members

chief designer in charge of the overall design, but doesn’t do all of the work

Refinement - FDD

The result of the refinement process will be a final design document (FDD)

large and detailed document, may be many hundred pages long, could be web based

covers all of the details of the design, from game play, through art and programming

used as a reference by team during the development stage

Refinement

Refinement process can last from several weeks to more than 6 months, depends on size and difficulty of project

some refinement will occur during development: problems encountered during development start development while finishing design

Refinement

How do we refine the PDD?

Just a lot more writing?

Partially, but need to evaluate design as you proceed

sometimes just writing down ideas helps to clarify the design, can see problems when you try to describe the details

Refinement

Most of the time you actually need to test the design, see if it really works

how do we do this?

Play testing: try out the rules in a paper version of the game

do the rules make sense, is it fun to play, is there something missing?

Refinement

Play testing can often find problems in the game mechanics: rules that aren’t clear rules that aren’t needed missing or incomplete rules parts of the game that are boring places that are too easy or too hard

Refinement

Another part of refinement is the technology

how do we know if that “cool” feature is going to work?

If our game depends on it, we better know if it will work, and as soon as possible

can’t wait until the end of development to discover it won’t work

Refinement

Solution: produce a prototype

an implementation of the effect or feature, but not the whole game

see if its possible to program it, see if it really works

quite often R&D has a test game engine that can be used for this

Refinement

R&D can produce the prototype during the refinement phase, or in the early parts of the development phase

The prototype code might be usable in the final game, but that may not be possible: different game engine not a complete implementation

Final Design Document

The final reference for the design

covers all of the objects in the design, all of the game play, etc

also assigns a priority to each object and feature in the game

priority used to allocate resources, determine what can be cut when we run out of time

Final Design Document

Both a written and graphical document

should have reference models for all the objects in the game, drawings of all of the characters, weapons, levels, backgrounds, etc

ensures the consistency of art work, makes sure everything fits together visually

Development

A lot of the same techniques as small projects, but some major differences: more people, different backgrounds longer time, larger project interaction between art and technical skills need for communications harder to test work

Team Structure

Typically split along art/technical line: art group works on artistic content: graphics,

animation, sound, etc technical group works on the programming

not as clean a division as it first looks, more on this later

each group may be further divided depending upon team size

Team Structure

Art Group modelling: produce geometrical models of

objects in product animation: behaviour of objects that move level design: produce the individual levels or

scenes in the product background: produce static images sound: produce sound effects, speech, etc

Team Structure

Technical group: game engine: the actual software that runs the

game tools: the software tools used to produce and

transfer the content special effects: special animations or visual

effects needed for one part of the game, sometimes combined with the game engine

Tools

Artists produce content, but how does it get into the product?

Game engine unlikely to directly read the files produced by the design tools

quite often need to process the output in some way

programmers produce these tools, sometimes on a project basis

Tools

What type of processing is required? Convert file formats: design tool formats often

too complex and general, want a simpler format pre-process: produce a more efficient format,

extra information that makes the product faster combine the output from several design tools,

combine several files

Tools

Animator uses 3D Max to produce standard animations for a character

short animations, only a few seconds, each in a separate file, easier for the animator to work with

game engine expects all the animations for a character to be in the same file, need tool for this

Tools

Quake based games use Radiant, or some variation for level design

levels are well defined and relatively static, some motion but over a limited range

file format used for level editing not the same as used in the game, need conversion programs

programmers produce a version of Radiant for each game

Tools

Conversion tools also do a considerable amount of work

convert levels into a very efficient format: solve some of the hidden surface problem,

quicker to display perform most of the lighting calculations, more

sophisticated visual effects

many hours to process each level

Tools

Tools produced by programmers, but they need to work with the artists: need to know what the artists need need to explain to the artist how the tools work may need to evolve the tools as the project

evolves, new features or new solutions to problems

need good communications and patience

Production Pipeline

The production of the final game content is a pipeline, one step after another

start with modelling, produce models of main characters and objects

animators then produce standard animations for each of the characters

level designers combine characters and other objects to produce levels

Production Pipeline

Levels are then processed to produce input for game engine

may need to convert file formats from one stage in the pipeline to the next

file conversion programs are typically custom programmed for each project, depends on type of content

Production Pipeline

Problem: if we change something at the start of the pipeline it may take several days to get into the final product!

If we change a character model may need to change its animations

then need to reprocess all the levels it appears in

then repackage the files for the game engine

Production Pipeline

We need to carefully manage the pipeline: changes in early stages mean a lot of work must remember to send all changes through the

pipeline must remember to run all the programs

there are ways of automating all of this, there are programs that can help with this, recognise out of date files and process them

Build Manager

Person who is responsible for “building” the product

combining all the most recent files, both art and programs, to produce the most recent version of the product

makes sure that there is an up to date version of everything

could be a dedicated person

Build Manager

After the project gets started will start doing a nightly build

build starts after most people have done home, files aren’t changing

may take all night!

Gives an up to date version of the product every day, finds build problems as soon as possible

Testing

Production pipeline has implications for routine testing

make a change, want to see the result now so we know whether its right

if we run through the complete pipeline it make take hours or days to see the final result, not good enough

Testing

Need to have a test environment where you can easily test something

a simple one level game, or use smaller levels, so its easy to test

could get something running in a matter of minutes instead of waiting for days

Management

Management becomes more of an issue with larger teams

each person sees a small part of the project, may not see how everything fits together

need to have good communications, so everyone moves in the same direction

don’t want people pulling the project in opposite directions

Management

One approach is to use small teams, maximum of 6-7 people

each team has well defined goal, owns one part of the project: animation team modelling team tools team

Management

Small teams have good communications: share an office, work close together can meet informally over lunch

team manager can meet with other teams, get an overall picture of the project

can then communicate with team members, goals and directions of the project

Management

With long projects hard to stay motivated: may not have visible progress for several

months, hard to stay motivated with feedback near end of the project may need to work long

hours, 80-100 hour weeks, can easily get sick of the project

need to have ways of keeping people interested and motivated

Management

Set sub-goals for each team, something that can be reached in a few weeks of a month

get more of a feeling of progress

have a public board showing things to be done and progress that has been made

can easily see that things are happening, know when more work is required

Management

Want to build a team at the start of the project, or keep the same team for a sequence of projects

don’t hire new people part way through a project, too much learning and need time to fit into the team

want people who work well together and know how to get job done

Testing

More important for larger projects: can take much longer to fix a problem many more things can go wrong

start testing as soon as there is something to test, want to find bugs early, so they can be fixed early

usually a separate testing team, don’t work on development

Testing

New version of product given to testing team each day

result of previous nightly build

each day the testing manager will produce a list of known bugs

this list will be given to the development team at the end of the day

Testing

For each new build, first check all the known bugs to see if they have been fixed

then start looking for new bugs

it will usually take several days before a bug fix will occur, so the test manager needs to keep good records

there are software tools for bug tracking

Testing

There should be no contract between the testers and the developers

the test manager is the only contact with the development team: developers can’t influence how the product is

tested testers have similar experience to testers

Maintenance

Once product is finished everyone takes a rest

with good testing there should be little need for standard maintenance

good games get few bug reports, bad ones just don’t sell

there may be a few maintenance releases

Maintenance

We would we have a maintenance release if there are few bugs? Add features add support for new devices add support for expansion packs

a game that stands still sells for about 6 months, a maintenance release can keep sales going for a few more months

Maintenance

Expansion packs are like maintenance

they use basically the same game engine, sometime it might be upgraded

expansion packs add more content, new characters, new levels, new weapons, etc

its much easier to produce an expansion pack than a new game, a good source of income

Maintenance

At least some expansion packs are planned before the initial produce is released

need to do some planning so the expansion packs are easy to produce

other expansion packs are used to extend the life of the game, fairly easy to produce and can keep sales going for months