Developing a New Major

starts off with descriptoin of woman working at a call center - one just working and the other working with a game wrapped arund the wrok

like the game wrapped work because - she’s engaged, knows the rules on how to advance, gets evaluated on objective measures, everybody’s stats are public, gets evaluated daily, more social contact with hte people on the team, learn from and teach people — things she was missing from the regular job

game wrapped job had a narrative and visuals - things to see while she worked and did the phone call stuff

people play videogames and are way more engaged, volunteer to spend time, to do tasks in the game - things they wouldn’t do at work, people are immersed, don’t experience time passing (no clock watching in a game like we do at work

their story - if yu want people to be engaged with their jobs..you have to think about how to bring in game elements..and the game elements shouldn’t be used just during training or orientation — not just about having fun at work

game elements can help people collaborate in distributed teams, help them share info, help them deal with boring elements in their jobs..games give feedback, rewards, tell  ya how to get better, what ya need to do next

“real-world organizations that have trouble moving quickly because they are legacy bound, risk averse, overloaded iwth info and worried about hte future..Modern info owrk is tough” p. 4

up and coming employees play games, gonna want different technology to use in their job, want immediate feedback, want oportunities for trial and error, willing to take risks, accept failure as part of the game, expect competition, want the rules to be known to all, will have access to machines that deliver engageing entertainment at home..usually better tech at home than work, use the things they learn in games in making work decisions, in wanting to improve the job

in games players do many of hte same things info workers do in the real world - analysis, team building, grinding drudge work..”gamers organize, categorize, nalyze, evaluate, diagnose, invent, buy, sell, lead, follow.” p. 5

not all gonna be good..repetitive stress injuries, aggressive behavior, overwork…need to apply game elements for the benefit of hte worker to get positive results

“the future of work is about engagine owrkers more than commanding them” p. 6

he’s very positive and upbeat - about work, about workers

using game elements in work will

• let people live where they want tna dcome tow work in the game
• people will choose the tasks they want to do
• people will form teams they need to do their job inside the game

“internal motivation will become more imporrtant than external permission, encouraging people’s best efforts” p. 7

games are fast paced, give cnostant feedback, make levels nad reputations visible, provide stories that are compelling, and give you a way to represent yourself in the game in ways you can’t do in RL

work that is too easy/repetitive is boring nad people lose interest in it, don’t pay attention while doing it - it can be made part of hte story, put into a quest that will keep players interested

work that’s too hard causes people to give up..lots of reasons jobs are too hard - might just be too hard to learn to do or take too long to accomplish so you dn’t see any results for so long, sometimes the task keeps getting interrupted or there’s just too much info to deal with, job might just be designed wrong - using game elements give people immediate and short term feedback, give ways to clarify objects, might hopefully fix the bad work flow design

“successful businesses in the future will redesign work from the gamer’s point of fview” (p.

“gamers also want to have fun - not necessarily a constant party but engagement that facilitates success and exposes their contribution to the larger good. p. 8

they hired grad students who were actual gamres - mmo players, guild leaders - to help them figure out what work aspects are in games - - some media ya can just study by watching once or twice but games take hundreds of hours to get to the end, to get to all the features, so need a guide, someone who’s already put int the time

“We believe the highest use of games will be to redesign work so that it is more like a game and to allow work to be conducted within games. ” p. 13

games are important to the people y’re going to hire - so that’s a good reason for yout o look at htem and figure out how they fit in your owrk…”These workers will bring new expectations about user interfaces, communication tools, and importantly, the pace of challenge and reward” (p. 13)

Continue reading

resources

agile manifesto - seems to be a core document - to be doing agile you need to buy into these core rpinciples, might implement differently or use any of the varieties of agile, but they should all use these core principles - http://agilemanifesto.org

mike cohn’s site - http://mountaingoatsoftware.com

lisa crispin - wrote book on agile testing -  http://lisacrispin.com

elisabeth hendrickson - http://testobsessed.com

Dawn Cannan - speaker at the conference about agile testing - http://passionatetester.com

a good testing automation tool - http://fitnesse.org

there’s a yahoo group about agile testing - agile-testing@yahoogroups.com

new keywords to look up - extreme programming, lean manufacturing, regression suite/regression testing, refactoring, unit tests, suer stories, vertical slices, certified scrum master, certified scrum instructor

book - innovation games

book - succeeding in agile

book - collaboration explained by jean tabaka, 2006

agile testing

• huge part of agile development - code isn’t done till it’s been tested and bugs fixed and retested and documented where necessary - - don’t want bugs going from one iteration to hte next, if code fails tests then it’s not done
• testers and developers have to collaborate in reality, not just in words - it’s not “over the fence” testing where developers “finish a project and just toss it over the fence to hte testers while the programmers walk away to do something else
• agile is into continuous integration - new junks integrated right away with old chunks and tested so you can have your workable deliverables at end of each iteration
• develop test acceptance plans before iteration and developers and testers have to agree on them or go back to team or to users/cusomters - programmers can develop for the tests and that helps cut down on bugs too
• lots of testing automated - automate the tedious taks - unit tests for when little chunks put into existing project or combo’d with other little chunks, acceptance tests (for api stuff, integration level and software below the interface), GUI tests (these can be hard to automate and be hard to maintain as gui changes), manual tests (things that can’t be automated, you need to explore system and see if stuff breaks, you need to think and analyze, usability tests, alpha nd beta versions of some features before they stabilize) — there are lots of tools for automating tests - she mentioned Fitness - fitnesse.org
• tests done on every single check in or can have a regular testing schedule
• unit tests should be runnable in like 10 minutes so programmer can see right away if they broke anything

pair programming - can take longer than a single programmer working on a project but much higher quality

agile about defect prevention not defect detection

lots of testing during and at end of each iteration

testers and programmers have to talk before during and after iteration so testers know about any changes, can develop test cases as software develops so team can reach goal of releasable code at end of each iteration

feedback is given and acted on - testing is part of the feedback so are retrospective meetings

customer wants to see product, not 400 pages of documentation and a broken project

gotta figure out if you’re looking at a symptom or a problem - can’t waste tiem treating symptoms - have to figure out the problem and treat it, have to ask a lot of why’s to get to the real problem sometimes

agile isn’t dogma, everybody implements a little differently, there are many flavors of it

but if you say you’re doing agile then you should be doing short iterations, doing quick unit tests so developers know within say 10 minutes of integrating their chunk of the build fi they broke something or not, smoe places run automated regression tests twice a day to check integrity of the project

short iterations gets you lots of feedback, forces you to break user stories down into smaller and smaller chunks that can be more easily finished

teams

• have to be really integrated - include testers - testers have to understand the user stories that the developers are working from so the testers have to be in on the planning sessions
• sometimes a company has to change their team structures, team mentality

have stuff for testers to test iwthin a couple days of start of each iteration so they can catch many bugs and get htem fixed before the iteration ends

company has to buy into the idea of testing and quality that comes from testing

acceptance testing

• set up the acceptance tests during hte initial planning meetings so tester and programmer agree on what the chunk to be worked on really does, what user story it is designed to solve
• programmer knows what htey have to do to get their code to be marked as done - and that helps eliminate bugs and useless features
• if programmers  and testers don’t agree about the acceptance tests they can go back to users or to managemetn to get clarification without wasting any time

make process and metrics visible - big charts publically displayed - so new people can see where they fit in, to remind old hands about all the tasks that needs to be finished

good to have a coach internally to help people with the transition to agile

use your retrospective to tackle little problems at the end of an interation or to address larger issues at the end of a project (bring in someone from outside the team to facilitate so everyone on the team can participate)

mangaers need orientation and training about agile - they’re afraid of it at first - some not happy about idea of self-organizing teams - so they know its benefits, so they see that agile can help make processes more transparent, more efficient, that products can ship faster and with fewer bugs - lots of rumors about bad code from agile and no documentation but that’s not a part of agile overall - chaotic development is not agile

failure to meet deadlines is so common in software development companies and folks are in denial big time - there’s so much room for improvement if you can get past the denial  - and agile is one way to get that improvement

amazon has the concept of the 2 pizza team - no more people on a team than you can feed at lunch with 2 pizza - like 6 to 10 people - easy to coordinate - that’s what agile wants too

scrum meeting - what you’re finished yesterday what you’re working on today, what you need help with - then people can offer to help after the meeting - - team talks to each other - management stays out of hte conversation except to take note of where htey need to help remove impediments

user stories

be sure to get from users ways to know that project is done

need to talk with stakeholders to get details about what they want and why and what they want to do to figure out what they really need - what they need isn’t always what they say they need

split the user stories up into small chunks and prioritize

the list of chunks is the product backlog - the priority is based on the value to the business of each chunk

put some of the most important ones on teh sprint backlog and start

lots of people seem to like 2 week cycle

daily 15 minute scrum meeting

at end of 2 weeks have retrospective meeting to get feedback for future scrum, to deal with problems to prevent htem from recurring in the future, not judgemental, goal is to get better, develop metrics, start/foster discussion

at end of iteration have finished, tested releasable chunk

stuff that didn’t get finished - decide if it stays on backlog or gets moved to make room for something else

Lean

reduce waste like deadtime as far as customer is concerned, waiting for meeting, developing a piece of software that you can’t use for a year, feature creep

optimize the whole - use queuing theory to speed process up

build quality in

lean uses terms management and mba types recognize, agile uses engineering terms

waterfall

• aim before you shoot
• lots of design upfront and then you follow that plan regardless and then test
• but so many things are hard to measure, hard to anticipate and they mess up the plan, change the software
• all the testing done at the end of a long project
• test cases made at hte beginning may not still match the software’s purpose (which may have changed over time
• often programming runs over schedule and there’s no time left to test - can’t do it in one day
• mini-waterfalls (kind of lloooks like iterative development except programmers consider their job done wihen they give the code to testers and start on the next chunk - even tho first chunk hasn’t been test and debugged - so mini waterfall is bad - bugs propagate thru the system

Continue reading

creative side has to play a lot of games to be able to do competitive analysis and feature comparisons, if you want to go into that you need to have a protfolio that shows off your creative ability, need to stay current on industry news - read gamasutra and game developer magainze regularly

producer side - learn how to owrk with teams, do project management, lead project, find out about the business side of hte industry, being a big gamer not as important but will give you some credibility with others, work up from QA and production assistant

QA testers - dn’t always need college degree - have to be avid gamer, you make contacts thru out hte company and hopefully after a couple of years you can find someone to show your portfolio too, have to be really good as a qa tester, be a self starter, have to build your own network

some game companies have you sign away rights to any game ideas you come up with while you’re working at hte company even if developed on your own time - so watch what you sign

localization is another good way to get into the business

Testing and Test plans

• test early, test often, test all areas of hte game, stress test multiplayer online games
• give testing dept copies of hte design docs so they know what design is supposed to be - then when they test they can see if it works the way the design docs said it was supposed to
• be sure to test new mechanics
• lead tester involved from pre-production so they have time to make thorough test plans - ex: test all the weapons, all the levels of weapons, all the weapons used by all the characters
• could have list of features and checkbox to say if the feature works or not, pass or fail
• main parts of each level includ  - is the score updated, were objectives triggered, does cut scene load, does character move as expected
• put on spreadsheet - play a chunk (a level) mark  all the bugs on the spreadsheet and put in the bug db
• talked int he workshop about looking at the spreadsheet to see if bug updated (not sure how spreadsheet gets updated)
• run thru game level by level, as you get closer to being done, run thru whole plan again and before going gold master go thru the whole test plan again

have a couple of core testers

hire some temps for a couple of weeks during the heavy testing

put more people on as you get closer to being doen - not something to be done with 1 or 2 people on a big game

testing is time consuming and if project gets behind people think you can just take time away from testing - ddoesn’t work

lots of QA crunch time

be sure to build testing dependnecies and adequate time/peple into budget/schedule

overestimtae the time and people because publishers tend to cut QA first

lead tester can be 1st alert if you’re behind on milestones because they also see milestone definitions and interim builds

types of testing - milestone testing, play testing, marketing and demo testing, wall crawls, bug tests and retests

gotta include time in schedule for fixing the found bugs and retesting

play testing means you need to have a bunch of testers early to make use of their feedback

producers and leads may need to prioritize bugs - fix now, fix in patch later

need a bug tracking pipeline - record in DB - version # of build, where in game it occured and the context, the type of bug (art, enginnerring..), severity (like crash bug that has to  be fixed immediately or minor bug that’s just irritating or bug report as feature request), steps to reproduce

bug reports need to be detailed so we can tell later if bug fixed or not, include actual results and expected results

one bug per report to make fixed bugs easier to track

console manufacturer have specific requests for how game has to behave (also guidelines about your design)

code release phase

• no bug fixes, just test
• people start to work on other projects
• keep some around to fix any last minute bugs
• don’t intro any new features just because you’re in the code - that usually just introduces a bunch of new bugs

closing kit - after code release and console approval - bundle up everything used to create the game - all the raw data for models, audio, tools used, documentation, master version of game - - it’s a project archive so you can go back later and create patches and sequels - use the kit to recreate your previous environment —- store it lots of places - onsite, offsite, at the publishers

gold master is version 1.0, patches are 1.1, 1.2

Continue reading

most don’t accept unsolicited pitches because of potential lawsuits over content - so set up a meeting

ask the publisher to sign a NDA (most won’t sign because they might already have a game in development with certain features of your game)

pubisher may ask you to sign an NDA in case they mention their own future project

s

Continue reading

ch5 in textbook

publishers are very selective because games take much time and money to develop

they might hear hundreds of pitches  and there’s usually a pitch process that you have to go thru

publishers can also send out their own RFPs requesting specific information - maybe they wnat gameplay elements or a schedule and budget draft, rarely asked for on spec prototype - too costlyy but you can show them work n other projects that do the things they’re asking for to show you can do the job - they don’t sendout blanket RFPs - they send them only to a few companies that they really want to work with and who they think can do the job

sometimes publisher is looking for the best quality, sometimes for someone to just do the design they already have worked out, sometimes for lowest cost

publishers have their own creative teams to come up with ideas but also go outside for ideas so they can be open to pitches

don’t give up if first pitch turned down - if you do a good pitch, make a good presentation then your reputation is enhanced iwht hte publisher and they’ll keep taking your pitches….screw up tho and the door is shut…don’t waste their time

if hte developer is owned by the publisher  then they have access to the decision makers so don’t have to do so much blind pitching

independent studios have to find publisher who will help with the retail chain and up front money

the pitch is your chance to communicate the game experience even tho the game isn’t done and there might not even be any assets to show - the publisher has to be able to “get” the game in order to make a decision about going forward

several depts at the publisher wil be involved in the decision to greenlight a game - marketing, sales, product evelopment

pitch might include

• brief treatment of the game (1-2 page executive summary - game essence, how its positioned in the marketplace, how the essecnce can be communicated to consumers - if it takes you a lot of words to explain the merits of your game then the consumer is probably not gonna get it — this is not a design doc with tons of details - it’s one or two sentences that describe your game and why people will want to buy it
• playbable prototype or vertical slice of game - doens’t have to be long but has to show how thte game will look and play - full visual quality, full animation quality, lights, sound..can be a 2 minute slice of gameplay that looks amazing not a huge world or multiple levels that look yuck - shows that the developer knows what the publisher needs to see and wahat consumers want
• game trailer - 30 secs to 1 minte - mood music, animation, setup, camera angles - whole package shows the emotional experience users will get, sould include game footage - goal is to show publisher how cool the game is - shows you kow how to turn your gameinto an entertainment vehicle
• pitch should focus on what makes the game special, on how the publisher cna sell the game, not on technical features
• include a page iwth other games you’ve made and their review scores

deals

• publisher funds 100% of evelopment cost against future royalties adn sales, publisher provides all the software and covers cost of dev kits, develper has monthly milestones they have to meet
• co-publishing - developer funds development, publisher packages and distributesx to retailers, publisher gets a distribution fee (% of sales* and size of the fee depends on what services publisher provides (packaging, marketing campaigns..)

pitch idea to management

• have to have all the planning done described above including concept docs, a playable and disposable prototype, and risk analysis
• get formal feedback and approval
• management will have ideas and changes they want, not all the ideas will be good and you have to take time to sort out the wheat from teh chaff, do some research, then come back and rediscuss
• it wil be a series of meetings, get feedback, do research, go back again to present…rinse and repeat
• producers and project leads attend along with publisher and studio reps
• make sure everyone from the team is excited about the game and knows how to communicate that excitement
• people presenting should be good at it - don’t need poor public speakers selling your idea
• need someone to take accurate and thorough notes so you get all feedback that’s offered
• you don’t always get the greenlight for your project - sometimes you get shelved completely and all your work just goes in a notebook. sometiems they ask you to reconceptualize- need to make sure ya know what hteir concerns were exactly so you can address them
• when you do get the greenlight - have a formal kick-off event - good to build some team spirit, everybody gets together and talk about the project, have some social time so people get to kow each other

once ya get the deal - you have to build/strengthen the trelationship

keep the publisher informed of your progress on the game - otherwise they think you’/re not making any progress and get frustrated, or the game you come up with might not be the game they thought they were getting and you don’t get paid or you’ll have to make changes which costs you and the publisher money

ask them for resoruces when needed (to keep that progress going) - if you haven’t been talking to them about your game they may give resources you need to other projects because htey don’t think you’re ready for htem

publisher usually assigns a producer ( book calls them PP publisher producer) of hteir own to hte project - have to make sure the duties of each are clearly spelled out so they’re not confused and neither are team members, the PP keeps the publisher’s depts in synch/informed of game progress, reviews the deliverables nad if acceptable, authorizes $$$$. they can be the developer’s advocate at the publisher - that’s a big help. they know what resources the publisher has and helps the game producer draw on them - for like localization and marketing

the DP (the producer at hte development studio) takes care of hte day to day management, makes hte game development plan, makes sure everybody stays on track, deals iwth HR issues, equipment needs - anything that affects the developers people directly, make sure your studio’s systems interface with any systems at the publisher - bugs, approval processes, any request forms

independent developer - huge risks - publisher doesn’t like product -> you don’t get paid

publisher owned studio - have to stay on schedule and on budget, consequences a bit lower if you don’t - you’ll still get paid (might get fired) but publisher has their fingers more tightly into your business - you have to negotiate a feasible schedule and feature set and work wth marketing - you have to mangae the organization and all it’s levels

publisher’s job - take the developer’s project and turning it into  into a product to be sold/marketed. they test it, submit it to console folks for approvals, create the marketing - publisher in the job of selling games (developer’s job is to make games

when ya provide prototypes and milestone versions - they’re most likely not pretty, not as much f8n as the end game - the developer has to set them up, give them context - getting them to understand what done means at each milestone

publisher has to figure out which developer can really do the project on time and on budget, they’re gonna want references, they’ll want to meet the leads and your development team

Continue reading

scrum is a type of agile development

agile = develop product using short iterations so you can fix problems while they’re small

everybody involved (on the team) knows what’s done, what needs to be done still

ned early and often communication

a lot of team mentoring and support

have a working game at the end of each iteration - and be sure to keep updating the design doc

agile takes a lot more mnagement  need a scrum master for each tem (someone who’s ful time production person no programming or drawing - they need special scrum master training)

going to agile development takes management buy in, publisher buy in - because you need extra resources, but as payback they get less wasted time, less need for crunch time

key to this kind of development - have to find the fun first in each feature (with waterfall might not have anything playable till all the work done nad hten you find out it’s not fun)

get sense of ownership by the team, especially important wiht big teams

many companies donn’t use pure scrum (maybe too expensive, not good for every develpmetn project, not good for creating lots of art assets for instance)

agile good when there’s lots of risk and uncertainty

team members like seeing hte whole project scope - can suggest changes with full knowledge of hte project, without stepping on toes of other groups

but the scrum philoosophy of communication can go across the whole project

scrum is a process, there are specific rules based on teh agile philosophy, can get certified in scrum ($$$)

waterfall - traditional project management, create lists of tasks, assumes you can break project down into tasks and know what sequence to do them in and how tlong they’ll take - most game development doesn’t fit this model

with straight scrum - each iteration starts with an 8 hour meeting, each day starts with a 15 minute scrum short meeting, management has to let go and let developers and programmers do what seems best day to day

outsiders can’t demand/stop the project during a sprint, only at end of iteration

have prototype to test at every step

average spring lasts 14-30 days

morning meetings point out what’s going wrong, people held personally responsible if htey’re holding up the project

not an excuse not to plan - but rather not to waste time overplanning

agile - gotta let go of the ego - get everybody involved in the development/discussion but also bringing ego in in terms of being responsible and motivated

marketing and busienss decision play a part too - designers can’t dedcide everyting - not a democracy - there’s a leader with authority to make decisions

short sprints - make progress on an idea, set milestones to finishe during that sprint, set length of time - no slippage

waterfall - fixed steps, time flexible - not good because it leads to late projects

at end of every spring - ask is the product fun, does the new feature add to the game, if it’s not fun have to work on fixing it

hard to hide bad engineering or sucky ideas because everyone can see right away

tools - pivotal tracker, accumate, fogbuzz, basecamp (not great, outgrow it quickly), shared whiteboards with sticky noes, google tools, unfuddle, Hansoft, MS Groove

MS Project good for waterfall, good for big overview

can’t plan away uncertainty - in game development there’s a lot of uncertainty - agile is about feeding feedback back into the plan

agile about delivery of features, not finishing tasks

sharp focus on short term goals

future goal/end goal is known but less clear than near term goals

disaggregation occurs each sprint - as you go along sprint works on only highest priority stuff and you break it down into pieces that you can work on in that short sprint period

with agile shippable products are created each iteration - each round you keep building ont he project, make it more fun

front load the high value parts of hte project so you get done in the time given

scrum is one kind of agile developement

it’s results and collaboration focused

sprint planning meeting - 8 hours at start of each sprint - this meeting is for them team, to keep updated on progress, not to update scrum master. scrum master not running the meeting, just htere to solve problems, to keep people on track if they start solving problems. meeting is to update - - problems solved elsewhere

eaily 15 minute stand up scrum team meeting - what did i do yesterday, what am i doing today, what’s holding me up

at end of each spring have a 2 hour or so long retrospective meeting to see what went right and wrong, keep everyone in a state of improvement

agile developed for products with lots of releases, short development, games aren’t like this either - could use internal play test builds or beta test builds as artificial ship dates  - don’t use marketing builds (they usually have a lot of smoke and mirrors)

scrum master cuts thru bureaucracy, has to be invested i how well the process worked, did things product owner want get imploement, did team collaborate, doesn’t care if project sucks

gotta have design doc, user stories - these still needed to build features

user stories - what are we letting user do, what happens on the screen

burn down chart - estimates vs actual work time

war room - wher eyou keep track of backlog, current stuff, finsihed stuff - - could be note cards on a wall

doesn’t wrk out of hte box for artists and designers

large group don’t always have a sense of ownership

scrum is hard to get started - people gonna need coaching/mentoring, regular reviews to let people know how they’re doing

easy to fall back into waterfall methods

bad habits - over design, over planning, delayed integration

get improved morale, productivity, quality, build reliability

easy for anyone to see/find out progress of project at any time - and that makes management happy

might take up to a year to get really up to speed with scrum, easy for management to panic and torpedo the process

to avoid crunch time - estimate good, don’t commit to doing more than you can do, you mess up the teams if you over commit and burn yoruself/them out - so under comit and over deliver

company culture has to commit to no crunch - sometimes have to be willing to say we overcommitted and can’t do this in the alloted time and cancel the project

Continue reading

lots of team members will be young, not have a lot of experience as employees or as team members or as professionals

producer

• as the team manager has to do on the job training on some basic work skills
• have to keep lines of communication open so you can hear about and address problems
• have to get a lot of different groups of people with different skills nad goals to respect and talk to each other
• leader’s job is to appreciate and inspire the team - not about the importance of hte leader
• actions -not talk- make you a leader
• you have to hold people accountable for hteir work and help them get back on track
• gotta like people
• you’re the champion of hte team to management
• there are different leadership styles and you will move in and out of the different styles depending ont eh situation - have to be more directi8ve with new employees, can be more participative as the employees get more skilled — takes time for you to develop skills in the different leaderships styles and to get comfortable moving between them

leads

• are basically managers, not content creators so don’t take your best artist just because he’s your best artist and make him the lead because you lose out on his art skills and they’re not necessarily a good manager
• lead needs to be able to communicate with lots of other tpes of non-technical people so need good people skills, need project management skills, need skills of hte team they’re leading so they’ll be respected by the team and to be ble to advice the producer on the team’s progreass
• gotta make sure lead doens’t go off on a power trip
• being a lead is a service role in the team, they’re responsible to hte team
• leads stay in place for hte whole porject, as team grows might assign a sublead role in some specialty groups

team building

long game development time means the team core is together a long time

as team grows you have to make sure everyone knows everyone else - intro new people around

make sure people know what they’re supposed to be doing, who they report to, who’s in charge of what aspects of hte project - - this will increase efficiency and morale

have job descriptions especially for new positions on the team so everyone knows what they’re supposed to do

cross training the leads - when you have down time - give the leads more respect for what others don ont he team, also really good for new employees to get the big picture, good for people who think they want to work on another part of hte team - shadowing, spend time in the departments, rotate people across departments

space organization

• 2 methods - seat by discipline so you have people wiht similar skills nearby to discuss problems iwth OR seat by what part of hte game they’re working on - everyone working on UI sit together, or put the character artists with the texturers and animators so they can talk about their part of the project
• offices vs cubes vs bullpens vs flexible open space - need space for private discussion and space for small group meetings, regardless of hte overall space layout

team meetings - keep focused and as short as possible, important to do regularly but not necessarily every week, good for discussing changes so you address concerns earlier rather than later

team wiki

keep all documentation, meeting minutes, handy references

still email around critical stuff, but wiki or websit is good for day to day stuff

it’s a place for people to collaborate and discuss

migth put up a team directory with photos, how to pronounce names, personal blurb (look at that article about the guild websites)

by the time you start to see warning signs of low morale, problem is probably huge, might have personal problems, might be pissed off about something on the project and they stop working hard - gotta address problems right away

sometimes people get burned out - need to find a way to change things up for them

everyting goes back to having build up strong communication lines in the group, int he team, int he company - don’t take hearsay as proof - gotta talk to al lthe people involved

show appreciation - buy snacks or lunch occasionally, celebrate birthdays with a cake

ties in the the company’s quality of life - people want different things from a job at different stages of life — (check out the quality of life sig at igda)

Continue reading

gonna make a lot of different types of pitches - to venture capitalists, to the IP holders, to assistant producers who act as screeners, to marketing guys who need just a low level pitch with a little detail, inside your own company to get a greenlight for your idea…

need an “elevator pitch that’s a minute or two long and convenys the high level macro concept and is designed to pique their interest and hope thatt hey extend the conversation

to publishers

• most don’t accept unsolicited pitches because of potential lawsuits down the road
• you can ask them to sin an NDA to protect your idea - most will refuse
• they’re gonna ask you to sign an NDA in case they mention any of their future projects that they have underway
• GDC Austin used to have a Live Pitch session where new developers could pitch to a varieety of publishers
• GDC SF and France also have the “Game Connection” - get 1/2 hour with each publisher
• look for new publishing companies - ask them what kind of games they’re interested in
• have 3 things for the pitch - a treatment, prototype and a trailer
• treatment - high concept description, art, competitive analysis, relevant industry trends, key features, complete budget, schedule - all this shows you know what you’re doing
• include a game tralier along with the prototype so anyone can watch and play and get a feel for the game
• publishers very involved in the development process - they assign a publisher producer - as the studio’s producer you need to manage this relationship to keep them out of your team’s way so be sure to keep open communication lines
• publishers wants to make sure you’re are spending the publisher’s money wisely
• ask them for stuff they can help with - a lot of publishers have their own testing dept that you can take advantage of for instance
• got marketing involved early so they understand game and you can act on any feedback they give ya
• marketing can do focus group, help with industry analysis and sales figures
• anticipate marketing needs and put them into the schedule. send them key milestone builds and build notes, demo builds and notes, story overview, character descriptions, main features, control overview, walk thru’s they can use for demos that illustrat ewhat you want them to highlight in their marketing

some notes from the vgexpo game pitch session

gotta be able to say who’s your main competition, know what’s gonna make your game spcial/what makes it different from other existing games (might be price, feature sets, IP, way weapons work, input device…)

pitch meeting is a time to develop an internal champion at hte publishers - try to make a connection with someone at hte meeting

have to give the impression that you can get the job done - on time, no budget

know clearly who’s your intended audiance (sometimes you know and it’s just not an audience the publisher is interested in reaching

at first you’ll pitch to screeners - they’re someone you can make a connection with, they’re on their way up in the company and your game might help them advance. don’t piss them off

internally you’ll have to pitcha the game and the feature set to members of your team, to other teams

most ideas get thrown away originally - they might already have a game like yours in projection, might not have a team available right now

need a narrative for your game, the when and why of hte game, majority of games the actual story isn’t that important - it’s the core mechanics, but you need to put the game in a narrative for the pitch

if you’re going to pitch an MMO - need lots of detail when talking to the developers; need to show how you can beat WOW if you’re talking to the suits especially if you’re leaving off features that WOW players are used to, be able to tell them how you’re going to make non-stupid NPCs - MMOs becoming very specialized right now - need to work with MMO expert to help you develop your pitch

gotta know what topics are hot and play up your games topic if it’s popular right now - pop culture trends, community features, ugc, microtransactions - hot right now

hard to sell a game with a content driven pitch - don’t start with the long backstory - if they just don’t like your content you’re screwed because that’s all they hear. better to talk mechanics, short content pitch

pitch goal - get listeners excited about something right from the beginning

remember - game is entertainment product - going to take liberties wiht content to be more entertaining and be cooler

if yo’re making a cell phone game - you have to understand mobile play habits (short bursts of time, text updates) know your competition on that platform, in US SMS costs money

some catchy terminology gives the audience something to ask you about

gotta show you have worked thru and analyzed problems/industry issues and have some solutions

think about using different technology for different parts of your idea - maybe some on the console version, some on the mobile game

create little widget games (??not sure what they meant - prototypes im thinking) to test ideas

Continue reading

gotta decide on a mood you want to create

music not needed till later in game production but leave time for feedback and correction

time for people to get cut scenes made if you want them to have music, music for trailers or marketing demos

musicians charge by the minute of music - can cost up to $1k per minute

make sure musicians know what approval process is, what the deadlines are, and make sure they keep you updated on their progress and you have to keep them updated on any changes in the project

there is original music, licensed music

need fallback in case you can’t get hte license

Continue reading