The following content is provided under a Creative
Commons license.
Your support will help MIT OpenCourseWare
continue to offer high quality educational resources for free.
To make a donation or view additional materials
from hundreds of MIT courses, visit MIT OpenCourseWare
at ocw.mit.edu.
[SIDE CONVERSATION]
PROFESSOR: Before we go into the test, there's a couple of tips
that I want to give you.
Some stuff for you to take notes on.
But you don't really have to do this today.
At some point of time in your prototyping
you might end up getting stuck.
And you're not quite sure what to change.
So [? if I ?] would have been asking you to do things
like amend rules, right?
Replace rules with other kinds of rules,
kill rules that aren't working.
Some other ideas that you might want to play with,
if there is a resource that's currently limited you
might want to make it unlimited.
And vice versa.
And I'll say the number of steps that you can move,
the number of currency that you have, make it unlimited
or you make it limited.
It could change the way how your game feels a lot.
[INAUDIBLE] with other players.
And maybe even sort of messing up the types of decisions
they get to make, or maybe even the order
that they get to make it.
Could be something as simple as reversing
the order of who goes next.
But it could be more significant,
like forcing another player to make
a move that they don't want or taking away their options.
You can mess with the play order.
Like I said, you could reverse who goes next, but then also
the order in which certain rules get played out.
Could be something that you should be always trying
to do with your own rules.
Do your rules has to be executed in the same order?
In fact, the answer is no.
You can probably rearrange your rules
and get a very different effect, even
without writing a new rule.
If you're going to deal with numbers at the prototyping
phase, generally you don't want to be making small changes.
You don't want to be making 10%, 20% changes to your numbers.
You want to be doing something like changing things by 50%,
maybe doubling it, maybe halving it.
At least change of 50%, but multiplying
and dividing by two.
This will give you a much better sense
of whether that change to the numbers
is going to be the thing that's going to solve your problem.
If you get the numbers wrong but the changes go in the direction
that you want, then you can dial back the scale of the change.
Maybe you have a variable that was too drastic,
but it started achieving the things that you wanted.
And so, OK, all right.
Maybe sort of halving that number
would make it 25% of that number.
As an exercise, once your prototype is already
starting to work one trick of trying
to simplify your prototype is to try
to identify the very few rules that
are necessary for your prototype to work.
So you take all the rules out and introduce rules,
then, one by one.
The rules that you've already got.
And you try figure out that bare minimum.
That's finding the core, and that's
the core of your prototype, that's
the thing that you might want to carry into a larger game
project in the future.
Finally, throw away.
In fact what I'm going to encourage you,
at the end of this class today, is
to make a completely new prototype from scratch.
For each person on your team.
But I would suggest as an exercise is just
go back to the mechanic idea and see what else you can
do with that mechanic.
Whether it's stealing from other people or hidden information.
All of your prototypes right now probably test one kind of way
to interpret that mechanic.
What else [INAUDIBLE] completely different ways
to interpret exactly the same mechanic.
Make a prototype.
You know, spend about half an hour to an hour.
You only spent an hour on these prototype so far,
and a lot of it was figuring out what mechanic
you were working on.
Right?
So try to build something, test it with me
or test it on your teammates.
It would be great if you had a weekend meeting, for instance,
to go into that meeting with as many different prototypes
as you have team members.
You just play each other's prototypes
and have a conversation.
These are all different ways to approach the same problem.
So [INAUDIBLE] basically and make something new.
And then revisit what you've got at a later stage.
So that's some tips for you to do in the following week.
But in the next hour this is what
I'm going to be asking you to do,
and that is to do a play test.
Now, there are many different ways to do a play test.
This is probably what they're going to be doing today.
How many of you have made a game that's really
only for one person right now?
All right, no one's made a multiplayer game.
So you're probably going to do a play versus player test.
That's fine, that's what we asked for in the assignment.
You can do multiplayer tests for cooperative and competitive
games.
You can have [INAUDIBLE] player tests where
everybody gets the same set of rules
or different sets of rules.
So the [INAUDIBLE] symmetric or asymmetric.
The trick with multiplayer play test
is that they tend to be very, very loose.
It's very hard to do, say, a really, really
tightly controlled experiment.
One thing that often happens is that when
you have people playing a game and later on in the semester
you're going to just give them a set of rules
and they're going to have to interpret it.
They might interpret it in a way differently
from how you intended.
They may come up with--
they may negotiate the rules based on things
that they don't quite understand from the rules
and come up with a solution that wasn't necessarily
what you expected.
Communicate openly.
They'll talk about, like, hey you know is that rule--
do you really want to move there?
You know?
And things like that.
One thing that you can do is to have the person who is actually
running the playtest, someone from your own team
where you're trying to get information,
you will explain the rules to people at the beginning,
in early playtest.
In later playtests we just hand them rules.
But if they come up with house rules,
if they decide to interpret your rules in a certain way,
I would actually suggest not stopping them right away.
Let them play out a little bet.
Because they're giving you a free iteration of your game
that you may not necessarily have considered,
and may end up working.
It might work out great.
But then you cannot--
But once they play a little bit of that
and then you get a sense of how that works, take note of that,
make sure that you know how that is supposed to work out.
And then explain the rules.
No, actually.
I'd like you to try playing it with the rules interpreted
this way, which is the way how you actually designed.
And then you can get a second player test
of the same group of people.
Let's see, what else.
This is absolutely necessary for multiplayer games.
You are going to have to do that.
[INAUDIBLE]
If you go to other classes and make prototypes
for digital games on paper, you are
going to need to do this sort of playtest.
So you're going to get some experience doing
that right now.
I do want you to know that there are a couple of other ways
to do playtests.
The Wizard of Oz test where somebody--
the person that you're inviting to play test
is basically playing with somebody
who's on your design team, and that person
is playing the computer.
This is very good for prototyping
a digital game, especially a single player digital game.
You can be very constrained on what information
you provide the player.
In fact, you don't necessarily even
need to provide a player a full set of rules.
You can just say, this is the computer screen,
your finger is the mouse, or something like that.
Or even giving them a simplified keyboard.
Up, down, left, right or something like that.
That's how you communicate with the computer,
you just push, or you point, you click
by touching on the screen.
The trick is to make sure that the player is--
that you're not giving clues to the player about what
the computer is thinking.
The computer should be communicating primarily
through the things that a computer will show you.
Either images, sounds, maybe numbers that change.
But the computer doesn't actively explain the rules.
If the game was supposed to explain the rules,
you should have little prototype pieces of paper
that you can hand out in front of the player.
Now say the player is completely confused and you think,
this would be a good time to introduce a [INAUDIBLE] test.
Oh crap, I actually didn't have a [INAUDIBLE] test
prepared ahead of time.
Well, grab a Post-it pad and write it down,
slap it in front of the player.
Now that's [INAUDIBLE].
So you can be--
this can be a very, very deep prototype.
You can actually test a lot of different things in a computer
game on paper this way, depending
on how much time you want to go into producing something
to be tested.
You don't to spend too much time because, remember,
prototypes are supposed to be disposable.
They're supposed to be fast and cheap.
So it's a Wizard of Oz because it's like the Wizard of Oz.
It's somebody behind the scenes, manipulating
what you're seeing.
But there's no actual computer there, it's just you.
You have to be very, very constrained
yourself when you're running a test like this.
You don't want to deviate from the algorithm
that you set up for your computer, if at all possible.
So if you've got some tough AI character,
you shouldn't be making human-like decisions
for that AI.
You should come up with a bunch of rules for that.
This is another kind of prototype that you can do.
Not for today's exercise, but later on in the semester.
If you decide to do a live action game
or if your games really about just a person
walking around in a space, even if it's going to be
like a top down board game.
You could just do a live action game
where you just have people actually walking
around a real space.
You explain the rules to everybody who's involved.
Maybe your game's for five people
and you explain the rules to all five people before the game,
and then you let them go.
The problem, of course, is that they're all
going to interpret those rules their own way.
And because they may be physically separated,
they may not be negotiating with each other
and as a result may be not even playing
with the same set of rules.
That's also a problem.
It's difficult to monitor what's happening with a lot of people
walking around a space and doing their own things,
like individual agents.
But it's really, really fast to prototype because you may not
even need to write anything.
You may not even need to produce any sheets of paper,
you just tell people here's a bunch of rules.
It's like setting up a schoolyard game.
And so if your games about, here's
a character moving around a space
or if you're [INAUDIBLE] trying to actually make
a live action then this is something that you can also do.
This is just as valid a prototype that anything
that you're doing with paper and cardboard.
So here are the rules.
There's going to be people who are going to play.
I think we have five teams.
One, two, three, four, five.
Right?
So that's a little tricky.
How many of you have two player games?
AUDIENCE: Ours has two to four.
PROFESSOR: Two to four.
How many of you have three player games?
One, two-- three to four.
[INAUDIBLE] four.
And how many players?
Four.
Yours is a four player game.
OK.
So there's three, three.
Yours is three to four.
AUDIENCE: [INAUDIBLE]
PROFESSOR: Oh, actually.
That's a good idea.
OK, all right.
So we're going to grab one more MIT Game Lab staff member
to come in and will help test whatever team is not
getting a chance--
that doesn't have a team available to test.
We'll probably jump in on this game.
So can I just check the two teams on my right.
You're both three person games?
All right, you test each others games.
And then this group here, the two to four player games
will test each other's games.
OK?
So you're going to test one game.
[SIDE CONVERSATION]
So, to clarify.
You're going to test one game, and they
are going to shift over and test the other teams games.
We're not going to do it simultaneously.
OK?
People, I'm not done yet.
I'm not done yet.
OK.
So we're not going to test games simultaneously.
You're going to actually--
we're going to test one team's game at a time.
So, say, the two groups on my left.
If you are testing your four player games,
we're going to play one groups four player game first.
Then everyone's going to move over and play the other game.
And the reason for that is because the team
that designed the game, even though they're not playing
the game, has a job to do.
Someone's got to be the facilitator, sometimes.
In a Wizard of Oz test that person
is often also the computer.
and that person's got the job of explaining the rules, right?
Everyone else has got to be an observer.
You should have a notepad, you should
have something that allows you to take down notes really,
really fast.
You should be like writing down everything you can
about what you're observing.
In particular, keep an eye on the faces of the people
who are playing the game.
It's too easy to just get mired and try to record everything
about game state.
It's more interesting to--
it's more important to also pay attention
to whether they're engaged or whether they get confused,
whether they're being frustrated,
or whether a particular game interaction--
what's interesting to them.
You can tell a lot just by looking at someone's face.
So, the observers and the facilitator,
once you're done explaining the rules really
shouldn't be talking all that much.
In fact, once you get onto the later stages of prototyping,
when you have written rules, you shouldn't be talking at all.
You should be leaving it to the players
to actually figure out the rules on their own.
And the reason for that is you don't
want to bias your results.
You don't want to accidentally suggest good strategies,
for instance.
Saying that no, you really want to be moving this first.
Well, maybe you should make that a rule instead of making it a
suggested strategy.
So take that out--
One's taking notes, practice being as quiet as possible.
This is a small room, it's very resonant.
It gets pretty loud.
You can have a discussion after class is over
or after the two play tests are over about what you recorded
and we can discuss what you're going
to do with that information.
OK?
So I think the three of us will be playing this game.
And you'll need to explain to us the rules and take down notes.
All right?
If you need note taking material,
there's plenty of pads.
[SIDE CONVERSATION]