Developing a New Major

has to be part of preproduction planning if company wants to do simultaneous ship with multiple language versions

make sure no text is hard coded - that includes dates and currency symbols

voice overs will need to be done in multiple languages or subtitles

store text files with text someplace obvious

make sure text is on a separate layer in any art

have to support unicode so ya can support all languages like arabic an dcyrillic

can cost 20-40k per language to do full localization

some games include subtitles so locoalist those and not hte voice over to save mondy

there are localization experts you can work with

translators need playable version of game and the game docs

have to submit the game to all the different age rating boards in different countries

Continue reading

ch3 in textbook

good to know formal methods and be aware of what’s going on in general in the business world - saves time in the long run

project management techniques help ya with the resources-features-schedule triangle - remember to develop a quality product - if you increase 1 usually you have to change the schedule/get more money or cut features or reduce quality

goal isn’t to make projects more corporate - but it might get more buy-in from the publishers - the suits - and keep them away because they can see what’s going on in the project and that the producer is on top of things

gotta educate team, implement big important stuff first to get buy in, could start small to get big impact like take notes at meetings and mail them around with action items for discussion

project management clearly points out problems with the project - like employees not hitting deadlines and that makes people nervous

not everyone is going to be excited/happy about introducing/using product management methods

• some people will be afraid it will stifle creativity or that it will remove them more from decision making
• it can involve some upfront costs - training, time away from wrok, someone to manage the process
• not suited for all game development tasks - doesn’t work so good with art resoruce development or some of the straight design tasks

but there are benefits to using them

• people get more time for creatvie development and prototyping because they’re not spending all their time putting out fires
• easy to bring in new team members and easy for them to get up to speed and see what they’re supposed to be doing
• get data for estimating time on similar tasks in the future - so can plan better, budget better
• makes people more confident in the games success
• metrics being collected - like Scrum’s burn down charts - let the team see how they’re doing, whether they’re behind or ahead of schedule
• team has to be involved in deciding what tasks to do and when - great team involvement and buy-in

hopefully using some of these techniques will help yu forestall a lot of problems

constraints (in time and resources as well as in story) make people more creative

there’s a project management institute - there is standard terminology for management

project management lets you collect and track statistics for better future planning

with good project management it’s easier to bring in new people - process in place, tasks listed, documentation available

some project management tech good for engineering tasks - like scrum and agile - can be useful to do agile in just the one area because it’s hard to manage otherwise

takes training to learn to use the techniuqes - that takes time and money that has to be planned for

(case studies int he text book about project management technique use

other project management techniques

waterfall

• used by defense industry engineers in the 60s and 70s to reduce project failures
• phased implementation of design, codig, integration then testing
• even ths simple use of iterative design reduced failures a lot

PSP/TSP (personal software process mostly just for engineers/team software process for when everybody on the team is gona try to implement it)

• created at CMU
• personal/team software process
• from carnegie mellon, for software engineers
• focused on code quality, how to plan, how to catch bugs earlier
• requires everyone go to 2 week training course simultaneously
• code reviews at every stage
• engineers commit to fewer bugs, better time estimates
• saves money in that code more stable, more efficiently produced
• TSP ’s goal = build more involved teams, more motivated teams who can complete more aggressive projects successfully on time and budget because they were involved iwth creating the  schedule
• TSP - whole team meets for 4 days to create the project plan and task list - concentrated focused chunk o’ time and with the team involved tasks are less likely to be forgotten
• takes a lot of time to do right - have to collect a lot of data - how much time each task is taking on a daily basis (that can weird people out if htey think they’re going to be evaluated on those numbers
• data collection and evaluation can hurt buy in so have to think how you’re going to sell it

scrum

• for about the last 5 years it’s really caught on in the game industry, it’s a kind of agile method, HIgh Moon Studios ws one of hte first to use it
• iteration and feedback - always have a working version of the game so start with core features and then add on - test and fix as you go
• focused on management principles, not engineering
• biggest pro - team morale improvements - people are enthusiastic, take ownership of their tasks, have direct control of what htey are doing, and because they “own” the tasks they’re more likely to work to get rid of problems instead of waiting for managemetn to do it
• flexible and relatively easy to start using
• “design, implement, integrate, debug, tune vertical slices as you go” instead of dividing project up into phases for each step
• self-directed cross functional teams working on game features, create their own prioritized task list, set up milestones called sprints (30 days, 2 wekeks, epends on the project length)
• scrum master on each team reports back to management/leads/producer
• scrum master has to have the power to deal with anything that gets in the team’s way
• any one employee might be on several teams at once - producer needs to make sure people aren’t spread too thng
• have something playable at the end of each sprint
• vertical slices of work - do all at once - art, design, engineering tasks - to get playable version sooner
• 5-7 people per scrum is a good size - multi-discipline teams working on a game chunk that gets put into the playable game at the end of the spring
• Mass Effect developed using scrum
• Bioware used it a lot for parts of BioShock
• don’t lock your features in for each scrum - some stuff from scrum 1 might not get finished and get pushed back - just lock in the time length of the scrum
• burn down charts posted so everyone can see - everyone can see the daily progress of hte team, shows how much time each task still needs to be finished
• important parts of hte game get finished earlier so chunks can be playable - get polished over time or features get added to the core
• as the gameplay emerges team can react right away - maybe some features get cut from the list because they don’t fit anymore
• idea is not to create a 500 page design document - goal is to build working prototypes, playable chunks, that show off the key features
• publishers like it eventually - they get to see early and often what the game is looking - “publishers may be reluctant to buy into this development process at first, since they need to be educated that writing huge design documetns and creating a MS Project schedule nly gives the illusion of control. Scrum actually gives more control to the process since a tangible deliverable must be ready every 30 days which gives a more accurate picture of the progress” p. 49
• another big pro - you can see that overtime for more than a couple of days actually reduces productivity so can schedule small bursts of overtime when needed to hit a deadline instead of making it go on and on and on
• 15 minute daily scrum meetings to get rid om impediments dramatically increased productivity
• only good for projects wth uncertainty - if you know everything about a project - like an expansino pack-  then use traditional methods because you realy can with certainty lay out in a MS Project sheet the schedule and show management you’re on track for hte delivery date
• using scrum does not mean you don’t do proper prior planning - you still have to scope out hte project’s boundaries, you still have to reevaluate the project occasionally and make sure any changes are communicated with hte team
• another con - make sure things do’nt ust build oup on the backlog - “this bit me badly on my 2nd scrum projuect when every single item in the original backlog was replaced by another “higher priority” request. I didn’t clearly communicate that this impacted the deadlne of hteh original requests and consequently they would not be completed by the original deadline. As each item got superseded, i tried to convey its individual impact, but since deprioritized items tend to just sink n the product backlog instead of being axed, upper management assumed they would all still get done” (p. 51)
• don’t use it for repetitive tasks - if an artist needs to make 300 animations doesn’t help to have a multi-function team around them (maybe another animator but don’t need sound  and design guys)
• the one con interview says “There are many things you can use in scrum that are great, but the interdisciplinary nature of a group is less important when you are in full productiona dn people are working on actual game assets” p. 51

PMP - project management professional - certication

• from the project management institute
• used in lots of industries, not just game design
• no 2 projects are exactly alike, consult the project management book of knowledge for appropriate techniques
• they give out a pmp certificate
• continuing ed required at home
• their goal is to standardize project management methods across industries
• standard methods that investors and publishers and developers can all understand
• for every project pmp recommends having a quality management lpan -regardless is using iteratve development or waterfall, ya need a qulaity plan to have a successfull game - can be a simple plan - everyone plays the game for an hour and day and reports their findings or could be elaborate testplans
• 5 process groups - initiating, planning, executing, controlling, monitoring, closing - - every project goes thru these 5 steps - details on p. 54-55
• 7 knowledge areas - scope management, time managemetn, cost management, quality management, human resources, management, project communication management, risk management - details on p. 55-57

sometimes you have to educate the publisher about developing projet management methods tho they are starting to see the benefits of these formal methods so it’s not as difficult now as in the past

project reviews

• montly/periodic full project reviews with producers and management and any other important stakeholders - regular contact is good
• forces producers to stay up to date on big project goals and on project progress
• works best if management says exactly what htey’re interested in seeing so you can prepare
• make action items out of the discussion and follow up wiht team and management on a timely basis
• partially CYA - you let htem know about any potential risks or scheduling problems
• producer shoule set these up on a regular basis - producer has to be proactive
• give attendees updated schedule, ask for any additional needed resources

critical stage analysis

• a monthly/perioidc post mortem during production phse - what’s gone right/wrong/what we need to change
• everyone answers
• lead ranks the master list, selcts the highest priority ones to address or say why it can’t be dealt with now and reports the results back to the team

status reports

• weekly report of current status of your part of the project
• include informatin useful to intended audience

Meetings

• have time limits and stick to subject on teh agenda (which you’ve sent out before hand)
• people have roles - lead/moderator, time keeper, note taker/secretary
• take notes/minutes and share with team afterwards and follow up on action items
• some companies have a specific meeting note template they use

resource allocation

• be ready to move people around if you know what skills they have and they have down time during a project or borrow people from other projects (maybe something in preproduction)

feature creep

• have people fill out change requests and them justify any request to add features
• reprioritize features if you decide to add any that have been requested
• a lot of companies don’t have any approval process set up for their change requests - gotta have and everyone needs to know nad folow it
• producer and associate producers are responsible for moving hte process along and updating everyone
• get approval before starting work on a feature
• helps to have specific resources assigned for each task and make sure there are approved tasks where needed
• have one point of contact so there’s one user who knows what’s been approved or not (and they update schedule

strike force

• like a scrum team but less formal
• multi-disciplinary team
• evaluate a specific problem and come back with proposed solutions
• there’s a team leader who has a specifc charge and deadline
• everyone agrees that they’ll go with what the strike team suggests

Continue reading

Business, Management, Project management, Scrum, Software development process

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

Continue reading

determine exit creteria f

notes from igda webinar about digital distribution

talk about being independent developer

- different platforms - steam, d2d (direct to drive part of ign gamespy - so you get some coverage on their videogame channels too, might get editorial content), psn, xbla, wiiware, dsiware

- what are their oversight requiremetns - do they give you a prodcuer to oversee your work, do they check for technical specs, is there a size limit

number of games they actually release each week/month (very small actually) xbla only releases 9 original IPs a year

- costs to develop - how much to license (time adn $), gotta be licensed developer, gotta pay for dev kit

- revenues - different pay backschedules, some after the fact funding

- esrb requiremetns - cost?

gotta talk competition for game developers - indy and studio - most games fail

can write an article about your game’s development

gotta pimp the game months before it’s released - industry is hit driven

price points brand studio and hard to change fromlow priced game image to higher priced game image

iphone market totally full and cluttered - can’t hardly break thru -probably only top 10 making anymoney - may not be worth the effort even with the short development times - gotta market like crazy - peopel going to the iphone store to buy apps and probably only to the itunes store so hard to market there

does digital distribution do away withthe need for the publisher (they give funding but they’re gonna take 35-50% of the revenue), studios focused on retail distribution and se digital distributon as a far second channel

iphone might be interesting for student development - pc development makes sense

casual game portals take a big big chunk of the money , developer might end up with 40 cents per sale

for students doesn’t really mater what platform - just show you can finish a game and get it out there on any platform

episodic content releases - bootstrap development, involve the community in the development process, controls your risk as dveloper, exploit the succes of the steps of the project - see if the idea has legs and then develop more content or adjust based on customer feedback or junk it and go on to next project

legal representation is important for developers - only a couple of lawyers specialize in videogame contract law, probably need a local lawyer to handle state law stuff (employment, incorporating, leases) and then a specialist for the big negotiations - doesn’t matter where they are - can handle online, articles on his website about legal issues, igda site has resources

game development is a business, and ya have to run it like a business, take legal steps to protect yourself and your IP - do’nt get swept away because publisher says they love it and you sign a contract without thinking about the deal details - you have to loveyour game enough to focus on the deal details - put as much care into the deal as the game development - many people get screwed on tehir first deal

not gonna get first game released by big studios, gonna have to go to less reputable, smaller studios - and sometimes they don’t pay, they’re more likely to try to screw ya on the contract

facebook as a platform - gotta figure out the buisnes model, probably not good for small developers because of the busines model

everything in a contract is negotiable in a contract - even with the big distirbution platforms - nothing final till it’s signed - they’ll offer the deal they want, you change to be the deal you want and then negotiations begin, that’s why ya need a good lawyer who understands the industry

maybe the class needs to be starting a stuido focus as well as being a producer focused

webinar by thom buscaglia - thb@gameattorney.com

contacts

steam - jason Holtman jasonh@valvesoftware.com, anna sweet anna@valvesoftware.com

d2d - damon marshall - dmarshall@igngamespy.com

xbla - arcade@microsoft.com

creators club - creators.nxna.com

wiiware - dan adelman - danade01@noa.nintendo.com

sony 3rd party - vivian lam - vivian_lam@playstation.sony.com

sony firstparty - ted regulski Ted_regulski@playstation.sony.com, Rusty Buchert Rusty_buchert@playstation.sony.com

other ideas for the class

copyright and legal stuff

video of a talk by larry lessig on copyright - http://blip.tv/file/2827842

Continue reading

need lessons on using photoshop/gimp to make sprites and background graphics, to create box art

need lessons on audio - using garage band and audacity to create sound effects and background music - need to know about loops and layering, need to think about emotion you want to evoke

1st semester - go thru tutorial, do the audio and photoshop lessons, retalk gameplay, genre conventions, rules, characters, story, do some levels for ideas we give them, talk about teams, documentation, make pitch docs, come up with an idea and do their pre-production by end of the semester

2nd semester is all about making their game - multiple levels, need sound, need game design doc, need instructions, need demo video, need box art, have playtestable levels every couple of weeks?

exercises for the first couple of classes before we go over any of the readings - have them put the info on their blog so we can come back to it later and to get hte used to creating blog posts, maybe find a picture to go with it or a video of their avorite quest- 1)pick a game you like and describe everything you experience during hte first 10 minutes. 2)PICK A FAVORITE MISSION OR QUEST and describe everytying yu see, everything you hear, every challenge you face, everythought you have while playing, every action you take. make a list - sights, sounds, mental activities, actions. tell them afterwards as we discuss that it is this combo that creates fun for hte player, when we get to ch21 have them compare their list of activities with the lists in the book - did their game have anything new to do, did they do things and not even notice till they saw the list?

as they develop their games have them look at the  lists in ch21 about what makes game fun adn not fun - which items from those lists are in their games - how can they add more fun? how can they reduce the not fun quotient. Look at the lists about things you can do in different genres - they have to identify a genre for hteir game - can they add any genre specific stuff to their game? Do theyhave any elements that are from other genres - do they detract from teh game? distract the user? why are they there?

need a section on puzzles - check out bob bates - http://www.scottkim.com/thinkinggames/GDC00/bates.html article about designing the puzzle, Perry book has a whole chapter on them (ch27, p. 615) and so does Challenges for game designers (the book about non-digital games by brathwaite and Schreiber) ch3 (puzzle design) and maybe ch5 (chance), need an assignment to do paper/pencil puzzles, play puzzle based games on different platforms and identify the puzzles using hte categories fromt eh chapter, need exercise to make puzzles, could do something with codes (letters, colors, flags, hand signals) - the challenge book has challenge 3 on p. 53 about password breaking and codes, some interesting puzzle creation projects on p. 56-57 - #6 (turn a single player puzzle like a sudoku into a 2 palyer competitive game), #2 (create tile based game where tiles only go together 1 way - do as solo and hten sas multi-player game)

chs I’d want to use from the Perry book - 2 (brainstorming), 4 (what publishers want), 9 (story), 11 (scenarios), 12 (characters), 13 (char roles/jobs), 14 (enemies), 15 (char abilities), 16 (speech), 19 (objects/locations), 21 (experiential design), 23 (goals), 24 (rewards), 27 (puzzles), 28 (pacing), 30 (communicating w/ player), 31 (common design problems)

chs from Rabin book - chapters are long, maybe thy’re the core of a whole class or a workshop instead of a weekly assigned reading?, do we read and use as bakground or give them handouts or have them buy the new book which isn’t a bad idea because the price isn’t too bad - but rabin + perry? might be a little steep — ch 6.6 (lighting), 6.9 (audio design & production), 7.1 (game production & project management), 5.1 (graphics), 5.2 (character animation), 3.5 (debugging), 2.2 (game design), 3.1 (teams)

chs from the Fullerton book - ch3 (formal elements),  ch6 (conceptualization), ch7 (prototyping), ch8 (digital prototyping, 9 (playtesting), ch10 (functionality, completeness, balance), ch14 (design document)

when we talk playtesting - bring in info from the game usability book - probably we need to read and use as background

Continue reading

take aways - team ahs to cmmunicate - amongst themselves , with publisher, with funders, with hte media - about hte game, how it’s being developed, how money will be spent, how time will be spent - documentation is how things are communicated (one way) and different pahses of development producer dfferent types of documentation as outputs. we’ll have a whole class on production - but there are leads in each department and they help make the documentation so everyone needs some practice with leadership, working with teams, communicating with the rest of the team thru doc, scheduling and budgeting

there’s a template for a schedule for the board game on google docs - the URL is in the LInks section of Mambo under project management tools - has start and stop dates - can look for dependencies there, has a section for people needed - also a dependency possibility in a small company

Game development phases - concept, pre-production, prototype, production, alpha, bet, gold, post-production - each phase involves different people on the team to differing extents and each phase has specific objectives to accomplish

concept development phase - starts when an idea for the game comes up and it ends when the decision is made to puton of hte ideas into pre-production - team needed is small - maybe only designer, programmer, artists adn producer, figure out what game is about, get it written downin teh concept document thtaa others on teh team can look at and comment on, gotta identify a target market, figure out what resources from teh company you’ll need

pre-production phase - the planning phase - develop the art style guide, the production plan. phase ends when the game design doc and technical specs are written - difficulty is figuring out which ideas are going to be really good and how to make the game really fun

prototype phase - a tangible version of hte game that shows off what makes your game special and what will make it successful, can create low-fidelity prototypes - paper based with cards, boards, miniatures - to test in house to show that the game mechanics work - using low-fidelity prototype lets ya focus on teh game mechanics and not the aesthetics. funders swant to see prototype - only willing to give an idea a minute or two so if they can’t understand the game they’ll can the project, do’nt develop new tech since project could be cancelled - prototype should just simulate the new stuff - prototypes sell ideas but not best reason to use prototype - instead use it to play iwth new ideas to see if they work in the game, play test with hte prototype with objective playtesters (not just your own team) to get good feedback — you have to incorporate the feedback into the prototype development, for playtesting low fidelity is ok

production phase - this is the longest phase, ends when the game is finished - crnch time happens when we miscalculate how long the production phase will last or when funders don’t give enough time for this phase - it’s producer’s job to keep the team on schedule and project on budget and keep employees fairly satisfied so they don’t all quit at the end

alpha, beta, gold - phases of getting the game ready to ship once it’s finished - fix bugs, test with users and fix more bugs, send it to console makers to be certified, change language for other markets, in alpha might still have place holder art and sounds, will write the manual, in beta ya put in all the finished art and sounds and finalize the interface and manual, gold is the stage where it’s shipped to the stores - gotta decide when to stop the development and move from beta to gold and sometimes that’s tough - always some more cool stuff you could add, can skip manufacturing process (making the dvd’s) if ya use digital distribution

post production phase - make new versions that improve the orginal game - patches, bug fixes, updates with new content, expansiosn - osme versions are free

agile development - rapid developmetn - all about iterations, producting worksable slices of the game over and over again - no tons of preplanning — design which includes planning and preproduction), prototype (playable), evaluate (playtesting)

list of mistakes in development process on p. 350 - many involve communication (motivation, and misunderstanding, dealing with difficult employees)

big thick documentation dudring preplanning stage not so useful because as game develops things change - but you need some doc to put hte game into a framework that everyone on the team can buy into and understand

concept doc - the pitch doc - helps management see if game is viable, no more than 5 pages, no more than a week to write, sell the idea to funders - include premise (the high concept or basic idea, gives the mood and the game’s hook that makes it unique, something you might put on a poster or the front fof hte game box to get player’s attention), talk about player’s otivation and the victory condition and why player is going to play thru to the end, the unique selling proposition - what makes game unique and what will make player choose your game over other games - no more than one paragraph and maybe alist of outstanding features, then talk about target audience - player demographics and psychographics and where thye’ll play and previous experience and specific age range - gain probably no more than a pragraph, talk about genre, target rating, target hardware, if you’re licensing any IP, gotta talk about competition and do a competititve analyis and talk about how your game can beat the competition, talk about the goals for the game - what mood are you trying to get in the player (go beyond fun) an dhow you’re going to achieve those goals

game proposal - your game’s hook, gameplay, any features you’re going to have for online and multiplayer, any special technology you’re going to use, production details (your team, rough estimate of hte cost and mention some key milestones and ship date posibillities, backstory and story synopsis, description of important characters, identify risks (SWOT analysis),include some concept art

game design doc - much longer than the other 2 docs - it’s the details the programmers and artists use to work from to make the game - has details about interface and the engine you want to use, all the characters, their abilities and anything they’ll carry - detials of the doc depend on the project details and company requirements - lots of templates

also gonna have an art style guide

producer makes the project plan - the path taken to develop the game - the tasks, dependencies, it’s the real world schedule with some padding built in - can break down into resource plan, budget, schedule, and milestones

then need a test plan - drawsn up by the QA department - a testing checklist and how the game is gonna be tested for bugs, gets revised as new areas of hte game are finished/added

Continue reading

Continue reading

ideas for first semester

• they need an assignment to play games and blog - we have categories of games - by genre, by hardware platform, by studio, by strongest characteristic, by success. They have to play games from each category and blog about them. Everybody could be doing a different category each week (so the games will go around) but over hte course of the semester they have to do 5 - 1 every 2 weeks. Goal is to get them to focus on that characteristic in depth in a game or two - for videogames
• same for board games -  we just play them to be playing, to get experience. we go for variety.so need to play in class and have assignments where they play outside of class
• COuld we move the domino and card game making activity to first semester - simple/uninformed approaches to making games,
• COuld also talk about aesthetics and rules and cheating  and briefly about marketing and picking an audience - so figure out what topics to spin off of making board games. could do a little photoshop intro to talk about making the board graphics.
• move the book report exercise to this fall semester class - and have them pick 2 or 3 of the questions to answer
• definitely want to talk more about mmos - community manager is a job they could get while still in school maybe (connects marketing and development, good to be in development meetings to hear what’s being proposed and hopefully talk about how users might react, could update development teams with stats and trends from community forum posts and events, comm mgr works to build relations with users especially the super users who will buy and try everyting related to your product - you pimp their events and websites and give them unique content and go to their events and help them set up whatever they need to create community around the game) , play with some text based (usually built with interactive fiction engines, there are game masters who create content and who work with users, these gmes have to have good solo modes, can do some things in text based games that you can’t in graphical gmes because framerate would disintegrate - like having everybody come to one spot to get a magic spell, when you have a small user base you try tings like personally greeting users as they come into the world and as base increases the personal contact goes down and you put in things like tutorials, people want to customize and make their stuff unique even in text descriptions)  and browser based mmos (they have lower barriers of entry, they’re less intimidating than big mmo’s, they can be bridget games for a probably small portion of casual gamers to more hard core games)
• intro brainstorming

ideas for second semester

• we need to look more at game mechanics from traditional games - collecting, racing, matching… need to focus on the board games and their mechanics so their board games are better. Use the domino and card games they made first semester as examples this semester - see what they did right and what htey did wrong, then build more board/card/domino/pyramid games to talk about their mechanics.have specific milestone dates, use the google spreadsheets in their groups (i put in the main milestones, their group might (should) come up with others)
• so need a different book for the 2nd semester - maybe something about making board/card games
• need to talk about ratings in videogames and any board/card game equivalents
• need to talk about playtest in a lecture before they do it - goals, difference between play testing, playing, quality assurance, need playtest forms
• need to talk about how to balance traditional analog games
• need some specific assignments on the audience reseach and game marketing (first semester just mention, look at some classic ads)
• blog this semester could be a group development blog - weekly or more frequent updates, pics of development, notes from their out of class meetings, final versions of their documentation, share the process, becomes raw materials for their final paperwork
• do more brainstorming practice - then after they’ve picked topic and done some research, have a brainstorm session in class
• need some readings from boardgame blogs, game developer mag, game developer blogs

Related articles by Zemanta

• Building Prototypes for Analog Games (profkim.blogspot.com)
• New Game Journalism: GDC The Text Adventure (rockpapershotgun.com)

Continue reading

http://web.mit.edu/spotlight/stata2/

gotta ask these questions of any building - do people enjoy coming there, can they do their work

but in a building meant to be fun - gotta ask does the space inspire us to ask what the architect was trying to do, does it inspire creative thought, doesit open people up to new ideas, does it raise the spirits of the people in it

Continue reading