Finally, the recorded content from the 2008 Leadership Forum is now available in two flavors:

DVD

28 conference sessions were recorded and are now available for purchase on DVD. The 5-disc set of hi-res video is priced at $99 (plus shipping). If you would like to purchase a copy, please email us via sales[at]igda.org and we’ll forward you the order form. (Copies of the 2007 Leadership Forum DVD are still available as well.)

Free Web Videos

You can watch the freely available lo-res videos hosted at Google Video, all linked via the “context index” page (just click on the speaker photos or “video” links for each session).

First, sorry for the late post.

Rodney Gibbs, studio head of Foundation 9 Austin studio Fizz Factor, gave a talk titled ‘Lifehacking for Producers’, the goal of which was to define and find useful systems for capturing ideas and acting on them or filing them away for future use.

First, he went through a few comments on things to do to make emailing more efficient. As all of us know, emailing can take way too much time.

• turn email and/or email alerts off
• filter like crazy – use folders etc.
• process emails in batches – do 30 minute email checking/responding spurts every 2 hours, and use other systems (phone, IM) for realtime conversations
• only touch an email once – delete it, respond to it now, archive it for informational purposes, hold it for later review or followup
• consume email ASAP - don’t let it “spoil”

Rodney then moved on to other applications that can make life easier:

Google Desktop, Quicksilver and Launchy – simple keystroke-based application launchers

Anagram - contact capture

Remember the Milk and Tada List – task lists with filters and web-based functionality

For the iPhone, task list apps include Omnifocus and Things – and the GPS on the iPhone can tell you when you’re close to somewhere you need to complete a task. (This feels a bit like a real-life quest log to me)

Text substitution apps were another tip, so you can type a small string and the computer automatically changes it into a larger string, even a paragraph – good for bulk emails which don’t need much text changed - Text Expander was the one app name I caught.

Evernote is a Flickr clone with text recognition – so you can take pictures of whiteboards or business cards and make them searchable

Tripit is an app for flight and travel coordination

Jott is a voice-to-text app so you can call in emails, status updates, and schedule items.

Twitter integrates w other applications so you can update your status on many sites simultaneously with your cellphone.

Rodney then moved on to Firefox extensions:

Read it Later – pretty self-explanatory, but gives a handy dropdown menu of recently read items instead of having to go into Favorites or History.

Ubiquity adds a command line to Firefox to allow you to quickly navigate the web and access functionality. (With search, users type what they want to find. With Ubiquity, they type what they want to do.)

Search shortcuts – on searchable sites, you can bookmark sites in Firefox you search on a lot and make shortcuts easily such as “goog search item goes here”

Rodney then moved on to hardware:

Bluelounge Charging Station – Universal charger compatible with 1500 devices

iPhone – the Tricorder is here! :p

eBeam Whiteboard - make any whiteboard web-enabled

Optima Pocket Projector – small projector for easy presentations nearly anywhere

There were a few more things at the end of the presentation as Rodney asked the audience for tips too:

Getting Things Done (book) , author’s site

43folders.com – how to find the time and attention to do your best creative work

inboxzero.com – the skills, tools, and attitude needed to empty your email inbox and keep it that way

Take Back Your Life (book) – how to use Outlook effectively.

yammer.com – Twitter for internal corporate use

highrise – web based crm (contact tracking)

mail2web.com – private Exchange server

getdropbox.com – file versioning with desktop sync

plaxo – business social network and online address book

delicious.com – social bookmarking

David:… this is really intimidating .. I learned quite a lot … an MBA isn’t always highly valued .. and isn’t for everyone .. am going to try and comm v quickly the lessons form the past 2 years that I think are most interesting …. Investing in Projects

‘A dollar today is worth more than a dollar tomorrow’

put a dollar in your retirement fund and with compound interest it will be worth more

the same logic can be applied to projects but isn’t

if you expect a 10% return then a million dollars is only worth 990,000 tomorrow

10% is not a good return how long to recoup this money “A dollar spent yesterday is worthless’ how do you recoup the dollar you already spent .. business school hammered this into us .. personal eg .. how many people do you know that buy a stock and then hear the news that the stock has dropped but refuses to sell because they can’t afford to?

Shouldn’t they take that money and put it somewhere else ?

Publisher A says = we have to kill this project cos we have already spent too much on it … the fact that the money has been spent doesn’t matter … that money has gone .. if you only have $10M more to spend and the market is worth $50M on top of the first $30M then that’s a fantastic market opportunity .. all that matters is how much is left to go and how much it’s worth Decision Trees Quantify your hopes and fears .. part art and part science .. highly simplified decision tree .

Famous IP – should we expand into a genre – Expand or Don’t? Expand – franchise could stay healthy and make a ton of money / Don’t Expend – Franchise withers 30#. choose to expand – RPG cost 10m – poss big success of 40%, lite success = 30% – Fail = 30% with 60% chance of no harm and potential 40% harm of IP = RTS cost 8M – big success risk of 20%, Success lite risk of 60% – risk of fail = 20% with potential 30% risk to harm IP and 70% risk of no harm change the probability .. think through the problem – decision trees forces you to quantity your thoughts and hopes .. new product strategy – how consumers are comfortable responding: Please rate your satisfaction with the game: We took a look a game that had gotten really good feedback .. we hated it .. where is the discrepancy .. focus groups generally won’t tell you your games sucks .. you’re a lot better off throwing up a game on Kongregate and seeing what the community really thinks.

Patrick put Crayon Physics up on the web and got such great response that a publisher got in touch and he has a deal .. throw out a prototype and see how it goes .. focus groups are always needed .. when Ken did Bioshock – without a deal .. he said that he was making a spiritual successor to System Shock .. consumers went ape .. and in the not too distant future he was being offered a nice publishing deal .. no focus group Ask your self what are your strengths and weaknesses? What are your competitors strengths and weaknesses? What do consumers want? Rock Band and Guitar Hero are doing very well .. other publishers want to get into that same space .. these publishers and dev should ask these questions .. can you overcome the strengths of GH and RB ? Marketing – psychology Everything is relative .. shows graph .. wehn you shop at a gents clothes store .. they will never offer you the accessories to the tux without selling you the tux first .. $50 on accessories is relative compared to the $500 spent on the tux a less honest real estate agent will take you to a property with something wrong and an over inflated price .. then to homes that seem better .. caviar on the menu .. average entree $30-60 .. one is prime rib at $80 ..caviar is $300 .. most people think this is for the rich dudes .. the reason it’s on the menu is to make the prime rib look like a bargain .. everything is relative Williams Sonoma had a bread making that wasn’t selling too well .. they had advice that said to sell another one at a higher price of $400 .. they took a photo of the old model, enlarged the photo and stuck it in a catalogue – they didn’t manufacture or stock it …. sales of the old cheaper model increased .. because it looked like such a bargain compared to the ‘new’ model examples of this in the games industry are collector’s version of games .. I won’t ever buy a $60 dollar collector’s version – publishers don’t care .. these collectors versions make the standard box seem like a bargain .. where is the caviar on the menu? put caviar on the menu in your virtual item sales too if you have a game you want to sell for x – when competitor is selling for y .. bundle it with an unusual item that doesn’t have to cost you very much – buy it stops consumers making direct comparisons and differentiates your product if you have 3 price points for the consumer to choose from .. the consumer will choose the middle .. the compromise principle – they don’t want the lower price as it makes them feel/look to cheap .. the highest price seems to expensive … they choose the middle .. club pogo.com – why do they have a flat sub rate? I don’t understand .. they should have 3 rates .. a premium that no one signs up for but everyone goes for the next lowest rate .. everyone thinking of setting up a subscription system should set this up .. Scarcity & Loss Phosphate detergent – banned in certain regions – before the phosphate was banned everyone believed the detergent was fine .. when the detergent was banned consumers believed that the phosphate detergent was much more powerful just because they couldn’t get hold of it any longer … we are all afraid of loss .. insulation company sales increase if they say ‘not using our product will lose you $500 a year’ .. as opposed to saying ‘using our products will save you $500′ .. news of scarcity is very powerful .. when there are 5 bidders on a house – it will get a fantastic return .. eg Wii shortage .. create more demand because everyone is competing how does this apply to games ? time limited promotions; artificially limit number of people in beta test; if someone in your free-to-play games has not played in 6 months .. the publisher will not delete the account .. but why not trigger the ‘loss principle’ and send an email saying that their character will be deleted unless they come back to play .. Mere Exposure & Priming when we are exposed to things it increases our likely for it .. exposed repeatedly to something increases affinity .. the underlying principle in most advertising .. eg. irregularly shaped polys shown rapidly to a test group .. they couldn’t remember seeing the polys but when asked which ones they liked they selected the ones that had been shown eg. two different control groups – one group is read a random group of words; group 2 all read words that had some correlation – Florida; old; .. that the people on control group 2 all walked out more slowly .. they were primed to feel old .. advertising works a fundamental truth .. a lot of indie developers don’t understand that consumers will have heard of their game many times before their game comes out- mere exposure – when a person is scrolling down the XBLA list of games they will pick the ones that they has been exposed to Managing & Motivating – commitment and consistency – we feel an internal drive to commitments we have made .. if you answer a survey agreeing to theoretically support a cause when asked for real a few weeks later you are 700% more likely to agree how can this apply to games? we don’t give enough ways for our customers to commit to our products .. maybe the way that a consumer can get into a Beta they have to tell 5 of their friends about the game? when the game is released that are that much more certain to buy it Compensation We are remarkably conventional in this industry – we compensate people in the same way that P & G do .. ind. variable bonus reports = employees expect a bonus – when they don’t, often for reasons that are nothing to do with them it is a huge blow – it causes a double whammy .. when the employee knows the bonus isn’t coming or is greatly reduced .. then right at the moment when you need your employee commitment they are totally demotivated .. bonuses don’t work .. employees who feel obligated perform more reliably .. SAS has 4% turnover rate .. they don’t give options, stock or bonuses – like their competitors – they have great family benefits and great working environment .. how does this apply? we need to focus on fun – give our employees the opp to enjoy their work .. we could all be making more money – but we would rather have a fun job and rewarding environment .. Relationships Matter – Sure, there are plenty more fish in the sea; but you’re not anywhere near the sea. You’re in the desert. Alone.

Turns out the human mind has difficulty grasping issues in teams over 75 – with teams going over 150 people we will have to deal with this problem. What companies don’t do is map out informal relationships .. I have been at MS 2.5 years and been re-org’d 6 times .. MS is really well run but whoever is in charge of the re-orgs has no idea of the informal relationships – if you have a team that is executing really you cannot move individuals around – keep that team together other things worth knowing: Other stuff: how to write a business plan – when you can’t trust numbers – which is almost always – negotiation, etc.

//Fantastic session – great speaker .. a little too fast for my typing skills. Very, very interesting.

Speaker: Tom Smith, Creative Manager @ THQ

Vision

• 10,000 ft view: Most high level view you could have. Defines game in way that sets it apart from other games and sets goals for production.
• It’s not just the game in your head… It’s also the game in your player’s head. You need to understand the user experience you are aiming for.

Things that are NOT “Good Vision” statements

• Use cases (tells story of the game)
• Prototypes
• Concept art
• Weaknesses of the above: Only talk about slices of the game, not 10,000 foot view

These are also NOT “Good Vision” statements

• Negatives (this game is NOT an RPG)
• Competitive Products
• Inspirations
• Weaknesses of the above: All kind of vague. Not precise enough

Still more things that are NOT “Good Vision” statements:

• Corporate vision. How your company works.
• Project goals.
• Positioning (platforms, ship date, etc)
• Elevator Pitch (the sales side)
• Razor X (the sales side)
• Feature List
• Unique Selling Point
• Back of Box
• User stories
• Weaknesses: These are more biz/sales/marketing, not DEVELOPMENT. Vision statement is a production tool.

A Good Vision Statement:

• Needs to be communicated within team and outside the team. Make sure everyone is seeing the same game.
• Helps resolve conflicts in an ego-free/positive way: “It’s not part of the vision” instead of “it’s a bad idea”.
• Makes people think about WHY they’re doing what they’re doing – and to think about the project as a whole, not just the task at hand.
• A Good Vision Statement is a Production Tool: It’s a central Statement that defines your game and what makes it stand out.

The Vision Chart:

• 30,000 feet = Vision… The WHY
• Top floor = Feature List, Unique Selling points… The WHAT
• Ground Floor = Prototypes, Feature Designs, Content Design Docs… The HOW
• (NB: There’s one more Floor, but I’m missing it from my notes)

When?

• Start of project
• Post pitch
• It guides preproduction
• It helps you make decisions you’re going to make during Preproduction

Who?

• The team (at least leads)
• Management
• The Publisher… If the relationship can support it.
  • You’ll even want to engage marketing if you can get them on board.
  • Their buy-in is critical. Ideally you can involve them, but it depends…

How?

• Group agreement.
• Brain storm (get it all out)
• Single visionary style vs. democracy. Tom prefers more of a democracy at this point.
• Discuss.
• Argue now so you don’t have to later.
• Have honest and tough conversations.
• As an aside: Even if you can’t get consensus, you identify potential roadblocks down the road when there are disagreements that can’t be resolved.

Sample Vision Statement (Conan)

1. Crush Your Enemies
2. Discipline of Steel
3. (NB: I missed #3-5)

Each point gets at:

• Player feeling
• Feature description
  • Drawn to life – not just a bunch of bullet points. It should express the heart of the game.
  • Or, if there’s a core new feature, then this should be spelled out clearly.
• Unique style/flavor

Example: Leisure Suit Larry

1. Funny – everything else is subordinate to this goal
2. Sexy
3. Varied

• Problem: Needed to address the game play earlier (as #1). Game play was #3 and should have been prioritized above Funny.

Wording

• Precise: Get at the heart of what the game is trying to do. Should not use jargon or inside references.
• Concise: Boil it down to as few words as possible so it can be easily digested and remembered.
• Positive: Say what the game IS, not what the game ISN’T.
• Evocative: “Crush your enemies” was a great example of something that evokes the feeling the Conan team was going for.

List Carefully

• Small is good. 3-5 is ideal. Only include the things you CANNOT do without.
• Prioritize the list. Order matters. Know which ones are more important than the others.
• Start with the core experience of the game. What does the player actually do?

Weak Visions

• Hard to interpret: Corporate doublespeak… “Good”, “Mass Market”, “Awesome”, etc.
• Don’t list things all games must do… No bugs, fun, beautiful, positioning.

Example: Hunter the Reckoning

1. “It’s fun to kill things” (too broad and vague)
2. “Want to push the graphics beyond what others are doing” (this is OK because it acknowledges that although graphics are important, it was subservient to goal #1. Combat trumped Art)

Once you have a good Vision Statement, you will need to expand it in order to help explain your vision statement to others:

• Use cases
• Prototypes
• Concept art
• Negative examples
• Competitor products (use specific examples of HOW you’re similar and different)
• Inspirations for flavor. Give a sense of a game that words can’t convey.

Applied Vision: What do you DO with the vision?

• Spread it around.
  • Everyone needs to know it and understand it.
  • Kickoff meeting
  • Show to newbs to the team
  • More than a doc. Not just a link to a wiki. Sit down and talk to them about it. Walk them through it. Especially important to make sure publisher (esp. marketing) are on board. Address misconceptions early on.
  • Keep it visible.
    • Post it on a wall.
    • Reprint in key docs.
    • Creative Spreading (t-shirts, contests, songs, load screens, etc)
      • NB: USEFUL spreading is the key.
  • Application is better than display: Cite the vision statement when making decisions.
• Use it as a filter
  • Assess all major decisions through it… But also all minor decisions, too.
  • Get everyone into that habit.
• Argument Ender
  • It’s often easy to avoid discussions of feasibility vs. fun if you check first whether it fits the vision. You can cull ideas outside the vision before wasting time discussing them.
• Kill Feature Creep
  • Kill ideas politely if they’re not consistent with vision
  • Example: Hunter: The Reckoning. We killed off all RPG elements early on as not part of our game. This let us focus more on the core parts of action combat
• Better Solutions
  • Quickly choose between equally valid paths.
  • Great for Agile development. You iterate to a goal. This helps you decide what should be a part of the next iteration.
• Remove Petrification
  • Gives you a means to reassess and kill ideas.
  • Remove the “sacredness” from sacred cows.
  • Example: Hunter AI. Tried something cool but very complex. It caused a bunch of schedule concerns. Once we got a feel for the combat, we realized we didn’t need the complexity to support the original goal of fun combat.
• Relationship Helper
  • Justify decisions to your publisher (if your publisher is bought in). Remind them that they agreed to the vision so that they can understand your decisions better.
• One Team, One Vision
  • Makes manpower growth/changes easier. Vision lives on and is shared beyond changes in people.
  • Get outsourcers on board quicker.
• Empower the Team
  • People can resolve conflicts alone. They can make better local decisions under time constraints by having a useful decision matrix.
• Thinking Teams
  • More of a mindset than a checklist. Get people thinking about the “Why” questions along the way.

Use it or Lose it

• Applied in these ways, vision can help.
• But if you don’t apply it, don’t bother going through the process.

Micro Vision: Applying Vision to Everything…

• Smaller visions (individual content).
  • When – before detailed designs or prototypes
  • Who – people in the trenches
  • How – meetings and documents
  • Smaller list (not necessarily 3-5 items)

Some examples:

• Variant Visions
  • Not all are like the game vision
  • Focus on the right questions
  • In other words, how do we justify this specific piece of content’s existence in the game
• System Visions
  • Holistic design. Example: Checkpoint System “The goal is to get the player back quickly after death” which can then guide design (frequent saves) and development (load times need to be fast).
  • Enemy/Challenge Design: Player perspective. The flow of content guides the player to different experiences. Example: “The purpose of the Cave Ape is to force player to learn dodge”.
    • Of course, if enemy design wanders, you know what action to take:
      • Either fix enemy so that it does work right
      • Or, find another enemy to teach with
      • Or, cut the feature (dodge)
• Power/Ability Vision
  • Aspirations “why is this gun awesome?” Focus less on the spreadsheet and convey powers in meaningful ways.
  • This also suggests dependencies: If purpose of machine gun is to mow down weak enemies, then provide levels that allow this.

Conclusion: Vision Benefits

• Communication
• Arguments
• Thinking
• Believing

Thinking teams make great games!

Tom Smith: tom.smith@thq.com

Questions:

• What if sequel? Do you still need a vision statement?
  • Want to focus on what will make the new version stand out.
  • But you also need to refer back to previous version Vision
• Is going through vision statement team-wide once per month a good thing?
  • Not sure if the repetitiveness is always a good thing. Depends on culture of the company.
• Localization: Are there issues when you translate them to teams in other countries?
  • Haven’t dealt with that issue a lot. In that case, it would be a challenge. Would take good translation and oversight of both groups.
• What would you do about people who think it’s too “touchy feely”?
  • Give some actual evidence that it has concrete use cases.
  • Reduce amount of wishy-washy language in the vision statement.
• What are conditions where you see vision changing during preproduction?
  • Obviously if you didn’t get it right, then you may need to change it.
  • If you are doing a lot of early prototyping, then you might need to know what the core fun is before you can build a meaningful vision
  • “Bad” cases: Direction from the publisher is changing might require revisions.
• Comment: Additional functionality – it serves as a benchmark for completeness. The functionality isn’t enough. The goal needs to be reached before you check it off.
  • On the publisher side I can evaluate the milestone based on the vision statement and see whether they hit their goal.
• How do you keep people from getting out of control when they come up with new ideas for features that are outside the vision?
  • Vision needs to be locked down. Need to encourage a more formal review process to try and settle down this kind of thing.
• How do you see intersection of vision and scope?
  • Vision sets the conceptual scope, but not the time scope. There are lots of ways to achieve the vision independent of time and budget scope.
• Communicating to outsourcers? How do you make this relevant to them?
  • Are they just completing a task? Not as important.
  • If there’s a long term relationship, then it’s more important to get their buy-in on vision.
• Microvision: Do you have meetings to scope features?
  • If it’s big (like combat system) then you might want to have a multiple point vision generated by multiple stakeholders.
  • Depends also on size of team.
• Comment: “The Giant Monkey is Not Making Me Die…” had to be the best quote from the talk.
  • The audience seemed to agree :)

Speaker: Curtis Creamer, Senior Producer at Bungie

User testing:

• Driving force for quality
• Pillar for defining milestones

What is it?

• Usability test:
  • Individual participant. Given a focused set of tasks to complete. Unbiased way of figuring out what participant is doing and thinking. The participant talks out loud as they go.
  • Observational data is videotaped (controls and on screen) and what they’re thinking while playing
• Playtest:
  • 16-48 all at same time. Primarily focuses on first hour of game play.
  • Measurement data: Behavioral data of actual game play and survey data. No interaction with participants while they’re playing
• Extended Playtest
  • 4-8 hours, but can be an entire weekend.
  • Measurement data: Behavioral and survey data. Allows you to test deeper and focus on broader issues.
• NOT a focus-group test:
  • No discussion amongst participants. These are more useful for generating ideas – but less useful for evaluating playability and enjoyability of game play.

Example: Video from Halo 1

• Shows player being confused as to where he needs to go. You can hear participant saying he’s confused.
• Next player shows the fix: Giant explosion to let player know this is not the way. Added some decals and text labels.

Why do it?

• Valuable tool to make a high quality experience
• Helps make game more accessible to broader group
• Why not just do friend/internal playtesting?
  • Game developers aren’t “typical” of the normal gamer.
  • Feedback will be skewed towards gameplay that professional gamers like.
  • Data can be gathered and analyzed quickly
  • The key is that you get unbiased feedback from people who aren’t on your team already.
  • We, as developers, can quickly identify issues users are having so we can quickly address and fix them.
  • Within 24-48 hours you can get a lot of data to sift through and act on.

What can you User-test?

• UI (game shell, setting screen, etc)
• Campaigns/Multiplayer
• The entire experience!
• KEY: Get critical facets of game in representative state as early as possible so you can ITERATE multiple times.

Getting the result: What Bungie gets from Microsoft Games User Research

• Written report with analysis and recommendations
• Video of participants’ play
• In-person debrief with designers
• Data visualization: This was really cool in Halo3.
• Progression map showing where participants went when they tried to complete a level.
• You can see where players are getting stuck and unable to tell what to do next.
• Once able to see where people get stuck, then you can go in and fix it!
• Comparisons over time are also possible. You can validate your fixes and make sure they worked (or didn’t work).
• You can tell if you have broken the experience with later fixes – or made it better.
  • Example: AI bug where enemies shifted to legendary by mistake. Whooops :)
• Discover how players experience the world — do they get too distracted by less important content? The example is a beautiful scenic view that was supposed to look cool, but not have players drive to their death or get stuck there not knowing what to do next.
• The COOL part was that you can click on the player death data and see related video. A very powerful validation tool to help understand the WHY players are getting stuck or doing something idiosyncratic.
• Also link behavioral data with survey data: You can tell how frustrated players are when they’re dying and help figure out design solution.

Why designers benefit?

• A way to verify the design is working and fun. A way to ensure the approachability, understandability and playability of game.
• Gamers evaluate and Designers revise based on their observations and understanding of the core issues.
• Designers can’t hide from the cold hard data… When players say “I’d quit” or die over and over again, it’s hard to ignore.
• You’re going to find it out – it’s a matter of when (before ship when you can fix it, or post launch when it’s too late).

Why producers benefit?

• Helps design team make better informed decisions: Generates lots of data quickly and cheaply.
• Identify issues earlier and have more time to react.
  • Example: Control scheme on Halo 1. The User Research group did a competitive usability analysis on another title and our designers were able to apply those findings to their own work. It gave us a great head start on our own work.
• Metrics for your “bar”
  • # hours of game play
  • What point of game are users likely to stop playing
  • How fun the experience is. How likely to purchase/recommend the game
  • You can make comparisons across time and across competitor products – or across different types of gamer (hard core vs. more casual)
• Great way to tell whether you’re making progress.
  • Which designers are making the most impact? Should we move them around? Helps direct design management in assessing work and needs for the game.
• Example; Campaign Metrics – Across Playtests
  • Survey data collected after playing a level (fun, challenge, combat, goal clarity, story comprehension, pace).
  • You can see the ups and over time to see how your design changes have improved.
• Example: Projected Game Length
  • We had high aspirations for the number of levels we wanted to create. But, we didn’t have enough time to make all of them. We could cut a level with confidence because we knew that we had already hit the length-of-game bar.
• Example: Campaign Metrics – Across Entire Game
  • Can see where the strong and weak points of the game are and make sure you focus your polish/balance efforts on the weakest parts.

Producing User-tests

• Been doing it since Halo1. We build milestone plans around user-testing.
  • 1st Playable – Basic mechanics
  • 2nd Playable – Iteration on basic mechanics + new features
  • 1st Playtest – Representative experience (didn’t have all the missions done, but had 2-3 of them that were playable end-to-end).
  • Nth Playtest – Iteration on experience (polish and balance and fix usability issues).
• Building in time for iteration
  • Will challenge your perceptions of what is fun – you need to decide how you will react to testable designs that aren’t fun?
  • You need to block out time to fix the things that are impeding fun.
• Costs:
  • It’s free with Microsoft – if you publish with them :)
  • It’s small in comparison to your overall budget.
  • It’s an investment – but you can start small.
  • Getting the build together: One of the toughest challenges
  • • It doesn’t have to be pretty (can have placeholder art, animations, audio). We started using some text-to-speech programs to get voices in the game early.
    • Design must function as intended.
    • It takes time and effort. It’s like a mini-release cycle. It needs to be stabilized, tested, and show stopping bugs need to be fixed.
    • BUT: It’s good for the team. Everyone works together to get a playable and evaluable build.

How often?

• As often as you can – but not too often
  • Need to balance ability to create a build and then react to it.
  • Halo 3: Started early and did a ton
  • • 1st test: 2005; Release in Nov 2007. We did them throughout the life cycle – from prototype to finish
    • We did something like 47 tests… For Halo 1 we did 7 or 7. Halo 2 we did 20-25.
    • It really motivated the team to get the game into a fully playable shape as soon as possible. Users could play the entire game early on which gave us 4.5 months to iterate on design of entire game.
  • But, you can’t run them too close together because you need to:
    • Receive data and report
    • Analyze data and plan fixes
    • Get fixes done
    • Get build ready for next test
    • This is on top of all the other stuff that goes in when making a game.
    • Every 3 weeks or so was the sweet spot for Halo3

Invest to get the best data

• Under the hood: Datamining system. Constructed during Halo 2: We added online multiplayer and we wanted to make sure we could understand how the system was working. The user research guys figured out a great way to leverage these tools and add functionality to yield better data.
• Leveraged existing debugging infrastructure to pop up survey questions at specific times and events.
• Used Tableau: A software tool to visualize the data in cool and powerful ways. This ended up working out really well.

Designer Anecdotes:

• Improved accessibility and reduced the punishment associated with some other games in the genre
• It’s painful to watch – why aren’t they reading the text. If they can’t figure out how to have fun on their own…

Is it worth it?

• Game rankings scores have increased over time.
• Bungie credits the MS User-research team highly. Probably the best relationship they had with MS
• Bungie will NEVER work again without some form of user testing

Resources:

MGS User Research:

• www.mgsuserresearch.com
• John Hopson: Upcoming presentation at GDC

Vendors:

• Bill Fulton, Ronin User Experience (www.roninux.com)

Data Analysis and Visualization

• Tableau Software (www.tableausoftware.com)

Questions:

• Comment: It’s also good for morale when data reveal that the designers have fixed a problem.
• Question: Does Bungie ever change engineering aspects of the game to make collecting data easier?
  • Most of the work that we did on data mining system went in during Halo2. We updated it as we added new features and content.
• How many iterations do you usually go through on a map? How early do you have a full alpha walkthrough to test difficulty and flow?
  • Halo 3 we focused on first few missions because we think they’re so important. We started on those in the beginning of 2006. Probably 12 or more iterations on the most important ones.
  • Halo 3 was fully playable end-to-end 4.5 months before ship. Probably did 7 playtests at this point.
• Where do you find your playtest subjects?
  • MGS User Research owns the database. They’re all Puget Sound, but are trying to expand outside the Puget Sound area. Vendors are available in every market to provide good gamers.
• How do you handle user bias like “this is the best weapons ever” even when we know it isn’t true?
  • One of the awesome things about the data: Data don’t generally yield these kinds of results. Usually you see a wide spectrum of responses. Overall you can get an unbiased look.
  • We look at the subjects first (loyal fans vs. new to the genre vs. previous Halo players) to understand biases.
• What’s most effective testing on HUD elements?
  • Primarily from usability testing: Talking out loud one player at a time. After the player has played for a while you ask them to explain all of the elements.
• How do you use metrics for multiplayer?
  • We did a ton of this. Read the Wired article from last year for more details.
  • We tried to understand map balance. With all of the data points we could generate a heat map of deaths so we could tell whether the maps were balanced or not.
• When decide on profile, does going outside of target profile water down the design?
  • No. you’re not trying to change design so that newb can play it – it’s about making the core design more accessible to the newb
• Where do you do testing? Any cultural differences?
  • All done in Seattle area
• You mentioned the one hour playtest vs. longer play sessions. How quickly could you iterate through extended game play sessions?
  • We ran 16 extended sessions and 11 shorter ones.
  • Generally they ranged from 16-48 people.
• Seems onerous to sit in a playability lab for 16 hours over a weekend. How does that affect fun ratings?
  • Drop out rate for Halo 3 was much lower than for Halo 2. Much higher percentage of people who went through entire game before checking out features.
• Is there any desire to try and shift the curve to the left – trying to get some earlier feedback on things.
  • This already represents a commitment to earlier focus on usability and playtest. Halo 2 was much more skewed to the right.
  • We put prototype work in front of users in Halo 3.
• What, in general, is your production methodology?
  • We did more Sprint mentality towards the end of the project. This integrated effectively with user-testing passes.

Keynote Panel – Studio Heads on the Hotseat
Speakers:
•    Jen MacLean – Chair, IGDA Board of Directors (moderator)
•    Dr. Mike Capps – President, Epic Games
•    Brett Close – President and CEO, 38 Studios
•    Tobi Saulnier – CEO, 1st Playable Productions
•    Tim Train – Studio General Manager, Big Huge Games

They originally came up with this panel at a discussion at DICE.  They were chatting about feedback about the 1st Leadership Forum, and it would’ve been nice to get some really honest stories and info about what it’s like running studios.

Studio Culture

Tim: The culture all started with the name of the company.  The basic reason behind why a culture is important is because it’s why people do what they do for you.  In reading these accounts about history and thinking about why do people do the things that they do in military for instance, so much of it is about the culture of the group.  Culture can make someone walk into machinegun fire on a beach, so it’s fairly important on how you can get people to make video games.

Brett: It’s sort of a self-governing culture.  It’s going to be there one way or another.  It’ll happen at your company, so if you don’t engage your people about this culture and behavior, that culture will run amok.  You have to actively engage people about it and create positive feedback loops that create a great educational and self-governing culture so that people can tackle problems when you aren’t all together.

Jen: Mike, how do you keep people excited about a project during tough times?

Mike: Epic’s culture is about perfectionism.  You can do whatever you can to keep people happy, but it doesn’t really matter unless people are excited about the quality of the products and games.  Our hiring process is  entirely built around passion and finding people who care so much about what they’re doing.  Doing whatever they can do to get themselves that invested.

Jen: Your company is not about making a profit, how does that fit into your culture?

Tobi: There are 3 types of people; people who are there for the paycheck, people who are there for the career, and people who are mission focused.  In a large company, you have to deal with all of these kinds of people.  Since I’m a mission-focused person, wouldn’t it be interested to focus on one type of game.  1st Playable from day 1 is a mission-driven culture and company.  There are some large mission-driven companies like Apple; you have to very specifically make the mission clear and obvious for people.  1st Playable has about 30 people right now, and it’s hard to tell if you’re looking for a new person who’s looking to join the team.  There are a number of different characteristics that you have to assess when hiring and adding them into your team.

Getting your company up and running

Brett: How do you fund a studio in the crappiest economy in American history? In our vision, we started a little differently; we had the initial funding from our founder and some angels.  We’re building a studio, we’re building a pipeline, we’re building a product.  In this particular economic environment, it strangely plays in our favor; the growth of the games industry is outstripping the growth of the economy.  It’s actual a shelter and a strong place to put money given the current economy.  Get revenue as quickly as you can.  It’s almost like playing an RTS; you’re building up some facilities, then you get more resources as quickly as you can, and then you build up more facilities.

Jen: Mike: I’m guessing you’re not as worried given the current economic state.

Mike: Well, we’re still worried that sales might just stop.  Normally there might be 10 hits this season, and there might only be 3 hits.  We picked up a team in Warsaw that got hit by a business crunch.  Same thing with a team out in Utah; it’s interesting about how these additions have fit into our company culture and how we can learn with each other.

Jen: Tim, your company was most recently acquired. How has that been?

Tim: We’re now a public company, so there is a lot more beurocracy.  Publishers have realized that they can’t really supplant developers and just move them around.  THQ has been really great at letting Big Huge maintain their culture.  The upside now is that they can focus on just making games.  So much of what I used to do was so draining.

Mike: If I were a studio owned by THQ, I’d be really scared since they’ve been closing studios.  You weren’t scared?

Tim: Obviously it’s a hard decision for THQ, but if they had come to us and said the whole company is hurting and we need to lay off 10%.  But since they closed other studios, it makes us feel safer since they’re basically double-downing on us.

Jen: The closings had to have freaked out your staff, right?

Tim: We told the truth as we saw it and there’s definitely a little bit of “those people died so you could make great games,” but that does lend a little more weight that, “man they really believe in us.”  I don’t feel like it freaked people out.

Work life balance

Jen: What does quality of life mean to you, Mike?

Mike: What is quality of life? That’s a good question.  How quality of life comes from doing what you love to do.  And it’s not just that, but if you’re a great character artist, not only do you get to make crazy cool characters, that art will be seen by millions of people.  We aren’t about 40 hour work weeks.  We split the profits within the company.  We kick people out at 2 AM, because that has an impact on the product.  I don’t think the 9 to 5 work style works for our industry.

Brett: We’re an anti-crunch company.  A bastard that I worked for would say, “You’re doing what you love, stop complaining.”  There are times where you’re going to need to do something for your family or take vacation and we’re going to honor that.  I firmly believe that if someone gives you enough notice, he or she shouldn’t be allowed to take time off.  If you can’t provide that for them, then it’s a problem in the culture of your company.

Mike: Question for you Brett, we like teams to crunch together, there’s a community that comes out of that.  We try to get everyone in there together.  There’s an official on-crunch switch so that they can inform their families of what’s happening.

Tim: We’ve been through a few phases of crunch.  During Age of Legends, we had a “whatever it takes to get it done,” and people got burnt out completely.  We tried to fix that over time.  I kind of disagreed with Curt’s talk yesterday which is that there’s no way sometimes to avoid crunch completely.  I’m just trying this explanation on for size, but games, as an entertainment industry is like joining a rock band.  People in rock bands don’t expect to have 40 hour work weeks.

Tobi: I think there is a poor understanding of what the long-term effects of crunching are on people and their lifestyles.

Brett; We’re exactly in the same position of dialing back, this is a marathon not a sprint, and you can’t work at this pace forever.

Tobi: People want to have an impact beyond just putting in the hours; they want to make change in their work and their communities and society.

Personal leadership

Jen: I’m curious given your role of managing an internal team and working with external partners, how do you maintain credibility?

Mike: We’re lucky that we can pick and choose publishers.  We’re brutally honest and say that when we’re working with certain people, we’ll call them on things if they do things poorly or wrong.

Tim: One of the things that has come up about internal credibility, having the belief that you’re all working together is something that means a lot people.   We have a very open door policy.

Brett: We don’t have any credibility.  Until you ship, you really don’t have any credibility.  We’re dealing with that by getting people who have delivered things in the past.  Actually show that the concepts that you’re pushing are actually really cool and that the increasing credibility bar is making it more difficult.

Jen: What do you love and hate about being a studio head?

Tobi: I’m a little bit of an idealist.  What I love is that I don’t have to listen to anyone tell me that I’m not an idealist.  I spent a lot of years having people lecture me about how being an idealist made me naïve.  What I don’t like, you end up having to make a lot of decisions without a lot of support.  You end up having to make up a lot more decisions on your own, and you know your making a lot of mistakes, and there’s no one to blame except yourself.  But there’s a payoff.

Tim: Why I do what I do, is because I love geek culture.  We all grew up watching Star Wars and playing RPGs.  I just getting the biggest kick riding up an elevator with guys in suits and guys and talk about balancing the races in our games.  What I love is creating and nurturing a support structure where the geek culture can thrive.  What I hate is that I don’t get to participate in that as much, and I can’t be friends with all the cool people in the studio.  I’m not going to get invited to all the parties.

Mike: I get invited to all the parties!

Brett: What I love is hanging out with you and drinking wine!  A lot of the same sort of stuff.  The Santa Claus sort of stuff.  I will get you any tool to make you do whatever you need to do.  I will do whatever I can do to make your lives great in this industry.  What we really want to do is facilitating that fantastic work environment.  I’ve been in other industries and it’s incredibly boring.  Incredibly smart and creative people in this industry.  It’s never fun to tell someone that they don’t fit.  By definition, there are people who won’t fit, even if they want to, and it sucks.  We’re intentionally not tied to a publisher at the moment, so I have to take on the honesty-guy role of a publisher.   It’s hard sometimes having to deliver a harsh message.

Mike: I love making people happy and I hate making them unhappy.  I love giving them an environment that can make them happy.  The cool thing about being a studio head is that we influence not just the millions of our audience, but also that hundreds of other engineers will be able to use these tools.

Jen: If you had one single piece of advice to aspiring studio heads, what would it be?

Tim: The thing that trips a lot of people up, is getting stuck too much on their idealism.  It’s different from the kind of idealism that Tobi’s talking about.  It’s about load-balancing and prioritizing.  See the big picture and understand the trade offs of what you can really accomplish.

Brett: Be consistent about what you say and what you do.  Very simply, if you aren’t straight-up with your people, they very quickly get a whiff of not really being able to trust you.  You could lie once and your credibility is basically gone.  No matter what, hold that accountability piece, setting the vision, setting the goals, and following through with what you said.

Tobi: Two possible situations; one you have some experience and want to start a studio.  Have a really clear idea about why this company is needed. For people who are just thinking that this is what I’d like to do sometime, just be a really good student.  Ask lots of questions, learn from everyone around you.  At some point, you’re going to have to have the answers.

Mike: Trust your people a lot.  They rarely let you down.  People really respect you when you trust them. Don’t be afraid to do the mean, bad stuff, 99% of the time it ends up well once I stand up and face.  No matter what, the company feels better.

Question 1: It sounds like passion is something you really need in this industry?  How do you handle someone who has lost the passion?

Mike: They’re done.   I’ve never seen someone who lost passion and got it back.

Tobi: Everyone has a sweet spot, and as a manager, you can do a lot to place that level attention on them and help them in their problems.

Tim: The most important thing is to keep an open dialogue.  Maintaining that your expectations remain where they were, but listening to them and whatever their situations might be.

Brett: Just pay them more. All things being equal, people need managers, not jobs.  It’s about how they’re being engaged.  If they’re doing the work, but has no passion, switch things up.  Put another manager on them and see what happens.

Tobi: As a small company, you have to think, this person who’s struggling could be a star someone else.  You have to help them recognize that.  If you’re constantly trying to rehabilitate that person, you’re preventing them from becoming that star player in another company.  You just have to trade them.

Question 2: I read somewhere that Jack Welch recommends laying off 5% to keep the bar up.  What’s your take, Tobi?

Tobi: I’m in the games industry because I don’t want to have to lay off people.  Corporations have to do that, but I just don’t have the stomach for it.  I’m too engaged with people.  I couldn’t be a surgeon either.

Mike: It doesn’t make sense in a small company to lay off 10% since we’ve spent so much time and money hiring the right people.

Brett: I’ve worked for some very large publishers and the mandate was 20%.  I’d say 75% of that 20% were really good people and that bottom 5% deserved to go.  That culling off the bottom, there are some places where that’s healthy. If you’re incredibly picky, you’re going to get the right people.  We’ve had very few people who have left because the company is happier, the person is happier.  We have the numbers that we need and that’s the core team that we’re sticking to right now.  There’s nothing more important than who you hire and who you fire.

Book Review Jam – quick hit book reviews given by members of the forum. Each reviewer touches on high points, key “aha” moments, applicability to games.

Reviewer: Simon Amarasingham
Title: The E Myth Revisited
Central idea is to work “on” your organization not “in” your organization,
i.e. rather than becoming critical to the day to day operations of your
company, spend your time on building/strengthening the organization.
Key Aha: Caused reviewer to confront whether he wanted to be spending most
of his time composing music or building a company.
Relevance to Game Industry: Many people get into Games industry because of
talent at some skill, e.g. programming, 3D art, music, etc. If you
subsequently find yourself in a leadership position, this book gets you to
think about whether you should be continuing to use your particular talent,
or whether you should be stepping outside of that in to focus on building
your organization.

Reviewer: Justin Berenbaum
Title: Ideavirus
Made reviewer think about disconnect between game developers and marketing.
The marketer is not and should not be the center of the message, the consumer is.
what ideas are virus worthy?
lots of game applications
dynamic ideas are virus worthy
if it is simple and smooth

Reviewer: Jason Della Rocca
Title: The Medici effect
Awesome book, best he has read this year
true breakthrough innovation happens at the intersection of diverse fields etc
key aha’s:
it’s hard for experts to be able to see problems in new ways – associative barriers such as a deep level of expertise can be a hindrance
The highest producers have the highest success and fail the most as well. Quantity leads to the rare quality idea.
Venture into unknown communities. Gaining success by bridging to other communities is useful
Applicability:
workforce diversity
specialized game dev edu hurtful to industry? We may be training particular expertise that may be limiting true innovations and breakthroughs.
Prototyping – need to fail often and fail fast, and learn from the failures.
self-referential designs limit innovation — why are we just regurgitating other game designs in our designs.

Reviewer: Mark DeLoura
Title: 4 Hour Work Week
Mentioned Mark Hutchinson’s death, and the team of retro studios finishing off Mark’s book on 3D Real Time Cameras. Look for it at GDC timeframe.
4 hour work week is a self help, not management.
xbox live points war for life. I’ve done all these interesting things, so can you. However did he find time?
Book’s full of cheap hacks.
1st part of the book, self evaluation
2nd part – techniques to start dumping stuff, like email.
3rd and 4th chapters: how can I make a business out of my dream and how can I outsourse most of it?
Last quarter of the book is the litany of resources. Here’s all the stuff I found really useful.
Applicability to games:
helps you refocus your priorities, huge amount of resources

Reviewer: Darius Kazemi
Title: Managing Humans
Book sounds like the ramblings of of a fever addled madman. Ostensibly about the task of managing, but is more about interpersonal than spreadhseet stuff. Breaks down situations. Book in 4 parts, scattershot. People skills, hiring. Managing up, book is also for software engineers or anyone who wants to understand where their managers are coming from. Taxonomies – mnemonics of patterns to recognize, such as meeting creatures, like the Big Cheese, Laptop Larry,Translator, Synthesizer. 2 different kinds of managers, organics and mechanics.  The book also contains many diversions.
Very opinionated, gives lots of specific and sometimes irrelevant examples. Meeting bullshit detector.
Applicability: helped him not hate a former co-worker.

Reviewer: Uma Menon
Title: Influence: the psychology of persuasion
Concise book, talks about weapons of influence:
Reciprocation – Hare Krishna gives a flower before asking for donation
Commitment and Consistency -
Social Proof – if everyone looks up you will too
Liking
Authority – push button experiment
Scarcity – the downloadables

Aha’s:
Influence as Science made a lot of sense to reviewr
Why do ppl say yes

Sales, Marketing, Game Design, and ppl mgmt are all applicable areas in games.
Reviewer: Robert Nyberg
Title: Thought Leadership
overview and insight into common modes of thinking. we follow paths in thought processes
Managing the thought process – group thinking
flipside versions of the 6 common methods of thinkins

Ahas:
Ways to identify the modes of thinking
eg – deficit thinking, tendency to find faults and risks. flipside is strength thinking – finding strengths instead of weaknesses.

this book is great for managing meetings and decision making at different phases during production, and helps kep meetings on track for the topic at hand. Recommended.

Reviewer: Tobi Saulnier
Title: Small Giants

Companies that choose to not follow the bigger is better rule – applies to her own company. goes against b-school conventional wisdom to focus on businesses that chose to stay small. Presents it as a valid and businesslike option.

3 AHA’s:
Why companies chose that bigger is not better, and how there’s a different path to Great.
Lots of Examples.
Shared traits includes high intimacy with locale, customers, suppliers, workers. techniques for dealing with these relationships.
The leaders of these companies have the characteristic of turning down advice quite a bit

applicability: new industries need balance to make a healthy long term profession,
Alternate view of bigger is better

Reviewer: Tobi Saulnier
Title: Strategy Pure and Simple II

Using elements of strategy to dominate the marketplace. Highly recommended as a strategy book. this falls in the middle between too simplistic aphorisms and dense b-school reading. Digestible but rigorous.
aha’s:
Control the sandbox – successful strategy allows you to choose and influence your competition. When you’re the industry leader, you can influence the competition.
how strategic thinking is not the same as long range planning. w examples. Good level of detail. Do them in parallel and don’t confuse the two.
The idea of knowing/shoosing your companies driving force and how that impacts strategies. What is your company’s strategic drive? product driven versus tech driven versus user driven versus capacity driven. Different approaches for each.
Applicability:
strategy little used in games.
one stop reference for ppl new to strategy

Jessica Tams recommends Good to Great, changed her view of self, company. Also recommends First, break all the rules.

Scott recommends Awake at Work.

Respectfully submitted,
Robin McShaffry
www.mary-margaret.com

Session: Training as a Productivity Multiplier

Speaker: Andrew Oliver, CTO, Blitz Games Studios

Training and the games industries. The bigger organizations do have training in place. Smaller, independent companies do not have as much formal training available.

Why bother training?

Industry is maturing

Training is a productivity multiplier

Investing in your people is protecting your biggest investment.

Sources for training:

External

In-house

Conferences – managers and leads get to attend, but programmers, artists, and designers doing line work, not as much.

Look for convergent skills. Some film industry experts have applicable skills, for example.

Hard & Soft skills. Hard skills – content creation. modeling / unit testing / level design. Soft Skills – communication and management

Teamwork is key.

Train your trainers: Training is a skill itself. Send your talent to presentation / facilitation classes so they can communicate/train most effectively.

Andrew then discussed the various art, code, and design disciplines and suggestions for gathering / delivering training for each of them.

Building a solution. Firstly, he says we need commitment from EVERYONE. Logistics can be challenging with schedules. His company has someone in HR who coordinates the sessions and attendance is higher.

Identifying needs and trainers. Project requirements and personal reviews. Train for game generation changes and look to your gurus.

When it comes to delivering training, there are different learning methods. There is instructor-lead training, asynchronous online or more local e-learning modules, and lastly one-on-one training.

Training loop – identify training need.

- Prepare / create modules.

- Deliver modules (moderate the 1^st time)

- Assess module results and feedback.

Costs.

- External training is more expensive. Inform your trainer an accurate audience analysis. It will be more effective if they know the knowledge level and culture of their audience.

- Bespoke training is vital to success.

- They used a combination of internal and external training.

- External training cost $2000/day.

- They spent around $7.30/day per person for training.

- Maya slick tips and tricks training example yielded a 22% productivity increase after training.

What didn’t work? Starting the training program before it was ready. Overestimating people’s ability to teach. Using dev staff to coordinate and organize training. Attendance “last minute” drop out rates. Assuming all disciplines would be the same.

Training metrics. Justifying the costs of training. Training ROI. The better trained your staff, the less staff you need and the less management they need, which keeps overhead down. Helps prevent staff from ballooning. There are 6 measures of training provision: 1. Effective – pre and post test comparison, 2. Efficient – re-use of the modules. 3. Applicable – aligned to company objectives. 4. Appropriate- right modules to the right people. Timely – just-in time training (not too soon). This has lead to improved efficiency and productivity, tracked through schedules. Better communication and team cohesion is another tangible benefit they have observed, as well as improved morale – all resulting in better games.

Other benefits are a stronger team structure and better risk management. Training mitigates risk, and leads to taking positive risks.

Note – want to avoid negative training.

Deliver the right training to the right people at the right time.

“These are things you can do to augment your success” – Rodney says you have to have a well running studio first. And I know he does have one – as an aside I’m always curious about how Rodney finds the time to involve himself in everything he does.

On Why – Amaze wants to create a unique environment in which his employees can be creative. He also wants to give back to the community – after all he gets paid to make games.

Rodney observes that doing works in the community (like his annual Big Brothers / Big Sisters Bowling Fundraiser) – his company gets greater visibility, improved recruiting, better QoL, create leadership opportunities to represent the company in classrooms, or in industry events like GDC, the development community itself is strengthened.

He showed a funny slide with the old Wonder Twins – and he talked about how these efforts can create interesting and unforeseen relationships with other organizations and individuals.

Rodney then went into some things are going on in Austin, Texas – where Fizz Factor is located. Fizz was started in Rodney’s living room with four people. They were founded at the same time as Digital Anvil, Edge of Reality, Inevitable, and other companies that were the insane AAA sexy titles, and were recruiting aggressively. Rodney’s company was doing a cute little horsey title – it was a little hard to compete.

So they did what anyone would do in that circumstance – they dressed up in Elvis costumes and went bowling – specifically for Big Brothers / Big Sisters of Central Texas. This grew and grew over the years, and employees would come to Amaze specifically because of their community works.

Rodney was contacted by a group who wanted to create the Digital Media Council, who was interested in doing workforce development for digital media industries – and they specifically wanted involvement from the games industry. This grew into teaching teachers – who could then pass this knowledge onto 100’s or 1000’s of students per year. Teachers had no idea how to address student’s questions about what skills they needed to get into the games industry.

This community work, Rodney found, had a positive effect on his employees morale – when they talked to students, they would come back feeling like rock stars! They got asked for autographs, and truly felt like the special people they always were – but sometimes hard to see after a few hard months of crunch.

Another program, Velocity Prep – tries to find ways to get high school students involved in professional workspaces. They started with chip manufacturers like AMD, and then got interested in the gaming industry. They did this in an interesting way – groups of these students were placed in a professional environment, office space and everything – and were asked to solve a real world problem. They were under the same kind of management supervision anyone would be under. One project was to create a marketing program for the Austin City Limits Music festival. When they are done they present their work to a group of industry professionals who judge their progress and give feedback. In one case – the kids came up with exactly the same conclusions as highly paid industry consultants!

A survey was done to find the economic impact of digital media – which found over 19,000 jobs and what their salaries were and even what their environmental and cultural impact of digital media in the central Texas area. It was much larger than anyone expected.

Rodney says game companies usually don’t want to involve themselves in this kind of activity – for many reasons – Austin was lucky to have a Chamber of Commerce that “got” the games industry, and helped energize relationships between local government and games industry professionals.

In one case – the Capital Area Workforce Solution organized SCRUM classes for local Austin game studios, which cost $30,000 for a two day class for 30 people, but this government program covered the complete costs of the program.

On the education side – once the economic impact study was distributed, local universities like UT, Texas State University in San Marcos, and St. Ed’s University became much more interested in creating programs that directly benefited game industry early professional development.

Rodney mentioned all the things that came from the State of Texas – both good and bad. He talked about Rick Perry, famed for the “Adios Mofo” comment while a mic was still on – and also the guy that did an E3 keynote about bringing game industry jobs to Texas. This was mostly due to the efforts of the Texas Motion Picture Alliance – who is also interested in games as well as film. Now, game companies can get back 5% of their development budget from any production dollars spent in Texas. Most states in the US have similar programs for film, and many have it for games.

Rodney – “Films are easy – since they are in trucks and can drive wherever the money is – with games it is a little trickier….but the wind is at our backs.”

Barack Obama is going to have a national CTO – who said that “Technology is usually a spoke in the wheel – now it is the hub.” Even Sandra Day O’Connor, just retired from the US Supreme Court, is making a video game. Math and science scores are way down – but kids are really interested in video games – Rodney observes they are a great carrot to motivate kids to study these subjects.

Rodney opened up the floor to questions and comments – and there were a few people around the country, Boston, for example, that have community outreach programs. In one case, all the game companies got together and created little booths to display what they were working on, and invited government officials over to show them what was happening. They were surprised to see the impact, and got an advocate to push for legislation to benefit the games industry.

Session: Level of Detail for Project Planning

Speaker: Mat Hart, Head of Production, Ninja Theory

Presentation is designed to be nuts and bolts rather than high-level theory.

Planning.

What’s the purpose of a Project Plan?

1. Reduce risk. Allows you to manage your risks. Front load and cut them early.
2. Reduces uncertainty. Allows you to build in time for prototyping.
3. Supports good decision making. A good decision is picking one of many options with info to help you.
4. Establishes trust. Stakeholders like to know what’s going on.
5. Conveys information, communicates.

How much detail?

1. Too much – granularity to 2-hour increments. Way too much time spent updating managing the schedule rather than doing the work.
2. Too little – Doesn’t inform the people who are doing the work what is to be accomplished in real time.
3. Just right – takes practice to pin down. 1-5 days usually.

Three Levels of Planning

1. Low-level. Deliverable centric, task-driven.
2. Medium. Phase centric, deliverable-driven.
3. High level. Project centric, driven by phase milestones.

You will want a high to low-level approach. Don’t expect the first pass at the schedule to be accurate, but it’s still a good exercise that will help you get to the actual schedule.

Stakeholders.

Who do you think they are? Who’s working on your project and who needs to know about what’s going on with your project.

Stakeholder analysis is a straightforward way to dissect who needs what information at what point.

General list:

@Publisher: Executive, production, pr/marketing, specialists,

@Developer: Executives, production mgmt, and team

@Other: Customer, Press/Media

What should we know about them?

None of these: perceptions of the project, emotions, constraints, nor Project engagement.

Keep it broad:

Who are they?

What do they do?

How do you get in contact with them?

How much power do they have to affect the project constraints?

How much interest do they have to the effect the project constraints?

How do we build a schedule that satisfies their varying needs?

Break into phases then treat each phase as a mini-project.

Each phase has a goal (may be theoretical.) Define the Phase goals in practice:

1. Project Goals

2. Design Docs

3. Feature List (medium level of detail)

4. Define quality for each feature..

5. Generate success (or exit) criteria. This the goal used in managing expectations.

6. Generating work estimates.

Keep the plan going after it’s established. The producers and leads are supported by a distributed schedule and it’s maintained on an ongoing basis. All tasks are either done or not done, there’s no percentage complete. Producers review daily. Head of production reviews in depth weekly.

<Examples of how MS Project has been used on Mat’s projects>

Topic: Leadership in Conflict:

Speaker: Kane Minkus

Where does conflict come from?

- Different “maps” of reality

- Attention is on answering a different question

- Different levels of experience

- Different belief systems

The Real Essence of Conflict.

- (Audience volunteers these: Competition, different needs, fear, survival, trust)

- Safety. Guarding our belief systems and what we experience to be right from wrong.

- Love/Belonging. To our family system, to own ecological system.

We don’t separate away from these when we go to work, and we will do anything to keep these stabilized.

In A Conflict.

- Defense of Belief.

- Focusing on the gap (what are the concerns? What is right now v. what would you like? Everything else is focusing on the gap.) Focusing on the strategy to get to where we want? What happens when you focus on the gap (concerns), the gap widens.

- Arguing with the example?

From Challenging to Listening

In a conflict, we are often challenging rather than listening.

Resolving Conflict.

- Rapport (especially deep rapport) is how we know we are safe with each other. Two processes are in place: Are we safe? What is the quality of our life? Literally gives the brain the signal that “we are alike.”

o Physical – Getting to the same body language with the other person

o Vocal – Tempo, pitch, tone of the other person speaking.

o Keyword Backtracking – Using back keywords that the other person just said.

o Breathing -

- Discovering the IPO

All behavior has a positive intention.  IPO = Intended Positive Outcome.

People are always doing the best they can.

The workshop’s focus was the systematizing of problem-solving. Michael’s initial slides demonstrated his process for solving problems: Identify the problem, gather information, identify possible solutions, implement a plan, follow-up/ evaluate/ adapt. He pointed out that it’s exactly the same as the scientific method that we all learn in school, just using different terminology.

Michael pointed out that in management, we often focus on decision-making instead of problem-solving. Decision making should instead be a later step in the process, otherwise you make uninformed (read: bad) decisions.

Perhaps one of the reasons we don’t associate the scientific method with what we do is its association with an individual solving complex problems in isolation: the context doesn’t make sense for us. The second part of Michaels’ talk focused on rerouting the scientific method toward teams. Just as there is a spiral of hypothesis and testing, there’s a cycle of taking knowledge on a team from tacit to explicit and back.

Tacit knowledge is resident in individuals, whereas explicit knowledge is defined as external data: books, models, etc. Michael presented a matrix of information flow from tacit to explicit.

When tacit knowledge is in stasis, it looks like collaboration without words: working together, not talking about working. Learning by doing. Apprenticeship. This is when you’re in the flow, ploughing through work.

Tacit knowledge goes explicit as Externalization. This is talking about our perspectives of a problem space, listen to other people’s perspectives to think about how those perspectives could fit into your own. This is where you’re vulnerable and open to being wrong. Instead think about the externalization of ideas as pushing them away from yourself, giving them their own life separated from the individual (it’s really safer this way!)

When explicit knowledge is in stasis, it’s identified as Combination. Creating systemic knowledge through systemizing of ideas, exploring hypotheses. Playing with models.

Explicit knowledge becomes tacit as Internalization. This is converting external ideas back into personal experience. Creating “muscle memory,” that annoying corporate buzzword that is nonetheless critical to a team’s tight functioning together. This is the ability to learn as a group. Value adds with keeping groups together (separating teams breaks up this “muscle memory” and the cycle must start over.

Michael then explained Value Stream Maps. These are a way of diagramming the process from the generation of an idea to realizing its value, whether that’s implementing a feature to 1.0 or getting a newly-hired employee to the point of a fully-functional team member. He pointed out later that we as humans totally suck at understanding time, which is why we’re obsessed with it. The point of a value stream map is to calculate the efficiency in the process and to identify where the inefficiencies are.

We then broke up into groups to create a value stream map for any product we wished. Our group (all developers) chose feature development, from getting the idea on the backlog, through its approval, work, and sign-off. We realized that some delays between steps were HIGHLY variable, anywhere from 2 days to 14 months in one case.

When there is a delay, it’s necessary to identify the root cause of that delay. Do this by asking “why” over and over. This is almost never a single person, it’s always the system that’s broken, and as managers, we’re responsible for that system.

Once you understand the root cause, you can draw the system as a diagram, showing how the root cause leads to the initial problem you were trying to solve. Each person has a perspective on the system, it’s necessary to see several perspectives to understand the system as a whole . Systems feed back either positively or negatively; there are often external motivators to the system. There are delays between a lot of steps. I believe he was implying that delays between steps often muddle our perception of the causality between those steps.

The familiar example he illustrated was crunch. The unrealistic ship date is the external motivator to the system. There’s a delay between the threat of being perceived as undercommitted and actually increasing working hours, which is how crunch can sneak up on you.

Michael’s parting message was that predictability doesn’t come from predictions or plans. It comes from your organization’s ability to adapt to the change that hits. Understanding how to rapidly change comes from understanding your system.

WHo is Mr. Mike? – Career started at Origin in the early-90′s working on the Ultima series, until Ultima Online.  Then founded his own studio where he made Magnadoodle and some games for Microsoft.  Then Ion Strom and then Breakaway Games doing Serious Games.  Wrote “Game Coding Complete” which is in its 3rd edition. Now working at Red Fly Studios where he did Mushroom Men.

Caveats -

• I don’t have the answers, just some wacky ideas
• I’m not trying to dreail anyone’s deal (especially Red Fly’s)

About Mushroom Men – 8 Reasons it should never have been signed or shipped

• Red Fly had no developers – they had to hire everyone (Previously they had just been an art outsourcing studio)
• They had no tech of their own
• They never developed on the Wii before
• It was an original IP for a Xmas 08 release
• It was a multiplatform, worldwide game from a developer that had never made a game before\
• The management team had never worked together.
• They signed a second project during mid-development, which is usually the death-knell for a small studio
• The second project was ALSO cross-platform

Most developers are too risk-averse to sign this kind of project.  Thanks and kudos to Gamecock for making it happen.

Why did this game succeed where others have failed? – The game had a good sould.  The teck risk was low.  But, most importantly, Gamecock was extraordinarily hands-off.  Thanks to the other things, this worked out.

So, how can we increase the chances of this happening again?

Mike asked a lot of people for input on this subject and got lots of feedback, but no one was comfortable being identified publicly.

Question: Are you happy with the way we do business?

Responses: Publishers, lawyers, and agents are generally happy, but developers are generally unhappy.  This is a problem. I’m not talking about the huge, successful developers.  I’m talking about aspiring developers, who are the source of fantastic new ideas.  These are companies like Harmonix, 5 years ago, who have the ideas that eventually turn into billion-dollar franchises.  However, many of them just do a project and then go out of business (Mr. Mike has already had 2 that fit that descriptions).

There are basically 2 major areas where this unhappiness comes from:

• Contract Terms
• Milestone Madness

Also, many small developers can’t say “no” to requests from the publisher, even if it hurts the game.  It is inevitable that publishers will make these kinds of requests.  The issue is how the conversation on the subject is had and how the decisions are reached.

As people get screwed over they add language to their contracts to protect themselves, such as “developer warrants that blah blah blah blah is true throughout the Universe.” (Someone points out that this is in every Disney contract and has its roots in the movie industry).  This is because attorneys are paid to protect their clients’ interests, not to create “fair agreements.”  That is up to the people negotiating the deals.  It is up to “you” (the non-lawyers) to decide to take the risks and which risks to take, but remember that risk isn’t inherently bad and it a necessity.

Another issue is that publisher contracts tend to start out extremely biased in favor of the publisher.  The developer then must fight tooth and nail to claw their way back to something fair.  “I challenge everyone to stop playing these games.  The only ones that win are our hourly paid attorneys.  Wouldn’t it be nice to create a standard contract?”  Think about the real estate industry.  Home purchase contracts are standardized.  You just fill-in the blanks.  This speeds-up business and saves money.  (Someone points out that UK company Tiga have created an industry-standard contract, but that it’s not used much).

(Mike shows a fairly standard-looking milestone schedule).  “These are negotiated.”  Then, what happens is that occassionally the publisher rejects a  milestone.  This puts the “aspiring developer” in a very awkward position because they are often immediately “up against a wall.”  They stop thinking about the problems with the milestone and how to solve them and then they start thinking about how to make payroll because if they can’t make payroll the employees will quit and then everyone loses.  This is a fundamental problem and Mr. Mike proposes a small tweak to the contracts to address these issues.

Mike proposes that, in addition to a milestone schedule, a separate payment schedule be created that is not directly related to the milestone schedule.  This is not a big difference, but it will create a “fundamental difference in the relationship.”  This means that finance and legal are no separate from product development.  This dramatically reduces developer stress and means that when money issues arise they do not have to be resolved by Producers, but by business people.

What is the motivation for publishers to do this?  Developers need to provide something to make it worth the publisher’s while.  Developers need to provide estimates that are not padded.

Anecdote: Mr Mike: “Why are internal games usually better than 3rd party games?” Mr Mike’s publisher friend: “Because there is 100% transparency of the production process.”

I believe that this wil have a drastic impact on the quality and predictability of the games that we are creating.  i challenge everyone to think hard about how to make this happen.

Panel discussion featuring Tom Buscaglia, The Game Attorney (Moderator); Martin de Ronde, Director, OneBigGame; Robert Khoo, President of Operations and Business Development, Penny Arcade; Shonda Schilling, Founder, The Shade Foundation of America.

Martin has been involved in charitable work for ten years, starting with creating a second-life style environment for kids in hospital to interact with each other in. He expressed disappointment that the games industry, whilst very big, gives back in a charitable way only very little.

Robert Khoo talked to the Penny Arcade effect, where they have a large audience (3.5 million gamers) which they can direct towards an endeavour relatively of their choosing. Instead of using this power for evil, they elected to use it for good… They started off with a donation and asked people to contribute and were blown away by the level of commitment from their fanbase. This is now an annual thing, raising over $4m so far to 60+ hospitals

Rhonda, Curt Schilling’s wife, got involved with ALS in order to help educate and raise awareness and money to help cure this disorder. Shonda herself was diagnosed with malignant melanoma and found that there was no real support groups or organizations to help her or others like her. For Shonda, she’s in this because she cares. It’s not just about the Schilling name, it’s about helping human beings.

Martin’s OneBigGame is a not-for-profit videogame publisher, challenging developers to take time out and make a small game which they will then publish and the profits from the sale of that game will go to charity. The response to this idea has been huge – lots of people want to get on board, which has lead to its own challenges – particularly when growing the organization. Another issue has been where developers find they need to focus on their day job so development on these titles can stall from time to time.

Robert talked about how the relationship between PA and Child’s Play is entirely one-way; there’s no links back to PA from child’s play, no pictures of gabe or tycho, no posts from them. They drive traffic from PA to child’s play but not the other way around.

Shonda talked to the fact that it can be difficult to get the message across, with people having difficulty understanding the real purpose – which is always to help people, despite what people might think. To avoid this, keeping a focus yourself on what you do and why you do it will help you. What you do for yourself dies with you, while what you do for others lives on.

Martin talked about some interesting resistance from the potential beneficiaries of his profits, with charities not necessarily wanting to be related to the games industry which can be perceived as being based around violence.

Robert talked about how great it is to be able to convert the awesome community that forms around gaming anyway into a power for good; it’s very satisfying to work together in this regard.

Scott Crabtree brought up the game “remission” by hope lab, which lets players play the role of their cancer medication – it’s been proven that kids that play this game are more likely to stick to their medication than kids with cancer that don’t. Robert mentioned that games can have other benefits on quality of life for sick kids, with gamer kids taking less pain medication than non-gamers and other related improvements.

Tom wrapped up the discussion by encouraging people to see what they themselves can do and to stand up and get involved.

Moderator: Heather M. Chandler, Executive Producer, Media Sunshine

PMI: Karin Groepper Boosman, Localization Project Manager, Aspyr Media/ Agile: Rich Vogel, Co-Studio Director, BioWare Austin/ CMM PSP: Tobi Saulnier, CEO, 1st Playable Productions

This was a tough session to blog, with lightning fast slides and summaries, so forgive some incompleteness! The overviews were awesome though! It’s interesting to hear the different methods and their similarities and differences.

PMI – Project Management Institute is an international professional organization linking project managers across 70 industries and 170 countries, founded in 1969.

PMI – Backbone of Methodology: Methodolgy scales to current body of knowledge and development technology, but always includes the 5 process groups – Initiating, Planning, Executing, Monitoring/ Controlling, and Closing. In addition to the process groups, there are 9 knowledge areas – Integration Management, Scope Management, Time Management, Cost Management, Quality Management, Human Resources Management, Communications Management, Risk Management, and Procurement Management.

Quality management is something we do awesome in the games industry. Human Resources Management comes down to treating people as your most valuable asset.

Scope Management and Control and Risk Management are areas for immediate improvement.

Scope Control, best practices for quick results:

Determine Scope baseline at the start [ Document expected final results and ancillary attributes. Document how scope is expected to achieve your studio’s business results, which could be making a profit for the studio, just recoup costs, or establish a name for your business, leading to future sustainability.

Create a formal, transparent, cost-associated change process – Measure scope change requests against the scope base line. Associate a cost with each scope change.

Risk Management, best practices for quick results:

Create a comprehensive Risk Plan. 1 = nominal, 5 = unsalvageable

1. First figure out what your negative risk thresholds are. On a scale of 1-5, what cost amount, time variance and quality variance qualifies as 1, 2, 3, 4, & 5?

2. List all risks your team can think of – Creative risks, schedule/ cost risks, and methodology risks.

3. Analyze each Risk – Rank each risk for likelihood and severity of impact. Prioritize all risks rating an average of 3 or higher. Define and document causes, avoidance plans and mitigation plans. Probably most importantly, Share this information with your team and with your stakeholders. Assign owners whose responsibility will be to navigate the risk according to plan.

PMI offers well practiced tested methods and templates to help PMs and Producers to do their jobs efficiently and effectively. No need to reinvent the wheel! Leverage templates and processes already created. Adaptable to a variety of development styles. YOU decide which processes serve your project.

CMM – “Capability Maturity Model” – www.sei.cmu.edu. Was developed to address a crisis of Software Risk in US industry in 1984. “Software Engineering” focuses on state of the art versus state of the practice.

CMM Levels are perfect for gamers! There are five levels for any process: Initial, Repeatable, Defined, Quantitative, and Optimizing.

Level 1: Initial – Ad hoc and occasionally chaotic. Few processes are defined, and success depends on individual effort and heroics. Characterized by a tendency to over commit, abandonment of processes, and an inability to repeat successes.

Level 2: Repeatable – Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on similar projects.

Level 3: Defined – The game development process is documented, standardized, and integrated across the organization. All games use an approved, tailored version of the organization standard process for developing and maintaining assets.

Level 4: Quantitative – Detailed Data on the game development process and the game quality are collced. Both the game development process and games are quantitatively understood and controlled.

Level 5: Optimizing – Continuous process improvement through quantitative feedback from the process and from pioloting innovative ideas and techniques. Start looking at defects or bugs and how you prevent it and change processes.

Take aways for CMM include an intuitive framework for *any* process improvement effort, as well as a step-wise approach for organizational development. You can be at different places in different processes. You might have a code standard already and be at a Level 3, but you might introduce something like code reviews and jump right from a Level 1 to a Level 3. Once you have that level of understanding in your organization, you can start to standardize your process.

Barriers in “leveling up” are your party and their stats (RPG analogy). A lack of professional training or knowledge on how to measure and predict their own work impedes process. People may not understand their own process beyond “code and then fix it.” There is a gap in project team training, and skills needed are planning, tracking and changing plans! The software industry had to deal with this exact issue 25 years ago when they pioneered the software process.

Training: PSP and TSP (Personal Software Process and Team Software Process)

PSP is aimed at providing professional engineering skills to individuals. Develops process steps other than writing code, compiling it and then fixing the bugs. Teaches tools and techniques they can use, and using data to improve estimating and planning. Also learn how to improve quality and reduce defects.

Basic tools: Using data to identify problems early, come up with solutions and gain knowledge and insights.

Challenge in software is that data does not transfer across individuals. The only one that applies to individuals is their own performance data. Data moves up pyramid to information and then last to knowledge and intuition.

TSP builds on PSP tools and techniques. Motivates and guides customized data collection and resulting decisions. Started with a TSP launch at a project kickoff to establish goals, define team roles, assess risks, and produce a team plan. Gave the team the power to solve their own problems, notice they were falling behind on something before Manager had to notice. TSP is basically an “in project” team training, related to something you are actually working on as you are doing it.

A TSP launch is multidisciplinary, including the client. This allows ALL team members to understand the game they are going to create and feel equally responsible for delivery. It’s also focused, realistic, creative and efficient, being accomplished in FOUR DAYS.

TSP is not new at all, we’ve done this all before but TSP provides a structure.

Benefits are team morale and cohesiveness, individual ownership of tasks, lessened burden on leads and PM for scheduling and delegation. Process is way more simplified, and useful data is gathered for future planning such as lines of code per hour, animations per day, task hours per week and better metrics for components.

Change acceptance is hard and there are models for this. If you want people to change things you need 2 of the 3 following things: Leadership, Shared Need, and Shared Vision.

Agile

The goal is high quality games a lower cost and that as fun to develop as they are to play. High metacritic rating (www.metacritic). Less work and less time.

Challenges of waterfall are team size. Communication challenge increases faster than team size. Centralized decision making gets overwhelmed (decision bottlenecks). “Fun” typically requires an unknown amount of iteration.

Key motivations are communication, fun factor and “Parkinson’s Law”. Scrum is not the silver bullet. If you have a dysfunctional team, scrum will not help.

Product roadmap. Set milestones every 6 weeks, made of two 3 week sprints. Define only the first two milestones in detail.

Release roadmap includes offsite meetings to reduce distractions, define release objectives, create one product backlog for all teams.

Everyone at BioWare, artists and programmers, get Agile/ Scrum training.

Mark Cerny’s Keynote

Mark has been in the industry for 27 years, consulting for 10 years working across a variety of roles from programming to production. His games have sold millions of copies. Works at Naughty Dog on their stable of titles.

Joined Atari games in 1982 (their coinup division), 11 years into the videogame industry.

Originality is KING! Was the motto – every game had to be a new genre. If it already existed, it was not an option. For example Super Sprint was considered selling out by many as it was an update to the original Sprint and therefore not original.

Industry was booming at the time – 6 billion dollars in quarters going into machines. 80% of that money was going to the operators. As a result, the industry was tiny. 15 programmer artists, 1 artist and a handful of business people = Atari at the time. The entire business was only 20x this size in total!

Sequels didn’t sell.

Asteroids sold 60,000 units – Asteroids deluxe sold just 10,000 units. Making a game that was similar to the first but shortened the gameplay experience (people were playing for an hour on the original on a single quarter) was an epic failure.

Process:

· Make game up to 80% point

· Put in a test location

· Measure income

· If it sucked, cancel it

2 of 3 games cancelled at this point!

Rapid hardware evolution was happening at the time. Mark’s first game (Qwak!) was one of these casualties. Marble Madness was the first use of the 68000 CPU, C and FM sound synthesis.

Back then, no assets!! Asteroids had about 15 simple assets.

Alpha & First Playable were roughly the same (1982ish), with Alpha often hitting within a week of first playable.

There was a deep management structure at Atari, all of whom typically wanted to be involved in the creative process. One of their sayings was “Success is random” (!).

Credits in 1982 – “the game is a corporate creation”. After a game had shipped, you were highly discouraged from mentioning you were even involved, in case you were head hunted by another company.

Arguments against credits: Too much memory, implementation time is too great, hurts team spirit…

Production methodology lessons learned:

· Not much

· Starting from scratch each time

· Complete chaos

Lessons learned:

· Slow and steady can and does win the race

Did not learn

· Estimation – games took an arbitrary length of time

Mark moved to Sega in 1985 to work on home console games. Sega’s motto was to make MORE games than Nintendo – they were behind, with around 40 games compared to Nintendo’s 80.

Production methodology: WORK YOUR ASS OFF! 1 programmer +1 artist x three months = 1 game. Sweatshop environment very literally, down to the layout of desks.

Despite this awesome approach, Nintendo had 94% market share compared to Sega on 4%, with 2% left for Atari.

Production methodology lessons learned

· Simple production does not equal easy scheduling

Mark joined Crystal Dynamics in 1992, making games for the 3DO Multiplayer. Suspected that “3DO” was short for “3Don’t”, as it was poor at doing 3D. Actually it was poor at 2D as well…

Production Methodology

· Venture Capital based

· 12 SKUs by year 3

· “Make ‘em fast”

Used the “proper process”

· Design it!

· Plan it!

· Produce and manage it!

And yet it didn’t work

Mark joined Universl Studios in 1994 as Vice President of development. Was given 3-6 months just to figure out what he wanted to do, with a budget of millions of dollars and no pressure on release.

Myth: It is possible to plan and schedule the creation of your game

Myth: Working productively means throwing out nothing

Myth: Frequent project review is essential to good management

Myth: Alpha = First Playable

Myth: A cancelled project is a sign of bad management or a bad team

Myth: The more defined your initial vision, the better. I need a 300 page document describing my game!

Myth: If you want to make a hit game, listen to the consumer

Method (1995) was a production methodology that defined the stages of production and pre production: First playable became the publishable first playable, the vertical slice. This pushed the chaos into the front period and ensured that production was more manageable and predictable.

Many projects won’t make it out of pre production – this has always been true and is likely to remain true.

Avoiding large design documents is good project management. You need one but it shouldn’t be out of whack with the scale of the project.

In 1982, Mark knew exactly what the player experience was in his game.

In 1995 he knew nothing about the player experience

With this in mind, Mark set about coming up with a production methodology to help understand the player experience.

Issues with Diifficulty, Comprehension and Bugs

Bug testing now is about finding bugs before release but no testing is done on how bugs affect the consumer experience. Once it’s shipped, testing and bug issues are over for the developer / publisher.

In 1995, you found out what the consumer thought by focus testing. Focus testing (concept testing version) is not great at finding truly successful concepts. Gameplay testing as a focus testing method is also extremely limited in applicability or as a real world measure of game quality.

A playtest, on the other hand, comes much later in the process and is much longer, focusing on difficulty and comprehension.

A playtest allowed you to check qualitative and quantitative issues, collecting metrics on where people die / get lost and how long they spend in each area, where the puzzles are difficult etc. You can also ask how they feel just be careful! It’s not a statistically significant sample and it’s subjective, don’t knee jerk react to this stuff.

In 1995, you could test your game in your engine quickly. By 2001 it was getting harder – tech takes so much longer to come online. So it made sense to start using other engines or tech to get gameplay polish in before the tech was ready. Now, however, that’s much harder thanks to the subtleties of the actual engine, including animation and visuals, having a massive impact on gameplay – see: Drake’s Fortune.

It’s hard to know what you’ve got until you’ve nearly got it. In the future, this should improve, taking us back towards where we were with regard to being able to prototype gameplay.

Our first “new” problem: TECH

Initial systems: difficult to predict time

· No legacy

· High “productivity”

· High wastage

· Low “effective productivity”

Mature Systems: Difficult to predict time

· Many internal interactions

Our second “new” problem: GOALS

There’s a conflict between perceived goals and actual goals

· Artist: best environment ever! = most visually complex?

· Programmer: Best AI ever! = most scripting options?

· Designer: Best puzzle ever! = hardest to understand?

· Writer: Best story ever! = most plot twists?

Good PM methodology: Bounding and directing the creativity

This is going to get harder and harder as teams and budgets increase – a tight feedback loop is a boon in ensuring that people work on the right stuff.

Final rant: NONE of this MATTERS

Culture trumps process

· Embrace the right kind of risk

· Support the true believer

The funnel – don’t be afraid to throw things away if that’s what helps you find the best option to move forward with. If that’s your culture.

Supporting the true believer:

· Focus tests

· Project cancellation

· Frequent management review

Is this Good? Or Bad?

Eyes on the prize…

· Play it!

· It’s a game!

Don Daglow, formerly head of Stormfront Studios, introduced his talk by talking about how he’s managed to stay interested and passionate about games over a 40-year career. (This is a guy who was writing games on mainframes in *1971*, the year I was born.) He went to Mattel to work on Intellivison, and then went to EA (and spent some time on Broderbund titles), ultimately ending up with 20 years at Stormfront.

He then was a bit candid — “challenge what you hear here, be cynical about it” because after all, who is he to tell you what to do with your life or what’s right for you. It’s some advice, but it might not be right for you. However, having done it for four decades, he’s been out to the extremes of the terrain and weather, and can act as a bit of a scout for us.

2008 has been a bit of a tough year for Daglow — they suspended operations of Stormfront after a few deals fell through, leaving them in a position without any cash. But even after taking apart something he has poured his heart into, he still loves what he does.

But thinking about ends, he thought a bit about the “circle of life” and came to the conclusion that every death or ending really is a beginning (and popped up an image of 12 Elvises in one place as his item of proof).

Daglow then moved onto his “Core Assumption:” “Passion for our work, our craft, our careers is not something we are given by others. It is something only we can control.” He feels that only we can be the carriers and guardians of our passions.

Our dreams are what get our passions going — but real life often intervenes, little detail things that we need to do as practical matters. And that can leave us feeling disconnected from our passions. But removing those obstacles is the way to re-connect us to our dreams and passions. The dreams, the passion are still there… we don’t get it from somewhere else, no one takes it away, but we need to find ways to get past whatever’s in the way.

Don then put up a slide showing his earliest games — or at least, images that indicated them. He had made a Parcheesi with Fog-of-War element Snoopy themed game around the subterranean Snoopy lair where he would disappear with Linus’ blanket when he was 10. He made another when he was 15 where he was simulating the hitting part of baseball (involving a slide rule for calculations!), quipping that he waited 8 hours after Curt Schilling’s talk to confess that there was no simulation of pitching.

He talked about being a social studies teacher and trying to teach kids the distinctions between countries and continents — noting that some adult’s still can’t tell the difference. But his kids finally got geography when he took the floor of the cafeteria in his school and taping down electrical tape across the black and white square grid of the linoleum to outline countries and continents across the world. (And recollected charmingly about children standing where they had come from — at that time, there were kids who had come across as Vietnamese boat people, children from Mexico…) His life to that point had gotten him emotionally invested when he was involved with games — his dreams were telling him that games were where he was supposed to be.

He said he wants to debunk the myth that hit games come together through some sort of manifest destiny, that there were no struggles and moments of cynicism and defeat in getting there. In reality, the best games still struggle through failure. Destiny can only be told if you look back from a great enough distance. He put up two pictures of basketball teams and asked which one is going to be the great person who does something amazing — the first taken about a year ago, and who knows, it’s too recent. The other contained, dead center, a young man who later would become President-Elect, Barack Obama.

To think about your dreams, he suggests that you take a moment to write something down, answering the following three questions in Fill-in-the-blank style. These are:

* My proudest moment working in the games business is when _______________.
* I knew that games were what I wanted to do ever since I ___________________.
* Of all the kinds of work I do or have done, I’m happiest when I’m __________________.

(On a personal note, I’ll answer the second one. I had a good idea this was what *I* should be doing when I played Crowther and Woods’ Colossal Cave Adventure back in about 1978 on a “dumb terminal” connected to my dad’s mainframe at work. He and I would print out pages and pages of “You’re in a maze of twisty little passages, all alike.” We’d run from a dwarf. Our batteries would die. It was terrific and the graphics had infinite beauty and precision, being entirely in our heads. I had the opportunity to thank Don Woods in person at the Game Developer’s Choice Awards a couple of years ago, when I was a judge. It was a proud moment for me to tell him that in large part, I owe my current career and successes to time spent with my father playing Crowther and Woods’ game.)

What are these questions about? The first is about pride in what you’ve done. The second is a deep primordial connection with that first time you connected with your dreams. And the third is about finding joy in every day.

There are obstacles. Insane schedules, insane bosses, inability to find the right job, a million little things.

Questions to ask yourself:

* Can I make a change now or am I stuck for a while?
* What would I have to do to feel like I’m chasing my dreams? (This is hard, he notes, since they might be tough things to do — go back to school, relocate, whatever. It’s better to do this, though, and make a concrete choice — this will help put any little voices you have to bed if you choose not to follow that now.)
* Can I change my approach and with it change the world around me?
* How can I make a living until I can get my dreams back on track? (Sometimes really, you just need a little distance. Sometimes you have to zig zag. This year Daglow had to turn back a bit. It’s not a straight line — it’s a path that meanders.)

Daglow turned back to this third one. It’s easy to look back 5 years and answer that question in a better way, once you have some distance from the issue. He told a bit of a story, of an excited young person who talks to a wise old manager, who claims he could achieve his every dream if only he didn’t have this stupid boss in his way. And the wise old manager asks, “What would happen if you were to act as if you respected your boss for his intelligence and creativity?” The idea being that the everything would improve if there were a better culture of respect between he and his boss. Daglow says that he wishes he had at times not been part of the problem in this respect, and that in fact his bosses were sometimes doing the right things and Daglow was introducing the obstacles himself.

Next: “Sometimes real life will require that we step back.” We’ll need to learn new skills or make some money. We’ll need to figure things out.

He puts up Maslow’s pyramid of self-actualization, quipping “Oh, I thought I was coming to a game development conference and I’m trapped in a room with Dr Phil!” But if you invert the pyramid, you think of the things you need to do as a sort of list — we have to take care of food, shelter, safety, and then family and love, becoming part of a team, being recognized, and ultimately finding joy in our work. (Google Maslow’s Hierarchy of Needs to get an illustration -> then turn it over and see a bit of a road map for yourself.)

He told an anecdote of a friend who put together and sold a successful business, but who on reflection realized that to build up that business, he traded his marriage, his marriage failed as a result. His friend wouldn’t have made that deal had he known he was making it. Sometimes we aren’t chasing what we really need, and we make choices that are wrong. The only right starting point, says Daglow, is our dreams.

Daglow then points out that one of the best things we can learn from Curt Schilling is that yeah, even the best are going to have fumbles, strikeouts, and mess-ups that are visible on national television with millions of people watching. But even those players can become Hall-of-Famers despite them. You can fail, so long as you don’t let those self-doubts allow you to tear yourself all the way down from within. We aren’t perfect, and we can’t expect ourselves to be.

He presented a quote on a slide entitled “What Artists & Writers Know”. “A Professional writer is an amateur writer who didn’t quit.” — Richard Bach. Writers get rejection upon rejection in the learning of their craft, and need to know it’s going to be criticized and rejected for a long time until they make their first sale (and probably for a long time after).

The word according to Daglow, “Three Reasons This is One of the Best Times Ever in Games”. 1) XBLA, PSN, XNA, and new avenues for great, innovative games like Flow. 2) As it turns out, we haven’t had an evolution of gaming hardware, instead the Wii has broken out with incredible success, and so has Guitar Hero — both were breaking all kinds of rules (GH with box sizes and price points). Innovation is fully upon us, not past. He claims in 5 years he’ll come back with another slide just like this one. 3) Publishers are recognizing that they need to grow the audience, which means we need to reach new audiences — a more diverse audience is going to be key. That means more diverse products. And that means more diverse game development teams. This makes him optimistic, because it’s become part of the core, that the financial future requires that kind of diversity.

To wrap up, Daglow returned to his Core Assumption. “Passion for our work, our craft, our careers is not something we are given by others. It is something only we can control.” We are the vessel for that passion and those dreams, and we can reconnect to them by looking at how we answered those three questions.

Daglow noted that a benefit of age is that people will come up to him and say how his games have changed peoples’ lives. He recounted how someone just recently told him that Earl Weaver Baseball changed his life, is why he’s in this industry, was his answer to the second question I listed above. He points out that we deserve to pursue our happiness, that we deserve to pursue our dreams. But we’re also lucky in that our games are havens for kids out there who are going to have their own dreams because of what we do. Daglow was that kid. And he has been lucky to meet people who were those kids. And that’s an honor and a privilege for us.

Why Make Licensed Games?

• Every game is a lciensed game
• Publishers need developers who “get” licenses
• Greater sales reliability/lower risk
• Repeat Business
• Amaze case: 10 years, 100+ titles, 30M+ Units

Core Business vs. “Filler business”

• Track record of day & date delivery
• Reputation for capturing franchise look & feel
• Sepcially honed staffing, product pipeline, and production practices

For licensed games to be a core business for a developer you will need to accomplish these things.  To do this, think of your business as a “service.”  This means:

• Provide capacity – Publishers may not have the internal resources to do the game so an external developer can take a lot of problems off of their hands.
• Provide solutions – R&D, concept development, production, development, test, script, etc.
• Make publishing partners & licensors successful
• Service is NOT acquiesence – It’s your job to protect your partners from their own misjudgments.  You are an expert.  Don’t be afraid to push-back if you think that they are asking for something that doesn’t make sense.
• Clear expectations are key to a key to a good partnership

You will need your staff to buy-in to the idea that you are a service organization and establish a culture of partnership & ownership

• Find and train staff who love working on licensed properties.  Avoid auteurs and individuals who feel like they are looking to work on the next [insert specific game here]
• Find & train communicators/collaborators (production staff who are experts in both dev & service)
• Find staff who can handle redesigns and revisions
• It’s important that leads are able to communicate effectively with external partners and exude passion.

Anticipate problems. If possible, every project should have an AP as well as a Producer.  Hone production practices for the licensor pipeline and short timelines, such as:

• Strong & Speedy concept and proposal talent
• Facile tech – this can be hard because the games are often very different in terms of genre. Consider licensing middleware instead of trying to have an internal engine.
• Rapid prototyping capability
• Easy iteration
• Easy ramp-up/outsourcing/contractor pools

Some case studies:

PROBLEM: Ungameable subject matter

SOLUTIONS: Get into the head of the fan-base.  “What kind of experience will the fan base want?”  Remember, licensed games are not about metacritic ratings.  They are about giving the license’s fans what they want.  Consider alternative approaches to genres & mechanics.  Examples:

• Lord of the Rings with a trun-based tactics mechanic
• The Sims with a more story-focused mechanic
• Indiana Jones with a “burst of gameplay” mechanic

(Of course, this assumes a fairly accomodating publisher/licensor)

Also, spend time with the licensor to understand the proposed gameplay.  Demo sample gameplay from published games to help licensors understand the vision.  Gently help them understand that they are not experts in game development.  Partners that understand this are much easier to work with.

PROBLEM: Multiple stakeholders / licensor gauntlets

SOLUTIONS:

• Expect delays.
• Accept that “best guess” forward progress is better than no forward progress.  Licensors will often create delays due to their own indecision.  Don’t be afraid to just take the best path you can identify.  It will often force them to make the decisions that they are waffling on.
• Force each stakeholder to identify a “point person” who is empowered to make decisions on behalf of the stakeholder.
• Set clear guidelines for approvals and timelines, ideally in the contract.  Also, make sure that the publisher and licensor deliverables are called-out in the contract.
• Schedules & budgets are your ally – it can be effective to  point out to the publisher that changes will have time/cost impacts, but do this sparingly.  Publishers/licensors hate hearing this frequently.
• Shame can be your friend – you can, if absolutely necessary, go over your producer’s head.  This is a last resort, but is something that you may have to do.

PROBLEM: Design Restrictions aka “The Rules of the License”

SOLUTIONS:

• Identify the ruels early
• Identify the intention BEHIND the rule.  (Make sure that you understand why the rule is there).
• Educate the licensor on how rules will affect gameplay
• Figure out ways to bend the rules, by contriving explanations for game situations that can be explained within the context of the license, even if it’s a bit of a stretch

PROBLEM: Change-Orders (that publishers don’t want to pay for)

SOLUTIONS:

• Get it in the Agreement
• Set expectations – try to make it clear when something becomes a change order
• Communicate clearly to minimize large scope changes
• Let the little stuff go.  If the request is small enough that it doesn’t have a big impact on the project timeline/budget consider doing it without asking for more money.  Remember that the relationship is more important than the gig…usually.

PROBLEM: Trust Issues

SOLUTIONS:

• Partners must prove themselves able to handle straight truth and transparency
• Accept that “shit happens” and that the two partners are going to need to be willing to work through things together.

PROBLEMS: Canceled & shifted movie dates

Most movies ship when they are supposed to, but sometimes they don’t (80/20).  This can be a death-knell for a one-projecty studio.  To avoid this problem, it’s important to have an excellent biz dev team that is able to quickly bring in new work, if necessary.  Also, try to have a variable-size workforce.  One good solution that allows this without having to do layoffs is to have sister studios that you can loan people to and from.  Finally, try to include “kill fees” in contracts.

PROBLEM: Day & Date Movie Releases

The projects often provide little pre-production time which can lead to poor design and/or inaccurate schedules.  To mitigate this risk, try to get the client to go along with something that you already do well or that is similar to an existing product.

These projects also have a risk of perma-crunch due to their tough deadlines which can lead to staff burnout.  To avoid this, try to keep the project scope small, consider outsourcing and/or working with partner studios. And make sure that you have strong pdoruction processes that you stick to.

These projects also create the risk of getting stuck in a vicious cycle where you get poor game reviews, which can make it very hard to find work.  Be smart with the game design and scope.  Build a game that plays to the team and studio’s strengths.  Try to work with a savvy, collaborative partner that understands your challenges and will avoid creating risk.

Finally, these projects also run the risk of being buggy when they ship, due to the short timeline, and introducing legacy technology issues into the code-base.  Be sure to commit resources to core tech and tools investment and do technical post-mortems.

The “3-Bullet Take-Away”

• Specialization – Focus on creating these kinds of games.  Make sure that your business, production, and development processes are all tailored for this type of game.
• Service – Think about service as being equally important to development prowess itself.
• Culture – Everyone in the studio should LOVE finding the “cool” in any license.

Linda Bonanno, Head of Product Development, Emergent Game Technologies

Linda has worked at big and small companies on all kinds of tech. She has an engineering background. She likes to think she’s seen a little bit of everything in management. Since her start writing software, she’s been in a lot of different leadership roles.

What is the problem? Industry turnover. Doesn’t depend on the business you are in.

It’s really hard to find good, talented people. Once you have them, you want to keep them. Competition will try to lure them away with bigger salaries, opportunities to work on exciting new IP, or an opportunity for a larger role.

Gallup surveys have shown that people don’t leave jobs, they leave their managers. The people they deal with on a day to day basis. Throwing money at the problem doesn’t work. Your best people always have an option, there is always an alternative.

Everyone should have at least one manager they look back on that they recognize has made a different in their careers, and in their lives. What makes these managers memorable? They communicated, clearly and effectively. They dealt with trouble head on, and they empowered their people for success. If people feel successful in what they’re doing, they feel happy, too.

Communicate: Understand that individual motivations are unique. Do what’s right for the individual. Connect, because open and honest communication creates trust. Share all that you can about the company. Give and take feedback graciously, the positive and the negative. Thank people publicly for a job well done.

People talk about how you treat them. Even if you help place an employee in another country, school, etc, they will talk about how you helped them, or didn’t, and it will impact your remaining employees.

Transparency is essential. If people feel informed, they will feel involved. The really good managers always err on the side of sharing more information than less. Transparency fosters trust.

Dealing with trouble: Your staff is watching you. Bring the issue to the light of day immediately. People can’t fix what they don’t know is a problem. If you wait too long, the issue becomes a serious detriment. Don’t wait for a review. Provide the opportunity for course correction and understand that everyone deserves a second chance. Most people really want to do a good job, and remember that empathy goes a long way. People don’t deserve nasty surprises, they deserve wake up calls.

Realize when you’re dealing with a lost cause and give up! What constitutes a lost cause? The person is unable to do the job, unwilling to do the job, and are toxic to the culture. You can’t make someone do their job, and you’re better off moving them out. They’re not helping your organization.

Empowering employees: Power to the people! Everyone wants to feel like they are empowered. Give team leaders and managers the permission for creative decision making. You don’t need to micro manage the details. Provide autonomy for senior contributors. Define clear boundaries for success for junior employees. Treating people fairly is not treating everyone the same.

Jamie describes an “Innovation Continuum” that ranges from Ports to New Original IP.  Prototyping is most valuable the further you are towards the “New IP” end of the curriculum

The Old Process – Develompent as a path from Design to ship, with vertical slice, content creation, polish, debugging in between.

Instead, we should be thinking of game development as a funnel. Ideas -> Prototypes -> Vertical Slices -> Shipped Games -> Franchises.  This approach more likely to weed out the games that are likely to be failures.  (These ideas are not new.  See: Building Innvative Games that Sell – Project Horseshoe’s Group Report or “Winning at New Products” by Robert G Cooper.)

“It’s common senes: you don’t want to ship evertyhing that you start.”  And, you migth say that our industry is already like that.  Most projects have greenlight kill gates.  Weak projects get cancelled.  BUT, we don’t THINK of the process as a funnel because we don’t see cancelling a project as a good thing.  So we get upset when a project gets cancelled or we see it as a failure, or we are tempted to spend good money to try and save a project that isn’t working.

Also, the existing funnels are fairly “fat,” in that they don’t weed out very many bad projects.  We should be trying to have a more “narrow” funnel.  We need to develop the “Will to Kll Sooner.”

The Axiom of the Cerny Method is that you should try to keep management’s eyes off of the prototype for as long as possible so as to protect them from the “Stench of Failure.”  Historically, Jamie agreed with this, but recently has started to change his mind because:

1. It widens the funnel
2. It tends to cloak unfun gameplay with pretty graphics

To use a Texas Hold’Em metaphor – this is like ALWAYS staying “in” to “see the flop.”  A better strategy would be to fold before the flop more frequently.

The solution: “Thumbnail Sketch Prototypes” which occur before the vertical slice; AND – show them to the publisher.  Sorta like a quick art concept sketch that you might use to provide high-level art direction.  But how do you do this for an entire game?

Embrace the “stench of failure.”  Developers: accept that the majority of prototypes will be rejected.  Publishers: learn to separate “fun” from “pretty.” (Jamie then goes off on a mini-rant about publishers and their ability to do this).

For examples of how to do a “Thumbnail Sketch Prototype” refer to:

• *”Experimental Gameplay Workshop” – Carnegie Mellon
• “How to Prototype a Game in Under 7 Days” – Kyle Gabler & Kyle Gray
• Kongregate.com

But what about “real” games?: Jamie explains that this was something that he was able to do in about 2 weeks for Spiderman 2′s web-swinging mechanic.

What do they look like?: Programmer art.  “Hideous.”  Not about the art.  In some cases, could even be all text/ASCII.  They are genearlly 2D and should only be 3D if it’s convenient or if the game mechanic really, really, requires it.  In general, 3D complicates this process and is to be avoided if possible.  Try to do it in 2D first.

In response to those who would say: “Once I did a prototype with bad art and it was rejected.”

• That isn’t necessarily a bad thing.  Remember, we are trying to weed out bad ideas.
• “But then I added good art and it was accepted.”  – This is exactly the point.  We dont want to cloak bad gameplay with good art.

Beware of doing “decent” art in a prototype.  If you must have good art, go all the way.  Mediocre art sends the message that you can’t do it well.  Realy, really, bad art is better because it makes it less likely that your artwork will be evaluated on it.

What else to skip:

• AI – make it multiplayer instead.
• Network Play – make it splitscreen instead.
• Tutorials/Accessibility – make it fun first.  Then figure out how to teach it to people.
• Balance – make it balanced later.  It only needs to be fun for a few mins at this stage.

But do NOT skip Audio!  It’s too important.

Don’t feel compelled to follow the traditional rules of development.  Instead of:

• “Finish one component before starting the next” – Do evertyhing half-assed
• Peer review – Nope
• TDD – Nope
• Detailed Schedule – Nope
• “Fix the bugs first” – Fix them later, if ever.

Prototyping Teams should be as small as possible.  At mose, a programmer, a designer, and an artist.  They can possibly even be just one person.  A decent programmer who loves games and can ger around in photoshop/Max can do this by themselves.

Talent is still important.  A talented protytper can be the difference bewteen a 1 in 100 success rate and a 1 in 3 success rate.

the procdess should take 1-4 weeks, but the deadline is fairly arbitrary.  A 4-week contract is convenient, though, and can be for a single prototype or can allow for early “kill” decisions to be followed by completely new/different prototypes.

How do you identify a “winner?”  When you show it your boss and they like it and then they go grab someone else (their boss?) and THEY like it and it snowballs from there.  But, make sure you warn everyone that art isn’t in there yet and that you twll them how to play.  Also, compare the responses that you get to the responses that you get from people on other prototypes to get a sense of context.  If you’re independent, potentially even consider putting the prototype on the internet for free and see what sticks.  (It worked for Audiosurf and World of Goo).

Remember that first impressions are important.   Nearly any game can become fun once people really get into it, but new players often won’t be willing to invest that kind of time.  It’s like juggling in this respect (“I could learn to do it, but why would i want to?”).  So, it needs to be fun quickly.

Once you’ve found “a winner,” it’s time to iterate.  The game should stay small, as should the team.  Agile Methodologies can be ideal during this process.  Identify a project owner who priorities the backlog (probably a publisher producer).  Weekly or even bi-weekly reviews are a good idea, which means that being local helps.

Begin trying to address other risks: multiplayer, network play, intellectual property fit, replayability/duration, etc.  Make sure that you have another “kill gate.”  This process could take 2-3 more months if you keep your team small, but be careful to avoid iterating endlessly.

If the protoype makes it through the second kill gate then it’s time to move on to a “Relase Quality Prototype,” (often otherwise known as a “Vertical Slice,” which is a term that Jamie isn’t a big fan of).

For publishers who have limited development resources, consider outsourcing prototyping.  Greenlight multiple develpoers to make thumbnail prototypes for the same proejct.  This is something that indy developers are very good at.  Approve several and greenlight the favorite for further development.

The contract for this sort of game would be very publisher-favorable.  Publisher gets to keep the IP and doesn’t have to pay royalties.  Just give the developer credit, such as “Based on a prototype by…”  You don’t even have to use the prototype developer to do the full project.

Publishers: Anticipate that it may be slow to get this type of deal approved by legal.  Anticipate that there will need to be at least 4 weeks of work for it to be worth a dev’s time.  Anticipate that the terms will be either fairly broad or small in terms of scope.  If you try to schedule them to do 4 weeks worth of work with no buffer time you run the risk of them focusing too much on the spec and not on iterating to find something fun.  Anticipate that the prototyping process may be prolonged by legal hassles and may involve downtime between iterations.

Something to think about: is it possible to use this approach for content, as well as gameplay.  Jamie seems to think so, if you can stomach “shooting your baby in the crib.”  He mentions that the guy who did World of Goo cut 2 out of every 3 levels that he created fromt he finished product.

Contact: jfristrom@torpexgames.com; www.gamedevblog.com; www.torpexgames.com.

Q&A

Q – “Do you have a preferred language or environment for prototyping games?”

A – “We have been using XNA.  I think it’s best to use whatever tech you’re familiar with, though.

Q – “You said ‘make it fun first and accessible later’, but you also said that first impressions are important.  How do you reconcile those 2 things.”

A – You can handhold a person who is playing a prototype in ways that you can’t with someone who is playing a retail product.

Q – “If you have a prototype team of 3 people who are working together and they have had a few attempts rejected how do you avoid demotivating them and/or hurting their morale?”

A – “I don’t know….pass! *laughs*  I think that you have to kinda be ‘ok’ with the rejection.  But, one thing that does help is the rapid iteration and going quickly from one project to another.  Remind people that it’s a rejection of the product, not of the person.”

Q – “This approach seems to make a lot of sense for a large studio or a company that already has a publisher relationship.  Do you have any guidance for a studio that is not in that situation?”

A -  “Well, for Schizoid we did cheat a bit and put in some good artwork before we did an actual greenlight meeting.  The pressure to ‘make it pretty’ is strong.”

Q – “How is this a practical business model for an independent studio?”

A – “It pretty much has to be a side business for a company that has another primary revenue stream.”

Q – “As a suggestion, if you’re concerned about protytping teams getting burned out by rejection, consider waiting on giving them the “feedback” until after they’ve moved on to another prototype.  They will be less invested in the one that is gettingk killed at that point.”

Stefan joins us from EA Black Box in Vancouver, BC to talk about managing engineering communities, and ultimately a little bit about engineers (and as one, I’m not sure that’s a good idea ;)

He inherited a bunch of problems when he took over the “engineering community” as CTO at EA Black Box — lack of communication within the studio engineering dept, and also facing outwards, a lot of pressure and therefore attrition. Platform transitions, lack of career definition, and little sense of community didn’t help the situation. The studio got there because it grew quickly — it built up due to enormous success of individual teams and products, primarily sports-related, and that didn’t scale well, particularly as looming next-gen requirements loomed and an argument was made for centralizing the technology.

He was overwhelmed and started off by getting the three most senior Tech Directors to have daily morning meetings to figure out how to do this, forming a sort of “CTO office”. From there, they went on to for the Technical Director group, which consisted of the 20 or so TDs from all the teams, for weekly meetings.

Stefan then talked about communication. Turns out, engineers like to communicate, but more in small groups (and with some encouragement), and they’re often too overwhelmed by project needs to do so cross-team. So he took one programmer per project per area of expertise (animation, physics, graphics) and formed Special Interest Groups to have monthly meetings to act as an advisory group to the CTO office. This led to technical policy making with cross-pollination between teams, and the nice side benefits of increasing the exposure of the Software Engineering Dept and fostering a sense of community amongst the engineers.

He also fostered more external communication (outside of project) by opening himself up as a resource, both listening as much as possible (via open-door policy, helping where possible and even occasionally getting a little more involved, which helped garner respect), and doing 1-on-1s with top talent, allowing him to take a bit of a mentoring role.

The CTO office was responsible for setting up a three-year roadmap of company technology, which is really hard when you’re talking about a lot of teams with different needs and goals. Coming up with and communicationg a technical vision was really tough, particularly when it came to higher-level game features.

The career path at EA for engineering was also a bit stalled — there was a real bottleneck going from being an SE3 to either a Senior Software Engineer or a Tech Director (no one had made that step in 6 years!). So he clarified that by identifying the top SE3s, made them into SSEs, and formed them into a little tiger team talking about what it meant to move into those roles, to become Senior SEs or Tech Directors.

Due to attrition, there was a lot of hiring going on, so improving that process was critical. Giving folks a clear understanding of how expensive it is to bring someone into the company (or not, depending) helped to emphasize how important it was to do a good job of interviewing folks to find a good fit. But of course, fixing the interview process is only part of dealing with attrition — it’s just the reaction. So the CTO office got involved in getting to know people better, making sure the right technical people were involved in the review process for engineers, and helping to be clear where people were trying to develop their careers.

Stefan was also frank about what didn’t work. Trying to set up a “portal” for software engineering was difficult and didn’t really work. Setting up a mentoring program was equally difficult and never really got off the ground, nor did a “community events” program. This was largely due to the fact that he didn’t have a big enough admin staff to get that off the ground. Having lots of meetings was detrimental to be able to get around to meet more informally with people.

However, despite the few things that haven’t worked, overall the community is a much happier place, with a better structure and better games.

Manveer Heir, Game Designer, Raven Software

Not a CEO or studio head, creative head or lead designer, not even a manager of any type. Firmly in the middle of his organization. Hopes to give you perspective on what your development team needs and what they really want.

What is leadership? Influence people around you to work more effectively and to be better quality. At the end of the day, we all want to ship a great game. Leadership IS influence.

Game development is difficult. If it wasn’t, we wouldn’t be working so hard to improve.  We need leadership in the trenches, because leadership is “f’ing hard.” The cost of failure can be devastating. Leadership gives us a better chance of success, and exceeding our expectations.

Myth #1: Leadership comes from title. Leadership can come from any part of the organization. Don’t fall into thinking that “I’m not the Lead, so I can’t lead.” 

Myth #2: Having title will make people follow me. Plenty of stories of people with poor leadership who led low budget, low quality titles. You need to earn followers and show people you deserve to have people follow you.

Myth #3: I’m not experienced enough to be a leader. 

If you’re not already a leader, how do you become one? First, identify who your leaders are. Who will the team go to during a crisis? Those people are the leaders. If your answer to that question is “nobody”, you may have a gaping hole in your organization. 

Next, examine your leaders. By examining the current leadership on your team, you’ll see what their styles are and also where there are holes. Then, inspect yourself. What qualities do you bring to the table as a leader? Honesty, respect, etc.

Once you’ve done these things, it’s time to lead. You don’t have to ask permission, you just have to do it. Super important tip: forget about yourself! Once you stop being selfish, you will be able to be an effective leader.

How to lead:

• Be effective at your job
• Be proactive
• Be an agent of change
• Find and solve problems
• Communicate outside your discipline
• Lead in all directions

Clinton Keith, long-term industry guy and the person who introduced Scrum to the industry, mostly through his company High Moon Studios (though he now works as a Scrum consultant). He introduced his talk by telling us he wants us to get good info on good and bad myths about Scrum before you take it on, as well as the kernels of truth that gave rise to those myths, and what the real experiences of teams shipping games in Scrum are.

First a quick overview of the process:
Start with a list of prioritized features (owned by a project director). We sprint to develop portions of these features in 2-4 weeks, taking things that are most important to the consumer. And we break those down into a “sprint backlog” of parts of those features we think we can implement, with the goal of an incrementally improved game at the end of that sprint, which goes back into the product backlog from which our overall feature set is drawn.

Daily scrums: everyone gets together to talk about the goal, getting that feature in, what’s holding it up right now, etc. (These are the 10 minute stand-up meetings you might have heard of.)

Scrum teams are usually cross-disciplinary — a little from every department. In addition, there’s a scrum master, who isn’t a lead but who is following the process rules of the scrum (what they agreed to). The product owner (publisher, internal director) — prioritizes the backlog, etc, and communicates vision.

Scrum: “Silver Bullet” Myths
Talks about various “silver bullets” which have been applied to programming along the way — object-oriented programming, CASE tools, automatic programming, and then used that as an intro into what myths have popped up around Scrum.

Scrum Myth 1: “Scrum doesn’t require competent leadership! It’s self-organizing!” (this makes me think about self-documenting code…) — he found you still need leads to mentor people to help people to understand their role in the organization. For agile teams, though, we’re moving from directed management (where in our industry the best people get taken out of what they do well to “manage”) to facilitation (best people serving as an example and mentor).

Scrum Myth 2: “Scrum will prevent problems.” No. You always end up with problems. The benefit of scrum is that you have transparency as to what your problems are — it finds everything that impedes productivity. Unfortunately, one common problem is that people associate those problems which are uncovered as being a result of Scrum itself, when they are more likely simply made more visible by the process.

Scrum Myth 3: “Scrum can achieve impossible goals.” If you already have impossible goals, adding a new process probably won’t help. However, it might help you realize just how impossible they are (and therefore fail faster), which may be cheaper for you in the long run.

Keith next addressed things that prevent people from adopting Scrum, what he calls the “fear, uncertainty, and doubt” myths.

Uncertainty: Endless iteration. “You’re always iterating with Scrum, you’re never getting closer to the goal.” Keith points out that that’s true, if you don’t have someone who has the vision to make sure you’re doing the right things. Agile planning is more about moving planning to the center of development, rather than a specific plan.

Doubt: “Scrum is just another management fad.” Scrum ideas, agile ideas, have been around for more than half a century. It’s been an evolution, though it finally got a name in the mid-80s. It has been a process of returning a fair amount of leadership back to individual craftsmen, rather than the assembly line process introduced by Henry Ford.

Fear: “It’s scary to change our process.” However, Keith notes that our industry has seen huge external changes that have led to internal changes in our industry — new platforms leading to bigger teams. But we didn’t really change how we did things, we kept writing big design documents first to plan everything out. But that didn’t keep us from being late or overbudget, and yet we’d still go back to doing that. Big plans up front didn’t work, but we’d still do them.

Keith moved into some more anecdotal development experiences.

He noted that Scrum can be a tool for changes in culture — if you have to have a playable game every two to four weeks, it forces you to make your practices more effective. It pushes more into data, and you get more feedback.

The big thing about adopting Scrum is that you need to be aware of the underlying principles. You need to focus on value — and tracking tasks are only useful for knowing what you’re doing to increase value (better gameplay, better looking environments, whatever). You should only change away from the existing Scrum methodology once you’ve done it long enough to understand the principles it values. He showed clips from Karate Kid — in which our young hero Daniel does a bunch of menial tasks for Mr. Miyagi, not knowing why, and comes out able to block Mr. Miyagi’s various attacks without really thinking about it.

Keith next illustrated that the practices of Scrum aren’t the value of Scrum, they’re just a way to show the underlying values you’re trying to achieve. (He talked about cargo cults which sprung up after World War II — google it, I’m not going to repeat it all here. Suffice it to say, making fake airplanes doesn’t give you the industrial knowledge to bring all the trinkets that the real planes brought.)

He then showed a roadmap for improvement — starting out as an apprentice, becoming a journeyman, and ultimately a master.

Scrum is best for pre-production — in identifying where the game fun is, so that you can then go into production and replicate that information across the game. He noted with an example that once you’ve identified a jump height and length in preproduction, you don’t want to alter that in production and end up having to move every ledge and change the spacing on every obstacle. But it’s good for finding the fun in an iterative way. Shorter term milestones with not a lot of longer term milestone and production detail to “find the fun” might be a good way to begin a developer/publisher relationship, with the idea that eventually you’ll be in a position to know that you can build the full game and get a full production contract at that point.

The goals of scrum are to focus your culture on the following things: delievering value quickly and early, continuously improving your game, transparency and communication.

Session: Truly Tapping your Strengths (and those of your team)

Speaker: Scott Crabtree, Engineering Manager, Intel

Leading video games projects is difficult, and we often make it harder by focusing on weaknesses rather than on our strengths.

Strengths movement – We can perform better by using our strengths more often. You’re in the flow, you feel engaged, energized – you’re doing things you love doing and at which you are talented.

Focus on your strengths – both on your own and on your team’s to be happier and more productive. You will find that your team is more engaged and produces work faster necessitating less crunch time.

3 steps to implement this way of Strengths-focused thinking:

• Have to acknowledge and change our own beliefs about strengths and weaknesses.

1. • We need to fully discover our key strengths.
   • We need to act on our own strengths and help others act on theirs.
   • When we focus on what they’re not doing well, we ask them to focus on what they do the worst.
   • Overcome the 3 myths:

. Myth: A good team member pitches in wherever necessary on a team. Truth: a good team member uses his strengths to help the team.

. Myth: Your personality with change significantly over time. Truth: Over time you become more of who you already are.

. Myth: You can grow the most in your areas of greatest weakness. Truth: We can improve the most by building on strengths. You can improve by working on your weaknesses, but you can grow MORE by acting on your strengths.

• We have to acknowledge and change our own beliefs about strength and weaknesses. We need to fully discover our key strengths.

1. • Start by clarifying strengths you already know. Ask yourself does it matter: Who? When? What? Why? Help suss out what is a lasting strength v. what is circumstance-dependent.
   • Track your strongest and weakest work over one month. Three things you loved doing and did well. Three things that you didn’t do well. In a group, this technique can be used to find out what people really wanted to do and encouraged teams to ask each other to do tasks that played to their strengths.
   • Use surveys, assessment tools, and colleagues to get some additional input such as the Myers & Briggs instrument and the Values in Action survey.
   • The Values in Action survey finds your 5 character strengths. Examples include creativity, persistence, social intelligence, leadership, and self-regulation.
   • Strengths finder 2.0 identifies your top 5 of 24 strengths has been very effective on Scott’s team
   • Reflective Best Self by Harvard Business Review suggests the following for finding your strengths:

. Gather input from friends, colleagues, etc. of their observations of your strengths.

. Get specific examples.

. Write a strengths self-portrait. This method gets beyond 1-word labels, which is a limitation of some of the other methods.

• We have to acknowledge and change our own beliefs about strengths.

1. • Start now re-prioritizing your tasks and use your strengths more.
   • Act within 72 hours – other wise the new information is lost and the habit will not be formed. Pick one thing you do excellently and do more of it. Practice.
   • Start doing less of those things that don’t use your strengths.

. Drop things that you don’t do well that you put upon yourself.

. Delegate things that you don’t do well that others can and want to do better.

. Deal – either by making deals to swap strength-leaning tasks with someone else who has a weakness in one of your strengths or by just dealing with the weakness that must be accomplished because there is not a feasible way to either drop it or delegate it now. Look for opportunities (create where applicable) to find a way to drop it or delegate in the future.

Chat about strengths with your friends, colleagues, reports, and your boss. Tact is useful here. “When should I expect your best work?” is likely to elicit an honest strength-response you can use to find out what someone on your team really loves to do.

With your boss, an effective approach to this conversation would be to focus on getting something done for him/her that plays to your strengths and then after this has been done successfully, suggest taking on more things that fit your strengths.

In conclusion: Make conversations about strength a team conversation. Learn and act on other’s strengths. In reviews and performance feedback, focus on strengths. Sustain acting on strengths. Practicing it will make it more of a habit!

Making Lots of Small Games Without Going Crazy
Speaker: J.C. Connors – Studio Head, Griptonite

Overview/History
Started working in Baltimore making small games.  Started by doing tech support and had to do testing, made a pen-and-paper RPG in 10 months, and fixing this game called Ninja that wasn’t fun.  So he was used to multi-tasking all over the place.  So two years ago, he started as the studio head of Griptonite.  He’d just recently shipped a big budget console title and shifted to a smaller studio, and not all of the skills crossed over.

The small game studio as a meteor shower
•    Projects are coming in fast.
•    Most are on fire
•    Some are chunky, bland, and devoid of anything interesting.
•    People are confused and scared
•    How long will it last?!?

Everyone had their own idea of what would make their game really great, and there were various issues that were caused by a number of different reasons, so he needed to come up with rules to prioritize.  These rules needed to be transparent so everyone in the studio would understand what was most important.

Lesson #1: Strong leaders make strong games.
A lot of small studios assume that strong leaders mean strong technical skills, but it’s not.  Producers and leads are like fruit flies- the point here is that short projects are so abbreviated, that they contain all of the parts of major projects, that people are constantly learning from incredibly fast projects.  The successful projects had really strong producers.  The producers would guarantee games that would be on-time and great.

Leadership is really cultural: foster a culture of asking questions and learning among producers and leads.  Watch out for those who make the same mistakes twice.   Really foster a community of people talking to each other.  Art reviews and game reviews; anything to get people talking is a good thing.  In a small studio with lots of small projects, the best educational assets are the ones that surround you- if you don’t learn from them, you’re going to fail.

Make roles clear to people.  If this is left to be grown organically, then many things will fall through the cracks.  In looking at Mystery Case Files – there turned out to be a client-side producer who was a full of really great design ideas, a designer on the project, and another producer who all had design ideas, and while they all had ownership on various features, there were features that didn’t have a clear owner.

Have a strike team in mind for emergencies.  Delegate this so that you aren’t always functioning as the firefighter on every single project.   Examples of firefighter roles:
•    The Technician (aka Batman)
o    Strong technical understanding of your pipeline and tech
o    Willing to do the dirty work
o    Empowered to get things done
o    Ability to be subtle and work behind the scenes
o    Autonomous
o    Example: In making realistic water effects on a DS game, they tasked him with it and when the team needed help, this person was there to just step in and actively, happily, tackle it.

•    The Man of the People (aka Superman)
o    Positive personality
o    Sell doing the right thing to teams and clients
o    Decisive yet empathic
o    Strong execution

•    The Jack of All Trades (aka Green Lantern)
o    Multitasker; can be given multiple projects and problems to deal with
o    Can work with any team
o    Willingness to use creative solutions
o    Intuitive

•    The Specialist (aka Aquaman)
o    When a certain team has a very specific problem
o    Understands his specialty very well
o    Extremely consistent
o    Don’t have a studio full of Aquamen!

Lesson 2: Give innovation the same respect you’d give a mountain lion
Innovation – something where there isn’t a clear template to follow.

Innovation is the coolest thing about creating small games.  Innovation can also completely destroy game production- one of the main features of innovation is failure and iterating upon that failure.

Unless everyone on the team, the leads, the clients, are all about innovation, then innovation is best in small doses.  In looking at Spore Creatures, they knew going into it that there were a number of incredibly innovative features.

•    Innovative Features
o    Creature Creator
o    Internet Pollenation
o    Shadowbox Visual Style
o    All-Touchscreen Combat
•    Tried and True Features
o    Linear, Quest-based Level Design
o    Elite Beat Agents-like social game
o    Achievement/Badge System

Replayability and accessibility is often more important then innovation on small titles.  Everyone wants to make an innovative, but not necessarily an accessible game.  It’s more important to get people into small games and handheld games, and once that barrier is lowered, then you can surprise people with how you can twist the rules and innovate.

Your game is as strong as your weakest, most-played component.  Prioritize core mechanics, prioritize controls, prioritize where your games’ strength really comes from.

Lesson #3 – Fun is everyone’s job
Everyone should be able to play their game in their head from the 2nd week of the project.  We always have a tendency to improve on what we’ve already done in the past.  If someone can’t communicate the game that they’re working on, then that’s a problem.  Producers should always be making sure that everyone’s on the same page.

•    Create a Game Culture
o    Game Days
o    Competitions
o    Giveaways
o    Shared play sessions

If everyone has a shared vocabulary, fewer people will be making a mistake.

Lesson #4 – Monitoring scope is one person’s job
You need somebody on the project to ring that bell if the scope isn’t making sense.  In looking at the problems with Spore Creatures, they didn’t realize that there were whole tasks and features that weren’t on anyone’s radars since they involved integration of all of the various systems.  No one was looking at the big picture.

The Great Fibonacci Videogame Equation for Fun and Perfect Scheduling
•    Time estimate Multiplier for Fun
o    Moment to Moment x 5
o    Minute to minute x 3
o    Hour to hour x 2
o    Once… ever x1

The more the player is going to be doing something, the more time should be spent on it.

Lesson #5 – Understand the difference between urgent and important
•    Always talk to your clients… regularly
•    Fix features that aren’t fun asap.
•    Deal with problem children
•    Don’t send anything sloppy.

At the beginning of a project, spell out what’s important to the team.  They’ve done a lot of work with Dreamworks and Activision, so they focus a lot on those projects that the humor is really important; this is what’s important to our client and this is what’s important to our studio.

Lesson #6 – Surprises are bad
Always give publishers fair warning of what’s happening, good or bad.  If suddently forecasts change, then give publishers as much heads up, and never wait until the last minute.  This applies to internal development too.  Make sure everyone is open and honest and don’t be afraid to share bad news to one another.

Even good surprises can be bad!  They were working on a licensed movie title and it was getting off to a slow start, so they created a new level to go at the beginning of the game and they were really proud of this change, submitted it, and the client was really upset by this was because the publisher thought the timeliness of the project was the most important.  In retrospect, it seemed as though the developer was focusing on the wrong thing.

Lesson #7 – Manage your projects like a portfolio
The more you diversify, the more likely you are to branch out, you’ll then be able to keep your stronger talent.

Lesson #8 – Leave time to think
You have to plan your studio’s future – you have to think 6 months, a year, two years out.  You have to be really honest about your evaluations – you have to plan these guys’ future and make sure they’re staying at your company.  If you’re always fighting fires, it’s hard to find that time.

•    Suggestions
o    No meeting Mondays/Fridays
o    Close the door; get off-site with your managers for some time
o    Make time for lunch
o    Talk to people you haven’t talked to before
o    If you think you have too much going on, you do. Fix it.

Embrace the insanity.  There’s always going to be a little bit of craziness, no matter what.

Q&A

Question 1: Making small games have very tight schedules and you’re dealing with licenses as well, how do you find yourself managing the publisher and licensor and still successfully hit the launch date?

I think identifying what’s important to the project and share that list with the publisher.  Get a document early-on and prioritize; this is what we feel is really important and that will help to avoid hassles from appearing later.  At least every other-day conversations with these people.  Foster better relationships with these people.

Question 2: I’m curious if your specialists were on your engine team?

Our engine is more of an open-source project internally.  Various projects contribute to the engine with what they think it needs.  If a game needs a tool, that game team builds it, and if it’s really useful, then it rolls out to the rest of the team.

Question 3: How do you set up your hierarchy? One team per project?

Griptonite has dedicated teams, we don’t want to shuffle people between projects.  We’re a big enough studio that we have dedicated art, tech and design leads.  Making sure that riskier projects have a senior producer on the project to mentor some of the younger producers

Question 4: Are you working on next-gen?

Because we’re part of Foundation 9, our specialty is handheld, and we’ve blurred the line into downloadable and cell phone.  But because the handheld industry is so large, we’re focusing on making great handheld games.

Question 5: Everyone’s job to make the game fun, but how do you prevent too many cooks in the kitchen?

Once a few weeks, we get everyone in a room and the producer is at the white board and writing down suggestions as everyone plays the games.  The producers are in charge with filtering that feedback to see if it’s an issue that needs to be fixed.

Question 6: How do you avoid taking on too much or too little work?

I think what we mostly do is that we’re very good at the beginning of a project focusing on what is really important and figuring out how many man-days or man-months are tied to that.  Then making sure that you re-assess the scope throughout the entire project and maintaining open communication with the publishers.

Question 7: When a project balloons out of control, what do you do?

We send in the troops to find out exactly what happened.  Sometimes it’s pretty easy: the game is too short, how can we fix it?   We exist as an independent developer, so we have to evaluate the scope and have honest discussions with our collaborators and be honest about the risk.  Early on, people used to just throw people out of QA at producing handheld games, but since the handheld industry has grown, more and more focus has been placed on making handheld properties great.

Question 8: What’s your list of worst practices for a company?

The worst thing you can do is having a reputation for being late or making crappy games.  We try to make really strong games and we’re never ever, ever late. If we abandoned those ideologies, we’d have a hard time getting work.

Question 9: Can you talk a little more about the Fibonnacci time is split and how you go about carrying that out on projects?

We make sure that we don’t schedule down to the hour; we schedule something in days.  For something like the Spore Creature Creator, we divvied up the important features into multiple parts for whatever makes sense to the team.  It’s about making sure what’s the most important

Question 10: How do you manage information sharing and knowledge sharing across teams?

We’re just really good at sharing knowledge.  Bi-weekly meetings to share knowledge.  Dedicated background art meetings where people share their work.  It’s harder for producers to share since they’re generally very tunnel vision on their projects, but having senior producers to oversee them has helped a lot.

Question 11: It’s good when you’re in a team to play the game in their head.  How do you create the conditions to let that happen?

We have designers prepare mini-presentations to share what the game is about and we supplement that with visuals and diagrams.  Starting that discussion and getting people playing games that are similar will allow people to have a common knowledge base to discuss the game’s design.

Question 12: With such a large number of games and short cycles how do you prevent burnout?

Minimizing crunch.  It’s a very organic progress.  I hold my producers accountable – if there’s a crunch, they’re responsible.

Question 13: Do you have rough metrics for a certain amount of crunch that equates to time off?

We handle it on a one-on-one basis.  Sometimes people crunch because they’re really passionate about a game.  Other times it’s got to be on a case-by-case basis.

Talking from perspective of both developer and publisher.

Overview

• Request for proposal
• Purpose of the DDP
• Preparation
• Conducting the Evaluation

Areas of investigation

Questions

what to look for

• Examine results and generate action

REQUEST FOR PROPOSAL RFP

• Listen to what the customer wants – udnerstand what is really being asked
• Focus on answering the really difficult questions
• Innovate and show off your creativity
• Do not spend more resources than necessary – have a timebox with 3 or 4 people and examine what things would make the biggest difference in getting that project

EG:  had couple of weeks to make a proposal for hardware manuf – producer made a sample game in Flash – mocked up 2 new controllers – rigged up electronics – and could demonstrate how the game could be controlled.   Showed extra effort and ingenuity.  This helped to show us in a better light.  Unfortunately we didn’t get that project but it showed us in the best possible light.

PURPOSE

*  Interview – Attempt to decide what it will be like working together; determine if they are capable of making the title; verify their flexibility and creativity

*  Risk Assessment – eg. what areas are ground breaking.  We all go throught the proces to assess potential risks:  – project management, schedule,

*  Proficiency of management and team:

- The management team is critical.  90% of the projects I have seen shut down were because of poor management.

- Management abddevelopent team’s – experience, proecess/methods, philosophy;

- Do the leaders have in-depth knowledge of the disciplines they manage?

* Partnership – looking for long term so that the process doesn’t have to be repeated.

- It is in both parties interest to have a beneficial relationship

- Trust is critical and earned – if you’re hitting milestones you’re probably get left alone by publishers

- Everyone wants a great product

- Be true to your values and capabilities – evaluate the title and be honest about your capabilities

*  Personality

- how do they react to requests? this will tell you a lot about how they will react to chage requests during production

- Do they act on coaching and suggestions?

- How responsive are they?

* How critical are they of fedback

- Are there any inconsistencies on the team?

* Passion

- how does the developer feel about the license or property?

- What types of games to they play?

- How much passion comes through when talking to the team?

- Passionate teams make better products.

*  Publisher Preparation

- Request and read bos for all team members – key man clauses in contract for key team members are common

- Request and read documentation from the developer (Engine API, art pipeline, software engineering, asset management, codings standards, schedules and design docs etc.)

*  What games has the company created?

What games has the team worked on? – Cross ref team members to the titles credits

- What games have the individual teams members produced?

- How long has the team been working together?

- How many games has the team produced?

DEVELOPER PREPARATION

- Prepare the team before the visit to help ensure things go smoothly

- Due diligence process meeting to discuss what to expect

- Inform team of the porject and discuss how you can leverage existing experience, tech etc

- Generate innovative game design ideas to discuss with publisher when they arrive

*  Know who you are interviewing with

* Determine how your staff tech and creative teams can best fill the brief

Conducting Interviews

- Talk to all key team and manageent members

- Talk to some of individual team members too

- the length of eval should be inline with the cost and scope of the project

- be professional, casual, friendly and informal – you are building a positive relationship

EVALUATION

*  Areas of investigation should include:

- Production/proj management:  previous project performance; scheduling practices and tools; what dev method; milestone deliverables; risk management (project risks, proposed solutions, contingencies, contingency trigger)

- Resources – company size and number of teams; team size; breakdown by discipline; outsourcing experience and process; time the core team has been together; experience on all target platforms.

- Risks – performance/FPS; memory; integration; localisation; networking; load times/streaming; TRC’s; load/Save game; Multi-processor support; memory latency; installation (PC); Compatability (PC)

- Design/Creative – Design process; docs and organisation; similar genre games analysis/experience; how do the tools support designers and artists workin on the same level at the same time; tuning tools and technique; game design ideas and innovations; differentiating factors from other developers.

Art

- Time to integrate assets using tools

- Art pipeline – how long does it take to iterate on assets?  how long does it take to create and integraTE NEW ASSETS?

-Use of standard tools – Maya, 3DS Max

- Style and Art Direction

- Quality – animations; models; environments; effects; in-game cinematics; movies; audio

TOOLS

- Version control (perforce, subversion, CVS, Sourcesafe

- Engineering tools – compile tools; build tools, editing, performance; documentation

TECHNOLOGY

- Animation; AI; AI; Audio; Character Rendering; Environment; Lighting & Shadows; Camera; Physics

Networking;

Asset Management

- How are builds gated so the asset creators are not disrupted by code changes?

- What is the/art check-in process?

- Version control of raw and game art and audio?

- Alpha, Beta, GMC changes

FInance – a sticky subject ..

- What is the burn rate?

- What is the average cost per man month?

- What is their general and admin ( G&A) overhead %?

- Cash reserves?

COMPLILING THE RESULTS

- Have a standard template that evolves as you conduct more DD evals

- Write up a report right after conducting the DD while it is fresh in your mind

- Score the developer on a standard scale in all areas (experience; art; technology; design , finance, resource etc) this will help you compare them with other developers.

FOLLOW UP

Follow up with the other side to determine next steps the week after the visit

Send any additionally requested docs and/or materials

OTHER THOUGHTS

- Take it seriously – millions of dollars are at stake

- Get lots of sleep the night before

- Ask other partners about working with them but try to get both sides oft he story

- show off your capabilities and sell your team

- work with existing partners to make them better rather than searching for another – better the devil you know

- be honest about your capabilities and needs

- if you are a developers try to work with multiple publishers if you have the teams for it

- Scale the proecess to match the scope of the project

- Your mileage may vary, each publisher is different

Kathy Gibson, Director of Human Resources, Threewave Software

I spent the first 20 minutes of Kathy’s talk frantically trying to post my previous blog entry, so I missed the fun interactive portion of the workshop. Oops! I did gather and complete the various personality tests toward the end, though, and learned I am (drum roll, please)… an Expressive personality. Anyone I work with or spend more than 30 minutes with can tell you that, but for me it was a relief to have it validated with a handy graph and tally. I fall smack-dab in the middle of Dominance and Warmth on the grid. I want to know “who”, I value appreciation, applause and a pat on the back (so true), am relationship oriented and like to inspire others. At least this is what Bender tells me. I imagine the Futurama robot, but you should imagine Peter Urs Bender, author of Leadership from Within. 

What followed the personality assessments were strategies for managing and communicating with Analytical, Amiable, Expressive and Driver types respectively. Each person has different needs, values and motivations, as well as different levels of assertiveness and responsiveness. My notes on Kathy’s general insights into these personality types:

The Analytical Person: Wants to know “how” things work. Wants to be accurate, and to have accuracy from others. Values numbers, statistics, ideas. Love details.

• Strengths - Thorough, disciplined, persistent, diligent, cautious, takes systematic approach, always thinking.
• Weaknesses - Perfectionist, too rigid or demanding of self/ others, withdrawn, boring and quiet, reclusive, sullen, excludes feeling from decisions.
• Fears – Being embarrassed. Losing face. Tend to be introverted and hide their emotions from others.

I hope I am not doing a terrible disservice to Hansoft in my coverage. I have managed projects, though not using any software, and not using SCRUM methodologies.  My apologies up front for any ignorant statements. I was asked to blog this session at the last minute. :)

Demo of Hansoft by Patric Palm, CEO, Hansoft

Patric’s excited to finally be giving a talk where he can actually talk about his product instead of avoiding the subject.

 Premiering the next version of Hansoft for us today.

Flexible tool that can be used with several PM methodologies.  Allows mixing and matching methodologies. Customizable workflow and columns. Set access and restriction rules.  Easy to switch from one to another and share assets across methodologies.

Also has a bug database, with work assigned to people in the task database. Can function as workload and timeline for the whole company. Allows view of where people are allocated and which are over-or under-allocated.

Seems like it has a robust “find” function, that allows printing.

I’ll ask my friend Victor Meinert what he thinks after we’re all done here –

You can use Hansoft to delegate responsibilities. Delegation functionality allows managers to give tasks or groups of tasks to other team members, and that designates that member as a PM on that task set – allowing him or her to add tasks, delegate further, etc

You can use Hansoft either as a project manager with an overall view, or individual contributors (IC’s) can look at it as a prioritized task list.

When an IC’s Hansoft and workflow has been updated they’ll get an email. IC can update completion in real time and the info is communicated immediately to the team and management.

Outsourcing – view for outsource user can be limited

Bug tracking – lots of great functionality here, and it’s clear that including bug tracking in an agile PM tool is critical to keeping all the tasks on the same task list.

Document management – full version history and full version rollback – (Victor says: awesome) – not for full project version control, but great for GDDs etc. Customizable integration of document tools.

New stuff with 5.3:

More recent adoption of QA functionality has allowed further feedback on that module, so  there are more goodies coming in the future for that.

Pipelines and workflows: some studios messing with the QA part to use it also as an art pipeline tool. This functionality will have more abilities in 5.3.

Pipeline functionality: a user can view the pipeline, change it, and have all the changes and updates show in the task lists. Completion automatically opens up the next step.

Several types of pipelines can be set up in advance, art, sound, levels, whatever. Set up the template once and you can use it any time you need.

Tasks are grouped and nested together.

Pipeline tasks can set new workflows. Pipeline task editing seems very easy.                             

Many teams are struggling to combine the linear workflow of asset creation with the agile process. Hansoft allows that combination. Allows treating the backlog as an asset list.

End of presentation, beginning of Q&A

Q: A lot of team members struggle with the software’s complexity. Are there any plans to have a simplified interface, a team member client? A:. There are several ways to simplify the view, but you have to know how to do it.

Q: How collaborative is it? A: All live networked in real time, so several members can use it simultaneously. Works for small and very large teams.

Q: Are there plans for a higher level exec view? A: you can make a template, or data can be sucked out of hansoft to an executive dashboard software. There are a lot of v expensive but not so great BI tools out there, so we have

Q: Web access? A- no. Users typically ask for this up front,  and then realize that as they use the tool they don’t really need it.

Q: Print stories out of the backlog? A: Yes, but it’s a little complicated and limited. When previously prioritized, found that this became less important the longer you use Hansoft.

Pitched his bottle openers – “important to open the beer in a timely fashion.”

Victor says: Pretty impressive, he went to the demo last year and it’s obvious they listen to their users – lots of feedback is showing.  Interesting that it supports both waterfall and agile in the same product. Wonders: Does that take away from their engineers ability to make a better agile product? Supports legacy task based groups.  Allows the use of one tool, has a good intention, interested to see how it works.

Also great that it has backlog support, which a lot of tools don’t support. Also integrating the bug database is great because it exposes bugs as tasks. Brilliant. That consolidation has to be a demand for the future of this tech. Victor has been doing research on scrum tools for about 6 months now.

I hope you’ve enjoyed my notes. See you tomorrow for the Book Jam.

Respectfully Submitted,
Robin McShaffry
www.mary-margaret.com

Girl on G.I.R.L. A Call to Action
Speaker: Torrie Dorrell, SOE

Overview/Personal History
Torrie didn’t start out playing games as a child.  She started playing games when she first joined this industry.  She’d always played arcade games, never console, so she quickly became a gamer, but it was mainly for work.

Since joining SOE, she’s been getting more and more into MMOs.  She started by playing Toontown with her daughter.  It was all couched in kid-talk.  She found herself “helping” her daughter by leveling her toon after she went to bed.   Shortly thereafter, she started playing EQ2 and WoW and became a guild leader and hardcore raider.

There are a lot of points in games where she noticed, “Hey, a guy designed this,” and it’s not that it turned her away from playing the game, but it’s more that it’s a noticeable difference than if a woman had created it.

G.I.R.L.
When she first joined SOE, one of her goals was to embrace diversity.  In order for a publisher to really attain diversity, they need a diverse team on the development side.  Because of this diversity flag that she was holding up at SOE, Torrie put together a team of really passionate developers and started an organization called G.I.R.L. (Gamers In Real Life).

This org is not about women-only dev teams for women-only games.  This org is about making games for a really wide audience.  All it takes is to have a few key members on the dev team to steer the game towards a broader market.  As part of the G.I.R.L. initiative, they created a survey to explore what may be driving women to the game industry.

One of the major points to notice was that the perceived male dominance in the industry was a deterrent for women to get into the industry.

G.I.R.L. announced a scholarship at GDC 2008.  This was for students specifically at the Art Institutes.  Received 100 applicants and narrowed it to 9 finalists.   The winner received a $10,000 scholarship at Art Institute and an internship at SOE.  They chose Julia Brasil as the contest winner, and while the concept art wasn’t necessarily “girly,” but it definitely has a different sensibility.  She writes a weekly blog at www.girl.soe.com.

Free Realms one of the projects that they’re working on at .  Lots of various minigames and goals.  Racing, card games, cooking, questing, exploring, aimed at teens and tweens.  Guys on the team are talking about having pets pee on fire hydrants, etc.  Laura Lynne (sp?) suggested having players bathe their pets. All of the women were all about that concept, but the men on the team didn’t feel the same way.  There are lots of opportunities for women to contribute and balance out the male dominance in teams.

She’s challenging every team to match the $10,000 scholarship to award women to join the industry.  Hoping to start more scholarship funds and will be announcing this new scholarship fund during GDC 2009.
The goal really for this organization is to make it extinct in 10 years from now.  This organization shouldn’t be here 10 years from now; we shouldn’t need it.  The goal is bring more women into the games business and as our kids grow up, this issue should become a moot point with our efforts.  All we’re doing is broadening our demographic and bringing more people into this world of games.

Q&A
Question 1: I agree with you about training young girls and bringing them into the business, do you guys have an idea on how to recruit people who are already in careers?  What is the track for that, what are your ideas?

Courtney and Sarah do a lot of public outreach, so they’re growing the recognition for this org.  Internal HR is going to a lot of job fairs, but not just game events, they’re going to lots of campuses and people are cold e-mailing Torrie about how to break into the game industry.  Lots of umbrella women’s organizations that also do outreach.  And they have to be endorsed by the highest levels in the company in order to make these kinds of movements successful.  This all started with diversifying their games, and if you want to diversify your games, you need diverse teams.

Question 2: In Korea, more girls play games than boys.  In a studio in Korea, there are more women engineers than men.
There’s a much stronger crossover in Korean games of gameplay features that appeal to both boys and girls.
Question 3: One of the things that the IGDA has found is that, in teaching girls how to design, they’ll play the games the same way as boys, but if boys are present, they’ll just pass the controller to the boys.  But when they feel safe by themselves, they will design games such as shooters and such.  For some reason, girls lose interest in the elementary and middle school ages in the STEM categories.

The fields that women are interested in in the games business are design and art, not necessarily tech and engineering.  That plays out in the engineering field in general, which is heavily male dominated.  It really is about educating our kids that this field even exists.  The entertainment industry in general, it’s fairly small; it’s not this huge industry.  People don’t necessarily think that I’m going to make games.  They think that games are just there to play.  As more and more programs are developed at the college level, there will be more awareness that game design can exist as a career.

Question 4: Why diversify video game companies at all?

It expands the audience, which expands the players, which expands the sales, which expands the profits for the company.  The bigger the pot you draw from, the bigger the industry gets.

Contact info: skaplan@soe.sony.com

Studio Growth Cases

Three speakers each give a 20 minute session

Jason Coleman, Studio Technical Head for Big Huge Games

Big Huge Games has grown from 60 to 120 over last 3 years

· Start work on open world rpg

· Added a second team

A large number of new things came up over this period

Caught up with someone at a party that had worked for him and figured out that he didn’t actually realize who Jason was – the company had gotten to the point where people didn’t necessarily know everyone anymore

Historically, hiring was occasional – easy to integrate

Now hiring is more rapid so integration is more difficult and requires deliberate action

People can get lost depending on happenstance – where they’re sitting can make a big difference

Assimilating better is important

· Pay more attention to initial seating

· Actively pursue mentoring

· Codify more of the process

Documented processes and systems, kept up to date, which show pictures of key people to talk to about systems etc to make it easy on new people.

A lot of personal growth

· New roles at every level

· Entry-levels can feel insignificant

Helping people adjust

· Clearly define roles

· Give people appropriate room to grow

· Everyone can help mentor

Important to let people experiment and fail – even if it’s something that doesn’t look like it’s going to work when you analyse it.

The Second Team was setup

· Split out all over the place, in different offices and areas

· Less cool? Less important?

· Little momentum?

· Constantly raided for talent for top team

Instead, the way to set up a second team would be more like:

· Not the “b-team” culture

· Give sufficient personnel

· Collectively move to a new space

Problems on the big team

· Never enough information at the right levels

· Big disconnection from making a game

Reorganisation focused on “A more intimate big”

· RPG steering group re-organization

o Departmental representation

o Conduit for accurate information

o Can make forward progress

· Return of Daily Games – rotate everyone in the company through, get them to play the game and remind people of what we’re doing. Helps people see the big picture, stuff outside of what they’re specifically working on (etc)

Anticipating structure requirements, they implemented matrix maps and formalized the structure of the team

Departmental managers and project leadership is separated to ensure that each role is given appropriate focus which has really worked

There’s always something you can do better!

Things like company gatherings and RSS feeds help to bridge the gap between separate departments – sitting in cross-team groups or sitting in on specific team meetings to answer their questions about other areas, etc, helps.

Combat teams have been really successful with collocated cross-departmental teams

Core principals:

· Make best-in-class games

· Practice Intellectual Honesty

· Teamwork Drives Success

Shaun Himmerick, Studio Head Midway Newcastle

From Midway Chicago, been at Newcastle for last year or so.

Formerally Pitbull Syndicate ltd before acquired by Midway, now working on Wheelman

Massive growth!

Growth strategy – kept all the same systems, hired a lot of people, promoted a lot of people. Basically if it ain’t broke, don’t fix it.

Mistakes? All of the above.

· Didn’t account for change and growth

· Weren’t prepared for more people

· Not everyone was ready for promotion – art leads who were working with teams of 5 were now art directors.

Grew so fast that people didn’t have much buy in, people weren’t aware of what the point of the game even was.

Hiring a few people here and there resulted in having a much larger team without actually planning to so there were no systems in place to cope with that. The art director, for example, was also assigned tasks on projects…

Everyone in every position should be planning for their successor – someone should be able to slot in if you leave or get promoted. This isn’t something they had originally considered

Admit something is wrong or just “not right” – easy to just let things slide if you’re not willing to make big changes

Listen to the team to make changes

The goals of “making a game” and “making a studio” are different things – knowing which you’re trying to accomplish is important

Hiring someone because “there’s nothing wrong with them” isn’t necessarily going to result in the right fit – look for someone who is going to make the studio better off by being there, even if that takes longer (it will).

One driven person could successfully lead a small team but when there’s 100, you cannot effectively lead them all yourself. You need to lead a small team of leaders who each lead their own small teams to effectively manage an entire team.

Bottlenecks destroy schedules

There will be people in the trenches that are also leading, despite not having leadership as part of their role. Get them on your side, enable them to help drive the vision – get them to run a meeting, give them training and nurture that frontline leadership.

Despite not being a scrum-guy, Shaun implements strike teams and finds them very successful.

While confidence is contagious, so is lack of confidence (Vince Lombardi quote) – very true.

“The best executive is the one who has sense enough to pick good men to do what he wants done, and self-restraint to keep from meddling with them while they do it” – T. Roosevelt

Being the smallest midget is not an achievement

Kelly Zmak, President of Radical Entertainment

Recently laid off half of their staff as a result of acquisition by Activision Blizzard – this talk is about growth that preceded that

Having a workable goal was important – leveraging tech process and leadership, scale (breadth and depth), studio planting. All of these goals needed to match the corporate objectives or there’s no point.

What we do starts at “hard” and goes up from there – temper enthusiasm with reality, this is 90% sweat and 10% talent.

What worked?

· Hired 100+ people in 12 months (50% growth, from 220 to 320)

· 10% attrition rate over that period – the staff believed in what was happening

· New Leadership opportunities

· Middle management advancement (promotions)

· New people brought new ideas with them

Must find a way to make it fun, thrilling and fulfilling to ensure engagement.

Great success in hiring from Britain – the brits loved the Vancouver / British Columbia environment.

What did not work?

· Underestimated the cost (both real cost and opportunity cost), such as relocation from the UK

· The time it takes

Some people suck at interviewing – no matter how much training you give them. Some people just don’t like talking to people, which means you tend to leverage the same small set of people to interview. People that are suddenly spending a lot of time interviewing and not much time making games.

What did they learn?

· It’s hard to learn fast

· It’s REALLY hard to grow well!

· It’s BRUTAL to grow FAST & WELL!!

· Make sure your staff knows “WHY” you’re doing it – that doesn’t mean saying why, it means checking that people get it and doing what it takes to ensure that people do get it. Don’t assume they do just because you said it. CHECK.

· What you sell MUST be what you are – there’s no “bait & switch”, don’t trick people into a role as they won’t stay

· Know what you need, understand what you want

· Let the staff make the decision as to whether they want to be a part of what you’re doing by being honest about what you’re doing

· New people with new ideas – what a pain in the ass! All these new ideas take time to consider, don’t underestimate it

· Do not underestimate the cost of a bad hire!

You can embrace, you can resist or you can ignore change it but you can’t avoid it. Everyone’s involved in it. You have to be personally invested in it and your people need to believe that you are 110% behind it.

They never hid decisions or ramifications from their staff – honesty and open communication helped people transition.

Q&A session

Retaining top talent is about making your organization the place they choose to be – their role will be the same wherever they are so what about your culture ensures yours is the company they want to work for? That’s what you need to focus on to retain your best people.

Defining your culture is the first part of protecting it. Giving people ownership of an individual area helps to protect that small-team cultural buy-in even when your team is much larger.

Preserving your culture is not hiring anyone. It’s the antithesis of change. Culture should be dynamic, adaptive and a biorhythm – it has natural highs and lows, you don’t want it snapping between them but to have them is fine.

Outsourcing is an opportunity to flatten out the ebb & flow of internal team scaling. Radical have averaged 12% of asset production outsourced over the last few years. For them, it’s not about cost saving, it’s about flattening spikes and ensuring solid delivery.

Internal teams that define a tight vision for the product enables outsourcing asset production without compromising the product goals.

Outsourcing is a bigger and bigger part of game production as games move to larger, more open worlds that need more content – expanding the team temporarily is less suitable in the game space than it is in the movie space.

Promoting someone into management just because that’s the next step up the chain isn’t necessarily the way to do it – some people are better if they keep doing their role so look for ways to provide advancement opportunities that don’t result in your people suddenly having to do something else

The common thread in these discussions for Shaun was open and honest communication with their teams.

Giving people opportunities as a group and seeing how people handle it is the best way of identifying future leaders – don’t tell people this could happen, simply enable it and see who stands up.

Employee evaluation should be less about numbers and more about assessing the employee’s impact on the team and the project; we’re doing stuff that people have often never done before so comparing to a preset scale has limited relevance.

Employee evaluations, the formal ones, should be a summary – there shouldn’t be any surprises in there. Problems and praise should be raised in real time or at least far more frequently. Having epic scary meetings once a year basically ensures real, good communication can’t happen.

Sharing tech across teams during development is harder than pulling cool stuff out of a finished title and putting that back into a shared tech base that other teams can start from. Sharing tech in real time across disparate teams and products is hard / not a good idea in practice.

If the only tool in your toolbox is a hammer, everything starts to look like a nail – it’s important to have lots of tools in your management toolbox.

Curt Schilling, Founder & Chairman, 38 Studios/ Pitcher, Boston Red Sox

Disclaimer: I totally geeked out when I learned that Curt Schilling would be speaking at this year’s IGDA Leadership Forum. I’m a long time Boston Red Sox fan, WoW player and Instance podcast listener, but aside from that I also admire Curt’s approach to gaming and game development. So this was a real treat. :)

Curt Schilling realized he was in a different industry for sure when he entered the Marriott ballroom and a kind and courteous IGDA volunteer handed him a blue speaker evaluation form, asking that he rate the talk and the effectiveness of, well, himself. “I can do it now if you want…”

When Curt first opened Green Monster games, now 38 Studios, he was sure the video game industry and consumers were going to love the company because he’s a gamer. He was going to go out and get R.A. Salvatore and Todd McFarlane and naturally “bowl the industry over.” But 15-20 minutes after their press release hit the wire, Curt found two bulletin posts on the brutal truth box we know as the Internet. First post reads: “R.A. Salvatore, isn’t that the “M-Fer” that killed Chewbacca?” Ouch. Second post: “Is this the Hindenburg all over again?” It quickly became clear to Curt that this whole business of making games wasn’t going to be exactly what he thought it might.

What Curt did know was that as a pro-athlete and team player for over 20 years, he was going to bring a different perspective to the role of leadership in game development.

Baseball analogies abound, but in the spirit of pulling out juicy kernels of leadership knowledge, I’ll summarize that according to Curt the difference between a baseball team and a team of game developers is… fashion. You have your superstars, your solid players, and your “asshats” (Curt’s word, heh), but at the end of the day it comes down to the people and the passion they bring to their collective effort.

What follows are my notes from the talk, hopefully relevant and readable. Enjoy!

MVP Leadership:

• Intent is not to be better than everyone else, not diminishing the challenge, but understanding it is a serious challenge.
• We start out with a lot of myths. Far from reality – Curt had a dislocated tendon, showed gnarly photo of his ankle 4-5 hours before the game. It bled during the game, and a lot of people in the media made it out to be that that was the reason we won. The reality was that Curt was a member of a team of 25 guys who had immeasurable talent and passion for the game, and the leader they had to motivate them.
• Success is about the makeup of the leader. Leadership is 1% talent, and 99% about managing great people who make up great teams. To truly accomplish anything of substance as a leader you must get your people, your family to CARE WHAT YOU THINK!
• A lot of testosterone in baseball, you shower with guys and become close. (Giggle.) But you get to know people intimately and you spend more time with your teammates than your family. This is true in games, too. Without the showering, I suppose.
• You want passion above anything else, because within passion lies all of the things you want in your customers and your employees. So how do you make people care? The core piece to being a good leader is making people care about everything. Passion is the most influential and valuable currency in business and in any leader.
• Band of Brothers, in the interviews before each episode he would listen to them talk, and the common theme in addition to bravery and valor was that Dick Winters was a man every one of them would have died for. Major Winters absolutely understood people, and life and death relied on maximizing results from people.
• “I know speaking from experience, I played for guys I didn’t care much for. And they didn’t get less effort from me, but there was different feeling at the end of the day. People act and react differently when you are invested in them.”
• This industry creates an immense amount of passion. Love and hate. Short of passion you can accept many things, almost anything really except APATHY. Slide shows Fitz Cartoon: “I was trying to figure out which is worse, ignorance or apathy… then I realized I don’t know and I don’t care.” People making the products are every bit as passionate about it as the people buying the games. But it starts at the top. You have to find the touch points in your employees.
• The sheer volume of entertainment product is staggering. We’re not competing for dollars anymore, we’re competing for hours and minutes. “There’s a piece here from a leadership standpoint that is important to me. It is without a doubt the thing I see the least amount of, but is one of the most important pieces… Apathy is Kryptonite to Superman, Venom to Spiderman, and the Red Sox to the Yankees.”
• Apathy is our mortal enemy. Apathy is a sure sign someone’s chiseling you, your product’s, or worst of all your company’s tombstone.

Customer apathy = product death
Employee apathy = your death, under achieving payroll burdens
Either can = your company’s death

• How do you make people care?

Above all else, being genuine and being honest. We are a society BUILT to look for the “but” and “if” in a situation. Care. Concern for your people, their families, their lives. Attention on THEM and to THEM. Respect for their needs/ worries.

• Micro managing is a killer for any company. Top of the food chain shouldn’t be micro managing down to the bottom. Trust the people you hire, give them the space they need to perform, and trust that they will. Accountability piece that you want to instill in the people that manage your company. “I can’t stand people that make excuses. It is something that absolutely drives me crazy.”
• There is a self honesty piece that comes into play and you need to honestly evaluate who and what you are, what your strengths and weaknesses are and make sure people understand that it’s okay to make mistakes and not be the smartest person in the room. You want to avoid being the “Last Supper boss”. Avoid being the last to know that you are inept. 
• Leadership is making sure people know you trust them, they can act on initiative since everyone is acting in the best interest of the company, and they aren’t afraid to make mistakes. At their old job making mistakes = getting fired…
• “Curt Schilling used to be the best game designer in the world, but now… he has crazy ideas that cost too much money and man hours”, but he has a team of people that he can trust to set him straight when he’s out of line. Every day is education. Don’t have a problem being the dumbest guy in the room. Listen to people and what they know and what they do and give them the respect and recognition they deserve. Exchange of ideas, getting people to buy into your vision and your passion is something you have to work on every single day.
• “I’m passionate about this company and these people and what we do as a team, as a family. That passion piece will not be there if you have a group of people working from a position of fear, of mistakes or failure.”
• Analogy – “early in 1993, struggling after being in first place for the most of the year and we talked about playing from the mindset of being afraid to fail, worrying about what it was going to be like if I didn’t do well. The fear of failure was a powerful thing for me, and finding out how people were going to act and react to that is an incredibly powerful tool.”
• People operate from the standpoint of, I make a mistake, I don’t hit a milestone, we lose our jobs. As a leader, you need to instill a mental process for people to understand what making mistakes mean.
• Mistakes – every single mistake made is a good one. Except: Mistakes due to stupidity/ ignorance – your fault for putting your employees in a position to fail. And mistakes due to malicious intent, their fault for being bad people.
• Heard the term “egregious error”, went to Webster and found out that meant “really big deal”. Process mistakes correctly and make sure they never happen again. Mistakes are nothing more than a lesson, an opportunity to learn.
• It’s hard in this world, especially now, to make people believe they are more important than the product. Your people, your teams, your leaders, they are the product at the end of the day. Don’t they have to be more important? And if you’re not conveying that to them, you’re fighting a losing battle. There are ways to operate to make them understand that.
• If you fire people for reasons other than performance, good luck. Performance should be the primary motivator.
• Two of the key reasons so many people make mistakes are: 1 – Paralysis by analysis (data overload to the point of inactivity) – You get so much information about a task, you can’t perform. Just let me do what I do – like getting 9 different ways to throw the ball. 2 - Fear of failure. These reasons go by the wayside with FOCUS and TRUST.
• Only possible way to fail something is to quit. Everything else is a loss. People should trust that those daily losses aren’t going to cost them their job or get them an ass-chewing. Helping them understand that when one of these two things come into play, the answer if to focus more granularly on the task.
• In the business world: Asshats = bad eggs. The asshats who suck don’t get fired, they get relocated to another team to keep sucking. What if I’m on that new team and I have to deal with the asshat? Asshats are “the Suck”. The best teams will fail, miss milestones and deadlines, make subpar work, when they have an asshat. No matter where you put them, no matter how you put them. 
• You cannot avoid hiring bad eggs. – Reality. You cannot avoid having bad eggs. – Myth.
• “At some point I’ve got to hand off that whole process” and trust that the leaders of my company are acting in my best interests. Have created an environment where if the company and the team members aren’t your priority, then you are not going to fit. If your focus is your paycheck every two weeks, then you won’t be around long.
• You want people to think they are the best at what they’re doing. Comes from accomplishment and achievement. Self evaluation, being honest with yourself. Great to think you’re the best coder on the planet, but if your code is breaking the game over and over, you might need to be honest with yourself.
•  Criticism. Have always been comfortable with hearing criticism. “Hard for me not to know I suck because it’s on ESPN all day. But I’m finding it very challenging to explain to people the difference between positive and negative criticism.” Criticism is built around helping them become who they want to be. A big deal to have that skill set.
• Traits not necessary to be a great leader – muscles, money, volume, IQ. Most important skill a leader can have, evaluate your talent.
• Draft and develop = Cheapest investment, longest return and the result is an employee who “gets you”.
• Spend in the market = quickest return maybe, far shorter timeline, and the result is an employee who you have to “make fit”. They have to, because you’re paying them. This industry is notoriously the latter.
• Have to identify strengths and weaknesses and put them in the best possible position to succeed. It’s an incredibly challenging thing. How do you get better at it? Comes down to investing in people, and investing in people for Curt was telling every person he’s hired, “You’ll never work for someone that care more about you than I do.” This is the core of 38 Studios and Curt Schilling.
• The “List”:

Passion
1a) Integrity
1b) Accountability
1c) Communication
1d) Care/ Concern
1e) Honesty with yourself
1f) Trust

• You have to care more about them than anyone they’ve ever worked for every single minute of every single day of every single week of every single year.
• Level 5 leader, best greatest guy on the planet who can do anything. Biggest reason they can’t, their affect on people. People react differently to me. As cool as it is, it’s a handicap. It stops people from being their talkative, imaginative selves. “Accepting that and understanding that redefined to me what I bring to the table. I wasn’t going to draw, code or write a story, but I could lead.”
• Is, has and always been about people. If you do not care more about your people than someone else they’ve worked for, you have an ex-employee. At 38 Studios, “if they leave and go somewhere else, it’s going to be for reasons outside of our space.”
• You build empires with passionate people that care about each other. Anything else is just a place to draw a paycheck…

We’ve got another fine squad of volunteer bloggers who’ll be taking notes during each session, and posting the notes (more or less) in real-time. This was massively appreciated last year, and we’re super appreciative that these fine folks have stepped up to handle live-blogging the Leadership Forum this year.

• Alan Bell – Sidhe Interactive
• Alison Beasley – Lincoln Beasley PR
• Andy Jih – Schell Games
• Ben Hoyt – Paramount Digital Entertainment
• Brett Douville
• Jason Schklar – Jason Schklar Consulting / Initial Experience
• Karin Groepper Boosman – Aspyr Media
• Lulu LaMer – 2K Marin
• Michael Lubker – Axelo Development Corporation
• Mike McSchaffry
• Robin McShaffry – Mary-Margaret.com
• Zhenelle Falk – 1st Playable Productions

Thanks!