Advanced PrototypingChaim GingoldChris Hecker

You Are HereHave IdeaAsk QuestionsPrototypeDevelopSell It

You Are Here 2Have IdeaAsk QuestionsPrototypeDevelopSell It

Answer questions Find upside & downside3. Persuade and inspireWhy Prototype?

Prototypes do not generate ideas from scratch!

Talk, Build, Talk Again, Build More

Bigger Projects, Too unwieldy

Sinking Ship Cant Do it

3

Problems & solutions

Metrics

Cheapagilelight

Falsifiablemake a claimtestabletestedlearn

// First hello.group GreetFirstContact{ // Warm welcome dialog { motive Default ; text "Welcome!" ; button { text "I come in peace." ; do RelationshipPlus ; do SayDialogFromGroup ReactToIComeInPeace ; } ; button { text "Prepare to die." ; do RelationshipMinus ; do SayDialogFromGroup ReactToThreat ; }; button Bye;

} ;} ;

Relevantgeneralizable

Surprisingfeedbackupside and downsideinspiring

Persuasivefuntangiblecleardisruptive

Cheap + Persuasive=

Org Chart

Football Plays

Design Doc=Prototype?

DocumentPrototypeFaithScienceReally CheapCheapStaticInteractiveBoringSexy

What is your Question?Question

Q:Question 1Can we make a fun social game between characters?

Q:Question 2Is Leg UI concept user friendly, powerful, and hot?

Q:Question 3Can rolling around with a sticky ball be compelling?

Q:Question 4Heres a design doc for a game.Is it going to be fun?

StartingSo you want to write a prototype?

Step 1:dont

steal it

fake it

rehash it

Step 2:permissionvs.forgivenessif it takes less than two days, just do it

Step 3:fail early

Step 4:gather reference material

DecompositionDecomposition

Division 1

Division 2

Division 3

Division 4

Bad Puzzle Pieces

Connections

Connections Cut

In/out?Whats in?

Whats out?

Account for connectionsConnections

CE

CE Mapcreature editor

CE Map 2(Animator,Skinner,Painter,Stitcher)creature editor

Part MorphingTorsoParts

Object CompositionObjectComposition

TorsoTorso

EconomyEconomy

LegLegs

constraints + freedoms + assumptionsprototyping:whats really important?

Economics

on the characteristics of your prototypeon the coupled characteristics of your prototypewhere do you spend your resources?interactivityrobustnesshotnessusabilityfundurationbeautyperformancevarietyagilityvelocity

qualitycostquality vs. cost curve is [very] nonlinear

qualitycostquality vs. cost curve is [very] nonlinear

codecontentvs.

costquantityprototypes

codecontentemotionalautisticdead bitsinteractive

scaredalien

codecontentyouarestillcluelessyouunderstandyourproblem

Only spend code where you need understanding;throw content at the rest.

Programming

agility&velocityWhats important?

Whats not important?robustnesseleganceoptimal code

Be LazyComputers are fast and HUGE

Dont commit to an abstraction!Code influences your mental model.Must stay agile.

Dont commit to an abstraction!toolkit vs. frameworkrecombinantcompositionalimmediatedelicatessenstaticcontrollingretainedprix fixe dinner

Tower of Tuningscriptinghotloadingdata drivinginteractive editorrecompiling

CollaborationCollaboration

Designer-ProgrammerCollaboration

Designer

and

ProgrammerCollaboration

FeedbackFeedback

SciencePR v SciencePRDemoTest

DemoDemoHarvest Good IdeasBuy-InPersuade

Correction

Correction2

TestTestingValidationObservationsQuiet!

Archive It.Repeat.Testing

the end

This talk is concerned with the Research phase, how to prototype, but somewhat with asking questions, as well.Ask Questions, Experiment with solutionsPrototypes dont generate ideas, they validate them.They generate upside, and suggest ideas, however.How do you tell a good prototype from a bad one?Does your prototype suck? Is it awesome?These are like economic indicators: they mark success and failure. What qualities should you look and strive for?Should take less effort than the real thing, in all kinds of dimensions.Youre going to be wrong a lot, so your failures should cost little, and you can have more of them.

agility - Incorporating suggestions and changes should be trivial.Everyone involved ends up with a low friction attitude towards divergent ideas.If most changes take no time to make = good.If youve got to wait weeks, schedule lots of tasks, discuss endlessly, something is up.

light - Small number of people are involved. Some of the best prototypes have only one programmer (at a time).If youve got a large team involved, producers scheduling and tasking, this is not light, and something is wrong.

You can prove bad ideas are bad, and good ideas are good.Implies a certain amount of focus. If its not a focused experiment, its hard to prove anything.

make a claim - Good prototypes make some kind of claim: it would be easy to use if we used only the left mouse button.Why are you writing a prototype? You must want to validate or disprove some concept.If you cant articulate criteria for evaluating the result of your prototyping work, you should double check your intentions.

testable - Does your prototype let you put something to the fire?Can you get a truth value from it, somehow?Will something be clearly working or not working?Otherwise, you are escaping to abstraction land, if everything works in theory, Id like to move to theory.

tested - Good prototypes are tested.Youve got data, people have played it, and you can explain why the design is this way based upon data.Beware of the prototypes that are only played by their creators, if at all.

learn - People learn things from good prototypes?What did you learn from yours?

Prototypes are cool but only if they inform the actual project.They must be relevant to the real thing.

generalizable - What you learn and validate in the prototype should also be true in the real thing.There should be actual payoff in the project.There are multiple ways things could generalize in: wholesale incorporation into the product, code or art reuse, design reuse, or as a reference point.

If you dont have any of these, then youve solved the wrong problem.Good prototypes surprise you somehow. They do something unexpected.

feedback - Good prototypes elicit lots of feedback. People come up to you and tell you what they love and hate.The best case is that you have to get people to leave you alone, and shut up, because too many people want to comment.If getting feedback is like pulling teeth, something is up.

upside - Lots of unexpected accidents should happen, both good and bad. These should be encouraged and harvested. Lots of great features should have been added in for free along the way by engineers, artists, designers -- everyone involved.If you discover lots of good ideas and hidden problems along the way you hadnt intended for, thats a good sign.If everything proceeds as planned, and no exciting discoveries or pitfalls are made, something is up.Youve found hidden problems, and hopefully been able to address some of them.

inspiring - You should want to write more.Discovered problems and solutions should beg for more experiments.

Good prototypes are cool and convince people of things.

fun - Were in the entertainment industry.If youre prototype isnt sexy, cool, exciting, or entertaining, youve got a problem. This should be true of everything from tech to art to gameplay.If nobody wants to play or see your prototype, or lacks enthusiasm for it, something is up.Even tech; Chriss early skinning prototypes convinced us he was smart and on the right track, even though it took months to see how what he was doing would really come together.People should be excited about what youre doing, want to help, give feedback, and work on it. They should rant and rave about what they wish it did and what they love.

tangible - Unlike design docs, which are neither interactive nor tangible, prototypes should clearly communicate and make real whatever they are getting at.People should take one look and get it. The design, the concept, the fun, the interface, the whatever. Best prototypes require minimal explanation.Mirror neurons should be firing when people watch it being used. They should know how it works and what it is. Oh yeah.

clear - Unlike design docs, which are neither interactive nor tangible, prototypes should clearly communicate and make real whatever they are getting at.People should take one look and get it. The design, the concept, the fun, the interface, the whatever. Best prototypes require minimal explanation.Mirror neurons should be firing when people watch it being used. They should know how it works and what it is. Oh yeah.

disruptive - If a prototype changes peoples minds, its good. If nobody is convinced of anything, then eh.If you win an argument about design verbally, you should be scared. If you convince people of things with a prototype, you should feel good.

So, one of the implications is that creative power and authority is not hierarchicalSince its so easy to make stuff and convince people of things, creative power, if things are going well, we claim, should be distributed.

The more cheap and persuasive your prototypes, the more of a meritocracy you should have. So, really good prototyping equals creative democracy.What if we think of design docs as prototypes?

Design docs are these lightweight things that we use to help us understand our designs, and persuade people of things. SoLets compare the 2, and see which tastes better. cheap - Docs are cheap to write -- drawing pictures and writing words is always going to be faster than typing in code. Thats why we doc in the first place, its more efficient than making the real thing. Good prototypes are also cheap, though.

interactive -Its an interactive medium. So prototypes give you something tangible thats far more relevant to what youre making than a doc. Maybe if we were writing a book, the doc would help us get a sense for what were making, but were making games.

sexy - You have to hold a gun to peoples heads to get them to review or read a design doc. Prototypes sell themselves. Nobody begs you to let them see the new version of the design doc, unless its your producer.

faith - You can test prototypes. You cant compile and execute design docs. So, its almost impossible to know whether a game will be good from its design doc. From a prototype, you can have a pretty good sense.

Katamari Damacy would have never been made, had Keita Takahashi given up after people rejected his proposals. Once they played the prototype, and saw with their own hands and eyes what he was talking about, they were his forever, and he got his game made. The power of persuasion and falsifiability, and cheapness.

Behind every successful prototype stands a good question, a clearly articulated problem to solve.

Before we get into how you go about breaking down a prototyping problem and building a prototype, we need to start with the question. Without a good question, youre wasting your time.

Where do you need understanding? Thats where you target your questions and prototypes.

Chaims sense is that the right question is half the battle. If youve framed the problem well, the rest is easy, like science.Bad!

First, prototypes dont generate ideas, they validate them. Also, they generate upside. Theres no idea to try out and test here. Basically, theres no idea to falsify.

What idea do you want to try out? Then come back and build something.

Its testable: build it, and put people in front of it. Do they need help? Is it cool? Does it accomplish what we want it to?

Sounds good.

Build it, put people in front of it: do they think its cool?

Its an idea. But its not focused enough to be tractable. You basically are asking for the whole game to be built, which isnt really a prototype. You must deconstruct the features.

How do you decompose a big problem into smaller tractable ones, while staying relevant to the whole vision? Stay tuned for our next section Decomposition.how to startmeta prototyping there is always a cheaper waysteal it web game, board game?fake it maya, photoshop, or flash mockup oceans maya rig block demorehash it skinproto metaballs, constraints, 3d paint, particle paint, etcsteal it web game, board game?fake it maya, photoshop, or flash mockup oceans maya rig block demorehash it skinproto metaballs, constraints, 3d paint, particle paint, etcsteal it web game, board game?fake it maya, photoshop, or flash mockup oceans maya rig block demorehash it skinproto metaballs, constraints, 3d paint, particle paint, etcoceans rule: if it takes less than 2 days, just do it.be incremental & clear on your goalsimagine & visualize goal behavior and feelemotional tone music, art, etc.mock up screenshotsiggraph papersexternal code & data librariescan be overlapped with real work if youre being subversiveHow do you break your big problem down into little ones that can be protoyped?

Prototypes are best applied to small problems, where they can make quick traction. What about big problems?You must be able to account for what has been placed outside of the bounds of the prototype, and justify it.

What are you assuming will work? What are you providing for in the prototype? This hinges on your prototypes relationship to other parts of the design.Ok, so Im going to show you some examples of prototypes from the spores creature editor. Weve done about a million of them, but heres a few key prototypes that illustrate how to account for relationships between features, and what happens if you screw up.

Ok, so Im going to show you some examples of prototypes from the spores creature editor. Weve done about a million of them, but heres a few key prototypes that illustrate how to account for relationships between features, and what happens if you screw up.

Ok, so Im going to show you some examples of prototypes from the spores creature editor. Weve done about a million of them, but heres a few key prototypes that illustrate how to account for relationships between features, and what happens if you screw up.

constraints thing things you must dofreedoms the things youre allowed to changeassumptions things you dont need to bother withconstraints are your friendswhats really important - taking a trip and have to pack, moving to a smaller houserazor you can use to be fastwill talk about how to get quality on the cheap laternow that weve got an idea of what were trying to accomplish, we start to talk about how to accomplish itthe economics of prototyping are the razor you use to figure out where to spend your precious resourcesthese are characteristics of your prototypelike a character sheet for your prototype, how do you spend your finite number of points?the characteristics are coupled, not independentthis is our list, you might have a different one, but one thing our lists will share is...per-characteristic quality/cost curvereally want to use the 80/20 rule here and do 20% of the work to get 80% of the payoff, the knee of the curvemight have hard constraints, minimum quality barmight have hard constraints, minimum quality baran economic decision...what are the characteristics you want to spend resources against, and which is the better way to get the quality bar you require

cant we all just get along?quantity, not qualitycode can be graphic designed, but much harderthis is the key...when youve written the code, you understand something, where displaying a bitmap is completely lacking in semanticsguy in jungle, gdc demo?you can set landmarks, but you dont understand

because code is so expensiveemotional stuff often requires contentdefault is to use contentagility you dont know what youre doing, by definitionvelocity you are probably wasting your time, find out fastrobustness needs to last long enough to get answerviolate SE norms intentionallylibrary dev - have to use before you reuse, refactor out, slightly higher bar, still in service of agility and velocityis your mental model?whole point of prototype is to keep agile mental model to answer question, find upsides, & gain understandingstlmfc

not compiling is the laziest!

...and some stuff thats hard, if its important to keeping agility and velocityIn the same body.We think this will be more common in the future (as it was in the past).You have to spend less time talking, because its yourself.This has the potential to go off the rails, though, since theres nobody keeping tabs.However, most of you are probably in this situation at work.

Keep in mind: A huge goal of prototyping is to generate upside, and find hidden opportunities.The programmer is not the designers compiler; whoever is programming can find 100 times the upside than the designer, since they are into the details. Designers who over-specify, smother, and destroy 2/3 of the good ideas available to them.

Moreover, the programmer can focus the designer, by bubbling up requirements and doing requirements elic. From the designer, which helps the design gel.

Miyamoto: programmers should understand the goal, and help find the answer. The designers job should be to set the problem, and work with the programmer to try and solve it.Demo is PR, test is Science.The more you talk and ask for suggestions, its persuasion and PR. The more you observe, the more you learn about whether your idea works or not.Learning.Inspiring.

You want to do it at your or their desk, so you can watch their first reaction, and see if they smile, laugh, get excited, or do nothing at all. Or frown.

If you use new ideas, your work improves. If you use other peoples ideas, then they are yours forever.Validation: full circle back to the question and hypothesisQuiet!: Youre not trying to convince them how cool it is. Youre trying to find out how cool it is.Observations, not suggestions. 2 kinds of data come to me when we do user tests on the CE: feature lists and observational data on what players did. Only the latter matters, because this is science, and we need to process the raw data, and form plans based upon it.Validation: full circle back to the question and hypothesisQuiet!: Youre not trying to convince them how cool it is. Youre trying to find out how cool it is.Observations, not suggestions. 2 kinds of data come to me when we do user tests on the CE: feature lists and observational data on what players did. Only the latter matters, because this is science, and we need to process the raw data, and form plans based upon it.