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 Chief Designer Artistic Director Technical Director R&D ArtistsProgrammers

Concept Formation You have a great idea, but you need: Money Team members Need to get people excited about your project, want to participate Treatment: 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 successful Done by the chief designer with some input from the artistic director and technical director Around 50 pages in length and takes several week to produce First 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 frequently This is where you “think out” the basic design Don’t worry about writing quality, just get the ideas down in a clear form If 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, 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