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.

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.

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.”