Developing a New Major

from chandler workshop at future play and from the textbook – assign students to read ch 14, 15, and 16 at the same time – 14 sets stuff up, then 15 and 16 have the details, need some spreadsheet practice with these chaps

better your preproduction – more thoughtful, more research, more complete planning – the smoother your production phase will be (theoretically) – in reality preproduction planning and production sometimes overlap, concurrent development, try to stick to the plan during product, focus on finishing hte game, not adding new features unless there’s some compelling reasons

big problem – communication – because team members actually on other teams as well as yours and they’re all at different stages of production

producer has to spend a lot of time talking to the team, play the versions of hte game and give lots of feedback (do you like it and specifically why or why not, need specifics about what they don’t like, what they’d lke to see instead

producer also has to keep distractions away from them during production (distractions like marketing wanting demo version or legal wanting to talk about licensing)

producer submits builds for outside approval

producer needs to set up a process for deciding what feedback to be implemented or addressed and what can be, add stuff to the schedule as new tasks

encourage team to give feadback to continue the buyin

assosciate producers help – they keep track of what the producer assigns

limits/restraints make people more creative and get people to work together

set goals to measure progress against

define game concept specifically so you know what you’re making and then game requirements (how things get done, risk analysis), then set up budgets and schedules

good time to negotiate with publisher and set up guidelines between people above and below you

publisher owned studios get assignments of what to make so they spend less time doing idea development and pitching and probably more likely to get the resources they need to stay on schedule

independent studios have to show they can deliver on time and on budget to get the contract

core team of leads (art, story, engineers, qa..) start the project

preproduction goal -  see if concept can be turned into viable game and not just a game that YOU want to play, have to decide if you’re developing for a specific market and is that market big enough to make a profit or for a mass audience

preproduction should take about 10-25% of the total time (including developing prototypes)

brainstorm

• do it often
• initial idea, character names, game look and feel, game play
• to get lots of ideas, to get buy in from lots of different important people up front
• brainstorming sessions have to be managed – they can’t be free for all discussions, have specific things to discuss – can be broad like let’s talk about the game concept but not “help let’s talk about the game”
• don’t get distracted by side topics about art or mechanics if that’s not the topic of the session
• going broad can lead to some interesting genre combos/topic mashups
• have specific start and stop times – if there are still lots of ideas then set up a second session
• have someone to lead the session who’s not a part of the discussion, who can enforce the rules and time limits
• try to keep the people involved limited to the team – try to keep out management and marketing types
• participants should prepare before hand – give otu the topic ahead of time and tell people to come with 10 ideeas to start with
• after session leads prioritize ideas and give people tasks based on the ideas, maybe put together top 10 ideas or top 3

defining the concept

• for the design doc
• assign the leads to write the part for their area
• there’s always a discussion about what makes up gameplay or story
• have a mission statement – what are we making, who are we making it for, make sure everyone has the statement and keeps it in mind during production – it’s the vision of hte game, doesn’t have to be fancy or in business speak – - goal of hte mission statement is to keep you from being distracted by cool features that don’t really fit the mission
• game setting = characters, location – lead designer usually has some ideas about setting and what’s gonna work best with the intiial concept, lead designer describes in words and gives to lead artist to create concept art
• mechanics – game play, how camera works, controls – what the player does, what the player experiences – challenges, rewards, how do they learn the game, what can the player do like jumpging, how does player control themselves on the screen – lead desginer creates most of this part of hte documention working with the other leads and the producer to make sure everything defined – this can take some time to get everything defined out – on a 2 year project might take 2 to 4 weeks to lay out the mechanics
• story synopsis – setting, key events, what happens at each level, how player is introduced, how does the game end, good story helps immerse the player in the game, don’t have to lay out all the details of hte story at this point for the concept pitch
• concept art – will it be cell shaded, 2d or 3d,helps everyone see what the game looks like in general, makes sure everyone has the same picture in their head about the kind of game we’re building. lead artist works iwth the concept artist and the lead designer to create initial pics of characters, levels, objects, can take awhile to create depending on how many pics needed and how detailed they need to be – the more you do of this the more consistent the game is going to be, the more realistic things will be in the game
• audio – good to include the audio guys from the beginning, sound effects, voice overs – they have to start lining up the audio assets just like the art guys do, lead designer works with the sound guy at first to make sure the sound guys has the same vision, have to decide about the unique voices for each character, what kind of music works with the game, where the music will play, what kinds of sound effects

defining game features

• start with a big brainstorm session – with the leads (rememer preproduction team is small)
• brainstorm all the features you want – take a couple of days to do – talk about single player, multiplayer, sound, gameplay, tools – everyting
• process features – things you need to improve the development process – how design doc should be laid out, how to set up approval process
• production features – the tools and technology you’ll use and any improvements you need to make to these tools like adding better lighting functionality to the graphics tools or adding cut and paste to the scripting tools
• gameplay features – might need to organize these into additional categories because it will be a huge part of hte list – it’s all the things that hte player sees and that affect their experience in the game – control of vehicles, customizing vehicles
• put everything in the list, producer sends to leads and has them prioritize – 1 to 3 maybe – they have to see the whole list and realize their depts needs aren’t always most important (don’t want to have the coolest graphics if that means gameplay is gonna suffer) – remind them to take into account the known constraints – like if you’re making a sequel then there are constraints on the subject and the look and feel; if you’re making a game based on a movie your game has to ship on the day the movie opens so there are limits on the features you can add that will take a lot of time
• they give list back and you create an average score for each feature (add up the priorities across the  different leads) – then get back together to create list of must have features, would like to have features, and it would be cool if..features – not everybody is gonna agree but you’ll get cnsnesus on most of hte features and in general consensus about what’s most important for the game
• publish the list  to the team
• this is a great way to fight against mission creep – you have list to keep going back to – not just sucked in by any cool features you see in a competitive game

analysis – competition

• competition – look at past and present competition, look at past games that have set standards so ou don’t reinvent the wheel, look at announced future games to get info to help marketing get ready to know how to sell your game
• for each competiting game write down title, developer (get to know their reputation), publisher, platform, estimated or actual release date, game summary, kiey features that they[‘ll probably play up in their ads and that show what you are going to have to include in your game to be seen as at least equal to them, any review scores, sales figures – works good in a spreadsheet – can sort by date or publisher, etc.

Analysis – SWOT

• get prepared to deal with possible problems and think about how to take advantage of good things
• strengths = usually things you have somse control over with in your team and you can exploit it to make game better
• weakness – might be things under your control but they’re negative like inexperienced team or bad platform choice for your game or tight budgets and timelines
• opportunities – you can’t control these – things like market trends, but you can exploit them
• threats – also out of your control, you have to react to them, mitigate them -  like politics or competition release dates

prototyping – makes the idea tangible

• can be paper, software, can use technology that you don’t plan to use in final version
• lots of people outside the teach can see your idea and test it out
• prototypes should be playable at some level
• low-fidelity prototypes are pencil/paper/card based
• high fidelity prototypes are digital, more like the real game, more interactive, more representative of the finished game
• exploratory prototypes – investigae new ideas, identify requirements, research alternatives – probably discarded along the way but you lern a lot about the strenghts and weaknesses of what you’re investigating/researching
• experimental prototypes – validate system requirements -  probably discarded along hte way but you lern a lot about the strenghts and weaknesses of what you’re investigating/researching, might develop new ideas to try out next
• operational prototypes that keeps getting refined until it becomes the shipped version
• example of iterative design – get playable versions very early and refine prototype as idea developed and as game development progresses
• be sure to especially prototype any new mechanics to see if htey’re really fun to play with and if they really work
• you don’t put features in on a whim – have to prototype/test all ideas
• start discussion among developers, engineers, artists with the prototype – they can all see what the idea looks like
• plan to prototype as much as possible and be willing to throw prototypes away, throw awy ideas
• better to spend some time in preproduction prototyping a key feature than to spend several weeks during production putting into effect a feature that doesn’t work right

risk analysis

• ongoing thinking of what can go wrong to figure out what to do, be ready to put into action when needed
• good to show to upper management to help them relax
• ex: publisher cuts 3 months from your schedule or your lead developer quits
• figure out how likely events are to happen and hten what you can do and what impact it will have on the project
• deal first with those possibilities that have a high probability of occuring nad or high risk to the project
• ongoing process spearheaded by the producer but which involves everyone on the team that starts after some of hte main game elements have been defined so you have an idea of what might be at risk, need to be aware of the biggest risks to the game even after it goes into production
• brainstorm the risks, get variety of people involved
• risks defined here as things that could go wrong that would affect the ship date, the game’s quality, the number of features, the cost/budget
• identify , prioritize, plan ways to mitigate/prevent, publish plan to the team, implement plans before problems occur if possible, monitor progress towards resolving known risks, identify new risks
• not all risks have same probability of occurring and not all risks have the same potential impact on the project – focus on risks that have a big impact on the project first
• goal is to do some planning upfront and then save time during development by not having to run around nad put out fires
• might take a day to brainstorm and then several days to prioritize and put together mitigation plan
• ex. p. 238

requirements – these aren’t a linear process – go round and round sometimes to set up

• define features and say what features are due when (set up scheduling milestones)
• decide what tools you’ll use, set up pipelines (file converstions, import procedures, who checks resources in and out
• write the design doc – details about UI, character, game play
• involve the team when deciding factors to get buyin and to prioitize them
• talk with team about process and how to improve it – how to get docs and art approved, etc., how to improve tools, how to improve gameplay
• make a big list of all the suggestons – then have leads rank them – must haves, want to haves, nice but not necessary — based on schedule and available resources
• if it’s a console title – you have to submit the actual title to them early on – the console manufacturer can requrest changes in the concept too – or htey can reject it outright and make you resubmit

milestones – key events to track game development progress, goals for designers and programmers

• happens after you make the feature list
• milestone = major event during game development, used to track progress
• theyre small, manageable goals to work towards – you say what deliverables are due at each milestone and everyone knows what to work on
• each team has different milestones – art has a set for character sketches, for environment pieces – and that’s different from the milestones for audo and so on
• make sure everyone agrees with the definition of the milestone deliverable
• definitions should be the same across al lthe project at a studio
• plan for localization at the beginning
• break down what each part of hte team should have for each mile3stone so engineering and art and audio and design know what to expect for their part and from each other
• as deadlines get closer – write up detailed description of what to deliver, some contracts from publishers have detailed requiremetns for deliverables
• share detailed descriptions with the leads to make sure everything can be met – these are a way to see what risks you face as milestones approach
• be sure to let publisher know if there are any problems – keep them up to date and some are wililng to be flexible
• share the descriptions and any problems with the team too to educate them about the development process and keep them buying in to the process
• set up exit criteria – how do you know specifically that a task is completed
• some common milestones include first playable version of hte game (could be based on the prototype built in pre-production), finishing the alpha version (still adding features and putting in art), code freeze (no new features added, just fix bugs – producer has to enforce this date -  people will want to keep tweaking), beta version done, and finsihing the code release candidate (descriptions on p. 244-245)
• define the deliverables in detail for each milestone so all the teams know exactly what htey have to do – have everyone check – add things they have been omitted, at some stages things won’t be e100% done – be sure to say what should be viewable/usable for each team – some projects span several milestones
• update the list regularly, keep it published, remind people to keep checking it so everyone is working ont he same schdule, things are gonna slip, take less time than expected..
• milestones are part of waterfall development process – plan out the big picture with waterfall techniques and then go to agile for the lists on the list

lead engineer and programmers have to evaluate technology they’ll use based on constraints of the game – ex in book says if you have decided to make a game known for its cutting edge technology then engineers have to look at all kinds of graphics programs and video cards – see what works off the shelf, what needs to be added on to, what needs to be built from scratch (which means no licensing fees and all the experts on it are inhouse – but it takes time to build so there’s a trade off of money and time)

production pipeline

• lead engineer works on this too
• production pipeline = steps needed to get code and assets to a playable version of hte game
• consider what tool software needed to convert file formats and asset management and compilers and langauges
• ocnsider if the tools can do 2way converstions – into finished versions and back to raw editable formats
• consider hte critical path thru the tasks and hwo to deal with bottlenecks like making sure no one person has a ton of work in the pipeline at once and everything bogs down tring to convert it
• consider when the system needs to be fully functional – might not need all the functions till several months into production
• consider how assets managed and tracked, how people are going to check stuff in and out
• consider what parts of hte process can be automated to keep down human error
• the tool we use to get software up and running and to convert between raw adn finished versions of assets
• critical path – order stuff needs to be done in to make sure everything done
• look for bottle necks along the critical path – if it breaks down, then development suffers
• need asset management – so all the pieces for a level are ready to go at same time

documentation -

• from all parts of the team, written for the specific audience – so engineering docs go to engineers look very different from docs going to marketing
• has to be clearly written – if nobody can/will read it or understand it – it’s useless
• have to update doc if changes made about how a feature works or what features are int he game
• for studio management doc put in overall gamelay mechanics, key features, how they fit together to give player experience
• design doc talk about all the features of the game and how they work – UI, mulitplayer, character backgrounds, character dialogue, scoring, mission designs, control schemes, player actions, storyline, AI, weapons, powerups, voice recognition – keep it short, precise, and technical – it’s not creative writing – have consistent formatting
• doc is written documentation about how stuff works – people can see it work by using hte prototype
• QA uses design doc to create their test plan  to see if things really work the way the doc says it should

alpha- still developing features and putting in art

code reviews – ???

update risk assessment as you learn more about the project, keep management apprised

game plan – who does what and when, deadlines, identify constraints, can change as details about budget become more certain, includes the budget, schedule, dependencies

has a graphic of a pyramid with quality in the center as the goal and on each side – features, time, resources – you can usually get 2 of the sides but rarely all three. you have to decide what you cn give up. Might see if you can get more time or more money or look for features you can cut so game is doable iwth hte time and money you do have

schedule

• over time teams/companies build up stats on how long tasks take
• list each task and estimate duration  of each task psaed on past experiences – involve the leads and get them to agree to the time frames and identify dependencies. no one wants to do this list but it needs to be done for every project
• set up small chunk milestones – like every month – internal, for teams
• when team is new, build in padding to schedule, keep track of how long tasks really take so over time can cut the padding from the schedule
• publish the schedule so whole team can see and update as needed
• work backwards from teh studio established ship date
• pad the schedule with extra time on key tasks because people always underestimate
• remember to put in time off for holidays and vacation and sick days – that will make crunch time easier to bear
• remember productivity goes down during crunch time
• maybe try to break tasks down into one and two day chunks so you can better see dependencies
• some dependencies to remember to put on the schedule are approvals from outsiders
• dependencies can cross departments
• project maangement software should calculate big tasks end dates based on little task durations, dependencies, and available resources
• can see bottlenecks where adding resources will actually speed up production – people could specialize, tasks could be done concurrently
• published schedule makes everyone responsible to the team when they can see how their deadlines affect others on teh team
• associate producer keeps track of progress, updates the schedule, goes around to individuals on teams and checks in – are you going to make the deadline
• make sure everyone knows their deadliens and their tasks so they can schedule their own time
• train people to bring schedule problems to management right away – let management know if schedule isn’t going to be met earlier rather htan later gives everyone more options
• time boxing – way to estimate schedules, set arbitrary start and end dates for the beginning, see what you get done in that arbitrary amount of time – tasks should be very well defined. if everything done and quality is acceptable – then hurray, if not see if it’s worth continuing with the task and either put back on the schedule if it’s worth continuing and set up new time box and new exit criteria or sometimes you see that a feature just isn’t worth continuing because it will take too long to fit into the schedule — let’s you keep better control over the schedule-  features don’t run wild and take up too much time without you being aware of it
• see if you can break a big complex unknowable task into smaller tasks that you can estimate duration
• see if you need to assign asdditional bodies to the task to get it done
• have a detailed schedule with specific subtasks for each task (like getting a level up and running
• take each big tasks and break down into subtasks from everyone involved – all the teams
• have them say what resources they need and how long their subtasks will take
• then put together into a schedule and look for bottlenecks and dependencies
• producer has to balance requests from teh publisher to change the schedule, from staff who want vacation/quit, from programmers who want to put in new features – have to balance them to keep up the game quality
• more work the producer can do during pre-production to set up the schedule and budget, the better — when things in flux during production, puts the game at risk
• schedule – list of tasks to be completed, estimate of task duration, who is assigned to the task, what tasks are dependent on this task
• good clear schedule can help prevent feature creep too, having small milestones along the way helps keep people on track and prevents feature creep
• some steps in the game making process like level building have the same steps each time – people and dates change, but tasks pretty similar from game to game int he same company
• hard to make a schedule ofr a 2 year project – but make it as detalied as possible – have to start somewhere, then keep updating it – gotta have some idea in case publisher changes the time frame or wants changes in the game – have to be able to say what will be the impact
• making the initial schedule can take a couple of days, a couple of weeks -depending on the project size – - and plan to update it during hte production phase
• get everybody involved in the schedule – they know how much work they can realistically do in a day so ask them and they can point out critical tasks that need to be on the schedule – don’t just tell people to do things by a certain deadline with no input or explanation because they wont take it as seriously, won’t have a steak in it, might take it as a guideline, not a deadline
• create schedule items for tasks that actually have to be done, not what you think needs to be done – yeah – how does tht work!?
• to create the initial schedule – determine exit criteria that show when a task is completed, the deliverables – ex. p. 265 – the exit criteria for finishing the pre-production phase includes finishing the initial concept, the competitive analysis, the pitch presentation, the risk analysis, get concept approval and have the project kickoff
• final exit criteria of course is delivery of hte gold master and getting it approved
• break down tasks into subtasks and assign them n the schedule – see ex. p. 266-267
• put in the ship date and work backwards
• talks about the work breakdwon structure (WBS – see ex. p. 269) – group brainstorms tasks based on the exit criteria, tasks grouped by dept and put in chronological order and then leads estimate times for each task, publish to the team so they can double check nothing’s been left off
• this detailed list of tasks gets ut on the schedule, dependencies identified and peopple assigned
• she recommends that tasks be broken down so they can be finsihed in a couple of days
• when new task or new team, put in some slop time — schedluing gets easier and more accurate as you gain experience
• don’t put overtime on the schedule – that’s demoralizing
• do put sick time and vacations into the schedule
• plan on people really only working 5 or 6 hours a day – other time needed for meetings and other non-task work, phone calls, email
• dependencies and bottlenecks can mess up a schedule – if you have to wait on approvals, no more production can occur. if someone has too many tasks at once, they don’t make progress at same speed as other people
• detailed scheduled on p. 271-274 – for a level, goes from no dependencies or resources to finished schedule
• look to see if adding resources might actually speed up production – sometimes adding anoth artist or programmer might make a positive difference if discrete tasks can be assigned to them
• someone has to track progress on hte schedule – they need to check with every team member on a regular basis and make changes to the schedule and republish right away so everyone can keepon track – that should be someone’s official job (not their whole job of course) – team has to be kept informed about the progress, where they’re ahead/behind — if tasks get finished early – you can update the plan that’s shared with everyone — can do with something like MS Project or a spreadsheet or print out and post on a wall (color in tasks as they get completed – probably just post the key deadlines dates and color them in — this person should also give teams heads up when deadlines are approaching

Budget

• goal – make a quality game released on time at a cost that will allow you to make a profit – gotta make a profit or ya don’t get to make any other games
• producers job = control costs, watch the budget
• good planning and scheduling help reduce costs
• publisher is gonna make a profit and loss estimate for your game – how many copies do they have to sell to make  aprofit – that determines how much budget you’re going to get – if you can sell more copies, you might get bigger budget – this is one of hte reasons for nailing down the audience (and probably for sequelitis)
• budget and schedule and resources all related – if you lose control of hte schedule, your game will go way over budget
• tie your budget to your schedule and resource needs – those resrouces include hardware, software, middleware, outsourced workers, kickoff meeting party – not just salaries and rent and benefits
• have to balance resources, budgets and time to get quality product
• look at your schedule – when can you roll p=eople on and off project so their salary won’t be charged to your project, when tyey could work on another project
• budgets get approved ahead of time
• track actual expenditures – if one area goes over budget, sometimes you can reallocate money from another area so whole project keeps on budget
• salaries and overhead are usually the biggest item on the budget, licensing fees can be huge too
• be sure to budget for stuff you’re gong to outsource – you have to pay those people too
• ex major budget line items on p. 279, then broken down on p. 280 – 282
• start with big top level line items and then break down, add number of people in each category, monthly rates, number of months and total costs – these get fed into publisher’s P&L to see if they’re doable – might be asked to redo/change to make game more profitable
• gotta track budget just like schedule -  probably have the same person do it – publisher has accounting dept that will be involved too – they can maybe better track overhead costs so go to them to get accurate cost estimates for your game thru out the production period
• keep detailed expenditure records

staffing

• quality, budget, schedule, and staffing all related – if you don’t have the money, you can’t hire more people, even if that would help speed up the project
• know people’s skills and backgrounds to see if hte people you already have on the team have other needed skills – then you won’t have to bring in new people and get them up to speed
• things that are normally outsourced – voice over, music, writing, art assets, localization — might also include contract programmers
• plan for outsourcing in advance to build it into the schedule
• have to be really clear about what you want outsourced contractors to do
• be sure to check their references to make sure they can really do what they say they can do
• outsourcing primarily saves time  – you’re going to have to pay a lot for quality work so usually not a budget saver
• outsource things you don’t specialize in – like certain kinds of animation or music production, outsource things that are discrete sets of tasks not dependent on things from other parts of hte team — she says writing is one of hte things outsourced – weird — and sometimes you just have to eat the loss and fire them when they dn’t make the deadline
• someone from the team should be responsible for keeping in contact with the outsourced guys – checking on their progress, getting updates, letting htem know of any schedule changes – if you get stuff to them late with out tellling them, you’ll have to pay probably some kind of penalty
• a potentially bad thing about outsourcing – you sometimes have to share source code iwht outsiders or your software tools that you’ve built
• another potential downside – harder to keep track of their schedule – they could fall behind without you being aware of any difficulties – so good to tell them the deadline is a week or two before you actually need it to build in a little slop
• leads report to the producer
• try to keep the project not too management top heavy
• executive producer is responsible for a whole franchise
• individual projects have producers
• sometimes have producers to do the scheduling and budget and creative directors who manage the game vision – - but producers usually have the final say to keep the project on schedule
• preproduction team small, and during production people join and leave the teams as needed, and during beta testing tem is small again – team size should show up in the production schedule and budget – so some job titles you need for the whole project, some for only a coule of months

Trackback URL

determine exit creteria f