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
29/03/2009 at 4:02 pm Permalink
Nice writing style. Looking forward to reading more from you.
Chris Moran